Issues | Professional JMS

There are some arguments against using XML as a messaging format. Generally, these surface in discussions about highly resource-constrained devices, such as PDAs, or in environments where network bandwidth is limited. The following sections will examine these issues in detail.

Parser Size and Complexity

Parser size and complexity is becoming a problem. The XML 1.0 specification (2nd Edition) (downloadable from http://www.w3.org/TR/2000/REC-xml-20001006), at 59 pages, is a model of elegance and simplicity. A number of the associated technologies in the XML family, however, are becoming increasingly complex and difficult for vendors to implement efficiently.

A number of the more popular and standards-compliant parsers currently available have a large memory footprints and demand high processing bandwidth. As such, they preclude implementation on resource-constrained devices, such as PDAs or programmable mobile phones. There are some solutions to this problem, including indexing a document with technologies like XMLC. There are also parsers available that work on small devices by compromising support for some standards; however there is no standardization among these, which ultimately causes problems.

Message Overhead

The most common criticism leveled against XML messaging is overhead. Text-based messages structured with markup are not very bandwidth efficient, particularly as messages become large and highly structurally complex. For LAN and WAN messaging, this is not a significant issue; the bandwidth tradeoff is a minor sacrifice measured against the gains listed above. For wireless devices, however, this is often a critical issue.

The WAP forum had to consider this issue when it began defining standards for data services on mobile phones. One component of the WAP standard is an XML-based presentation markup language called Wireless Markup Language (WML). This is analogous to HTML, but optimized for devices with small display real estate, limited entry capability, narrowband communication channels, and severe limitations on processing power.

The WAP forum has addressed the issue of WML verbosity by introducing a binary compression scheme for XML. It relies on lossless substitutions for certain common tags and idioms, and selective filtering of some document content like DTDs (WBXML is described in the WAP Binary XML Content Format, Version 4, Nov 99 http://www1.wapforum.org/tech/documents/SPEC-WBXML-19991104.pdf). Usually, this would be implemented as a layer in the transport interface.

The cost of such compression is legibility on the wire. This may not seem like much of a sacrifice, as the data can be trivially decoded; however consider how much web development has benefited from the plain text representation of HTTP and HTML, which permits client/server dialogs to be easily tracked using a basic network sniffer.

Packaging of Non-XML Data

Consider a simple XML messaging scheme like the following:

     <?xml version="1.0" encoding="UTF-8"?>     <Envelope>       <Header>          ...       </Header>       <Body>          ...       </Body>     </Envelope>

The Header contains control information such as identifying a service that the message is targeted for, and message unique identification. The Body element contains the data to be sent to a remote application.

The problem with using XML to package arbitrary data is that some data will result in illegal XML. For example:

     <Body>        < Remote parser will reject     </Body>

Sometimes this can be solved using entity references, the predefined XML escape sequences:

     <Body>        &It Remote parser will reject     </Body>

But there are other cases that cannot be so easily escaped:

     <Body>        This data contains an </unbalanced> tag     </Body>

In this case, one option is to declare a CDATA section, which effectively declares the area off limits to further parsing. This is sometimes used to transport an existing XML document packaged in an XML envelope. The parser would reject this without the CDATA escape because the XML declaration <?xml> can only occur once in a document, and must be the first token in the document:

     <?xml version="1.0" encoding="UTF-8"?>     <Envelope>       <Body>         <![CDATA[<?xml version="1.0" encoding="UTF-8"?>           ...         ]]>       </Body>     </Envelope>

Although this works, it is an inelegant hack. It also does not address the problem of non-textual data, such as binary pictures. For binary data, a standard encoding schema is needed. Most messaging application make use of Base64 as a solution to this.

Note

Base64 is described in RFC 2045, titled Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (http://www.ietf.org/rfc/rfc2045.txt).

Binary content can be encoded using Base64 alone:

     <Body>     <BinaryPicture>               sdfsd73hd77n4sfYsa9hGY8w9s3 ...     </BinaryPicture>     </Body>

Ultimately, this is not a very satisfactory solution. The parser on the receiving system must process this entire document, which means that it will isolate the encoded binary item as a string, holding it in memory in its entirety. This could seriously limit the scalability of a high volume messaging application. It would also be incredibly wasteful of resources if the goal of parsing were simply to get at a header value, perhaps so the message could be relayed to its ultimate destination by an intermediate.

There are also some general design problems with this. Both the sending and receiving parties must be made aware that the BinaryPicture element contains data encoded in Base64 (this could be indicated using some features built into XML Schema). Consider also multiple attachments. What if a picture, a sound file, and a spreadsheet file all had to be transferred?

We could define our own schema defining a container for multiple attachments, with items that have attributes describing metadata about the attachment like their type, encoding, etc. Furthermore, whatever we came up with would be a proprietary solution. Fortunately, this problem has already been addressed in the context of mail, which faced similar challenges a number of years ago.

Note

RFC 2387, The Multipart Internet Mail Extensions (MIME) Multipart/Related Content-type (http://www.ietf.org/rfc/rfc2387.txt) defines a standard for aggregation of interrelated objects.

It's not XML, but it can be processed very efficiently, and there are a lot of tools, infrastructure, and general expertise that support it. Several of the XML messaging standardization efforts, which will be described later, have settled on the MIME multipart/related content type to package problematic data. This includes other XML documents, as was alluded to above. In particular, MIME defines mechanisms for not only rendering binary content in Base64, but also packaging raw data, which removes some processing burden from the sender and receiver. This is an important consideration for high volume applications.

MIME is best illustrated with an example:

     Content-Type: Multipart/Related;       boundary=boundary_marker;         start="xml-message1@someURL";         type=text/xml;     -- boundary_marker     Content-Type: text/xml;     Content-Description: Main XML message envelope     Content-ID: "xml-message1@someURL"     <?xml version="1.0" encoding="UTF-8"?>     <Envelope>       <Header>         <Manifest>            ...         </Manifest>       </Header>       <Body>         ...       </Body>     </Envelope>     --boundary_marker     Content-Type: image/jpeg     Content-Description: An encoded binary picture     Content-Transfer-Encoding: base64     Content-ID: "imagel.jpg@someURL"     bshOI47KJ64kI6hksdf7gh32fsd87kj3r3     Sdfkj3483jusYioyu8reti34hfs89fsdio     I5h3489hpw         ...     --boundary_marker--

The opening line declares the MIME content type to be multipart/related. MIME defines a number of standard parameters represented as simple attribute-value pairs. MIME supports recursive structures: a MIME body part may contain other MIME entities. This does complicate processing somewhat, but in general, MIME lends itself well to parsing by existing Internet infrastructure, like firewalls, which may not be XML-aware.

The boundary attribute defines a marker delimiting the MIME parts. One of the MIME parts is the root, and may be the logical piece that relates all the other parts. The start attribute, if included, points to the root MIME part's content ID; the first MIME part is the default root if this is not specified. The content type attribute in the main header defines the content type of the root MIME part.

Each MIME part has a distinct header, defining its content type (the content types are defined in the MIME specification RFC 2045), an optional description, an encoding, and a content ID.

Notice here we have included a manifest element in our XML header. It is a common strategy to use manifests when packaging data items, especially if the package can be broken up into multiple components. Java JAR files are a good example. The manifest here might contain references to MIME parts using the unique MIME Content-ID parameter. For example, Microsoft's BizTalk messaging framework, which will be examined later in the chapter, uses manifests to refer to body parts using URIs. The manifest for a BizTalk version of the above message might look like:

     <manifest>        <reference>           <attachment href="CID:imagel.jpg@someURL"./>           <description> Description of JPEG imagel </description>        </reference>     </manifest>

Content ID URLs are described in RFC 2111, Content-ID and Message-ID Uniform Resource Locators (http://ietf.org/rfc/rfc2111.txt). Notice that in this example, the Body element remains in the primary MIME part with the headers. Since the body is where XML unfriendly data may appear, it may be better to simply remove this entirely to its own separate MIME part that could be encoded as necessary. If we left it in the primary document with the headers, this entire MIME part may have to be encoded, including the headers. This would impede quick and efficient access to header fields, perhaps by an intermediate. Creation of a separate MIME part for the body is the solution adopted by the ebXML group with its payload (analogous to the body), which is placed in a distinct MIME part.