Java Web Service clients

Service lookup

There are two families of Web Service clients which differ in the way code is written and services are invoked:

Unmanaged clients i.e. J2SE or J2ME clients ==> Service lookup is through the JAX-RPC ServiceFactory, a factory for the creation of instances of services access points. {JSR 101: "The JAX-RPC ServiceFactory is the standard way to look up Web services in a J2SE environment."}

J2EE container-managed clients ==> Service lookup is through JNDI lookup {JSR 109: "JNDI lookup is the standard way to look up Web services in a J2EE environment."}

JAX-RPC ServiceFactory

The JAX-RPC ServiceFactory is an abstract class which acts as a factory for instantiating JAX-RPC Services. It is vendor independent that helps writing portable code. The ServiceFactory is instantiated and used as follows:
javax.xml.rpc.Service service = ServiceFactory.newInstance().createService(...);

JNDI service lookup

J2EE container-managed clients are packaged into Enterprise Archives (.EAR) files and run from inside a J2EE container. In addition to the Java code, descriptors are also packaged into the archive. JAX-RPC defines the programming model for unmanaged clients, whereas JSR 109, "Implementing Enterprise Web services", defines the programming model for J2EE container-managed clients. One of the goals of JSR 109 is that its client programming model is compatible with JAX-RPC. However, JSR 109 does not recommend the use of the JAX-RPC ServiceFactory. It recommends clients use Java Naming and Directory Interface (JNDI) instead to obtain a Service Interface. This is a two steps process:

1) Instantiate a local JNDI Context ==> Context ic = new InitialContext();
2) Do a JNDI lookup for the Web service name in this context ==> Service service = (Service) ctx.lookup("java:comp/env/service/MyService");

The logical name of the Web service, in this case java:comp/env/service/MyService, is specified in the client application's deployment descriptor. JSR 109 recommends that all service reference logical names be organized under the service sub-context. With the client environment context being java:comp/env.

The JNDI lookup returns a JAX-RPC Service Interface. The J2EE container makes sure an implementation of the generic JAX-RPC Service is bound at the location specified in the deployment descriptor.

Service access

The J2EE container typically generates the service Interface Implementation, JAX-RPC Service, during deployment. The Service Interface Implementation acts as a factory for Service Endpoint Interface (SEI). A SEI is basically the Java representation of the Web service operations described in the WSDL port type element. The Service Interface Implementation must provide a static stub and/or dynamic proxy for all ports declared by the service element in the WSDL description. A container provider must support at least one of static stubs or dynamic proxies, but may provide support for both. When both are supported then the choice of generated stub or dynamic proxy is a deploy time binding information. IBM WebSphere 6 only provides support for static stubs. I think that it make a lot of sense as it is facter than dynamic proxies.

J2EE container-managed clients access and invoke Web Services as follow:

1. Get a JAX-RPC Service ==> Context ic = new InitialContext();
Service service = (Service) ctx.lookup("java:comp/env/service/MyService");
2. Obtain a SEI using the JAX-RPC Service's getPort() method ==> MyPort aPort = (MyPort) service.getPort(MyPort.class);
3. Invoke the Web Service operations ==> aPort.myOperation(myArg);

Unmanaged clients i.e. J2SE or J2ME clients use one of the three following methods for accessing and invoking Web Services:
• Stub
• Dynamic Proxy
• Dynamic Invocation Interface (DII).
See the following documents for more details about those three techniques:
· http://java.sun.com/webservices/docs/1.3/tutorial/doc/JAXRPC5.html
· http://www-128.ibm.com/developerworks/webservices/library/ws-javaclient/