Most Java clients for SOAP which exploit Apache SOAP for Java look something like the
GetAddress.java sample from Apache.
But if you look at the code, you will notice that most of it is intimately linked with the service's
deployment descriptor.
In fact, it is probably true to say that the client won't work if it is not coded according to
the contents of the deployment descriptor. For example, the Java code registering the type
marshallers is an exact transcription of the deployment descriptor.
For this reason, it seems quite reasonable to simplify SOAP Java clients by parsing the deployment
descriptor at the client side and wrapping the boilerplate code into a generic layer. Doing so means
that we:
- avoid duplicate code
- avoid run-time errors due to mismatches with the deployment descriptor
Here is how the simplified client
appears, when using the proposed generic layer. Note that this code can hardly be simpler.
The rationale here is "never state things twice". If the deployment desciptor describes the
service, use that instead of hard coding the details into the client.
The source code for the generic client is in
SoapClientHelper.java
Explanations
The generic client layer uses 2 mechanisms:
- parsing the deployment descriptor
- using the JDK 1.3 Proxy functionality
For simplicity, we assume that the client is not multithreaded. In the event
that it should be, some sections would have to be synchronized. Each
"Service" (i.e. each Interface) has an associated "ServiceData", for lack of a
better term, whose purpose is making the service method calls. Services methods are
stored in a map indexed by the interface. In our example, we only have one service
method.
The deployment descriptor parsing phase creates a "ServiceData" for each Service.
The handling of the namespaces is rather crude, but it illustrates the essentials. The
ServiceData contains an "InvocationHandler" which is the key feature of dynamic invocations
(also known as a "Proxy"). For more information on Proxies, you can read the
Proxy specification from Sun Microsystems.
The generic clients first creates a Service instance, which returns a Java
Proxy to the given interface. The client code is now free to call any method of
the interface, as it would in a normal situation, this is the power of Proxies!
Finally, note that all exceptions thrown by the SOAP layers are wrapped
into a
SoapClientHelperException.java for rationalisation.
Conclusion
Using a generic layer is the first thing that comes to mind when we code such
remote invocations. After all, this is like using RMI or CORBA, for which the generic
machinery has been around for years.
