XML and Content Delivery: When SOAP Just Won't Do

Client- vs. Server-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 my orgainization 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.

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").

"XML Data Processing" 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 J2EE 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 his organization. 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.

Here's how to use the IBM WebSphere Studio Application Developer (WSAD) Wizard to generate SQL. From the WSAD tool's data perspective view, select the WEB-INF/databases//statement folder. Right-click on the statement folder and create a SQL select statement. Once the statement is completed and tested, save it to the statements folder.

After creating the SQL file within the WSAD data perspective, create an XML file that saves the results from a SQL query. SQL lets you make an XML schema or DTD file that describes the structure of the XML result; then you can use the schema or artifact within a J2EE application. And a basic XSL file gets created, too.

An XSLT processor, such as Xalan, expects an XML file and an XSL file (that is, style sheet) to be passed as parameters. The two files are then placed into memory using an XML parser, such as Xerces or Crimson, and transformed into HTML pages.

The wizard also generates a query template file that makes XML documents dynamically from the SQL query (it must have an extension of .xst). To generate .xst files, right-click on the "person" statement the SQL wizard made and select "generate new XML" (see screen below). The wizard gives you options for specifying mapping patterns, generating schema definitions, generating a template file and selecting an output folder.

Once you've tested your query and output XML documents, you can create them dynamically when running your application within the WebSphere Application Server or Apache Tomcat. To do this, save your query in a template file.The template file, which includes an SQL query, is passed to the SQLToXMLds object via a parameter, the (SQLToXMLds) object can then be invoked by a servlet (or an EJB).How XML and XSL processing works:

1. The browser submits a page. An HTML page submits a form request (i.e. ) and sends the request to the doPost() method on the servlet.

2. The servlet invokes a local protected method. The doPost() calls the runQuery() method and passes along the response object.

3. The objects used to contain XML and used for XML writing are created.

A ByteArrayOutputStream is installed in a PrintWriter object.4. An object for JDBC ResultSet and XML parsing is created. The SQLToXMLds object is created with an object that contains the SQL statement and database information.

5. The object used to contain XML is sent to the SQLToXMLds object. The PrintWriter object gets set into the SQLToXMLds class.

6. Data is retrieved from the DBMS and mapped to an XML String object by invoking the execute method. The SQL statement is executed.

7. The JDBC ResultSet is stored in a String object. It's converted into a String object.

If client-side XSLT processing is required, then only the above steps would occur on the server, and the remaining steps below would occur on the client or HTTP server.8. The objects for XML presentation, HTTP response and XSL processing are created.

9. The object used for the XSLT transformation is created. A Transformer object is created with the .xsl Source document, and an object with XML is processed.

10. The server sends the response to the client. The HTML response is passed back to the client that initiated the doPost().