email article printer friendly get the code more resources

Grasping Handlers
Define a complete service that demonstrates just how useful JAX-RPC handlers can be for you
by Sameer Tyagi

September 10, 2003

Editor's Note: This is the second of three installments on JAX-RPC handler classes by Sameer Tyagi. The first installment, "Handle Your JAX" (Java Pro Online, August 25, 2003), began the discussion with a look at how handlers plug into the JAX-RPC architecture, compared the life cycle of a handler instance to that of a servlet, and outlined the order in which handlers are deployed. In this installment Tyagi discusses defining a complete service to demonstrate handlers' usefulness.

To understand the concept of handlers further, let us develop a complete service and see how handlers can prove useful. At present JAX-RPC has no provision for encrypting and securing the content of the SOAP message itself. It relies on the HTTPS protocol to secure the content on the wire, though additional security mechanisms will probably be introduced in JAX-RPC 2.0. We will develop a "content service" that accepts business documents (or any other binary/text content) and stores them on the server. Assuming that this content is large and contains sensitive business information, we will show how a handler can be implemented on both client and server sides to first compress that information and then encrypt it using password-based symmetric ciphering (PBEWithMD5AndDES) before including it in the SOAP message.

The client-side handler intercepts the request, compresses the outgoing data, and encrypts the data using a symmetric cipher. We will use the Java Cryptography Extension (JCE) API—bundled with JDK 1.4 and also available separately for use as an optional package to the Java 2 SDK, versions 1.2.x and 1.3.x—for all our security algorithms. Once the handler is done with the encryption, it places the data back in the SOAP message and sends the request on its way to the service.

When using handlers the development approach in starting with the Java code remains the same (recall that you can also take an existing WSDL and develop both the service and the client from that in JAX-RPC). We write the service definition, the service implementation and the handlers, and then deploy the service.

The term service definition is used to refer to the abstraction that defines the publicly surfaced view of the service. The service definition is represented as a Java interface that exposes the operations for the service. The service definition is also called a remote interface because it must extend the java.rmi.Remote interface, and all methods in it must throw a java.rmi.RemoteException (see Listing 1).

The service implementation, also known as a servant is the concrete representation of the abstract service definition; it is a class that provides the implementation for the service definition. The Java class must have a default constructor and must implement the remote interface that defines the service. When using handlers the service implementation does not require any additional code or modification. In fact, the service implementation is not aware of any of the changes (compression, encryption, decryption, and decompression) that have been applied to the SOAP message between the time the client initiated the request and the time it was processed.

The service implementation contains the acceptContent() method that accepts raw bytes and writes them out to a file called Myfile.doc (see Listing 2).