ML message transmission and processing are at the foundation of the web service programming model. To effectively improve web service performance, you need to reduce the overhead associated with parsing, serializing, and transmitting XML-based data. Fast Infoset is an open, standards-based solution for doing just that. It specifies several techniques for minimizing the size of XML encodings and maximizing the speed of creating and processing those encodings. Using these techniques, you can tune Fast Infoset encoding according to your specific domain requirements, whether that means favoring compression over processing performance or requiring efficient compression but not at the expense of processing performance.

In general, Fast Infoset documents are smaller and therefore faster to process than corresponding XML representations. As such, they can be very useful when the size and processing time of XML documents are a concern. For an example, the W3C's XML Binary Characterization Working Group has identified two such use cases:

1. Web services for small devices that have bandwidth constraints
2. Web services within an enterprise that has high throughput requirements

This article introduces Fast Infoset, demonstrates it in an example based on the reference implementation of JAX-WS, and presents some empirical data comparing the effects of Fast Infoset and MTOM/XOP (another technology for optimizing XML data transmission and processing) on web service performance.

XML Infoset and Fast Infoset
An XML infoset is an abstract model of the information stored in an XML document. The XML Information Set (Infoset) is a W3C specification that specifies the result of parsing an XML document, called an XML infoset, and identifies various Infoset components, called information items and properties. More and more technologies, such as SOAP 1.2 and MTOM/XOP, are defined in terms of the XML Infoset, because most common XML use cases are really concerned with the information stored within an XML document rather than its presentation with a specific encoding.

The Fast Infoset specification provides a representation of an instance of infoset using ASN.1 binary encodings. It can serve as an alternative to W3C's Infoset syntax. Fast Infoset documents retain the hierarchical structure described by the corresponding XML infoset. Depending on which features you select, a Fast Infoset document can be self-contained or not. Self-contained Fast Infoset documents can be converted to and from traditional XML documents without loss of information, at least with respect to the information items and properties defined in the XML Information Set. You therefore can consider these representations as equivalent to XML documents for the corresponding XML infosets.

To provide you a concrete example of Fast Infoset document, the source code download for this article contains a SOAP request XML document (lookup_soap_request.xml), the corresponding Fast Infoset document (lookup_soap_request.fi), and the octal dump of the Fast Infoset document (lookup_soap_request.fi.o). You can generate the Fast Infoset document from the XML document with the free tool FI Coverter from Noemax and generate the octal dump with Hod from the Fast Infoset document. You then can view the Fast Infoset document as XML with another free Noemax tool, FI Viewer, to verify that no information was lost during the conversion.

Fast Infoset in Practice with a JAX-WS 2.0 Web Service
In this section, you will develop and examine a sample web service with JAX-WS RI, which will demonstrate Fast Infoset in practice.

This sample web service simulates a book catalog management system. The web service endpoint interface CatalogPort defines three operations: echo, upload, and retrieve. You will use the echo() method later to allow clients to initiate a request to the service and establish Fast Infoset encoding for the remaining message exchanges. The upload() and retrieve() methods allow client applications to register (and update) book information and retrieve the sample chapter stored in the system, respectively.

In the endpoint implementation class CatalogImpl.java, the upload() method stores the following:

• Basic information about the book and the sample chapter name in a properties file with the name of ${isbn}.properties under the book_info folder
• The cover image in a file ${isbn}.jpg under the book_cover folder
• The description (desc) string in a file ${isbn}.txt under the book_desc folder
• The sample chapter content in a file ${isbn}.pdf under the folder book_sample

The upload() method simply returns a Boolean value indicating whether the implementation process completed successfully. The retrieve() method on the other hand obtains the sample chapter name from the properties file and the content from the book_sample directory (all based on an input parameter isbn) and returns a Chapter object to the client. In the message exchange related to the upload() method call, XML processing and transport overhead is associated mainly with requests, and the size of the request message depends mainly on the sizes of the cover image and sample chapter content. In the message exchange related to the retrieve() method call, XML processing and transport overhead is associated mainly with responses, and the size of the response message depends mainly on the size of the sample chapter content. You will consider these behaviors later to design your performance test harness and present the collected performance data.

Extract the application source code for the web service WSDL and related XML schema file from the code download. To implement the web service with JAX-WS 2.0, you need to use the apt tool to generate the port type interface CatalogPortType.java, the domain objects in the com.company.mtom.catalog.book package, and the service class Catalog.java, which the clients will use to obtain the CatalogPort.

After creating the service endpoint implementation class, you're ready to get the web service up and running. You need to come up with the web service deployment descriptor (sun-jaxws.xml) and the web application deployment descriptor (web.xml), and then deploy the application war into a container (Tomcat, in this example). That's about it for the service.

On the client side, you keep the input book information in a properties file named isbn and the book cover image, sample chapter content, and description text in separate files under ./etc. In the sample client, the private method getBook() creates a Book object for invoking upload(), and compareSample() compares retrieved (through retrieve()) sample chapter names and content with information available in the local repository (.../etc). Note that the client uses the open source JAMon library to collect response time information.

The sample application comes with all the input files utilized by the client for three sample books. To look at the SOAP messages in transmission, you can install tcpmon as a proxy. Later, you will see that when Fast Infoset is enabled for the message exchanges, the messages displayed in tcpmon are mostly gibberish.

Next, you will see how to enable Fast Infoset in JAX-WS RI with the sample web service.

Fast Infoset in Action with JAX-WS RI
The reference implementation of JAX-WS supports Fast Infoset by negotiating HTTP content with the standard HTTP headers Accept and Content-Type. By default, all JAX-WS web services are Fast Infoset-enabled (through the service runtime). To turn on Fast Infoset for message exchanges, the client needs to indicate to the service that the client runtime is capable of working with Fast Infoset documents. It accomplishes this by sending an initial request encoded in standard XML and including the MIME type application/fastinfoset as part of the HTTP Accept header list. After this initial request, all the conversations between the client and the service will be encoded in Fast Infoset, as long as the client continues to use the same BindingProvider instance to converse with the service.

In JAX-WS RI, you can enable the above content negotiation in two ways:

1. Set a system property on the JVM used to run the client
2. Set a property on the binding provider object (a port proxy or a dispatch)

In either case, both the property name, "com.sun.xml.ws.client.ContentNegotiation", and its value, "pessimistic", are identical. (In contrast, for the optimistic form, the client directly initiates a message exchange using Fast Infoset encoding.) The JAX-WS 2.0 RI also defines a constant, CONTENT_NEGOTIATION_PROPERTY, in the interface, com.sun.xml.ws.developer.JAXWSProperties, to represent the property name, but this constant was deprecated in a later release of the reference implementation, version 2.1.1.

With the first approach (setting the system property on the JVM), you can start the JVM in which the web service client runs like this:

          java –Dcom.sun.xml.ws.client.ContentNegotiation=pessimistic ... 

This code snippet shows an Ant target that runs the sample web service client with content negotiation enabled:

    <target name="run">
        <java fork="true" classname="${client}">
            <classpath>
                <path refid="client.classpath"/>
                <pathelement location="${build.classes.home}"/>
                <pathelement location="${basedir}/conf"/>
            </classpath>
           <sysproperty key="com.sun.xml.ws.client.ContentNegotiation" value="pessimistic"/>
           <arg value="${isbn}"/>
        </java>
    </target>

You can also enable the sample application with content negotiation by following the second approach (setting the property on the binding provider object) like this:

                        ...... 
   CatalogPortType port = service.getCatalogPort();   
          ((BindingProvider) port).getRequestContext().put(JAXWSProperties.CONTENT_NEGOTIATION_PROPERTY,
          "pessimistic");
              //((BindingProvider) port).getRequestContext().put("com.sun.xml.ws.client.ContentNegotiation",
              "pessimistic");
                ......

The example uses a port proxy. If you are working with a Dispatch instance, you can again cast it, get the request context, and set the corresponding property to enable content negotiation because a Dispatch instance in JAX-WS is also a BindingProvider.

Web Service Performance: Fast Infoset vs. MTOM/XOP
MTOM (SOAP Message Transmission Optimization Mechanism) is a W3C Recommendation for packaging binary data within SOAP messages in a way that avoids base64 encoding. It depends on XOP (XML-binary Optimized Packaging), which provides a mechanism for embedding binary data in XML infosets. XOP supports only the embedding of binary data for chunks of character information items. As you have learned, Fast Infoset describes a binary encoding of the XML Information Set and allows for the direct embedding of binary data (as either chunks of character information items or the property of attribute information items). In this sense, Fast Infoset does what MTOM/XOP can do plus a lot more.

JAX-WS 2.0 and its reference implementation support both Fast Infoset and MTOM/XOP (see my previous DevX article on MTOM/XOP and its support in JAX-WS 2.0). So which technology is better in terms of their impact on web service performance? Let's find out using the example application.

For each of the following settings, Figure 1 and Figure 2 present bar charts that summarize the average response time (ART) for three different sets of data (corresponding to the ISBNs provided in the example application):

1. A standard JAX-WS web service (Standard)
2. Both client and service MTOM-enabled (MTOM/XOP)
3. Fast Infoset enabled (FI)

Figure 1 shows the results of invoking the upload method. The data size format (X + X) indicates the size of the cover image plus the size of the sample chapter. It marks one standard deviation on the bars.

Figure 1. ART for upload() Method Invocations This figure shows the results of invoking the upload method.

Figure 2 is for the retrieve method (with the size of the sample chapter list). It also marks one standard deviation on the bars.

Figure 2. ART for retrieve() Method Invocations This figure shows the retrieve method (with the size of the sample chapter list).

As the empirical data clearly demonstrates, web services—especially those that process and transport binary data—clearly benefit from both MTOM and Fast Infoset. However, the reference implementation of JAX-WS 2.0 Fast Infoset-enabled web services consistently perform better than MTOM-enabled ones.

Fast Infoset Rising
Fast Infoset is on its way to being widely supported in various platforms and frameworks such as Microsoft .NET and .NET CF, Sun GlassFish, BEA WebLogic, IBM SDK for Java 6.0, and TMax Soft JEUS 6, as well as in the Linux, Solaris, and Win32 operating systems. (Fast Infoset support in JAX-WS is based on the FI project at java.net.) Developers—particularly those in the SOA domain—should explore this promising technology and learn how they can work more efficiently with XML to deliver high-performing web services.