It’s been more than a year since Sun Microsystems introduced its Fast Web Services technology at JavaOne 2003. I’ve been following the status of binary Fast Web Services because of my interest in increasing the speed of SOAP messaging in my projects, and discovered the U.S. military shares my interest.

On Tuesday and Wednesday this week, the U.S. Air Force and the MITRE Corp. held a conference in Virginia on “XML for Binary Interchange: Addressing Machine-to-Machine Interoperability & Tactical and Mobile Computing.” MITRE is a not-for-profit corporation managing research centers for the Defense Department and other federal agencies. At the conference Tuesday, Santiago Pericas-Geertsen, one of the inventors of Fast Web Services, gave a presentation on the technology during the public portion of the conference. (Wednesday afternoon featured “military only” sessions.)

The primary Air Force group co-sponsoring the conference is the “AFC2ISR Center” at Langley Air Force Base. The Air Force Command, Control, Intelligence, Surveillance and Reconnaissance Center helps develop technologies that allow reconnaissance aircraft and satellites to communicate real-time battle information to troops on the ground. The conference’s primary objective was to help build the Global Information Grid by looking into using XML technologies for messaging “in tactical and bandwidth constrained environments,” combining “the advantages of XML with the efficiency of binary-format information exchange.”

In order to increase the transmission speed and processing of XML, various standards bodies have developed, or are looking into, binary equivalents to XML technologies, including binary SOAP messaging for faster web services. Not everyone agrees binary XML is a good idea (more on this below). But apparently the military thinks it is. In announcing the XML for Binary Interchange conference, a MITRE conference organizer wrote in an email to the xml-dev mailing list that he was sorry he didn’t have time “to engage in a protracted xml-dev discussion. Suffice to say we believe there to be real issues that must be addressed.”

If you haven’t heard of Fast Web Services, here’s some background. FWS is a mix of technologies that attempt to solve the web-service speed problem by using binary equivalents of XML for messaging. Binary XML encoding not only makes SOAP messages faster to transmit over the wire, the format also makes it faster to create and parse the messages, including serializing and deserializing the message from and to programming-language objects.

Fast Web Services uses Abstract Syntax Notation One, developed 20-years ago by the International Telecommunication Union. Sun has worked with the ITU’s telecommunication standardization group to create a mapping standard between ASN.1’s schema language and XML Schema so ASN.1 can be used as a replacement for XML. Once XML is turned into its ASN.1 equivalent, it can be compressed using Packed Encoding Rules, another ITU standard.

As an aside, anyone I’ve talked with who has used ASN.1, including two Sun engineers, has made it pretty clear they never want to see ASN.1 again. It is a horrid data language, apparently. But on the positive side, web services developers using Fast Web Services should never have to deal with ASN.1 directly, just like they don’t have to deal with the underlying HTTP protocol when writing web services today. The web-service transport layer handles the creation and parsing of the ASN.1 messages.

Binary XML has been a topic among XML developers for more than 5 years. Critics have argued that binary XML

  • Is an abomination that flies in the face of everything that human-readable, self-describing XML was invented for in the first place.
  • Will let unskilled developers create fine-grained web services that will increase server loads unnecessarily.
  • Compressing SOAP XML messages using GZIP works just as well

The first two criticisms are good points, but I don’t think they’re strong enough to quash a binary web service standard. Web services are here to stay, especially with the big vendors pushing service-oriented architectures implemented through web services. If we can make web services faster in the CPU and faster on the wire, why not? But as far as compression goes, verbose XML is only one reason web services are slow. Creating and parsing the XML, especially if the XML is being deserialized into Java objects, accounts for a lot of the slowness.

Sun implemented a prototype of its Fast Web Services, using a modified version of its Java Web Services Developers Pack. Sun then compared the speed to RMI, RMI-IIOP, JAX-RPC SOAP encoded, and JAX-RPC XML literal. Its tests, running on one machine to eliminate network-connection latency, shows Fast Web Services took 165% the time of RMI, was 2 times faster than RMI-IIOP, and was about 4 to 10 times faster than regular web service calls. You can read Sun’s
Fast Web Services
 article for details.

Sun’s goals for Fast Web Services are to:

  • Speed processing of web service messages by using a binary format that is faster to create and parse.
  • Speed transmission of web services messages by using a more-compact format.
  • Lower the memory needed for web-service applications, opening web services to limited-capability devices like PDAs and mobile phones (and maybe battlefield gizmos?).
  • Minimize any changes needed to existing specifications (like WSDL).
  • Maintain the interoperability of web services by keeping the message format platform- and language-neutral.

Another major goal is to shield developers from having to know anything about the binary XML format. In Sun’s implementation, APIs like JAX-RPC will remain the same. Programmers will continue to write and call web services the same way as today. The transport layer will perform the FWS magic by talking to the server hosting the web service (probably by examining the service’s WSDL) and inquire whether it supports FWS. If so, it uses it. If not, it reverts to standard XML SOAP messages.

When Sun unveiled the technology in 2003, it said it should have an implementation available for developers in early 2004 as part of the Web Services Developer’s Pack. So far, I have heard no updated plans to release the technology to the public. Perhaps Sun is waiting for the ITU’s Study Group 17 to come out with a planned fast web services specification. Rima Patel Sriganesh, a technology evangelist at Sun, said during an online chat in July that she expects ITU’s Fast Web Services specification to be completed by next summer.

The W3C also has an XML Binary Characterization Working Group looking into whether a standard binary XML format is desirable. If the answer turns out to be yes, perhaps the W3C will pursue a binary web services standard. In July, the working group published its first draft of use cases describing the need for a binary XML format. The group cited “Web Services as an Alternative to CORBA” and “Web Services for Small Devices” as two uses for binary XML. (By the way, Robin Berjon, the chair of the W3C XML Binary Characterization Working Group, also spoke Tuesday at the military conference.)

It will be interesting to see where fast/binary web services go. Will the W3C come out with its own binary web services specification (and any necessary changes to the WSDL specification to support it)? If so, will those specifications compete or complement ITU specifications? Will OASIS modify its SOAP Message Security standard to work with binary SOAP messages?

The W3C binary XML working group has spelled out a need for binary XML, including binary web services. Members of the ITU have said there’s a need for a binary web services standard. And the U.S. Defense Department is saying it needs binary XML and faster web services.

But for faster, binary web services to take off, we’ll need clear, compatible standards to ensure interoperability. The W3C will need to work with the ITU to prevent competing standards. And we’ll need product companies like Microsoft, IBM, BEA and Sun seeing a big enough market demand to implement those standards as part of their web service stacks.