XML and OAG

---

Online XML

The use of XML is not restricted to batch operations. Real-time interfaces to systems necessarily define data structures. Often, these structures must be self-describing for a variety of reasons.

For example, suppose we have a real-time interface that performs some service on behalf of a client application. This service must support several client applications simultaneously. Suppose further that the interface specification needs to include additional data elements in order to support some new requirement. Not all client systems can be updated simultaneously; in fact, it is likely that at least some older client systems need to be supported for a year or more.

One traditional solution for this requirement is to include a version identifier in the interface structure. The real-time service module can examine the version of a particular message and respond to either the new or the old type of message. (In this situation, you are well advised to normalize either message type into some standard internal structure rather than actually leaving the original code as is. Otherwise, there will be two versions of the service module to maintain.)

An XML-based interface specification is a perfect choice for this situation. Each client service request that is based on XML will be self-describing. The service module can extract the data that is actually in a particular message, perhaps providing defaults for data that is not present in the message. The service module can respond with an XML-based return message containing either the new or the old data set. A client application can extract the information it requires from the response. An even more sophisticated solution would allow the client application to pass in an initial DTD at runtime. This DTD would define the structure of the request and response method that the client can accept.

These advantages work for the client application as well. Client applications that use XML-based messages when talking to services can talk to new and old services simultaneously. The structure of the messages is not tied to the various versions of the services, only the message content is. This greatly simplifies the coding required to support multiple versions of service modules talking to multiple versions of clients.

XML is also an excellent infrastructure for interactive messages between systems. For example, an online procurement system might send an XML-based catalog query to a supplier's system. The supplier's system could reply with catalog items described in XML, including prices. The procurement system could simply display the results in a browser or store the results in a database for later access.

---