Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: 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.

    IoT & Smart Cities Stories
    The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
    DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
    All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
    CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
    The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
    SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...