There are three ways to create SOAP clients using Axis tools (following the JAX-RPC standards):

1. Generated stubs (just what you’d expect—code generated at runtime). This is done using the WSDL2Java tool.
2. Dynamic invocations which builds the request dynamically using the Service and Call objects. The service specifies the endpoint and the call is used to invoke the service.
3. Dynamic stubs which generates the code automatically at runtime.

Axis supports RPC, Document, Wrapped (root element corresponds to method name), and Message styles of interaction. The last one, message, is Axis-specific and passes XML to a method. Wrapped provides some minor benefit over Doc-literal in that it puts the method being called front and center in the SOAP. It’s not clear to me from the tutorial why the message style is desirable. not surprisingly, Odysseas recommends using the Doc style and discourages use of the RPC style.

The architecture of Axis is based on a chain of “handlers”. Message context provides a uniform contents within the chain. The context contain the request message, properties (like information from the HTTP or other transport headers), the response message, and some hard-wired properties (mainly a performance issue).

A handler is invoked with the message context as its sole argument. Handlers also have initialization and cleanup methods. Handlers don’t have to be thread safe because there is a handler instance created per service request as long as the scope is set to “request” when the handler is added to the server. If you specify the scope as “application” or “session,” then the handler should be thread safe.

The Axis architecture has a key concept called the “pivot point” which is the place where the actual Web service is invoked. Before that point, Axis is processing a request. After that point, Axis is processing a response.

A chain is a sequence of one or more handlers. A chain is really just a handler itself. When you invoke its “invoke” method, it invokes the methods for each of its members. As special chain, called the “targeted chain” is the chain that contains the pivot point.

Messages pass through three primary phases on their way in and out of Axis: transport, global, and service. The transport phase is, obviously, where transport related handlers are placed. The global phase is where handlers that apply globally to the all services are placed. The service phase is the targeted chain (where the service is invoked). All of this is configured in an XML-formatted configuration file. When a service is deployed, you can specify changes, handlers, scoping, and customer encoding/decoding.

At present Axis supports HTTP, JMS, Mail (SMTP/POP3), and Java (for testing) as transports. New transports can be added by users.

tcpmon is a tool for monitoring SOAP message flow. It functions as a proxy and listens to and logs requests and responses. There’s also something called a SOAP monitor that runs as an applet on your browser.

jUDDI is the Apache UDDI registry. jUDDI is an J2EE application and so must be deployed on a J2EE container. The registry uses an external database and can use LDAP or other enterprise IdM system or authentication.

Apache has an addressing project to add support for WS-Addressing to Axis. WS-Addressing generalizes addressing from a URL for transports that don’t understand URLs. As a SOAP message moves from invocation to service endpoint, it may traverse multiple intermediaries and you may not be able to control the transport that these intermediaries use. WS-Addressing ensures that critical information isn’t carried only in the HTTP header where it could be lost in these transitions.

The original implementation for WS-Addressing in Axis was a pair of handlers, but its now a pair o JAX-RPC handlers, which reduced the dependency on Axis. The current implementation is a little behind the latest spec.

Apache is also providing support for WS-ReliableMessaging (WS-RM) in Axis through a project called Sandesha. WS-RM is based on establishing a message sequence between the client and service endpoint. The sequence is created in response to a request from the client to the server. Delivery policies are negotiated between the client and the service endpoint.

For WS-RM to work, it has to be supported on the server and client side. Sandesha, therefore provides handlers on the the Axis side, but also libraries that must be used on the clients side.

Overall, there was some good information in this tutorial, but it was pretty low-key. I would have preferred to see more demos, for example, showing how these worked, or adding new handlers, etc. In general these tutorials are a lot more interesting when you show people how to do something rather than just giving out information. I’ve been guilty of that myself.