XML: A Managers Guide (2nd Edition) (Addison-Wesley Information Technology Series)

Business Challenge

Typically, the different nodes of a distributed application communicate using an application-level protocol running over standard networking protocols. Often, the nature of the application requires the use of a particular application-level protocol. While SOAP is the standard for general XML messaging, you might need a more specific protocol. Sometimes, you would define your protocol on top of SOAP. An electronic commerce application may need to exchange information between the client and server to specify the contents of an order and authorize payment. Such a protocol would run on top of SOAP. Other times, you may need to define an alternative to SOAP. Different nodes of a distributed application server may need to exchange hardware utilization statistics to perform effective load balancing. Such a protocol probably has performance requirements different from SOAP.

XML Benefit

A large part of implementing an application-level protocol is designing message formats and implementing the engine that will take data from internal data structures and put it in the appropriate message format. XML takes care of both these problems. XML elements and attributes already provide the basic model for indicating what the information in a protocol message means. Software developers simply have to design a schema for each particular message type. XML processors take care of making sure that message instances have the appropriate format. Moreover, processors extract the information in these messages and put it into internal data structures that the application logic can manipulate. By using XML, software developers gain enormous leverage in the design and development of application-level protocols.

Developers also get the benefits of XSLT. Often, debugging distributed applications can be very difficult because it's hard to decipher the messages exchanged. When developing XML-based protocols, developers can simply specify an XSLT stylesheet for each message type, and they can view protocol messages in an easily readable format on any XML-capable Web browser.

Architecture

As Figure 8-5 shows, the architecture of XML-based distributed protocols is relatively simple. As with most application-level protocols, they probably leverage the standard TCP/IP networking protocols and the corresponding network drivers provided by operating system vendors . They also allow developers to use HTTP as the message exchange protocol. HTTP engines are widely available, and most security firewalls provide options for HTTP tunneling , making it an attractive option. This is the approach that SOAP uses. The processing of information extracted from the custom formats occurs in a library. Finally, developers write their application so that it accesses the information from the library, performs any necessary processing, places the results in a data structure representing the response, and instructs the library to encode the response message as an XML document.

Key Features

The key characteristic of an XML-based distributed protocol is that remote messages exchanged over the network are formatted as XML documents. These messages are extremely short lived.

Development Process

Implementing an application-level protocol requires first specifying the allowable message flow. In operation, such a protocol consists of messages flowing between two nodes in the distributed application. These messages must occur in a specific order: The nodes must exchange handshake messages first, then exchange authentication messages, and so forth. After designing the message flow, you must design the message formats. For XML-based protocols, schemas specify the format of different types of messages.

With these elements in place, you must choose a lower-level protocol for message exchange. They can exchange messages over raw TCP/IP sockets or use a higher-level protocol such as HTTP or even SOAP wrappers. Then they must implement the control logic that governs the assembly, sending, receiving, and disassembly of messages.

Schema Source

For a given protocol, message types have a corresponding schema. In some cases, a protocol may be an industry standard, with the schemas part of the standard. In other cases, the protocol may be unique to a particular application, and you must specify your own schemas.

Document Life Cycle

The node sending a message in a distributed application creates the corresponding document. The node receiving the message consumes the document, at which point the document would usually be destroyed . An application could archive a complete or partial transcript of protocol messages, preserving the corresponding documents. However, the large volume of such documents would typically make such an arrangement cumbersome except perhaps during testing and debugging.