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 FWS here). 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 Conference San Francisco 2003 paper - audiocast available here - 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 above.

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 Web services.

• 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 met

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 <--> Transport

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 2^nd 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 Fast Infoset.

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 rima.patel@sun.com if you have questions on this blog.