IBM WebSphere Developer Technical Journal: A practical introduction to message mediation -- Part 1

The basics of message mediation

This article series explains message mediation, one of the new capabilities of IBM® WebSphere® Application Server V6. Part 1 covers the basics of message mediation, including how to develop, deploy, and test a simple mediation.


Dan Murphy (, Software Engineer, IBM Hursley, UK

Author photoDan Murphy works in IBM Hursley in the United Kingdom. He has been with IBM for more than 11 years and is currently a test designer and developer for WebSphere Messaging. He enjoys cooking good food and collecting edible mushrooms. Dan is very much looking forward to the forthcoming Saint George's Day mushroom crop. In order to counter his gourmand eating, Dan recently resumed his martial arts training with the IBM Hursley Karate club. Dan can be reached at

01 March 2005


Message mediation is one of the new capabilities of IBM WebSphere Application Server V6. A mediation is a programmable extension to the messaging capabilities of WebSphere Application Server that can simplify connecting systems, services, applications, or components that use messaging. A mediation is used to process in-flight messages. The type of processing a mediation can perform include:

  • Modifying or transforming a message.
  • Routing messages (or cloned messages) to other or additional destinations.
  • Allowing or disallowing a message to be delivered based on some conditional logic in the mediation.

WebSphere Application Server V6.0 provides a mediation framework runtime that enables you to mediate messages. Both IBM Rational® Application Developer (hereafter called Application Developer) and the WebSphere Application Server Toolkit provide you the tools needed to develop, assemble and test mediations.

Part 1 of this series of articles explains the basics of message mediation. Subsequent articles will build on this to encompass routing messages, simple modification of payload, transformation of messaging using XSLT, and request/reply message processing. To follow this article, you will need to install one of the following software combinations:

  • IBM WebSphere Application Server Toolkit Version 6.0 and WebSphere Application Server V6.
  • IBM Rational Application Developer V6, including the integrated WebSphere Application Server V6.0 test environment.
  • IBM Rational Application Developer V6 and WebSphere Application Server V6.

The screen images that appear in this article are from Rational Application Developer V6. (A trial version of this software is available for download.) If you use the WebSphere Application Server Toolkit, you can still use the steps documented here, as they are identical for both Application Developer and the toolkit. You can install the WebSphere Application Server Toolkit from the WebSphere Application Server installation media or images.

This article assumes familiarity with messaging technologies (such as JMS or Web services), Eclipse-based tooling, and the ability to develop and deploy J2EE applications using these tools. If you have previously used WebSphere Studio Application Developer Version 4 or 5 to develop J2EE applications, you already have the required skills.

Why use mediations?

There are a number of considerations when deciding if mediations are the right solution for you. It is already possible to write a message-driven bean (MDB) to transform messages between different formats, so why choose a mediation?

The most obvious reason for using mediations is that they preserve message identities. If your MDB resends the message after you had manipulated its body, you are actually sending a new message. As a result, the message ID of the new message would be different than that of the original message. This would cause problems if you tried to correlate sent and received messages. Other message properties, such as the expiry or message timestamp will be reset or overwritten when the new message is sent.

Another reason for choosing a mediation over a message-driven bean is that mediations are not tied to a specific messaging technology. When writing an MDB you need to implement specific Java\u2122 interfaces depending on the type of message it will process. An MDB that processes JMS messages would implement the javax.jms.MessageListener interface. Other interfaces would be implemented for Web service-based MDBs, and additionally require an appropriate resource adapter:

  • javax.jms.MessageListener -- Used for standard JMS messaging. In this case the MDB is passed a javax.jms.Message object when the container invokes the onMessage() method.
  • javax.xml.messaging.OnewayListener -- Used for one way Web services. The MDB is passed a javax.xml.soap.SOAPMessage when the container invokes the onMessage() method.
  • javax.xml.messaging.ReqRespListener -- Again, used for request/reply Web services. The difference here is that the onMessage() method also returns a SOAPMessage which is returned to the Web service client.

While you could develop a class that implements all three interfaces, you end up with quite a lot of technology-specific code for accessing and processing the actual messages. However, the mediation programming model provides a Service Data Object (SDO) interface to all messages and a common API for accessing properties and metadata.

In summary, a mediation should be used when you need to transparently modify or route messages. And since the same mediation can operate on Web services or JMS messages, there are more opportunities for reuse.

When can you mediate and what happens when you do?

You can mediate inbound or outbound services, queues, and topic spaces. In short, you can mediate just about any type of destination in the service integration bus. When you mediate a destination, it will be split in two parts: pre- and post-mediated. The mediation will be delivered messages from the pre-mediated part of a destination.

Once processed, and assuming the message is not redirected or consumed, the message is placed on the post-mediated part. The message is now available to be delivered to a message consumer, such as a service provider or an MDB. The splitting of destinations to form pre- and post-mediated parts ensures that a mediated destination has the same quality of service as an unmediated destination.

When a mediation is applied to a destination, it is invoked after the message has been put to the destination, but before it is received or delivered from a destination.

Mediation programming model

The mediations programming model is based around four interfaces:


Your mediation handler must implement the MediationHandler interface. When a message arrives that needs to be mediated, the mediation framework will invoke the handle(MessageContext) method on it. An instance of the mediation handler may be reused, exactly like a stateless session EJB. As such, your mediation handler should not maintain state information within its instance.

When deploying a mediation, the administrator is able to choose if the mediation supports concurrency. If selected, the framework may simultaneosly invoke the handle() method on difference instances of the mediation from multiple threads. Therefore, when you code a mediation, you should ensure that the instances of the class are threadsafe. If you allow concurrent processing of messages, the order of message delivery is no longer guaranteed. These are all standard considerations for J2EE developers.

The javax.xml.rpc.handler.MessageContext parameter, passed when the handle() method is invoked, will actually be an instance of This interface allows access to the message. It also provides other mediation-specific operations or attributes.

Mediation handlers

A mediation handler is invoked and passed a message context when a message needs mediating. The handler returns a boolean value to indicate if the message should continue in the bus. In the majority of cases, your mediations will return true. If you return false, the message is not processed further nor delivered, and will be discarded. You could use this, for example, to check for and remove invalid messages before they are received by a consuming application or service.

Using the message context you can access the following:

  • Message payload and message meta data.
  • Context properties, which provide access to configured name value pairs.
  • Message services, using the mediation session; for example, to send messages to other destinations.

Mediation handlers are Java™ classes that implement the interface. These classes are then assembled as Enterprise Application Archives (EARs) which are deployed by the administrator.

Mediation handler lists and mediations

You assign mediation handlers to one or more mediation handler lists along with a sequence number. When the administrator configures a mediation, they will specify the name of the handler list. The mediation handlers contained in the mediation handler list are invoked in their specified sequence. This concept is illustrated in Figure 1.

Figure 1. Conceptual mediation of messages
Figure 1. Conceptual mediation of messages

An administrator creates a mediation specifying the name of the mediation handler list they wish to use. The administrator then applies the mediation to one or more destinations. To aid reuse, each mediation handler should perform a specific task. You can then compose a number of handlers in handler lists. This process will define a set of operations that should be applied to each message.

An example of mediation handler composition is the use of a logging mediation handler. You could use this mediation when developing and testing other mediations. The logging mediation handler could then be invoked before and after other mediations. You could use this process to capture before and after images of messages that are processed by other mediation handlers.

In most cases, a single mediation handler per mediation handler list is sufficient. The tooling used to assemble mediation handlers into deployable components offers simple and advanced handler list configuration options. The simple configuration option automatically adds the mediation handler to its own mediation handler list.

Develop a mediation handler

Creating a mediation handler is a relatively simple task. Mediation handlers are simply Java classes that implement the mediation handler interface. To create and impement the handler, you will need to:

  • Create a Java project.
  • Target the project to a WebSphere Application Server runtime.
  • Create a handler class that implements the interface.
  • Write the actual mediation code to process messages.
  • Assemble the mediation handler into a deployable artifact (an EAR file).
  • Apply the assembled and deployed mediation to one or more destinations.

The mediation handler is then ready to be assembled into a deployable artifact (an EAR file). Once assembled and deployed, the mediation is applied to one or more destinations, then messages placed on the mediated destination are then mediated by the mediation handler.

The next sections will step you through the process of creating a sample mediation, one that writes information to the WebSphere Application Server logs. You could use this mediation to debug message flows in your environment. For example, it could be applied to a destination associated with a message-driven bean to provide information about messages before they are processed.

  1. Create a mediation handler project

    The first thing you will do is create a suitable project to contain your mediations. This can be achieved by creating either an EJB or Java project that can access the mediation framework interfaces:

    1. Start Application Developer. For the purpose of this exercise, the default workspace is acceptable.
    2. Create a new Java project called MessageMediation.
    3. Use the project context menu to select the project properties. This is achieved by right clicking on the Java project and selecting Project Properties from the menu.
    4. Select the Server property and then set the Target runtime to be WebSphere Application Server v6.0, as shown in Figure 2.
    Figure 2. Setting the target runtime using project properties
    Figure 2. Setting the target runtime using project properties

    The Java project you just created is now capable of accessing the mediation framework interfaces. The advantage of using a Java project, as opposed to developing the mediation handler directly in an EJB project, is that the Java project can easily be added to multiple Enterprise Application or Enterprise Java Bean projects.

  2. Create the mediation handler

    Using the new Java class wizard, create a class mediation.handlers.DebugMediation that implements the interface, as shown in Figure 3.

    Figure 3. Creating a new Java class
    Figure 3. Creating a new Java class

    This will create a skeleton class for the mediation handler. Edit the class and insert the following import statements:

    Listing 1.
    import java.util.Iterator;
    import java.util.List;
    import java.util.logging.Level;
    import java.util.logging.Logger;
    import javax.xml.rpc.handler.MessageContext;

    The handle(javax.xml.rpc.handler.MessageContext msgCtx) method is invoked when your handler is required to process an in-flight message. When invoked, the class is actually passed an object that implements the interface, which extends the javax.xml.rpc.handler.MessageContext interface. The SIMessageContext interface enables you to access:

    • Context properties.
    • Message and message meta-data.
    • A mediation session, used access services.

    Enter the following code into the "public boolean handle(MessageContext arg0) throws MessageContextException" method:

    Listing 2.
    boolean continueMsgProcessing = true;
    SIMessageContext siMsgCtx =     (SIMessageContext) msgCtx;
    if (log.isLoggable(Level.INFO)) {"Context Properties: " + getContextProperties(siMsgCtx));"Message Info: " + getMessageInfo(siMsgCtx.getSIMessage()));"Session Info: " + getSessionInfo(siMsgCtx.getSession()));
    return continueMsgProcessing;

    Obviously, this method is invoking methods that don't yet exist, so the class will not compile. In a moment, you will write implementations of these methods and learn how the MessageContext can be used. Before we move onto the mediation itself, you will need to enable the logging of data to the WebSphere Application Server log.

  3. Use java.util.logging to write to the WebSphere Application Server log

    We want our mediation handler to be able to log information to the WebSphere Application Server's log. This can easily be achieved using standard Java logging interfaces defined by JSR 47 and part of J2SE 1.4. Add the following code to the handler class:

    Listing 3.
    private String loggerName = "MsgMediation";
    private Logger log = Logger.getLogger(loggerName);
    private String className = DebugMediation.class.getName();
    public String getLoggerName() {
        return loggerName;
    public void setLoggerName(String loggerName) {
        this.loggerName = loggerName;

    Using this approach to logging enables you to easily switch off and on the logging of messages to the application server's log.

    As we will see later, providing set and get methods for the loggerName also enables the mediation framework to set the loggerName when the class is instantiated. The value set is contained in the deployment descriptor for the mediation handler. The same technique can be used to provide the mediation with managed object references, such as a data source that could be used to augment the message with other data.

    For more information on how to use standard Java logging inside WebSphere Application Server components, see the WebSphere Application Server Information Center reference on the subject.

  4. Mediation context properties, using SIMessageContext

    The MessageContext provides a means to access context properties. These properties can be set using the administration console so that a mediation can retrieve configuration and other properties that may affect the processing of the message.

    The sample mediation handler produces a string representation of all properties that have been set on the mediation. This is achieved by iterating though the properties names and returning them as a formatted String. Add the following method to your mediation handler class:

    Listing 4.
    private String getContextProperties(SIMessageContext msgCtx) {
        StringBuffer data = new StringBuffer();
        Iterator i = msgCtx.getPropertyNames();
        String propName;
        while (i.hasNext()) {
            propName = (String);
            data.append(propName); data.append(" = ");
            if (i.hasNext()) data.append(", ");
        return data.toString();
  5. Accessing messages and the SIMessage interface

    You can access the message to be mediated by using the getMessage() on the MessageContext that is passed to your mediation handler. This method returns an instance of a You may wonder why some type of JMS message isn't returned. The reason is that mediations are used with several types of messages, not just JMS messages. The SIMessage object is used to represent many different message types, including JMS and Web services formats.

    The SIMessage interface provides many operations you may want to make use of in your mediation. The API message ID can be set by a user application or component. In the case of JMS messages this will be the JMS message ID. The system ID is assigned by the messaging system when a message is created or received on an inbound service definition. The correlation ID is used for the purpose of correlating request and reply messages.

    The message format string identifies the original type of message sent. As you will see in subsequent articles, you can obtain the message payload in a format that is not the same as the original format, as long as they are compatible. For a list of supported formats, see the WebSphere Application Server Information Center entry for JMS and Web service formats.

    A message may have a number of user properties set which can be any serializable Java class. The message may also have a forward and reserve routing paths. A routing path defines a sequential list of intermediary bus destinations that messages will pass through to reach a target bus destination.

    For more information on the SIMessage interface, see the WebSphere Application Server Information Center SIMessage API entry.

  6. Extract information from the SIMessage

    The sample mediation extracts information from the SIMessage and returns a string representation of the message attributes.

    Enter the following code into the mediation handler:

    Listing 5.
    private String getMessageInfo(SIMessage message) {
        StringBuffer data = new     StringBuffer();
        data.append("API message id = ");
        data.append(", System message id = ");
        data.append(", Correlation id = ");
        data.append(", Message format = \"");
        data.append(", Message descriminator = \"");
        List list = message.getUserPropertyNames();
        if (list != null && !list.isEmpty()) {
            data.append(", User     properties = ");
        list = message.getForwardRoutingPath();
        if (list != null && !list.isEmpty()) {
            data.append(", Forward routing path = ");
        list =      message.getReverseRoutingPath();
        if (list != null && !list.isEmpty()) {
            data.append(", Reverse routing path = ");
        data.append(",      Reliability = ");
        data.append(", Priority = ");
        data.append(", Redelivered Count = ");
        data.append(", User id = "); data.append(message.getUserId());
        return data.toString();
  7. The SIMediationSession interface

    The SIMediationSession interface defines all the methods for querying and interacting with the messaging system. For example, it provides information about where the mediation is being invoked. A more typical use of the session interface is to route message clones to other destinations.

    For the purpose of our mediation, we will return information from the session object in string form so it can be written to the logs. Enter the following method into the mediation handler class:

    Listing 6.
    private String getSessionInfo(SIMediationSession session) {
        StringBuffer data = new StringBuffer();
        data.append("Mediation: ");
        data.append(" @ Destination: ");
        if (session.getDiscriminator() != null && 
    			!session.getDiscriminator().equals("")) {
        data.append("(discriminator = ");
        if (session.getMessageSelector() != null && 
    			!session.getMessageSelector().equals("")) {
            data.append(" (message selector = ");
        data.append(" on Bus: ");
        data.append(" in ME: ");
        return data.toString();

    For the most part, the invoked methods are self explanatory. For example, the getBusName() method is used to extract the name of the bus on which a mediation has been deployed. Although not solely mediation concepts, message discriminators and message selectors warrant a brief explanation.

Message selectors and discriminators are used to conditionally mediate messages:

  • Message selectors operate on message properties. For example, an ordering system may set the value of an order as a message property. The mediation can then be configured to only mediate orders over a certain value.
  • Message discriminators are used to qualify the topic of message within a topic space. This functionality enables your mediation, or application, to process messages published only on certain topics.

Assemble the mediation handler into a deployable unit

Before you can install and configure the mediation handler, you need to package it into an EAR. While you could have developed the mediation handler in an enterprise application project, the mediation is more reusable if is contained in a Java project. Using this approach, you can add the mediation to many enterprise applications or develop a library of mediation handlers that can be reused by many projects.

The next sections will describe the steps to assemble your mediation:

  • Create an enterprise application project that references the Java project and contains a new EJB project.
  • Set the EJB project JAR dependencies to include the Java project.
  • Define the mediation handler in the EJB deployment descriptor.
  1. Create an enterprise application project
    1. In Application Developer, launch the New wizard by selecting File => New => Other, as shown in Figure 4.
      Figure 4. Select the new EAR project wizard
      Figure 4. Select the new EAR project wizard
    2. Select the Enterprise Application Project wizard, then Next.
    3. Name the project DeployableMediation and click Next.
      Figure 5. Creating the new EAR project
      Figure 5. Creating the new EAR project
    4. Add the existing Java project and create a new EJB module, as shown in Figure 6, Click Finish.
      Figure 6. Adding modules to the EAR project
      Figure 6. Adding modules to the EAR project
  2. Set the EJB JAR dependency

    Open the EJB project properties and select the Java JAR Dependencies property. Check the MessageMediation project, as shown in Figure 7, then click OK to close the panel.

    Figure 7. Setting the EJB JAR Dependencies
    Figure 7. Setting the EJB JAR Dependencies
  3. Add the mediation handler to the EJB deployment descriptor
    1. Open the EJB project and edit the deployment descriptor by double clicking on it.
    2. When open, select the Mediation Handler tab, shown in Figure 8.
      Figure 8. The Mediation Handler tab of the EJB deployment descriptor editor
      Figure 8. The Mediation Handler tab of the EJB deployment descriptor editor
    3. Click on the Add button to open a new panel.
    4. Use the Browse button to select the mediation handler class. The class is then introspected for fields that can be exposed as parameters. Our mediation handler's field has a suitable default, so you do not need to specify a value unless you need to override it. The completed panel is shown in Figure 9.
      Figure 9. Defining the mediation handler attributes
      Figure 9. Defining the mediation handler attributes
    5. Click Finish.

    By default, the mediation handler list name is the same as the mediation handler name. As discussed in the Introduction, it is possible to compose mediation handlers together by assigning them to the same mediation handler list. To set a different mediation handler list name, select the Advanced button, check the Define Handler List containment and click Next.

At this point, the EJB deployment descriptor will be complete, having been updated to include the newly added mediation handler, as shown in Figure 10.

Figure 10. The updated EJB deployment descriptor
Figure 10. The updated EJB deployment descriptor

After saving and closing the EJB deployment descriptor, the mediation handler is now ready to be deployed.

Deploy and test the mediation

Deploying and testing a mediation requires a messaging bus and a means to put messages on the queue you intend to mediate. For simplicity, a script has been provided to create a simple bus. In the real world, setting up a messaging topology requires a number of considerations, including the WebSphere Application Server topology over which the messaging topology will be created.

The following sections detail the steps to deploy and test a mediation:

  • Create a messaging bus and a destination.
  • Create JNDI resources that map to the message resources.
  • Create a mediation.
  • Apply the mediation to a destination.
  • Send a message to the mediated destination.
  • Review the WebSphere Application Server log to verify what happened.
  1. Create a messaging bus and a destination

    First, you need to create a messaging bus on which you can deploy the sample mediation. To simplify this tutorial, a simple script has been provided. You can execute this script by executing the wsadmin command. Alternatively you can make use of the support to execute scripts that are built into both Application Developer and the WebSphere Application Server Toolkit.

    As shown Figure 11, you can use the context menu on a defined server to execute an admin script.

    Figure 11. Running scripts from the IDE
    Figure 11. Running scripts from the IDE

    (If you don't have a server defined, use the context menu of the Servers view (part of the J2EE perspective) to add one.)

    Navigate to the createSampleMsgBus.jacl file and execute it. This will result in the following messaging artifacts being created:

    • A message bus, called SimpleBus.
    • A bus member, the server instance.
    • A queue, called sampleMediationQueue.
    • Two JNDI references:
      • jms/CF1, a connection factory used for connecting to the message bus.
      • jms/mediatedQueue, a queue linked to the sampleMediationQueue bus destination.

    As the script is executed, messages will be written to the Console view. Check this view to ensure that the script executed correctly. The last step of the script is to save the configuration. The messages put to the console should include the following:

    Listing 7.
    Create messaging bus
    $AdminTask createSIBus -bus SimpleBus
    Add server as bus memeber
    $AdminTask addSIBusMember -bus SimpleBus -node 
    		neodogNode01 -server server1 -createDefaultDatasource true
    Create SIB Queues
    $AdminTask createSIBDestination -bus SimpleBus -name 
    		sampleMediationQueue -type queue -node neodogNode01 -server server1
    $AdminTask createSIBJMSConnectionFactory -name CF1 -jndiName 
    		jms/CF1 -busName SimpleBus -type Queue
    $AdminTask createSIBJMSQueue server1(cells/neodogNode01Cell/nodes/
               -name sampleMediationQueue -jndiName jms/mediatedQueue 
    			   -queueName sampleMediationQueue
    Configuration saved
  2. Create a mediation
    1. Launch the administration console from the context menu of the defined server and log on when prompted.
    2. Expand the Service Integration tab, select Buses, and click on the SimpleBus link. When the page loads, you will be presented with the bus configuration panel, including the mediations configuration, as shown in Figure 12.
      Figure 12. Bus configuration
      Figure 12. Bus configuration
    3. Select Mediations to load the mediation configuration panel, then New to create a new mediation.
    4. In the panel, enter DebugMediation for the name of the mediation and DebugMediationHandler as the name of the handler list to associate with this mediation. If you want to set a mediation context property, click Apply rather than OK so you can set context properties. The completed new mediation panel is show in Figure 13.
      Figure 13. Creating a new mediation
      Figure 13. Creating a new mediation
    5. Click OK to return to the mediations configuration page.
  3. Apply a mediation
    1. Select the sampleMediationQueue destination and click Mediate.
    2. In the panel that appears, select DebugMediation from the drop down list, then Next (see Figure 14).
      Figure 14. Selecting the mediation to apply
      Figure 14. Selecting the mediation to apply
    3. Select the bus member on which a mediation point will be created. In our case, the only choice is to select the existing bus member. Click Next and then Finish.
    4. Once the mediation has been applied, save the configuration.
  4. Install the mediation

    Now that you have created and applied the mediation, you need to install the actual mediation code -- a simple job. Use the context menu of the defined server to add the DeployableMediation project to the server and publish it. Since you have created a new messaging topology and JNDI resources, you need to restart the server. Use the context menu, or restart icon, of the defined server to restart it.

  5. Test the mediation

    Launch the Universal Test Client from the server context menu. Navigate to Utilities => Send a message and send a message to destination jms/mediatedQueue using the jms/CF1 connection factory.

    Sending a message will trigger the mediation to write information to the WebSphere Application Server log. Your output should be similar to that shown below:

    Listing 8.
    [03/03/05 17:15:42:279 GMT] 000000b3 MsgMediation I 
    	Context Properties: logMessages = true
    [03/03/05 17:15:42:314 GMT] 000000b3 MsgMediation I     
    	Message Info: API message id = ID:640788c617cd000bae211cd6110a134f0000000000000001,
                     System message id =     A8A19FCBE04A95AA_10000001, Correlation id = null,
                     Message format ="JMS:text", Message descriminator = "null",
                     Reliability =   ReliablePersistent, Priority = 4, Redelivered Count = 0, User id = 
    [03/03/05 17:15:42:319 GMT] 000000b3 MsgMediation I Session Info: 
    	Mediation: SampleMediation @ Destination: sampleMediationQueue
                     on Bus: neodogin ME: neodogNode.server1-neodog


In Part 1 of this article series, we covered the basics of message mediation, which included what mediations are, and why and when you should use them. We also demonstrated how to write simple mediation handlers and assemble them in mediation handler lists, and described how to deploy a mediation.

Subsequent articles will look at how to access message bodies using the SDO programming model, routing messages, and other related topics.


Many thanks to Dave Vines, Alastair Nottingham and others for their valuable suggestions and feedback on this tutorial.


Code  ( HTTP | FTP )8 KB



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

Zone=WebSphere, Architecture
ArticleTitle=IBM WebSphere Developer Technical Journal: A practical introduction to message mediation -- Part 1