XML for Java Developers
Dr. Jean-Claude Franchitti
New York University
Computer Science Department
Courant Institute of Mathematical Sciences
Session 5: XML MOM Application Server Framework
Course Title: XML for Java Developers Course Number: g22.3033-002
Instructor: Jean-Claude Franchitti Session: 5
XML MOM application server frameworks are emerging as important integration architecture patterns for developing applications that create/send and receive/process XML. This handout looks at the design of an XML MOM application server framework and how it simplifies the task of writing XML applications.
First, let's distinguish XML MOM application server frameworks from something most of us are already familiar with -- Web servers. A Web server responds to user requests via HTTP and delivers HTML documents; it can also manage the interactions between a user and a back-end application via CGI or other application programming interfaces. An XML server is similar to a Web server in that you could use a browser to retrieve an XML document from it. But there are two things that make an XML MOM application server different:
· It provides a standard application interface for processing XML-based information
· It provides a variety of communication alternatives for passing the XML documents to and from the XML MOM application server.
An XML MOM application server, which can receive, interpret, and generate XML documents, is really designed to communicate with other applications or other servers, not with users. The XML MOM server can be used to automate the interchange of information between different applications, or between different organizations. For instance, a purchasing application might send information in a standard XML format to another application, which could use it to update a product database.
There are several examples of XML MOM application servers in the market.
XML Server Architecture
An XML MOM application server can be a small, specialized application -- nothing you couldn't do with a Perl script -- or it can be a complete application development framework for general-purpose use.
Figure 1 shows the architectural diagram of an XML server, based on an earlier design of Bluestone Software's XML-Server.
Figure 1: Architecture of an XML MOM Application Server
The major components are:
This can be any application that sends or receives XML documents. Clients can range from a device like a Palm Pilot, to a browser or Web server, to another XML server application.
An XML MOM application server must be able to support a variety of communication protocols. Email and HTTP are the most useful, but some applications might need to multicast or broadcast XML documents to a large number of clients, or may need the guaranteed delivery of a message queuing product. Ideally, an XML MOM application server should provide a framework for any communications protocol to be used as the transport layer for an application.
The aforementioned Bluestone XML-Server, for instance, advertised a robust, pooled, multithreaded communications service capable of running either inside the server, or as a distributed service. Multiple communication handlers could be plugged in to the communications service without changes to the XML MOM application server, the application code, or the interface. This means that you can write a single application that can handle multiple communications protocols without any changes. An XML MOM application server might support communications handlers such as HTTP, email, ftp, EJB, RMI, IIOP, COM, MQSeries, and others.
Bluestone's XML-Server was mentioned for illustration purpose as it was written in Java for reasons of portability, scalability, and productivity. Java provides an excellent framework for integrating new services and reusing objects across applications. Java also leverages work from many vendors that provide core XML services as well as base-server functionality. For example, IBM, and Sun provide Java-based XML parsers. These parsers abide to the W3C specification of the Java API for the Document Object Model (DOM), one of the core interfaces that defines how a program accesses an XML document.
The key functional unit in an XML MOM application server is called a document handler. A document handler is a particular piece of business logic that can operate on a certain class of documents. Each document handler will usually have multiple methods -- functions that can be performed on a particular type of document. A purchase-order document handler might have submit, acknowledge, and cancel methods, for example. Each of these methods would incorporate application-specific logic and they might call different back-end data objects such as a database.
Bluestone's XML-Server implemented each document handler as a separate class, and each action item as a method of that class. In Bluestone’s framework, each document type is associated with a single document handler in a local metadata repository. The document type can be read as the top node in the XML document. Once the base document handler has been invoked, it can delegate processing to additional document handlers directly. Thus, you can create a chain of document handlers, each one calling the next. This lets you organize common document-handling functions across different applications. Document handlers also support a request forwarding architecture. This lets you specify additional handlers that will be executed after the first handler has completed. As the XML MOM application server receives forwarding requests, they are queued for execution. Both models -- direct chaining and request forwarding -- ensure maximum reuse of document handlers. For example, direct chaining enables the developer to build atomic classes that handle a particular element and its subelements. One such class might perform a transformation on the XML document in memory to generate a tree representation of the document. Then a request would be forwarded to another handler that would operate on the tree structure.
Data Object Access:
The document handler calls the appropriate back-end data object and passes the appropriate input fields based on the method processing. For example, it may invoke a SQL statement that inserts a new customer into the database. An XML MOM application server should have an implementation with production-level features such as connection pooling, secure database login, JDBC support, error handling, and transactioning. Access to other non-JDBC or XML data sources, including SAP, PeopleSoft, mainframes, middleware, and "new-age" objects like Java, EJB, CORBA, and COM are also important for many implementations.
When the data or objects are returned from the back end, they are then used to generate an XML document within the document handler. The returned results are put into a callback structure or into an XML DOM for manipulation. Page generation can proceed in a number of ways via a mapping or binding service, template processing, content-generation objects, or even Extensible Style Language (XSL). The key idea is to "bind" the data fields coming from the database to the appropriate elements in the XML document -- for example, the pur_num database field is "bound" to the <PO-Number> element in the XML document that is generated dynamically. If multiple rows of data are returned, then multiple items must be generated in the XML document in the appropriate fashion. As with the input side of this process, it may also be appropriate to filter and translate some of the data. This final assembly of the XML document is called content generation, and can involve use of XSL or reusable Java classes, called content-generation objects. Content generation should be handled by an XML POP application server as described in the previous section.
XML Core Services:
The XML application server uses core XML services such as a parser and DOM, as well as XSL and XML Query Language (XQL). In particular, the aforementioned Bluestone XML-Server bundled the IBM Parser for Java (XML4J), Lotus XSL, and Datachannel XQL implementations. You could also plug in other implementations such as Sun's or Microsoft's parser. These tools were used by Bluestone XML-Server as core services for parsing the incoming document to determine the appropriate class and method to call, as well as getting the data out of the XML format for manipulation by the database.
The Flow of an Application
Figure 2: Sample XML Application Flow
The example in Figure 2 runs a query in the database to get a list of authors and then generates an XML document based on those results. An XML document is submitted as input (1). The class author_list_Handler_S is the document handler that corresponds to the author_list element and it is shown in Listing 1.
Listing 1: Sample Document Handler
* Sample Document Handler Java Code for Bluestone XML-Server
* author_list_Handler_S is the Document Handler class. It
* will be called by the XML-Server (SaExXmlApp) when the
* document type <author_list> is passed to the XML-Server.
public class author_list_Handler_S extends SaDocHandler implements SaIOutPut
* There is only one method in this document handler FgetAll.
* This method may be called directly, or may be embedded
* as a processing instruction in the document as we have done
* in this example.
public void FgetAll()
SaXmlApp app = SaGetXmlApp();
if(app == null)
// TODO - print error
* "cbs" refers to callback structure. This is where the returned
* results from the database are placed for later processing.
* Note the ability to embed an SQL statement within the code.
* The first parameters are defining the database to call.
* The last parameter is passed thru the data access layer.
* Note also this SQL contains no input parameters, so no
* additional parsing of the document was needed for input
SaCbs cbs = SaExecSQL("SapphireTutorial", "PUBS2", SGEODBC,
"select * from authors");
* Use this content generator class - SaApi.SaPopulateXmlMsgBox.
* This will format the data with the column name from
* the database formatted as tags around each data element.
* This creates a well formed XML document, and also puts
* a DTD on the front of the document.
app.SaPopulateByName(null, "author", cbs, "SaApi.SaPopulateXmlMsgBox");
This document handler retrieves author information from the database by embedding a SQL statement (2). The results are available as a callback structure (3). Then a content generator object, saPopulateXmlMsgBox, shown in Listing 2 is called to format the data returned from the database.
Listing 2: Sample Content Generator Object
* Sample Content Generator Object Java Code for Bluestone XML-Server
public class SaPopulateXmlMsgBox implements SaIPopCall
public static final String ELEMENT_DECL = new String("<!ELEMENT ");
public static final String PCDATA_DECL = new String(" (#PCDATA)>\n");
public String SaContent(Object site, Object client, SaCbs cbs)
int r, c, g;
int cols, rows, groups;
String vallist = null;
if(cbs == null)
req = cbs.getReq();
if(req == null)
out = cbs.getOut();
if(out == null)
app = req.getApp();
if(app == null)
if(client instanceof String)
val = (String) client;
if(val == null)
val = "sa_document";
vallist = val + "-list";
groups = cbs.getGroups();
if(groups > 1)
groups = 1;
The aforementioned content generator object uses the column name from the database to generate tags around each item. It reiterates on all rows returned from the database. The final result is a valid XML document (4), shown in Listing 3 complete with DTD.
Listing 3: Sample Generated XML Document
* Generated XML Document with DTD
<!-- author DTD -->
<?XML version = "1.0" ?>
<!DOCTYPE author-list [
<!ELEMENT author-list (author)* >
<!ELEMENT author (au_id, au_lname, au_fname,
phone, address, city, state,country, postalcode) >
<!ELEMENT au_id (#PCDATA)>
<!ELEMENT au_lname (#PCDATA)>
<!ELEMENT au_fname (#PCDATA)>
<!ELEMENT phone (#PCDATA)>
<!ELEMENT address (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT state (#PCDATA)>
<!ELEMENT country (#PCDATA)>
<!ELEMENT postalcode (#PCDATA)>
<address>10932 Bigge Rd.</address>
<address>309 63rd St. #411</address>
<address>589 Darwin Ln.</address>
The above example illustrates the power of a dynamic XML MOM application server. Essentially five lines of Java code have performed a complete query to the database and generated a well-formed XML document, with automatically generated DTD. The XML MOM application server took care of the parsing for us using a standard XML parser. The XML MOM application server also took advantage of reusable Java components like the content generator.
Just as the Web server has become the key component in a Web infrastructure based on HTML, XML MOM application servers provide an important building block for the next generation of Web applications.
XML Server Products
Bluestone Software (www.bluestone.com) developed its XML-Server as a Java-based framework for building and deploying XML applications from the developer of the Sapphire/Web application server. Bluestone Software has also developed Visual-XML, a graphical developer's toolkit for generating XML documents, DTDs, and Java code that processes XML.
Binary Evolution (www.binaryevolution.com) developed VelociGen XML Server as a cross-platform tool for processing XML on the server using Tcl and Perl interfaces. That particular server is based on two components: a graphical development tool and a Web-server plug-in to process XML and serve the results. The graphic development tool shown in Figure 3 lets the user create mappings between elements and code. On the left is a tree view of an XML document that shows the elements in their context. You can select one of those elements (the agent element is selected in the figure), and define the actions that should be performed when that element is encountered. In the example, there are some simple HTML mappings, and also some Perl code that will be output by the server when the element is encountered. The small folder in the main window indicates that the children of the tag will be processed there (it will be replaced with a better image in the final product). So in the example, the children of AGENT (EMAIL, NAME, and so on) will be processed after the final . The mapping in the main window prints the AGENT information by querying a database for the agent ID. The EMAIL, NAME, and other fields create other rows in the HTML table defined in AGENT's mapping.
In addition to the two listed here, there are other XML servers available, with more entrants expected to appear in this market. Object database vendors such as Object Design and Poet Software now offer XML-oriented servers -- eXcelon and CMS, respectively. Software AG (http://www.softwareag.com), an established vendor of enterprise database servers, has announced Tamino, which combines XML and RDBMS technology. Many other packages will handle XML as an interchange format and process the XML data into and out of a relational database such as Oracle 8i or IBM DB2.
Figure 3: VelociGen XML Server's visual XML tool.