home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam    

Book HomeJava and XSLTSearch this book

4.3. XSLT and EJB

Now that the options for web tier development have been examined, let's look at how the web tier interacts with other tiers in large enterprise class systems. A typical EJB architecture involves a thin browser client, a servlet-driven web tier, and EJB on an application server tier. Figure 4-7 expands upon the conceptual XSLT model presented earlier.

Figure 4-7

Figure 4-7. XSLT and EJB architecture

This diagram is much closer to the true physical model of a multitier web application that uses XSLT. The arrows indicate the overall flow of a single request, originating with the client. This client is typically a web browser, but it could be a cell phone or some other device. The client request goes to a single servlet and is handed off to something called RequestHandler. In the pattern outlined here, you create numerous subclasses of RequestHandler. Each subclass is responsible for validation and presentation logic for a small set of related functions. One manageable strategy is to design one subclass of RequestHandler for each web page in the application. Another approach is to create fine-grained request handlers that handle one specific task, which can be beneficial if the same piece of functionality is invoked from many different screens in your application.

The request handler interacts with the application server via EJB components. The normal pattern is to execute commands on session beans, which in turn get their data from entity beans. The internal behavior of the EJB layer is irrelevant to the web tier, however. Once the EJB method call is complete, one or more "data objects" are returned to the web tier. From this point, the data object must be converted to XML.

The conversion to XML can be handled in a few different ways. One common approach is to write methods in the data objects themselves that know how to generate a fragment of XML, or perhaps an entire document. Another approach is to write an XML adapter class for each data object. Instead of embedding the XML generation code into the data object, the adapter class generates the XML. This approach has the advantage of keeping the data objects lightweight and clean, but it does result in additional classes to write. In either approach, it is preferable to return XML as a DOM or JDOM tree, rather than raw XML text. If the XML is returned as raw text, it will have to be parsed right back into memory by the XSLT processor. Returning the XML as a data structure allows the tree to be passed directly to the XSLT processor without the additional parsing step.

Yet another approach is to return XML directly from the EJB components, thus eliminating the intermediate data objects. Chapter 9, "Development Environment, Testing, and Performance" will examine this in detail, primarily from a performance perspective. The main drawback to consider is that XML tends to be very verbose. Sending large-text XML files from the application server to the web server may be less efficient than sending serialized Java objects. You could compress the data, but that would add processor overhead for compression and decompression.

Regardless of how the XML is generated, the final step shown in Figure 4-7 is to pass the XML and stylesheet to the XSLT processor for transformation. The result tree is sent directly to the client, thus fulfilling the request. If the client is a browser, the XSLT stylesheet will probably transform the XML into HTML or XHTML. For a nonbrowser client, however, it is conceivable that the XML data is delivered directly without any XSLT transformation.

Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.