XML provides a convenient mechanism for information exchange between heterogeneous applications. Information providers expose data that is of some value to their clients in the form of an XML document. The way information is processed varies from one client to another and is dictated by the actual application run by the client. A financial Information provider, for example, runs an XML server application that provides company information (see Listing 1) to its clients, as shown in Figure 1. This information can be used by a Stock Quote application that tells its subscribers about the current stock price for a given ticker symbol, or by a stock analysis application that can graphically depict the performance of a stock over a period of time. It can also be used to generate a list comprising a company name, address and key employees for a directory service.

The Stock Quote application may be an intelligent Internet agent (see Figure 1) that provides services to a wide range of subscribers who may use a desktop computer or a wireless device to sign in. The agent serves the information in the format accepted by the device (i.e. a WAP phone subscriber is sent the information as WML, while other PDA users may receive the same information as HTML).

A Stock Quote application is interested only in the current stock price. It doesn't have any use for the performance history and company information that comes along in the XML document from the information provider. Likewise, Stock Analysis and Directory Service applications are interested only in a portion of the XML document and have no use for the extra baggage. This implies that a lot of bandwidth is wasted in transporting unused information.

A straightforward approach would make the XML server aware of the clients it's serving. That way, the server could generate an appropriate XML document for a given client. However, with this approach the server application is tightly integrated with the clients. The server needs to be modified with each new client application. Maintaining such a server can become a daunting task and can also impact the availability of the server.

A better approach is to allow a client to tell the server what information it's interested in during the registration process. The client sends a template XML document when it registers with the server. When the client requests information, the server can filter the XML document before sending it to the client. This way, the client controls what information it can expect from the server and the server is immune to change caused by new client applications. The template describing the information required by a Stock Quote application can be represented by stockquote.xml (see Listing 2).

Now I'll describe how to build an XML filter that can be used by the XML server, along with a simple protocol for registration and subsequent information exchange.

XML Filter
The XML filter is written in Java using the SAX API. SAX is an event-driven API for parsing XML documents. The parser notifies the filter when certain events happen. The events that are used by the XML filter are:

• startDocument: Signals the start of the document.
• startElement: Signals the start of an element. The parser fires this event when the contents of the opening tag have been processed. This includes the name of the tag and any attributes it might have.
• endElement: Signals the end of an element.
• characters: Contains character data that is the actual value associated with a tag.

The sample code presented here uses the XML4J parser available from IBM. However, the code isn't dependent on any particular parser implementation as it strictly conforms to the SAX API as recommended by the W3C specification.

XML filtering is done in two phases. In the first phase an XMLFilterDescriptor (see Listing 3) object is created using the XML document supplied by the client. XMLFilterDescriptor parses the XML document using SAX API. The startElement event handler converts the XML tags into fully qualified tag strings and stores them. A fully qualified tag string is a concatenated string of the tags that have been encountered from the document root through the current tag. A fully qualified tag string is required to differentiate between tags that have the same name in an XML document but a different meaning. For example, as shown in Listing 1, <high> included within the <january> tag is different from <high> within the <february> tag. A fully qualified tag name will appear as .companyList.company.performance.january.high.

In the second phase an XMLFilter (see Listing 4) object is created that parses the server XML document. The startElement event handler converts the XML start tag to a fully qualified tag string. This tag string is then searched in the XMLFilterDescriptor object, and if found, indicates a tag that is of interest to the client. All the associated attributes and their values are then sent to the client after formatting them as XML. The actual value associated with the tag, if any, is sent to the client by the Characters event handler. An end tag is sent to the client by the endElement event handler.

Registration and Information Exchange Protocol
Figure 2 shows the simple protocol used by the client and XML server. The client registers with the XML server specifying the information of interest. This information is an XML document that is actually a subset of the XML document available from the XML server. The Stock Quote application uses stockquote.xml (see Listing 2) to register with the information provider. The client receives a registration context after a successful handshake with the server.

The client makes a request to the XML server for information specifying the registration context. The XML server fetches the XMLFilterDescriptor object corresponding to the registration context, then filters the XML document using the XMLFilter object. The filtered XML document is then sent back to the client.

The code presented here shows how an HTTP client (see Listing 5) may communicate with a Java servlet-based server (see Listing 6) using a tunneling mechanism.

(In an actual implementation for a Stock Quote application it may be a better approach for the XML server to call back the client whenever it receives a stock update. This eliminates the periodic data requests the client application makes to the XML server.)

Conclusion
Without a doubt, using an XML filter provides a loose coupling between the XML server and its clients. New clients may come and older clients may go without requiring the server for a code change. This is particularly helpful in a business-to-business environment where new alliances are continuously formed for increased market presence.