With these modes, JAX-RPC supports two types of Java client applications - namely, static client and dynamic client. In this article, we will see how both Java clients can be written or generated using synchronous request-response mode on the WebLogic platform.

Parameter Modes
The Web service invocation based on JAX-RPC uses pass-by-copy semantics for parameter passing. It does not support the pass-by-reference way of parameter passing. The following types of parameters are supported by jax-rpc:

The parameter passing mode for out and inout parameters uses holder classes. Holder classes enable the mapping to preserve the intended WSDL signature and parameter-passing semantics. The JAX-RPC specification includes "holder classes" for the mapping of simple XML types to the Java data types. The holder classes for primitive ones (e.g., int, float, etc.) are available with JAX-RPC implementation under the avax.xml.rpc.holders package. For the complex XML data types, the name of the holder class is constructed by appending Holder to the name of the corresponding Java class. These generated holder classes are packaged as part of the generated subpackage named holders in the WSDL-to-Java mapping.

Each holder class provides the following methods and fields:

Web Service Invocation
BEA WebLogic 7.0 comes with a JAX-RPC 1.0-compliant runtime engine, which has both client-side and service-side libraries and deployment tools. Figure 1 shows a normal Web service invocation flow for synchronous request-response mode. The client application uses WebLogic's JAX-RPC runtime to perform a remote procedure call to invoke a method on the Web service. The runtime serializes Java objects to the SOAP message, which is sent to the Web service end point using HTTP transport. On the Web service side, WebLogic Platform receives this request and the service side JAX-RPC runtime deserializes the SOAP message into Java types and invokes the method on the Web service. The Web service, after processing the request, sends the response back to the client in a similar fashion.

I have explained the simple Web service invocation based on JAX-RPC. The remainder of this article develops a sample Web service, and a static and dynamic client for it, on the WebLogic platform.

An Order Processing Web Service
I chose an order processing example for its proximity to a real busines-use case. This Web service will be capable of processing and updating a given "Order" using two methods - processOrder and updateOrder. ProcessOrder will take orderID string as an IN parameter and Order object as an OUT parameter. It will return status string as the return parameter. The updateOrder will take Order object as the INOUT parameter, update the orderDate, and return the Order object back to client. As both methods use a complex datatype, Order, that is also an OUT/INOUT parameter, a holder class has to be developed. The Order class and its holder class are shown in Listings 1 and 2 (the complete code can be found on the Web at www.sys-con.com/weblogic/sourcec.cfm):

Now let's develop our Web service for the described functionality. The code is shown in Listing 3.

The next step is to compile and deploy it on the WebLogic platform. WebLogic comes with some easy-to-use deployment tools using Ant (Apache's build tool) and includes predefined tasks for deploying the service on WebLogic Server 7.0. The sample "build.xml" is shown in Listing 4. This build file will generate an EAR file that will store information about the service endpoint, deployment descriptor (web-services.xml), and serializer and deserializer code (OrderCodec class); and will even generate a static client in the sample.client package and bundle it in a JAR file. The deployment descriptor (web-services.xml; it can be found in 'web-services.war' in 'ws_order.ear') has to be changed for the style of the parameter so the first method is OUT and the second method is INOUT. Once these changes are complete, repackage whole files into the EAR file (ws_order.ear) and deploy it using WebLogic's admin console. The OrderProcessing service will be available at the following URL:

http://<your_machine_name>:<port-num>/
<contextURI>/<serviceURI>

In our case it may look like :

http://localhost:7001/WebServices/OrderProcessing

OrderProcessing Web Service Clients
Static Client
The static client to invoke a Web service uses a more strongly typed Java interface. On WebLogic, writing a static client is really easy as the Ant tasks specified above generate the client JAR, which has the following:

A client application has to use the generated classes in the client JAR. The static client is invoking the processOrder () method of the OrderProcessing Web service (see Listing 5).

Dynamic Client
A dynamic client is analogous to looking up and invoking the Java class methods using the reflection APIs. All the information like target endpoint and method parameters must be set explicitly. Listing 6 shows you how to write a dynamic client for invoking the updateOrder method OrderProcessing Web service.

Running the Client
For running both types of client, set the environment using a WebLogic-specific "setWLSEnv.bat" file. This .bat/.sh will set the classpath variable to include JAX-RPC-related jar files. Additionally, we have to add a client-specific JAR file generated by running the ant task earlier. After the environment is set, simply give the following commands:

For the static client:
<prompt>java sample.client.StaticClient

For the dynamic client:
<prompt>java sample.client.DynamicClient

Conclusion
In this article I tried to demonstrate how to develop JAX-RPC-based Web services. The method described here gives the developer the freedom to write client and Web services in a way that hides all the complexities of serializing objects on-the-wire XML format. For the developer, it will simply appear to be a Java method invocation. This article also highlights how easy it is to expose a given "Java class" as a Web service.

References