Content area
The main goal of this scaled-down XML architecture is to reduce the overhead from parsing so your application's performance improves. It's flexible for XSLT processing, too. Say you need to buy another processor or server for your XSLT processing. This XML model would let you take the cheaper way out, off-loading XSLT processing-where XML files are transformed into HTML-onto your HTTP server or the client browser instead of buying new hardware and using Java resources.
Full text
SOAP isn't always the cleanest integration model for your applications. Sure, the W3C's Web services architecture has become the de facto approach for getting Microsoft Windows- and J2EE-based applications working together. And you can use the IBM zSeries mainframe server or a similar platform with the Simple Object Access Protocol's XML-based Web services to integrate your intranet architecture.
But your network response time can suffer and CPU usage can spike when you retool your old COBOL-based OLTP applications to Java: If you re-engineer your legacy order-entry application as a SOAP service, it can require as much as 100 percent more CPU use and degrade your response time. And this setup is not as efficient as using Java applications, either.
That's when an alternative to SOAP-based Web services makes sense. One option is Sun's J2EE Blueprints, but this J2EE design pattern's heavy reliance on objects can drag down the throughput of your transactions. Here at QVC, the retailer for which I work, we're deploying a simpler cross-platform XML application architecture-sans SOAP. This XML architecture requires few objects and can be implemented easily inside a Java application or servlet.
Client- vs. Service-Side
XML indeed is becoming the lingua franca among large, disparate, distributed computing environments. Applications receive and generate data in XML format. The integration model we implemented at QVC is a two-tier, client-server model rather than a three-tier one. As with the SOAP RPC model, XML data is sent through the network. But unlike SOAP's, our setup doesn't contain an envelope packed with encoded information for the message and header. The processing overhead with SOAP's XML payload is the W3C architecture's main trade-off: Time-sensitive transaction processing applications don't need that kind of payload baggage.
You can configure the XML-based intranet model to simply send and receive XML messages over the network. Because it uses cross-platform components, such as XSLT (Extensible Stylesheet Language Transformation) processing for creating HTML pages and J2EE application servers, this architecture gives you plenty of leeway in how you configure your processors. That's a big plus. In most organizations, the driving force behind application hosting and configuration is the total cost of ownership-the cost of building, hosting and maintaining an application.
The main goal of this scaled-down XML architecture is to reduce the overhead from parsing so your application's performance improves. It's flexible for XSLT processing, too. Say you need to buy another processor or server for your XSLT processing. This XML model would let you take the cheaper way out, off-loading XSLT processing-where XML files are transformed into HTML-onto your HTTP server or the client browser instead of buying new hardware and using Java resources. Putting XSLT processing on an HTTP server is the best option when you want mass distribution of XML documents. It's the job of the server to transform them into HTML for browsers. The client-side approach, however, is a little trickier. If you prefer running XSLT on the client, your browser must support XSLT 1.0 or XSL-WD, as Microsoft Internet Explorer 5+, Netscape 6+ and Mozilla do. And your client machines must have at least a gigabyte of memory.
IBM's zSeries, meanwhile, is optimized for I/O-intensive, database management systems and queue parallel-processing applications, so it really doesn't make sense to use this state-of-the-art server for HTTP Web processing with static pages, GIF and XSL files. Let the mainframe handle database calls and place your XSLT processing on an HTTP server or client.
The heart of this XML-based application integration architecture, however, is the J2EE application server that processes all incoming XML requests and integrates with a database. This server handles Java Server Pages (JSP), Enterprise JavaBeans (EJB) and Java Servlets.
The WSAD Way
So how do you design and implement this reference architecture? We use IBM's WebSphere Studio Application Developer 5.0.1. WSAD is IBM's core-application J2EE interactive development environment. Although it's built on the open-source Eclipse 2.1 (the core framework for the XML-based intranet architecture), it's targeted at J2EE application development on IBM's WebSphere Application Server. Eclipse, which is aimed at independent software vendors, includes the runtime modules in which plug-ins are loaded and run. These plug-ins are for XML parsing and similar tasks. (I once used Eclipse on a BEA WebLogic development project-it can work on a non-IBM platform.)
In general, the XML reference architecture is similar to the JSP Model 2 Architecture. The client application makes a request to a controller servlet, which processes the request and sends the response to the client in the form of an XML or HTML message. But JSP Model 2 sends a response in HTML page format only, whereas the XML architecture responds in either XML or HTML. JSP is purely server-based, so it can't off-load the XSLT processing, either.
The XML architecture, like most business application tools, is primarily for getting and setting data in a database management system with Internet technology. It uses SQL statements to define not only the data to be retrieved or set into the database, but also for the XML structure and basic XSLT style sheet that's used in creating HTML pages. That's where the WSAD wizard comes in (see "Generating SQL Using a Little Wizardry" page 76).
"XML Data Processing" (facing page) shows the core business logic for processing XML data within the Web application. The EmployeeServlet receives the request from the client browser and forwards the request to the SQLToXMLds object. The SQLToXMLds class, which is bundled with WSAD, provides database connectivity and key JDBC Resultset mapping to XML messages. If you want to insert, update or delete data in the database using XML, you use an XMLToSQL class.
The SQLToXMLds class provides database connection pooling to the Web application, which can boost an app's response time by reusing existing connections to the database rather than initiating a new connection. Most J2LE enterprise applications require connection pooling.
Like most Web applications, the XML model we use sends parameters and receives data from a database. A request is sent to the servlet, which invokes the SQLToXMLds object. That object then integrates with a DBMS, and HTML is sent back to the client browser.
XML Lite
So if SOAP is too heavy for your application environment, try this lighter-weight XML model to integrate your existing applications with J2EE-based ones. It reduces network traffic by using only XML over HTTP on an intranet. It places parsing, a big culprit of processing overhead, on the most efficient platform so your application performs better.
The catch is that this architecture requires not only J2EE application servers, but also newer browser versions if you want to do your XSLT processing on the client instead of on the server. But it's worth the effort to ensure that your converted applications operate efficiently.
Frank Teti is senior architect at QVC. Previously, he held senior-level architect positions at Cambridge Technology Partners, BearingPoint and CSC. He can be reached at [email protected]. Post a comment or question on this story at www.nwc.com/go/ask.html.
Copyright CMP Media LLC Nov 25, 2003