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
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,
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,"
"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
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
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
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
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
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
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,
implemented through web services.
If we can make web services faster in the CPU and faster on the wire,
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.
running on one machine to eliminate network-connection latency,
shows Fast Web Services took 165% the time of RMI,
was 2 times faster
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
- 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.
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
Rima Patel Sriganesh
a technology evangelist at Sun,
said during an
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.
the working group published its
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
as two uses for binary XML.
(By the way,
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.
come out with its own binary web services specification
(and any necessary changes to the WSDL specification to support it)?
will those specifications compete or complement ITU specifications?
Will OASIS modify its
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.