WebReference.com - Part 4 of chapter 3 from Professional Java Web Services, Wrox Press Ltd. (1/6)

Developing SOAP Services

[The following is a continuation of our series of excerpts from chapter 3 of the Wrox Press title, Professional Java Web Services. The code for the examples discussed in this excerpt can be downloaded from the Wrox Web site (free registration required).]

In this section we will dive into the details of creating a SOAP service. In this section we will discuss:

Apache SOAP Architecture

Pluggable Provider Architecture

Service Implementation Class

Type Mapping (including serialization)

In order to illustrate some of topics discussed in the chapter we will look at parts of the Job Resumé Repository System that was introduced in the previous section.

Apache SOAP Architecture

The Apache SOAP server-side facilities allow code artifacts to be accessible from SOAP clients without the code artifacts having to be SOAP-aware. This means that no code has to be added to code artifacts to make them work with Apache SOAP. So in essence, the server-side facilities of Apache SOAP act as a bridge between SOAP clients and code artifacts. The following diagram illustrates this:

To help explain how this works let's go through the process of accessing a standard Java code artifact:

The Apache SOAP run-time environment has to be configured to route requests to a particular code artifact. This is known as service registration or deployment. This is done using the command-line tool or the web-based administration tool that's provided with Apache SOAP. We discussed both methods in the Deploying and Running a "Hello World" Service section.

An Apache SOAP client or another SOAP 1.1-compliant SOAP client sends an RPC-based SOAP request message to the Apache SOAP runtime. This request contains the name of the service and the name of methods to invoke.

The Apache SOAP runtime validates that the service is registered and that the requested methods are marked for exposure to SOAP clients. If either validation fails, a SOAP Fault message is sent back to the SOAP client.

The Apache SOAP runtime dispatches the RPC method request to the code artifact.

The code artifact processes the method call and sends back a return value to the Apache SOAP run-time environment.

The Apache SOAP runtime packages the return value in a SOAP response message and sends it back to the client.

Pluggable Provider Architecture

Code artifacts are supported within Apache SOAP through the Pluggable Provider architecture. This is a layer of abstraction between the Apache SOAP runtime and the components that know how to interact with the code artifacts, which are called Providers. A Provider is a Java class that is responsible for locating, loading, and invoking a code artifact. It also is responsible for packaging the return value into a SOAP Envelope when necessary. Apache SOAP provides Providers for each one of the default code artifacts. Below is a diagram of the architecture:

The architecture also provides support for User-Defined Providers; these are Providers that can be developed to handle other code artifacts. This would be useful if we had some code artifacts that we developed in a non-Java language that we wanted to make available as a service and we didn't want to invest the time or money in converting them to Java. For example, we might have some C++ classes that contain functionality that we want to make available as a service. Instead of rewriting the classes we could develop a Provider that knows how to handle C++ code artifacts. Likewise, we could write a Java Messaging Server (JMS) provider.