Have you played with SOAP yet? If so, which SOAP implementations have you used so far? Even though SOAP is on its way to becoming a standard, one thing you'll notice is that every SOAP implementation has a different programming interface. SOAP only defines the format of the messages that are sent across the wire. It doesn't define the way that a Java application interacts with SOAP. What this means is that when you build a SOAP application, you have to select your SOAP implementation up front. There are no SOAP tools available that allow you to write a generic SOAP application that can use any SOAP implementation.

So the Java Community Process (JCP) is developing a set of standard Java APIs for Web services. The theory is that all Java SOAP implementations will support these APIs, so you should be able to write a portable SOAP application. There are two APIs in development: the Java API for XML Messaging (JAXM) and the Java API for XML-based RPC (JAX-RPC). Both APIs support both RPC-style and document-style services. A more accurate way to distinguish the two APIs is to describe JAXM as a low-level SOAP API, and JAX-RPC as a high-level WSDL-based SOAP framework.

JAXM
The JAXM API consists of two packages. The javax.xml. soap package provides a low-level Java abstraction for the core elements of a SOAP message. You use this package to create a SOAP message and to construct its elements. You also use this package to create a connection to a SOAP service and to call that service, passing the constructed message. The call method blocks until a response is returned. The javax. xml.messaging package provides a slightly higher-level abstraction for SOAP messaging, which includes a MessageFactory object that you use to construct a SOAP message structure (the envelope, header, and body) based on a predefined profile. Once the message structure has been constructed, you populate the message with your payload data. When your message is ready, you connect to your service and send the message using either the asynchronous send method or the synchronous call method.

JAX-RPC
JAX-RPC provides a very high-level abstraction of SOAP communications. For the most part, the developer never works with any SOAP constructs. Instead, JAX-RPC provides a remote method invocation-style interface. JAX-RPC uses a WSDL file to generate the code that maps an RMI call to its SOAP message representation. JAX-RPC supports both RPC-style and document-style operations. In both cases, JAX-RPC is responsible for mapping all Java data types to XML data types, and for marshalling the method parameters into the SOAP message. JAX-RPC also provides access to the low-level SOAP constructs using the javax.xml. rpc.soap package, which relies on the JAXM javax.xml.soap package.

JAX-RPC defines three different client APIs. The generated stub API relies on a WSDL-to-Java mapping tool to generate a proxy object that implements the SOAP interface code. This proxy object, which is bound to a specific binding and transport, is included in the client application. The dynamic proxy API generates the client proxy object from the WSDL at runtime. A dynamic proxy binds to the specified binding and transport at runtime. Both the generated stub and dynamic proxy APIs require the client application to know capabilities of the service at development time. The dynamic invocation interface (DDI) API allows an application to access a previously unknown service. It reads a WSDL file at runtime and dynamically constructs method invocations.

API Readiness and Adoption
The JAXM 1.0 specification was released in November, 2001. To date there are two SOAP implementations that provide some level of support for this specification: the JAXM reference implementation (included in Sun's Java XML Pack), and Systinet WASP. Both are available as early-access releases. The JAX-RPC API was still in development as of March, 2002. The most recent release of the specification, 0.7, was published in February. To date there are two SOAP implementations that provide some level of support for this specification: the JAX-RPC reference implementation (included in Sun's Java XML Pack) and Apache Axis. The JAX-RPC RI is an early-access release. Apache Axis is available as an alpha release. Given that the specification is still changing, you should expect it to take a few months before any of the other Web service platform vendors adopt JAX-RPC.

Personally, I'm a big fan of JAX-RPC, and I'm looking forward to its completion. It would be nice, though, if the spec stopped at the client APIs and didn't attempt to define behaviors on the server side. For example, JAX-RPC defines a general-purpose mechanism called a message handler that allows you to intercept SOAP processing to bypass, alter, or add processing behavior. While it's necessary to have a mechanism to intercept SOAP processing, this "back door" approach is pretty crude and not particularly useful. First, it restricts the architectural design of a SOAP implementation, and second, the handlers are so completely undefined that they will never be portable across SOAP implementations.