Copyright  2001-2007 Nicholas Quaine.
Home   Basics   ServerSide   ClientSide   Demos   FAQ   Resources
About this site
About the authors
Contacting us
Partner Sites

Simplifying your Java SOAP Client

Most Java clients for SOAP which exploit Apache SOAP for Java look something like the 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


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 for rationalisation.


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.

[ Nicolas Gouteux ]

Copyright 2001-2007 Nicholas Quaine. All rights reserved.