Introduction

Although Java™ Messaging Service (JMS) is now widely used as the standard for enterprise messaging, it does not resolve many of the connection problems between applications, sometimes not even between one JMS application and another, let alone bridging the gap between JMS and non-JMS applications.

JMS transport nodes, a new feature in IBM® WebSphere® Message Broker V6, can help you resolve these connection and protocol conversion challenges. This article describes what the JMS transport nodes are, how to configure them, and how to use them to solve common connection or protocol conversion problems and increase the business value of your messaging infrastructure. In addition to outlining the function, use, and value of the nodes, this article also offers advice on key performance and scalability considerations when implementing message flows that use JMS transport nodes.

What is JMS?

JMS is the standard J2EE messaging API for building enterprise messaging applications. The JMS specification offers an abstract, provider-independent messaging interface, so that you can write messaging applications to this common API without worrying about the underlying messaging implementation. JMS offers two common messaging paradigms on which to build messaging applications: point-to-point and publish/subscribe (pub/sub). JMS applications send messages to JMS destinations, which can be queues (in the point-to-point domain) and topics (in the pub/sub domain).

Benefits of using JMS as the messaging interface include:

• Since they are written to a standard API, applications are portable between JMS providers, and you should be able to move your application to any other JMS provider.
• Programmers can write to a common API regardless of the underlying implementation, which means your programmers can build common skills and instead of needing to develop in-depth knowledge of specific products.

For more information on JMS, see the JMS specifications from Sun Microsystems.

Most enterprise messaging providers offer a JMS implementation as a mechanism for using their products. WebSphere Message Broker V6 and its predecessor releases, as well as WebSphere MQ, are JMS providers, and let you perform JMS messaging across WebSphere MQ, WebSphere real-time and WebSphere multicast transports.

Integrating JMS within the enterprise

One of the claimed benefits of JMS is that it enables portable applications. But in practise, many JMS providers offer extensions and capabilities beyond the standard JMS API, resulting in applications that are no longer truly portable. Once a JMS application is written, tested, and in production, you will probably not want to move messaging providers and risk outages as a result of the migration.

Adding new applications to the existing infrastructure using a new JMS provider can present a challenge, because the JMS specification does not define the wire format for JMS communications. Therefore underlying messages are likely to be incompatible between JMS providers, with one JMS provider unable to send a message directly to another JMS provider without a transformation between the two formats. This incompatibility presents a problem when integrating JMS applications based on different providers within your enterprise, and you need to convert the protocol of one JMS message implementation to that of the others. The new JMS transport nodes in WebSphere Message Broker V6 can add significant value to your enterprise by resolving this communications issue.

Another common enterprise scenario involves connecting a JMS-based application to a proprietary messaging application. The two messaging formats are incompatible, and once again some form of integration and transformation between the two systems is needed, and it can be provided by the JMS transport nodes in WebSphere Message Broker V6.

What are the JMS transport nodes?

WebSphere Message Broker V6 supports many messaging protocols, including:

• HTTP and Web services
• WebSphere MQ
• WebSphere MQTT
• WebSphere MQ real-time

JMS transport nodes extend this list by enabling WebSphere Message Broker V6 to send and receive messages from any JMS provider transport, as long as the provider is compliant with the JMS 1.1 specification. JMS transport nodes enable a broker to be a JMS client (JMS consumer or JMS producer) to any JMS provider, which enables the broker to send messages to and receive messages from the JMS provider. JMS nodes can operate in both JMS messaging paradigms: point-to-point and pub/sub.

There are four types of JMS transport nodes:

JMSInput node

Acts as a JMS consumer to a JMS destination, and can connect to the JMS provider in point-to-point mode as a queue receiver or in pub/sub mode as a subscriber. The role of the node is to receive messages into the message flow that will transform and route the message. Once the input node has received a JMS message, it builds an internal JMS message tree that you can use like any other WebSphere Message Broker tree representation. The JMSInput node can receive all six types of JMS message as defined by the JMS 1.1 specification: Base JMS message, Text, Object, Bytes, Stream, and Map.

JMSOutput node

Acts as a JMS producer to a JMS destination. It can connect to the JMS provider in point-to-point mode as a queue sender or as a publisher in pub/sub mode. Its role is to send messages that have been transformed and routed in the message flow. It converts the internal JMS tree into a JMS message to be sent to the JMS provider. The JMSOutput node can send all six types of JMS message as defined in the JMS 1.1 specification.

JMSMQTransform node

Used in conjunction with the JMSInput node. It converts the message received from a JMS provider into a format that can be sent to WebSphere MQ.

MQJMSTransform node

Used in conjunction with the JMSOutput node. It converts the message received from WebSphere MQ into a format that can then be sent to the JMS provider.

Node configuration

JMS nodes have the same configuration requirements as any JMS client -- access to the JMS provider's client code, the definitions required to access the JNDI repository, and the name of the administered objects to retrieve from the repository. The nodes can reuse any existing JNDI repositories and administered objects that are already set up for the existing JMS network. These settings are made by altering the node properties in the WebSphere Message Broker toolkit. An example of the configuration properties for the JMSInput node is shown in Figure 1 below. A key advantage of the implementation of these nodes is that you do not need to write any code to set them up:

More advanced JMS client configurations, such as adding message selectors to filter incoming messages, are also configurable as node properties. For more information on these settings, see the WebSphere Message Broker toolkit online help.

Connection to a JMS provider

Figure 2 below shows how the JMSInput and JMSOutput nodes connect to a JMS provider. The diagram shows the JMSInput and JMSOutput nodes running in a message flow that will be hosted in a broker. As mentioned above, the nodes behave like clients, so like any JMS client, they use JNDI to look up the JMS connection factories and destinations. They then use the objects they have looked up to connect to the JMS provider and the specified destination (either a queue or topic) and send messages to or receive messages from the destination:

Technology benefits and business value

So far this article has focused on what the JMS transport nodes are and how they can be configured and used. This section describes some common scenarios that show how you can use these nodes in your enterprise messaging infrastructure. As you will see, JMS transport nodes help you solve many conversion and bridging problems solutions with no coding on your part.

Enrich an existing JMS provider

You can use JMS transport nodes to enrich any enterprise messaging system that has JMS 1.1 support by adding brokering function to the JMS network. Once a JMSInput node has received a message from a JMS provider, all WebSphere Message Broker V6 transformation and routing capabilities are available to process the messages. On completion of the message processing, you can send the result back to the same or to another JMS network via the JMSOutput node.

Some simple example flows are shown in Figure 3 below. They show the XML Transformation and the Database nodes being used to transform and store JMS messages in a database:

Bridge any JMS providers

As discussed above, there are is wire compatibility between different JMS providers. Without WebSphere Message Broker V6, bridging between any two JMS providers typically requires custom code. The JMS transport nodes in WebSphere Message Broker V6 let you do the the bridging without writing any custom code.

Figure 4 below shows how the JMSInput Node can connect to one provider and the JMSOutput node can connect to another provider, so that the messages will flow from one provider to the other. Additionally, you could if you want, insert any of the WebSphere Message Broker nodes in between to perform any additional transformation or routing processing:

Any JMS 1.1 compliant providers can be bridged in this manner, such as integrating WebSphere MQ JMS and the WebSphere Service Integration Bus (the WebSphere Application Server V6 JMS provider). Therefore you can run many similar flows using other providers within the same message broker, using the broker as a bridge between any number of different providers.

Integrating JMS with application server applications

Any J2EE-compliant application server such as WebSphere Application Server must include a JMS provider to enable J2EE applications to do messaging. Therefore it is common for Web applications using Java servlets or EJBs running on an application server to use JMS.

JMS transport nodes let WebSphere Message Broker V6 connect to any JMS 1.1-compliant JMS provider. Therefore they can connect to the JMS provider of an application server. Once a message broker can communicate with the JMS provider of an application server, it can send messages to and receive messages from the JMS destinations that are being used by the servlets, EJBs, or MDBs running on the application server. Therefore you can use use WebSphere Message Broker V6 to enrich messages being used by the application, or even to bridge the application to WebSphere MQ or to another JMS Network. It is now possible to enrich Web-based applications running on an application server using WebSphere Message Broker V6, or to integrate those applications with the rest of your enterprise infrastructure using the integration capabilities of WebSphere Message Broker V6.

Bridge any JMS provider to WebSphere MQ

You can use the MQJMSTransform and JMSMQTransform nodes to connect any JMS network to an existing WebSphere MQ Network. Figure 5 below shows how you can use these nodes in a message flow to perform this function:

This feature lets you easily integrate JMS networks with any MQ-enabled applications. JMS transport nodes let you connect:

• WebSphere MQ-enabled applications to JMS applications
• One JMS network to other JMS networks

Thus you can connect WebSphere MQ clusters and WebSphere Application Server clusters. And because that connection is achieved using WebSphere Message Broker, it is robust and scalable.

Using transactions with JMS providers

The JMS transport nodes offer different levels of transactional support, which can be configured as a property of the node instance depending on your particular requirements:

• They can be non-transacted, so that messages passing through the flow are not part of any transaction. This setting best suits non-persistent messages where high throughput is a requirement.
• The individual nodes can be enabled for local transactions, which means that each node uses a transacted JMS session to their JMS provider, so the messages are sent and received as part of individual transactions.
• The third level of transactionality is global transactions (also known as XA transactions). JMS destinations that supply messages to a JMSInput node, or receive messages from a JMSOutput node, can be coordinated as part of a message flow global transaction. Therefore the whole operation performed by the flow can be contained in a transaction, so that all or none of the processing takes place, depending on the outcome of the transaction.

Global transactions are available to any JMS provider that conforms to the JMS 1.1 specification, and supports the JMS XAResource API through the JMS session. An example of such a provider is WebSphere MQ JMS. Global transactions use the WebSphere MQ Queue Manager as the transaction coordinator. The coordinator handles events such as transaction start and end, and the need for other resources to be included in the unit-of-work, including resources such as updates to WebSphere MQ queues, DB2 databases, and any XA-compliant JMS provider destination. Therefore you can combine one or more JMS providers in a single XA transaction. For example, within the same XA transaction, you can include:

• Receiving a message from WebSphere MQ
• Logging the message to a database
• Sending the message to a JMS provider

Any of the message flows shown above can also be included in an XA transaction.

Connecting JMS pub/sub and point-to-point networks

As shown above, JMS nodes can act in either the point-to-point or pub/sub domain. Within a single flow, you can therefore have the JMSInput node connected to a JMS point-to-point network, and the JMSOutput node configured to a JMS pub/sub network. The reverse configuration is also possible. Thus a message published on a queue can be received by the JMSInput node and published to a topic on a pub/sub network by the JMSOutput node, which provides a fast way to connect the different messaging domains without custom coding. Figure 6 shows a simple way to make this connection:

Performance and scalability

This section discusses performance considerations when implementing message flows that use the JMS transport nodes. For more information on JMS transport node performance, see WebSphere Message Broker V6 performance reports.

JMS Transport node performance depends on which JMS client and transport you use. For example, WebSphere MQ real-time transport generally yields a much higher message rate than WebSphere MQ client transport, because WebSphere MQ real-time transport is a lighter weight protocol, with the tradeoff that it offers a lower quality of service than WebSphere MQ client transport.

As with any JMS application, the quality of service you choose impacts performance -- reliability and robustness have a cost. For example, a non-persistent, non-transacted client performs better than a persistent and transacted client, so use these options only when necessary.

Each JMS provider has tuning parameters and techniques to enhance JMS performance. For performance tuning information for the JMS server or JMS client setup, see the JMS provider documentation. For performance tuning information on the IBM JMS providers, see the Resources section below.

Message type and size are also important performance factors. Smaller messages offer better performance, particularly when using persistent messages. The different types of JMS message are handled differently by the nodes. JMS Bytes messages require less work than the other message types, while JMS stream and JMS map messages require extra work to be parsed and interpreted and therefore offer lower performance for a given amount of resource.

Typically, when scaling any WebSphere Message Broker application, using additional copies of the message flow (additional instances) and multiple execution groups will increase message throughput rates. For examples of such scaling, see WebSphere Message Broker V6 performance reports. The same is true for message flows involving the JMS transport nodes. The exact gains vary depending on the scenario.

In point-to-point mode, with each additional instance of the message flow, a new connection to the JMS provider is made (for both JMSInput and JMSOutput nodes) to the same JMS queue. The result is multiple connections and threads serving the same destination, with the potential for higher message rates.

In pub/sub mode, there is a limit of one connection to a destination from a JMSInput node (to avoid multiple subscriptions and resulting duplicate messages), and therefore additional instances are not helpful. However, by using a different approach, you can build message flows with the JMS transport nodes within them that allow message throughput to be scaled with additional copies (though not with additional instances). You must design the topic tree such that each copy of the message flow can serve a particular topic or portion of the tree. In this way, you can concurrently run multiple message flows (containing JMS transport nodes) where each message flow subscribes or publishes to a different topic.

Conclusion

This article has explained the role and function of the new JMS transport nodes in WebSphere Message Broker V6. It has shown how you can use the nodes to solve common protocol conversion and bridging problems. Typical uses of the nodes include:

• Enriching an existing JMS provider
• Bridging any JMS providers
• Integrating JMS with application server applications
• Bridging any JMS provider to WebSphere MQ
• Using JMS providers in XA-coordinated transactions
• Connecting JMS pub/sub and point-to-point networks

In a number of the cases, no coding is needed, which is a big advantage when you need to solve a protocol conversion or bridging problem with minimal effort. In other cases you may need to perform more complex transformation or routing processing on a message, and you can use the full range of WebSphere Message Broker function once the message has been read into a message flow using one of the JMS transport nodes. This article also discussed performance and scalability considerations when designing your message flow applications.

Resources

• JMS specifications
  Complete, downloadable specifications from Sun Microsystems.
  
  
• WebSphere Message Broker V6 performance reports
  These reports describe current WebSphere Message Broker V6 performance on each platform on which it runs.
  
  
• WebSphere Message Broker online help for JMS transport and JMS nodes
  Part of the WebSphere Message Broker V6 information center.
  
  
• Performance Harness for JMS
  A useful, free tool from IBM alphaWorks for testing and driving JMS node message flows.
  
  
• WebSphere Message Broker information center
  A single Eclipse-based Web portal to all WebSphere Message Broker V6 documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere Message Broker environment.
  
  
• WebSphere Message Broker documentation library
  WebSphere Message Broker specifications and manuals.
  
  
• WebSphere Message Broker product page
  Product descriptions, product news, training information, support information, and more.
  
  
• WebSphere Message Broker forum
  Get answers to your technical questions and share your expertise with other WebSphere Message Broker users.
  
  
• WebSphere Business Integration products page
  For both business and technical users, a handy overview of all WebSphere Business Integration products
  
  
• developerWorks WebSphere Business Integration zone
  For developers, access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product info, and more.
  
  
• Most popular WebSphere trial downloads
  No-charge trial downloads for key WebSphere products.
  
  
• Trial downloads for IBM software products
  No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
  
  
• Safari Bookshelf: e-library designed for developers
  Complete search and download access to thousands of technical books for a one-time subscription fee. Free trial for new subscribers.
  
  
• WebSphere forums
  Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
  
  
• developerWorks blogs
  Ongoing, free-form columns by software experts, to which you can add your comments. Check out Grady Booch's blog on software architecture.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• What is JMS?
• Integrating JMS within the enterprise
• What are the JMS transport nodes?
• Technology benefits and business value
• Using transactions with JMS providers
• Connecting JMS pub/sub and point-to-point networks
• Performance and scalability
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Message Broker
• Briefing: WebSphere flexible business processes
• Buy: WebSphere Message Broker

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers