Summary
J2EE, as a multitier enterprise application framework, currently remains incomplete by relying on HTML as its presentation layer, limiting the target audience largely to Web browsers. In this article, Eoin Lane proposes an open source replacement for the J2EE presentation layer by building an XML-aware application server with a fully operational end-to-end solution. He presents a case study of a car rental system and analyzes the various layers of the J2EE architecture. The solution ensures target-device independence by dynamically producing XML data, which then gets postprocessed through the Cocoon pluggable Java presentation framework. The solution consists of an application server based on open source technologies from Apache, jBoss, and the W3C.

Today's organizations' rapid moves to e-business bring new demands on defining flexible systems architectures. Systems need to be powerful, scalable, robust, and, most of all, capable of meeting new business demands. With that in mind, although more and more organizations are adopting a multitier, Java 2 Platform, Enterprise Edition (J2EE)-based application server architecture, they rely on HTML for the presentation layer. This prevents them from fully benefiting from the flexibility the distributed, multitier J2EE framework can offer. XML's Web publishing capabilities are key to solving this architectural shortfall.

This article proposes a replacement for the current HTML-based J2EE architecture presentation layer with a dynamic XML content layer. Through a case study, we'll see an XML-aware, open source application server within a fully operational end-to-end solution. At the heart of the case study resides Cocoon, a servlet from Apache that provides a pluggable Java presentation framework used to present XML content in a variety of formats, on demand.

The situation
J2EE defines a standard for developing multitier enterprise applications. J2EE simplifies enterprise applications by basing them on standardized, modular components, by providing a complete set of services (persistence, security, transactions, and so on) to those components, and by handling many details of application behavior declaratively, without complex programming. However, the architecture's presentation layer is primarily HTML-based, thus limiting the target audience largely to Web browsers. Tomorrow's audience will be much broader, what with a variety of new devices about to revolutionize how we send and receive information. As such, it's imperative to decouple content from presentation logic and become independent of our intended audience's devices. XML is the solution.

XML's Web publishing capabilities are possible using XSLT to transform XML documents into other textual documents. These target documents are often XML-based languages themselves (with HTML serving as a notable exception as it is based on SGML). As a metalanguage, XML can also produce other Web languages such as:

• XHTML (for Web browsers, WebTV, and soon WAP devices)
• WML (a language for describing two-dimensional graphics in XML)
• SVG
• MathML
• VoxML (for voice)

XSLT can transform an XML document into any one of these target languages. Once we've expressed the solution in terms of XML, we can leverage it using XML's sister technologies to produce powerful, media-aware Web application that will remain invariant to target device changes.

Case study
The case study develops a software application to automate a car rental company's various processes -- reserving, renting, and returning a car. Our objectives: analyze, design, and implement the car rental agency system and build a scalable system capable of targeting multiple end user devices (Web browsers, WAP -- Wireless Application Protocol -- phones, Web TV, and so on).

For simplicity's sake, we'll implement just one use case: reserve car. Other use cases such as modify/cancel reservation, return/rent car, or maintain car could be similarly implemented.

Under the reserve car use case, the customer first calls the reservation desk to make a rental reservation. The rental reservation agent (RRA) takes the customer's name and queries the system for a match. If the customer is new, the RRA takes the customer's information and enters it into the system.

Then the RRA requests information regarding the reservation -- start date, duration of reservation, and the type of car required from the customer. Once entered into the system, the RRA checks to see if the customer's requested car type is available for the required time period. Keep in mind that other auxiliary requirements for additional information on reservation, overbooking, and vehicle availability could be added later.

After giving the customer a reservation confirmation number for future communication, the RRA calculates the amount chargeable to the customer for the terms of the reservation so that the customer knows what the rental cost will be, up front. At any point during the conversation, the customer may choose to terminate the interaction. In such a case, the reservation is canceled, but the customer information is kept should the same customer call again.

Set up the container environment
The project employs two open source containers: an EJB (Enterprise JavaBeans) container called jBoss and the Tomcat servlet container from Apache. Tomcat includes the Cocoon servlet to make it XML aware. The instructions for setting up Apache, Tomcat, and Cocoon can be found at the Cocoon Website with install cases for Unix and Windows 2000/NT. jBoss now comes with Tomcat embedded in it and can be obtained from the jBoss Website.

The servlet container: Tomcat enhanced with Cocoon
We'll employ Tomcat as the servlet container for this project. Tomcat, developed by the Apache Software Foundation, serves as the official reference implementation for the Java Servlet 2.2 and JavaServer Pages (JSP) 1.1 technologies. This article uses the stable Tomcat 3.2. Tomcat 4.0 (based on Servlet 2.3 and JSP 1.2 APIs) is currently in development.

Since it is based on the Servlet 2.2 API, deployment occurs with a war file -- a Web archive file (similar to a zip or jar file) used to bundle together JSP pages, associated JavaBean classes, servlets, XML files, images, and XSLT files. Since Tomcat coupled with jBoss is in essence a bare-bones application server, it makes sense, when they run on the same machine, to run them in the same JVM, which can speed up the response time by a factor of 30.

Cocoon, a 100% pure Java publishing framework also developed by Apache, relies on new W3C technologies (such as DOM, XML, and XSL) to provide Web content. Even though Cocoon is just a servlet deployed inside of Tomcat making the servlet container XML aware, it represents the backbone of our project. Cocoon allows the clear separation of content and style using the XML/XSLT paradigm.

The EJB Container: jBoss
jBoss, an open source EJB (1.1 compliant with some 2.0 support) application server, incorporates most of the features found in a high-end application server. Because jBoss employs hot deployment for EJB jar files, deployment is as easy as dropping an EJB jar file into a deployment directory. jBoss also leverages Java 1.3's dynamic proxies features to provide dynamic compilation of subs and skeletons. Further, though not available yet, clustering capabilities using JINI technologies will soon be included.

For our project, we'll use jBoss 2.0 (with Tomcat embedded). Version 2.0 includes integration with JMS (Java Messaging Service) using SpyderMQ. JAWS (Just Another Web Storage) delivers container managed persistence for entity beans, while Minerva manages pools of database connections.