Writing a JAX-RPC client to an Axis2 web service

1. Deploying the Axis2 Service

Download and launch Apache Axis2 - it comes with a sample web service which is by default available at http://localhost:8080/axis2/services/Version - we will be using this as the service to write our JAX-RPC client.

2. JAX-RPC

JAX-RPC is intended to be a Java API to expose remote procedure calls that use XML to business applications and it facilitates the invocation of remote procedures using XML as the data format and SOAP as the data protocol. The overhead in developing JAX-RPC clients is minimal since the API it self abstracts and hides the low level SOAP semantics associated with RPC from applications.

3. Axis2 and JAX-RPC

Although Axis [version - 1] had support for JAX-RPC - Axis2 does not. Axis2 has the support for JAX-WS - JAX-WS 2.0 is the successor of JAX-RPC 1.1 - the Java API for XML-based Web services. If possible, JAX-WS should be used instead as it is based on the most recent industry standards.

4. JAX-RPC client

First we need to generate the Stub classes for the service we are going to invoke. This can be done using the wscompile tool. The tool is available with the GlassFish distribution.

wscompile tool needs a configuration file as an input - which dictates where to find the corresponding WSDL and the required package names for the stubs to be generated. Let's first create that config file, say version-config.xml
<configuration xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
 <wsdl location="http://localhost:8080/axis2/services/Version?wsdl" packageName="org.wso2"/>
 </configuration>
Now lets generate the stubs with the wscompile tool. 
$ pwd
/Users/prabath/blog/jax-rpc
$ sh ~/glassfishv3/glassfish/bin/wscompile -gen:client version-config.xml
$ jar -cvf version-stub.jar *
Following is the client code - and you need to have version-stub.jar, which was generated in the previous step and javaee.jar from [GLASSFISH_HOME]/glassfish/lib
package jax.rpc.client;

import javax.xml.rpc.Stub;

import org.wso2.VersionPortType_Stub;
import org.wso2.Version_Impl;

public class VersionClient {


 public static void main(String[] args) {

  try {
   Stub stub = createProxy();
   stub._setProperty(javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,
     "http://localhost:8080/axis2/services/Version");
   VersionPortType_Stub hello = (VersionPortType_Stub) stub;
   System.out.println(hello.getVersion());
  } catch (Exception ex) {
   ex.printStackTrace();
  }
 }

 private static Stub createProxy() {
  return (Stub) new Version_Impl().getVersionHttpSoap11Endpoint();
 }

}
5. JAX-RPC Vs JAX-WS

JAX-WS still supports SOAP 1.1 over HTTP 1.1, so interoperability will not be affected. The same messages can still flow across the wire.

JAX-WS still supports WSDL 1.1 so what you've learned about that specification is still useful.

What are the differences?

SOAP 1.2
JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.

XML/HTTP
The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-RPC ignored the HTTP binding. JAX-WS adds support for it.

WS-I's Basic Profiles
JAX-RPC supports WS-I's Basic Profile (BP) version 1.0. JAX-WS supports BP 1.1. (WS-I is the web services interoperability organization.)

New Java features
JAX-RPC maps to Java 1.4. JAX-WS maps to Java 5.0. JAX-WS relies on many of the features new in Java 5.0.
Java EE 5, the successor to J2EE 1.4, adds support for JAX-WS, but it also retains support for JAX-RPC, which could be confusing to today's web services novices.

The data mapping model
JAX-RPC has its own data mapping model, which covers about 90 percent of all schema types. Those that it does not cover are mapped to javax.xml.soap.SOAPElement.
JAX-WS's data mapping model is JAXB. JAXB promises mappings for all XML schemas.

The interface mapping model
JAX-WS's basic interface mapping model is not extensively different from JAX-RPC's; however:
JAX-WS's model makes use of new Java 5.0 features.
JAX-WS's model introduces asynchronous functionality.

The dynamic programming model
JAX-WS's dynamic client model is quite different from JAX-RPC's. Many of the changes acknowledge industry needs:
It introduces message-oriented functionality.
It introduces dynamic asynchronous functionality.
JAX-WS also adds a dynamic server model, which JAX-RPC does not have.

MTOM (Message Transmission Optimization Mechanism)
JAX-WS, via JAXB, adds support for MTOM, the new attachment specification. Microsoft never bought into the SOAP with Attachments specification; but it appears that everyone supports MTOM, so attachment interoperability should become a reality.

The handler model
The handler model has changed quite a bit from JAX-RPC to JAX-WS.
JAX-RPC handlers rely on SAAJ 1.2. JAX-WS handlers rely on the new SAAJ 1.3 specification

Reference : http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc.html

Labels: