Introduction

Building on Part 11 in the series, this article helps you use BPEL and the ESB together to implement a service-oriented architecture (SOA). In Part 2, WebSphere Business Integration Message Broker implemented the ESB patterns for the customer enrollment application. A new messaging engine written in Java™ was added to the WebSphere Application Server V6, and it provides support for queuing, routing, transformation, and standards. The messaging engine consists of three main components: the service integration bus, a list of destinations, and mediations. Previous articles (see Resources) explain these concepts in detail.

Back to top

Revisiting the personal loan scenario

In Part 3, we used BPEL to implement the odFinance personal loan business process. The doCreditCheck activity performs a credit check on the client to ensure they have a good credit history with other financial institutions. The credit-checking services can be provided by multiple providers, and odFinance doesn't care which provider is used. Next we use the ESB to route the request to the different providers in a round-robin fashion. Figure 1 shows the interaction between the personal loan business process, the ESB, and the credit-check providers.

Back to top

Configuring V5 default messaging in WebSphere Application Server V6

The Service Integration Bus (SIB) in WebSphere Application Server V6 supports Java Message Service (JMS) clients running on WebSphere Application Server V5 to communicate with the SIB using the V5 default messaging JMS provider. This provider wraps the V6 JMS resources as V5 JMS resources to support the interoperability of V5 JMS clients. To configure V6 to interoperate with V5 JMS clients, do the following steps:

1. Configure the SIB in WebSphere Application Server V6.
2. Create a WebSphere MQ client link.
3. Create JMS resources for V5 JMS clients.
4. Create an SIB base queue and alias queue.

Configure the SIB in WebSphere Application Server V6

Previous articles in this series describe how to create an SIB, so we won't repeat the details here. For the purpose of the sample, create a bus with the name V5toV6Bus, add a new bus member to the local server, and configure the messaging engine.

Create a WebSphere MQ client link

The WebSphere MQ client link enables WebSphere Application Server V5 J2EE applications to use messaging resources of the Application Server V5 default messaging provider that are backed by destinations on the SIB.

Each WebSphere MQ client link presents itself as a queue manager and transforms between the WebSphere MQ client protocols used by V5 JMS applications and the Application Server V6 protocols used by messaging engines.

To create a WebSphere MQ Client link:

1. From the Messaging Engine Configuration panel, select WebSphere MQ client links, as shown in Figure 2.
2. Create a new WebSphere MQ Client Link and specify the properties:

   Name: Enter MyMQClientLink
   MQ Channel Name: Use the default WAS.JMS.SVRCONN
   Queue Manager Name: Use the default in the form of WAS_node_name_server_name

3. Default queue manager: Select this checkbox so you can use the MQ client link as the default queue manager when an application cannot find a queue manager it specifies to communicate with.

Creating JMS resources for V5 clients

To create the JMS resources for V5 JMS applications, use WebSphere Application Server V6 administrative console to create a V5 default messaging provider, as follows.

1. Select Resources > JMS Providers > V5 default messaging from the navigation bar, as shown in Figure 3.
2. Select WebSphere queue connection factories to create a QueueConnectionFactory. Use jms/QCF as the JNDI name.
3. Select WebSphere queue destinations to create a queue. Use Q1 as the queue name and jms/Q1 as the JNDI name. Unlike the V6 JMS resource, which is explicitly mapped to an SIB base queue, the queue name of the V5 JMS resource is used to map to an SIB base queue implicitly. For example, a queue named Q1 is mapped to an SIB queue named WQ_Q1. The WQ_ prefix is added by the WebSphere MQ classes for JMS. So, if you send a message to a JMS queue with a name Q1, the message will be routed to an SIB base queue named WQ_Q1.

Create an SIB base queue and alias queue

After you've defined a V5 JMS queue (Q1) for the V5 default messaging JMS provider, you also need to define a concrete queue named WQ_Q1 in the SIB messaging engine. The recommended way to support both V6 and V5 JMS clients is to create a base SIB queue named Q1. Next create an alias queue named WQ_Q1 that points to the target base Q1 queue.

The messages eventually arrive at Q1 when the WebSphere MQ client link routes the message to WQ_Q1, because the V6 JMS client does not impose the WQ_ prefix. If you define an alias queue, regardless of whether the clients are from V5 or V6, the messages will eventually arrive at Q1.

To create the SIB base queue:

1. Select the V5toV6Bus bus.
2. Select Queue as the destination type.
3. Enter Q1 as the identifier. Select the bus member and complete the creation of the queue.

To create the alias queue:

1. Select the V5toV6Bus bus.
2. Select Alias as the destination type.
3. Enter WQ_Q1 as the identifier, and enter Q1 as the target identifier. Select V5toV6Bus as the target bus and complete the creation of the alias queue.

Figure 4 shows the result destinations on the V5toV6Bus.

Back to top

Creating a simple BPEL to send a JMS message

Using WebSphere Studio Application Developer Integration Edition (Application Developer) V5.1.1, create a simplified loan process (shown in Figure 5), with a credit-check activity that sends a JMS message to the JMS queue (Q1). The Web Services Description Language (WSDL) of the credit-check service is shown in Listing 1.

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="JMSService"
  targetNamespace="http://jms.demo.ibm.com/JMSService"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
  xmlns:format="http://schemas.xmlsoap.org/wsdl/formatbinding/"
  xmlns:jms="http://schemas.xmlsoap.org/wsdl/jms/"
xmlns:tns="http://jms.demo.ibm.com/JMSService"   
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <message name="SimpleMessage">
      <part name="ssn" type="xsd:string"/>
  </message>
  <portType name="SendMessagePortType">
      <operation name="send">
          <input message="tns:SimpleMessage"/>
      </operation>
  </portType>
  <binding name="JMSBinding" type="tns:SendMessagePortType">
      <jms:binding type="TextMessage"/>
      <format:typeMapping encoding="XML">
          <format:typeMap formatType="java.lang.String" typeName="xsd:string"/>
      </format:typeMapping>
      <operation name="send">
          <jms:operation/>
          <input>
            <jms:input parts="ssn"/>
            <jms:propertyValue name="WSDLBinding" type="xsd:string"
            value="http://jms.demo.ibm.com/JMSService:JMSBinding"/>
            <jms:propertyValue name="WSDLOperation"
               type="xsd:string" value="send"/>
          </input>
      </operation>
  </binding>
  <service name="JMSService">
      <port binding="tns:JMSBinding" name="JMSPort">
         <jms:address destinationStyle="queue"
            initialContextFactory="com.ibm.websphere.naming.WsnInitialContextFactory"
            jndiConnectionFactoryName="jms/QCF"
            jndiDestinationName="jms/Q1" jndiProviderURL="iiop://hostname:2809/">
           <jms:propertyValue name="JMSTimeToLive" type="xsd:long" value="0"/>
           <jms:propertyValue name="JMSExpiration" type="xsd:long" value="0"/>
         </jms:address>
      </port>
  </service>
</definitions>

The <jms:address> section needs to be customized to your environment:

• The JNDI name of the queue connection factory and queue.
• The JNDI provider URL. WebSphere Application Server V6 uses 2809 as the default port number.
• The JMS propertyValue elements for message expiration. Without these two elements, the JMS message will have a default value specified by Web Service Invocation Framework (WSIF). If the value is 0, the message will never expire.

Back to top

Unit testing

After generating the deploy code for the loan process, we can unit test the process with the Process Web client shipped with Application Developer, as shown in Figure 6.

Next, verify that the message has arrived in the SIB base queue Q1. From the Application Server V6 administrative console:

1. Select Buses from the navigation bar.
2. Select the bus you defined.
3. Select Destinations.
4. Select Q1 from the list.
5. Select Queue points from the Message points section.
6. Select the Q1 queue point identifier from the list.
7. Select the Runtime tab.
8. Select the Messages link from the Additional Properties section.

You will find the message sent from BPEL. Select the identifier link. Next, select Message Body from the Additional Properties section. You should see the content of the message that matches your input from the Process Web client, as shown in Figure 7.

Back to top

Adding a routing mediation

The next step is to bring a routing mediator into the picture. In this simple scenario, we add two SIB base queues, Q2 and Q3, for the two service providers to listen to. The message coming to Q1 will be routed to Q2 or Q3 in a round-robin pattern.

Instead of developing and deploying the routing mediation from scratch, you can take advantage of the WebSphere Platform Message Patterns described in Part 11. You can develop a class (for example, SimpleRoutingMediation), add it to your Unified Modeling Language (UML) model, and mark it up with the <<Mediation>> keyword. Then you can use the patterns to help you deploy and configure your new mediations. The implementation code for this new mediation is shown in Listing 2.

Alternatively, you can also configure and deploy the mediation following the documentation in IBM Rational® Application Developer.

public class SimpleRoutingMediation implements MediationHandler {

  /* (non-Javadoc)
   * @see com.ibm.websphere.sib.mediation.handler.MediationHandler#
      handle(javax.xml.rpc.handler.MessageContext)
    */
	
  public static final String remoteDestination1Name="Q2";
  public static final String remoteDestination2Name="Q3";
	
  private static String routingDestination=remoteDestination1Name;
	
  public boolean handle(MessageContext context) throws MessageContextException {
		
   SIMessageContext mediationContext = (SIMessageContext) context;
   SIMessage message = mediationContext.getSIMessage();
		
   SIMediationSession mediationSession = mediationContext.getSession();
		
    // Create a forward routing path which will be set on the cloned message
    Vector forwardRoutingPath = new Vector();
		
   SIDestinationAddressFactory destFactory = SIDestinationAddressFactory.getInstance();
		
   SIDestinationAddress dest;
		
   if (routingDestination.equals(remoteDestination1Name)){
	 dest = destFactory.createSIDestinationAddress(remoteDestination1Name,true);
	 routingDestination = remoteDestination2Name;
	}
	else{
	 dest = destFactory.createSIDestinationAddress(remoteDestination2Name,true);
	 routingDestination = remoteDestination1Name;
	}
	forwardRoutingPath.add(dest);
	message.setForwardRoutingPath(forwardRoutingPath);
		
	return true;
}
}

Back to top

Adding message-driven beans to receive the messages

Finally, you need to enable the two credit-check providers to receive messages from the queues. You can also use the Message Facade Pattern described in Part 11 to assist you. The Message Facade Pattern allows the credit-check services to be invoked asynchronously by implementing a message-driven bean.

Back to top

Summary

In this article, you learned how to integrate BPEL-based business processes deployed on WebSphere Business Integration Server Foundation V5 with service providers deployed elsewhere using the ESB capabilities in WebSphere Application Server V6.0. Using a simple loan example, we demonstrated the flexibility of a service-oriented architecture. This type of architecture allows existing services, such as credit checks, to be consumed into a new application, even though each is running on a completely different system.

Back to top

Downloads

Description	Name	Size	Download method
mediation project interchange code	i-odoebp13code1.zip	6 KB	HTTP | Download Director
BPEL project interchange code	i-odoebp13code2.zip	21 KB	HTTP | Download Director

Information about download methods

Resources

• Building an Enterprise Service Bus with WebSphere Application Server V6, Part 3: Read about setting up a message-driven bean to listen to messages on a JMS queue and a J2EE client application to send a message to that JMS queue. Also look at the setup needed to send the JMS message through the message bus in the application server.
  
  
• A practical introduction to message mediation – Part 1: Explains message mediation, one of the new capabilities of WebSphere Application Server V6. Part 1 covers the basics of message mediation, including how to develop, deploy, and test a simple mediation.
  
  
• Working with the Enterprise Service Bus and Mediations, Part 1: A guide to create, deploy, and test mediations.
  
  
• DB2 Alphablox information roadmap for business intelligence architects: Get more information about DB2 Alphablox, including technical documentation, how-to articles, education, downloads, and product information.
  
  

About the authors

Christina Lau is a Senior Technical Staff Member at IBM. Christina is an architect on the On Demand Development team focusing on the next generation technologies for the On Demand Operating Environment. You can reach Christina at clau@ca.ibm.com.

Colin Yu is a technical software development manager at IBM. Colin is on the Service Oriented Asset Repository Development team focusing on reusable asset repository and SOA asset development. You can reach Colin at coliny@ca.ibm.com.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Revisiting the personal loan scenario
• Configuring V5 default messaging in WebSphere Application Server V6
• Creating a simple BPEL to send a JMS message
• Unit testing
• Adding a routing mediation
• Adding message-driven beans to receive the messages
• Summary
• Downloads
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community