Improving Web Services Performance through Fast Web Services - I
It has almost been eight months since
Sun first talked about Fast Web Services (FWS) (find out more about
Today our group attended an interesting TOI meeting on FWS delivered
by Sun's FWS team. It was very nice of FWS to come and talk to us.
Your effort is well appreciated, guys!
Anyway, here are some of the highlights
from this TOI session -
There is a different set of issues
involved in XML performance vis-a-vis Web Service performance
As I discussed in my Sun Network href="http://java.sun.com/developer/onlineTraining/webcasts/35plus/rpatel3/rpatel3.html">here
Conference San Francisco 2003 paper - audiocast available
- some of the ways to improve performance if you are transmitting
significant amount of XML data is to use traditional compression
mechanisms such as zip/gzip or home-grown compression algorithms.
Also, if all your application does is vanilla XML processing then
there are quite a few techniques and best practices to improve the
performance of XML parsing, validation, etc. discussed in the paper
However, if what you do is not simply
exchange and processing of XML information on the wire but rather Web
services then what you need is a technology to improve Web service
performance such that -
Processing overhead is greatly
reduced so that smaller devices can communicate with Web services
without consuming more battery.
Bandwidth overhead is greatly
reduced so that devices that have to pay to transfer every byte on
the network (for example cell phones, etc.) have a chance to consume
Interoperability is preserved. Of
course. Any technology that doesn't meet this requirement kind of
contradicts the very problem Web services are trying to solve.
Existing standards and APIs are
supported to accommodate existing Web service technologies and
frameworks such as JAX-RPC, JAXB, etc.
Fast Web Services outlines ways to
improve Web service performance such that the above requirements are
FWS aims at maximizing the use of
existing APIs, tools and standards. So for Java developers this means
that you would still be using JAX-RPC to develop and use FWS. Mostly
it is the tools and the runtime that is responsible for implementing
Fast Web Service technology. Also the technology would be useful to
have on all the three flavors of Java i.e. Enterprise edition, Mobile
edition and Standard edition. For instance, Sun presently has a FWS
stack implemented on top of JAX-RPC 1.1 and MIDP 2.0/JSR-172.
Workings of Fast Web Services
In order to improve performance, FWS
tackles with Web services at two layers -
XML Information Set layer
A standard Web service communication
pipeline looks something like this -
Binding <--> Infoset <-->
i.e. Network protocol such as TCP
transfers the bytes that reaches an endpoint which in turn converts
those XML encoded bytes into a SOAP message XML Infoset which is
finally bound to Java types by a runtime such as JAX-RPC.
In the above communication pipeline,
FWS can optimize the 2nd segment such that Infoset bytes
are encoded to binary (from XML) before putting them on wire. So the
communication pipeline will now look like -
Binding <--> Infoset <-->
Binary representation of Infoset <--> Transport
This greatly reduces the number of
bytes to be transmitted on the wire since binary encoding is more
efficient and hence, results in compact messages as compared to XML
encoded messages. The resulting binary form uses PER (Packed Encoding
Rules) encoding as defined by ASN.1 standard. Similarly the pipeline
at the receiving end of the SOAP message can decode the binary bytes
back into a SOAP message XML Infoset such that the SOAP runtime can
later bind message parts to programming language types (Java types,
say). This mechanism of encoding/decoding XML Infoset is termed as
The pros of this method is that the
inherent self-descriptive nature of XML remains intact at the
application level since the XML Infoset is kept intact. Refer to the
FWS paper hyperlinked above to find out details about the performance
gains achieved through Fast Infoset mechanism.
Please note that one can use XML
APIs such as SAX, DOM, StAX to work with the XML Infoset in a non-Web
service scenario. In fact, the runtime technology (such as JAX-RPC)
that binds XML Infoset to Java types might use the above XML APIs (at
a higher level, say JAXP) to achieve this binding.
XML Schema layer
For Web services that rely on XML
Schema to type SOAP message parts (most of the doc/literal Web
services fall in this class), FWS defines a mechanism termed Fast
Schema to improve performance.
If Fast Schema mechanism is in place
during an outbound SOAP communication, the runtime will reduce the
SOAP message parts defined by XML Schema to essentially bare data
stripped of all the XML tags, thereby making the representation more
efficient and less self-descriptive. So the resulting communication
pipeline looks like -
Binding <--> Binary
representation of XML schema typed data <--> Transport
The bytes that are transmitted to/fro
are encoded in ASN.1 PER using an ASN.1 schema corresponding to the
original XML Schema. Which is why in order to employ Fast Schema
mechanism, XML Schema must be available to help the runtime process
the inbound and outbound SOAP messages.
Referring to the FWS paper hyperlinked
above, you would realize that the performance achieved through Fast
Schema is of a higher magnitude than Fast Infoset and that it is
almost close to that of RMI.
Fast Web Service Standards
Sun submitted the work done in Fast Web
Services project to ITU-T/ISO body to define a set of standards for
FWS. I am planning to talk about these standards in a future blog.
Send an email to email@example.com if you have questions on this blog.