The drive has begun for a new generation of Internet commerce architectures. The stimulus is coming from organizations building customer-oriented e-tail sites and business-to-business applications. New architectures are needed to accommodate both sets of requirements. Java's move into enterprise software development is also a major step toward the development of these new applications. With the XML revolution, major vendors and organizations have agreed on XML as the standard for information exchange. This standardization also requires a change in the way we develop Java-based Web applications. Java Servlets, the part of enterprise Java responsible for interacting with HTTP requests, should be able to communicate with any type of delivery channel such as a customer browser, a PDA/mobile phone or another Web server. With XML as an intermediate format, you can take data from any source and deliver it to any device.

Suppose you have a Web application that provides an online pizza inquiry and order service. You want to deliver this service to a mobile phone, PDA and/or Web browser. Another supplier - a business partner - may be required (order distribution to multiple suppliers) to make specialized pizzas. Since each client device has specific formatting requirements, the same data can't be sent to everyone. The mobile can understand only WML; the browser can render only HTML; and the business partner's Web server requires plain XML data. If you're developing separate servlet (Web application) versions for each delivery channel or using DCOM/CORBA to integrate the different supplier networks, then your architecture needs a major change - XML over the Internet.

XML has gained widespread popularity as a way to represent data in a portable, vendor-neutral, readable format and to exchange data between different systems. It's effectively turning the Internet into a middleware of Web applications in which XML is the spoken language.

This article assumes that readers have a sound understanding of XML/XSL and Java Servlet concepts. I provide a small pizza order and inquiry example to demonstrate how we can use XML to develop Web applications that serve any client device or delivery channel. The code for this article can be downloaded from the XML-J Web site. It requires a basic understanding of the Servlets, XML4J and XSL code level.

XML Processing in Java
Several XML parsers/converters are available. I chose the IBM XML Parser for Java and the Lotus XSL Processor to format information. (Both are available from the IBM alphaWorks Web site, www.alphaworks.ibm.com.)

Traditional Web Application Development
A restaurant owner wants to provide an online pizza inquiry and order service over the Internet (Web browser). Since you know how to work with servlets and Java, you design a domain object model and write servlets with validation- or order-processing logic. In this case I've come up with Pizza, PizzaType, Order and Customer domain objects. You can have any other classes in your case as required. I've come up with one inquiry - a receiver servlet that generates the HTML dynamically, contains information about different pizzas and can be read from a database. For the sake of simplicity I've hard-coded the two pizza objects (see getAllPizzaz () method on the XML-J Web site). The getAllPizzaz () method returns an array of Pizza objects. Each instance of these objects forms a row in the HTML table and the Pizza types for that object are displayed.

The output of the Pizza inquiry can also be used to submit Pizza orders to the server. I haven't generated any HTML to submit orders; I leave it as an exercise for the reader. I assume that whenever an HTTP request is made to the AddPizzaToBasket Servlet, it contains three parameters (Pizza unique name, size and quantity). An order object is constructed against these parameters and added to the session vector that's maintained as a session variable. The request to the CheckOutServlet should have the customer name and credit card number. The customer object is constructed against these parameters and a processOrders () method is called. This method is left empty so you can do anything you want in it. The code for these servlets can be found in Listing 1.

New Business Requirements from Business People Suppose you're an architect. The restaurant management talks to you about WAP technology, which would enable pizza inquiries and orders on mobile phones. They want this functionality available as early as possible in order to remain competitive. You have a problem: the WAP-enabled mobile phones can understand only WML and all your HTTP servlets are responding with HTML.

The Unstructured Approach
You develop a separate servlet for the new WAP delivery channel. All problems are solved - you copy and paste all the business processing logic from the HTML-generating servlet and replace the HTML syntax with WML syntax.

Another approach: the HTTP header contains information about the User Agent, which you can retrieve from the HTTP header in the servlet code. Make two separate functions: one for Web channel response generation and the other for the WAP channel response channel. Call them from the doGet () function that's based on the User-Agent value in the HTTP header (found in Listing 2).

XML-Based Structured Approach
Why have I called the above approach unstructured? A good enterprise application design can absorb new business changes with minimal effect and scale to n tiers as the business expands.

As an architect, you'll foresee that the business people will come to you again with new requirements. Today they require a WAP-enabled application, tomorrow - B2B. Look at the unstructured solution again; it'll create problems in the B2B-based architecture extensions since the data is in the form of Java objects. These objects require RMI to travel over the wire. The other end also needs RMI infrastructure, and the solution won't work behind the firewall. The business needs a global data carrier - HTTP and language- and platform-independent data structures - such as XML.

Imagine the scalability of your structured solution. Your Web server will deliver plain XML to any other B2B partner over HTTP (the Internet). This solution works for n tiers of business-logic processing in which each tier is from a different party and resides behind the firewall. XML data is independent of any client device so the delivered information can be formatted/parsed to be used in any application (HTML, WML, PDAs, ATMs, FAT/custom applications). The business-logic-generated XML data is used by all delivery channels. Only one copy of business logic is used by all types of clients. Any change in the business rules is automatically applied to all channels.

XML in Inquiry Applications
The restaurant owner wants to serve mobile phone clients. The information for both distribution channels (Web and WAP) is the same, but each requires different formatted data. Here XSL comes into action. It has the ability to convert XML data into any other suitable format as required by the delivery channel (see Figure 1). The business logic to extract information from the data source remains at one place, the same servlet can serve multiple clients, and information for each of them can be formatted using XSL (found in Listing 3). All the WML tag code is tested with Nokia WAP toolkit version 1.2.

XML in Order Processing
You've just seen XML usage in the information delivery, but what about information processing? The order object is constructed whenever the request is submitted to the AddPizzaToBasket servlet. The vector of the order is maintained in the session. The hit to the CheckOutServlet retrieves the vector from the session and processes the orders. However, we want a scalable design that distributes an order to multiple suppliers who process it in an optimal manner. These suppliers may reside behind firewalls and possess different IT infrastructures. XML over HTTP can play a significant role here. The order's DTD is distributed to all suppliers and XML is sent as the parameter in the HTTP request. The response also contains the result in XML, as this will be a B2B message or transaction.

While I was writing this article, a friend asked, "Why are you using XML to send the data to the other Web server over HTTP? Why not use the simple form field/value parameters?" I agree. This is true; a simple field/value pair can do the same task but this approach is useful for simple form data submission. What would happen if the orders have complex structures made up of multiple interrelated parameters? Where will the structure information about the data be maintained, or how will you relate one parameter to another? If you use the simple field/value parameters, the HTTP request handler code at the other partner's server should have the necessary information about the interparameter relationship. Any change in the parameters will require code changes in all the receiving Web servers. This would be a bad design from a maintenance point of view. In the case of XML the change requires only an update in the DTDs, which will be distributed to all suppliers, but the code for input validation or data extraction remains as is. Listing 4 shows the code.

It's a simple process to send XML data as form data over HTTP to the partner's Web server. The response is also received as XML data. In addition, I've developed order and order acknowledgment DTDs that validate the structure of submitted or received XML data. To keep the examples simple, I've hard-coded the DTD reference paths in the XML data or document. You may want it to be separate but I'm a bit lazy!