This article focuses on the Java-based Web Service APIs and compares some of the most commonly available tools, like Axis1.x, Axis2, XFire, WSIF, and SAAJ, along with stating the necessity for a Java Reflection-like API for Web Services based on WSDL that can retrieve the port type, operation name, service namespace, service style, method parameters, return types, Java data mappings, etc.
The first question that might pop into everyone's mind might be about Apache WSIF. Though WSIF mainly focuses on using the meta-information available in the WSDL, it doesn't offer a solution to directly work with the actual underlying XML message for a SOAP-based WSDL service. Also, it can look up the default port type and create default input and output messages for a specific operation, yet it does not offer a full-fledged Reflection API-like lookup for any and every piece of meta-information in the WSDL. Such a dynamic lookup can be used to check for available operations and exposed services at runtime and invoke them appropriately.
Also, as organizations look forward to web services as high-volume, transaction-capable, reliable, and interoperable workhorses, the ability to turn off Java object binding becomes highly desirable. This would be handy especially in scenarios in which the application is just a broker to a web service, and the actual data consumers are elsewhere. WSIF also depends on stubs generated from the Apache Axis WSDL2Java tool.
Apache SOAP was based on DOM and had to maintain the entire XML tree in memory, and hence was not suited to handle data-intensive services. Though Axis1.x (which was developed from Apache SOAP) was based on SAX and has enjoyed huge success in many corporate products, it also has a serious flaw with web services that serve out huge XML content. It failed miserably in handling huge XML-based transactions, since the SAX-based parsing was tightly coupled to Java object binding. Thus, even though the SAX parsing could handle huge XML data efficiently, the data had to be stored in memory by generating and mapping to POJOs via its type mapping registry mechanism, coupled with its serializers and deserializers. It did not allow for a direct method to deal with the XML content transparently. There was no way one could turn off the generation of objects and deal with the XML content in a memory-efficient manner. Though it offered handlers and handler chaining mechanisms that could subscribe to receive the XML request/response message content, the object binding was mandatory, and each handler was presented with its own local copy of the message, which all added up to memory woes and hindered performance. However, Axis1.x has a very good WSDL parser tool called WSDL2Java, though it does not expose a complete set of APIs that clients can use to look up datatypes, method parameters, and their XML name tags or return parameters.
Axis2 is a complete re-architecture of Axis1.x from the ground up to address these issues. It is based on the new StAX (Streaming API for XML) and is poised to perform better than Axis1.x because of the advantages offered by StAX-based pull parsing. It provides more XML-oriented approaches and has a good Object Model named AXIOM that revolves around StAX to provide partial or deferred building support. This dependence on StAX allows it to boast of a low memory footprint. It also does not depend on storing the entire XML content in object forms in memory. It has support for plugable data bindings, and either SOAP or Java transport mechanisms can be used. However, one flaw with Axis2 is that it also does not allow a transparent and efficient method to dynamically invoke web services like WSIF, nor any lookup methods based on the WSDL.
SAAJ1.3 from Sun is a reliable SOAP messaging API. However, it does not deal with other Java-based transport mechanisms like JMS, RPC, etc., as Axis2 does. It's surprising that SAAJ offers much better performance than most of the Axis clients, though it offers a DOM-based API.
XFire has been developed by the Codehaus team as an alternative option to Axis1.x (at the same time that Axis2 was envisioned and drafted) to improve performance, along with the goals of catering to SOAP1.2 and being WS-I 1.1 compliant. It has an embedded HTTP server (Embedded XFire HTTP Service) and can be used to easily expose Java methods as web service endpoints with easy integration in Spring. It is also based on the current generation of pull parsers and incorporates StAX. However, XFire does not support encoded RPC-style services, and is yet to support dynamic clients (which might be featured in the next release).
Though the performance aspects of current Java web service tools are pepped up by the use of XML pull-based parsers like StAX and a more XML-oriented approach with optional object endpoints, the missing link in Java-based web service tools is good Reflection API-like dynamic WSDL parsing capability. It could be used to provide a handle to the meta-information available on the WSDL at runtime for clients. A mix of WSIF-like (with a more extensive WSDL parser) and Axis2-like StAX-based functionality is desired. It should not only offer a lot of possibilities like handling of small changes on the web service specification (WSDL) at runtime (an open issue would be to decide which changes are small and which can be handled), but empower clients at times to even ward off a complete rebuild and code changes. Another great feature would be to allow the clients to choose between options to turn on/off the WSDL parser and cache the WSDL metadata, as it need not affect the performance every time a call to the WSDL reflection API is made. This would be useful when the web service definition is not static and is in development or re-evolving stages, so that clients do not need to wait for the final release, but can continue with their development and testing. It would also lend much flexibility to the client design, as it could transparently decide which WSDL-exposed operation to choose or which transport protocol to use at runtime. Let's hope such a tool with the best features of all existing APIs will soon be released.