Michael Gilbode

Subscribe to Michael Gilbode: eMailAlertsEmail Alerts
Get Michael Gilbode: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, Java Developer Magazine

J2EE Journal: Article

Using SOAP Message Handlers with WebLogic 7

Using SOAP Message Handlers with WebLogic 7

WebLogic Server provides mechanisms to expose standard J2EE components and Java classes as Web services. It typically processes an RPC-style Web service by determining the operation to invoke from the SOAP message, deserializing the operation's parameters in the SOAP message to Java, and then invoking the back-end component.

Sometimes, however, this behavior is not sufficient and a Web service needs access to the SOAP message. SOAP message handlers can intercept SOAP messages in both the request and response to do additional processing of the SOAP message. SOAP message handlers are defined by the Java API for XML-based RPC (JAX-RPC). Handlers enable programmatic access to the SOAP message and are often used to process SOAP message headers. SOAP message headers may contain information about such things as transactions, security, and routing. Processing specific to these headers can be done in SOAP message handlers. Handlers can also be used to add functionality such as caching, encryption and decryption, logging, and auditing to a Web service. Handlers may also be used to process SOAP attachments.

Each WebLogic Web service consists of one or more operations. Operations can be implemented using a combination of back-end components and SOAP message handlers. WebLogic supports Web service operations that are implemented with back-end components only, back-end components and SOAP message handlers, and SOAP message handlers only.

SOAP message handlers are assembled into handler chains - ordered lists of SOAP message handlers that can be applied to the service client or the service endpoint. A WebLogic Web service can optionally define one or more handler chains. These handler chains are then associated with appropriate Web service operations.

Internally, WebLogic Web service operations are implemented as handler chains. The handler chain begins with an authentication handler, followed by any user-defined handlers, then optionally by a component invocation handler that can invoke a back-end component.

Message Handler Life Cycle
SOAP message handlers must be implemented as stateless instances. The JAX-RPC runtime system considers all instances of a particular handler class to be equivalent. This allows the JAX-RPC runtime system to pool handler instances, although this is not required.

The life cycle of a handler consists of two states. A handler either does not exist, or is in a ready state. A handler instance has two life-cycle methods. The init() and destroy() methods allow initialization of the handler when the handler instance is created, and cleanup when the handler instance is destroyed.

Once a handler is in its ready state, its various handle() methods can be invoked. On a service client the handleRequest() method is invoked before the actual SOAP message is sent, and the handleResponse() method is invoked before the actual response is received. On a service endpoint, the handleRequest() method is invoked before the actual service endpoint is invoked, and the handleResponse() method is invoked before the actual response is sent to the client. On a service client the handleFault() method is called before receiving a SOAP fault, and on the service endpoint the handleFault() method is called before generating a SOAP fault.

Designing the Message Handler
When you design SOAP message handlers you must decide the number of handlers, the order in which the handlers will be executed, and whether to invoke a back-end component.

Any arbitrary number of handlers can be configured on both the service client and the service endpoint. The order in which handlers are invoked is significant. For example, consider a handler chain on a service endpoint that is configured with an encryption handler and a caching handler that inspects the SOAP message payload. In order for the caching handler to be able to read and process the message, the encryption and decryption handler must have already decrypted the SOAP message.

A SOAP operation in a WebLogic Web service may or may not be designed to invoke a back-end component. However, a message handler can change this behavior at runtime. A handler can prevent back-end components from being invoked by returning false from its handleRequest() method. In fact, this prevents any of the rest of the handler chain from being invoked. Further processing of the handler chain can also be prevented by returning false from the handleResponse() and handleFault() methods. For example, consider a caching handler. If the incoming request has cached results, the cached results could be returned and further processing of the handler stopped. The following code shows an example of this:

public boolean handleRequest(MessageContext context) {
SOAPMessageContext smc = (SOAPMessageContext)context;
if (Cache.exists(smc.getMessage())) {
return false;
return true;

SOAP message handlers in a handler chain can also share state with each other. Each of the handle() methods in a handler class accepts a MessageContext as a parameter. The MessageContext instance that is passed to the handle() methods is shared among all handler instances in the handler chain for a single request, response, or fault processing on a service endpoint. Listing 1 shows two handlers that share a property named "myProperty". Handler1 sets this property, and Handler2 uses this property.

Features such as aborting the handler chain processing by returning false in a handle() method and sharing state among handlers introduce interdependencies between handlers in a handler chain. These interdependencies should be planned for and designed in advance because they affect how the SOAP operation is processed.

Implementing the Message Handler
A JAX-RPC handler must implement the javax.xml.rpc.handler.Handler interface. To make handler development easier, JAX-RPC provides the javax.xml.rpc.handler.Generic Handler abstract class. This class provides default implementations of the life-cycle methods and the different handle methods. Only the methods required for the specific handler implementation should be overridden.

The life-cycle methods of a handler should be used to initialize and clean up resources within a handler instance. If a handler makes use of a resource such as a database connection, this can be established in the init() method and cleaned up in the destroy() method.

Handlers can also obtain configuration information when they are initialized. This configuration information is passed as a part of the HandlerInfo object that is passed to the init() method of the handler instance. For example, a logging handler may be given information such as severity level and log directory in its configuration. This would be obtained as follows:

public void init(HandlerInfo handlerInfo) {
Map handlerConfig = handlerInfo.getHandlerConfig();
String severityLevel = (String)handlerConfig.get("severityLevel");
String logDirectory = (String)handlerInfo.get("logDirectory");

The handleRequest() and handleResponse() methods may be invoked in a different context depending on whether the handler is deployed on a service endpoint or a service client. This may be important for handlers such as encryption handlers. On the service client the handleRequest() method should encrypt the message and the handleResponse() method should decrypt the message. However, on a service endpoint, handleRequest() should decrypt the message, and handleResponse() should encrypt the message. This can be handled by creating client handlers and service handlers. However, since the behavior is essentially the same, this can also be accomplished by passing configuration information to the handler to tell it whether it is on a service client or service endpoint. (Source code listing EncryptDecryptHandler.java shows an example of this; the source code for this article can be found at www.sys-con.com/weblogic/sourcec.cfm).

Configuring the Message Handler
WebLogic Web services are configured using a deployment descriptor file. This file is named web-services.xml and is deployed in the WEB-INF directory of the WAR file that is hosting the Web services. Web service operations, back-end components that implement the Web service, and handler chains associated with the Web service are specified in this file.

This file is relevant to SOAP message handlers in that it is used to define handler chains, pass configuration information to handlers, and associate handler chains with Web service operations. Handlers and handler chains are defined in the handler-chains section of the Web service deployment descriptor. The handler-chains section contains one or more handler-chain definitions, each of which contains one or more handler definitions. Listing 2 is an example of a handler-chains section of a web-services.xml file. (A complete example is shown in the source code file web-services.xml.} This deployment descriptor defines a single handler chain named "MyHandlerChain" that contains a single handler. The information contained in the handler elements is used to create the javax.xml.rpc.HandlerInfo instance that is passed to the init() method of the handler instance. The parameter names and values defined in the init-params section of the descriptor are put into a Map, which is available through the getHandlerConfig() method of the HandlerInfo instance. This allows a handler instance to obtain configuration information at deployment time.

Using SOAP Message Handlers on the Client
The web-services.xml file is used to configure message handler chains and associate them with SOAP operations on the server. However, handlers can also be used on the service client. The JAX-RPC specification does not specify any standard packaging and deployment model. This work is currently under development in the J2EE 1.4 specification and JSR 109. Since there is no current standard client container for JAX-RPC Web services, SOAP message handlers must be configured programmatically on the service client.

In order to associate a handler chain with a Web service, the developer must programmatically crate the handler chain. A handler chain is simply a list of HandlerInfo objects. Listing 3 shows how to configure a log handler on a client. (A complete listing is shown in the source code Main.java.)

Packaging the Web Service
WebLogic Web services are packaged as standard J2EE applications. The following steps should be taken to assemble a WebLogic Web service that uses message handlers:
1.   Create web-services.xml file
2.   Compile handler classes
3.   Build Web application: Place web-services.xml file into WEB-INF directory of the Web application and the handler classes into WEB-INF/classes.
4.   Build an enterprise application: The Web services Web application should be included in the enterprise application.
5.   Deploy the enterprise application to WebLogic Server: The source code file build.xml shows an example of an Ant script to assemble a Web service that invokes a handler chain and a that component.

SOAP message handlers provide a standard, flexible method for implementing Web Services. They allow additional processing when exposing a back-end component as a Web service without requiring modification of the back end component. SOAP message handlers can be very useful when implementing WebLogic Web services.


  • SOAP 1.1 specification: http://www.w3.org/TR/2000/NOTE-SOAP-20000508
  • JAX-RPC 1.0 specification: http://java.sun.com/xml/downloads/jaxrpc.html#jaxrpcspec
  • JSR 109 - Implementing Enterprise Web Services: ftp://www6.software.ibm.com/software/ developer/library/ws-jsr109-proposed.pdf
  • JSR 151 - J2EE 1.4: http://java.sun.com/j2ee/j2ee-1_4-pfd-spec.pdf
  • More Stories By Michael Gilbode

    Mike is an architect for Anexinet Corp. in Philadelphia, PA. Mike is experienced in large scale J2EE projects built on the BEA WebLogic Platform.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.