After having covered two of the most used protocols that WebSphere Enterprise Service Bus (ESB) supports for connectivity -- namely JMS and Web services (SOAP/HTTP) -- we will now move on and add one more protocol to the mix that is commonly required in real life enterprise environments: WebSphere MQ.
Many applications already exist that support message exchange across WebSphere MQ to communicate with external applications, and an ESB is often used to transform into and expose application functions over MQ as services. Hence, we will show here how existing applications supporting MQ communication can be tied into a service-oriented environment by utilizing the WebSphere MQ support in WebSphere ESB.
The updated scenario
In Part 2, we described how each delivery of a package by Posts-R-Us results in a message being sent to the ESB, from where it is forwarded to a Java™ EE application using a message-driven bean (MDB). This level of indirection established a decoupling between the systems generating the event (that is, the event that a package had been delivered) and the one consuming it (the MDB that received the message). Putting this in an SOA context, it means that the ESB offers a virtual service interface to the client that hides the real location and interface of the service provider.
At Posts-R-Us, an existing mainframe-based application exists that also needs to receive notification messages about delivered packages. It receives those messages, formatted in XML, over a WebSphere MQ queue. The design team decides to change the ESB mediation, adding a connection to forward the incoming notification messages to the appropriate MQ queue, while continuing to send it to the original Java EE (formerly J2EE) application. Figure 1 shows the updated architecture.
Figure 1. Updated architecture for package delivery notification
As the figure shows, the message is forwarded to a queue that is managed by a remote WebSphere MQ queue manager, in a separate process, whereas the original queue is managed within WebSphere ESB, in the same process, from where it is handed to the message-driven bean.
A couple of aspects are important to note here, all showing the value the ESB brings to the architecture of the system:
- The client application is not affected at all by this change. It continues to send the JMS message to the destination in the ESB.
- The existing MDB application is not affected by this change either.
- The existing mainframe application continues to receive messages from the associated WebSphere MQ queue.
Setting up WebSphere MQ
To run an example that reflects the architecture described above, you need to create a queue that will receive messages from WebSphere ESB. (In a real enterprise, the queue that the mainframe application listens on would probably already exist.) The easiest way to do so is through the WebSphere MQ Explorer. Once you start it, the main window will look like Figure 2.
Figure 2. WebSphere MQ Explorer main window
Keep in mind that you usually have one or more WebSphere MQ queue managers. In the figure above, the queue manager we will use is called QM_atost. To create a queue under this queue manager, right click on the Queues node in the WebSphere MQ Explorer Navigator, then select the New => Local Queue... (Figure 3).
Figure 3. Creating a new Local Queue
In the resulting dialog, name the new queue PackageReceivedQueue, leave all other default values, then click Finish.
And that's all you need to do in WebSphere MQ. There is no need to create any specific connection configuration to communicate with WebSphere ESB.
The mediation module
Next, you need to update the mediation that we already used in Part 2.
Open the PackageReceivedModule module in the assembly tool in WebSphere Integration Developer. This module consists of the mediation flow component, the JMSClientExport export, and the MDBImport import.
Add another import by dragging it from the palette into the assembly. Name the new import
MQImportand connect it to the mediation flow component, as shown in Figure 4.
Figure 4. Add another import to the mediation module assembly
Now you will generate the bindings that connect this import with the WebSphere MQ queue created earlier. Right-click on the MQImport and select Generate Binding..=>Messaging Binding..=> MQ Binding.
Figure 5. Create an MQ binding
In the resulting dialog, enter or select the following values (Figure 6):
- Queue manager name: enter the name of your queue manager; in this example, we use
- Send Destination Queue:
- Host Name:
- Request Serialization type: Serialized as XML
Leave default values for all remaining fields.
Figure 6. MQ binding definition
This will connect the import in the mediation module to the WebSphere MQ queue you created earlier. Moreover, it specifies that the payload of the message should be sent to the queue as a serialized XML message. You will see what this looks like later when you run the final test. If you need to, you can make further changes after you have created the binding simply by opening the Properties view for the import.
Figure 7. MQ bindings properties view
- Queue manager name: enter the name of your queue manager; in this example, we use
Next, you will create the mediation flow component implementation. Instead of updating the existing implementation, you will simply generate a new one, since the flow we will use is a very simple one. To do so, right-click on the mediation flow component, PackageReceivedMediation, in the assembly, and select the Regenerate Implementation menu option. The Mediation Flow Editor will open.
Connect the interface node on the left to both reference nodes on the right, as shown in Figure 8. Make sure that you wire it to the PackageReceivedIFPartner1 reference first.
Insert a Message Logger mediation primitive into the flow and connect it to the Input node. Connect the output terminal of the logger primitive to both Callout nodes. This will lead to the message being logged, and then forwarded to both imports, namely the JMS queue that the MDB listens to, and the MQ queue you defined earlier.
Figure 8. Updated mediation flow
Save all of your changes. Also, run the Project => Clean... menu option from the main tool menu. This will make sure that all required artifacts for the mediation module are built and updated according to the changes you just made.
Running the updated scenario
You are now ready to run a test to show the effect of the changes you made:
Start the server, if it is not already started. For this test, we will assume that no enterprise applications have been deployed on the server. If you have any existing EAR files deployed, you should remove them and then restart the server.
Right-click on the WebSphere ESB server in the server perspective and select Add and remove projects... Add the PackageReceivedModuleApp project first, then the PackageReceivedEAR project, then click Finish.
Restart the server.
Run the test client in the PackageReceivedClientEAR project. (This is exactly the same as described in Part 2.) As a result, you can see in the console how the message-driven bean receives the message (Figure 9).
Figure 9. The server console
Remember that the message is also forwarded to the WebSphere MQ queue. To ensure that the message was sent successfully, open the WebSphere MQ Explorer, navigate to the PackageReceivedQueue queue, and browse the messages that are on it (Figure 10).
Figure 10. Browsing the WebSphere MQ queue messages
Right-click on the message in the queue and select the Data tab (Figure 11). This will show you the content of the actual message which, you will notice, consists of a header portion as well as the payload as an XML string (and remember, we asked for the message to be sent in serialized XML format).
Figure 11. The XML message
If you want to experiment with this example a bit more, you can add an XSL Transformation mediation primitive before the callout node for the MQ import. This would enable you to transform the incoming message into a format that is appropriate for the backend application.
With these instructions, you saw how to extend the scenario developed in Part 2 to include a connection to an existing WebSphere MQ system. We added an import to the mediation flow and generated MQ bindings on it that connected the import to an existing WebSphere MQ queue under the control of a remote queue manager. The configuration required to do so is minimal and the change does not affect any of the previously existing pieces of the scenario.
As a result, you have now seen how to use three protocols when communicating with WebSphere ESB: JMS, SOAP/HTTP, and WebSphere MQ. In the next part of this series, you will see how to switch from one protocol to another, including a change from an asynchronous invocation to a synchronous one, and vice versa. Stay tuned!
More in this series
- Part 1: An introduction to using WebSphere ESB, or WebSphere ESB vs. SIBus
- Part 2: A JMS messaging example
- Part 3: Adding Web services and promoting properties
|Code sample||part4-downloads.zip||25 KB|
- An introduction to the IBM Enterprise Service Bus
- WebSphere Enterprise Service Bus product page
- Getting started with WebSphere Enterprise Service Bus and WebSphere Integration Developer
- Developing custom mediations for WebSphere Enterprise Service Bus
- Building a powerful, reliable SOA with JMS and WebSphere ESB
- WebSphere Enterprise Service Bus V6.0.2
- Tutorial: Invoking a Web service with a JMS client
- Redbook: Enabling SOA Using WebSphere Messaging
Dig deeper into Business process management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.