Hot Stories

This article explores certain approaches that will result in a robust integration solution.

Messaging technology is designed to deal with requirements. Home-grown solutions can face significant challenges to meet these needs.

The rest of this article will deal with IBM's WebSphere MQ as the messaging product. The principles described here apply to any messaging product.

Most integration systems are given these NFRs.

1. Applications being integrated may not be running at all times.
2. The network layer between the systems may not be available at all times.
3. The same message may not be processed twice (unless a message is being retried due to earlier failure in processing).
4. Information sent to an application must belong to a transaction along with other activities, such as database updates. The information should be sent only if all of those activities go through.

The Principles of Messaging
Most developers are trained to write synchronous applications. In the popular programming languages, method calls are inherently synchronous in nature. Messaging requires a different way of thinking. To help the developers understand the uniqueness of messaging, I have the following maxims.

DO NOT ASSUME TIMELINESS OF MESSAGE DELIVERY
A message sent to a system will be delivered on a best effort basis. Systems cannot ensure delivery within a specific time period. For immediate delivery, consider using a synchronous technology, such as Enterprise JavaBeans (EJB).

WebSphere MQ Client-based programs can also do an immediate delivery of messages. In this case, the application connects to a remote queue manager using TCP/IP and sends the message directly to a queue in the remote queue manager. In both cases, we fail to meet NFR #2.

DO NOT ASSUME THAT THERE IS ONLY ONE RECEIVER PROCESS
There may be more than one process picking and processing messages from a single queue. WebSphere MQ ensures that a message is delivered to one process only. Multiple receiver processes are run for scalability reasons. We can process more messages per minute, especially in a machine with multiple CPUs.

If the queue is clustered, the receiver processes may even run on multiple machines. This leads to the next maxim.

DO NOT ASSUME THAT A MESSAGE WILL BE DELIVERED TO A SPECIFIC MACHINE
The sender should not have any assumption about the specific machine to which a message will be delivered.

WebSphere MQ clustering allows you to host the same logical queue in multiple queue managers running in different machines. When you put a message in such a queue, the system will perform load balancing and fail over to distribute the messages among the queue managers in the cluster.

DO NOT ASSUME A SINGLE SENDER APPLICATION
Messages may be put in a single queue by applications running on different machines.

DO NOT ASSUME THE ORDER OF DELIVERY
Systems do not necessarily deliver messages in the order in which they were placed. In addition, messages placed by one application may be interspersed with messages placed by another application (if there are multiple senders). If the order of delivery is important, use the message grouping feature of WebSphere MQ. Messages in a group are delivered to a single receiver application in the strict order in which they are placed.

Communication Patterns
DATAGRAM
A datagram message is a one-way form of communication. The sender does not wait for a reply to come back from the receiver.

REQUEST RESPONSE
In this pattern, the sender sends a message and waits for a reply to come back from the receiver. The response is correlated with the request message using a correlation ID. The correlation ID of the reply message is usually set to be the same as the unique message ID of the request message. The sender instructs the GET operation to wait for a message with a specific correlation ID.

This pattern is an approximation of synchronized communication. In general, avoid request response type messaging.

DATAGRAM WITH CONTEXT
In this pattern we use datagram communication. But, the messages going back and forth between the systems can be correlated. For example, when an order is placed in a Web-based application, the system saves the order in the database and sends the order details message to the back-end ERP system. The order ID primary key is a part of the message. In a few days, the ERP system ships the order and sends an order status update message to the Web-based system. The order ID is again a part of this message. The Web-based system uses the order ID to update the order information in the database. In this case, the order ID serves as the context. Datagram with context is the most robust mode of communication.

Problem Domain
The integration solutions I am commonly asked to develop fall into two categories:

1. Web tier to back-end integration.
2. Retail location to head office integration.

WEB TIER TO BACK-END INTEGRATION
Here, one system is a Web-based application. The application is probably clustered in multiple machines. The other system is a legacy application. Datagram with context works best in a situation like this. Database primary keys of orders, users, or other entities are passed around as a part of the message. The latest information is stored by each system in its own database. Information in the database is updated upon the receipt of a message by the system.

In some cases, primary keys are too related to the internal implementation of a system and have little business meaning. In that case, unique key index values are used as context. For example, for an order, an enterprise-wide order ID is generated by the Web-based system (in addition to a primary key value).

RETAIL LOCATION TO HEAD OFFICE INTEGRATION
Multiple retail locations need to send daily order details data to a central location. The central location (known as head office) needs to push out price updates and promotion details to the retail locations.

The challenge is that outgoing messages from the head office to the retail locations may be store specific. The system should be able to pick the correct queue in which to put the message. In this article, we will not be exploring that problem domain.

Laying Down the Framework
WEB TIER TO BACK-END INTEGRATION
The Web-based system may be clustered. If it is not, start with the assumption that it may be clustered in the future. Machines in the cluster should be indistinguishable from one another. That is, the machine ID (host name or IP address) should not be featured as a context in a message. Contrast this with multiple retail locations. Here, the location matters. Messages may be store-specific.

The use of WebSphere MQ clustering works very well with WebSphere clustering. Create a queue manager in each Web tier application server machine. The queue manager names must be different in a network. Create one local queue in each queue manager to receive messages. The queue name must be the same in all cases (WEB_Q in our example).

In the back-end system, create a queue manager and a local queue to receive messages. Set up an MQ cluster that involves all queue managers. Share all local queues in the cluster.

In the Web-based application, develop a Message-Driven Bean (MDB) to act as the listener. The MDB will be bound to the local queue manager (WEB_QMA or WEB_QMB) and the local queue (WEB_Q).

Such a design will have several advantages:

1. MQ clustering is a simpler way to set up remote comunication than using a remote queue definition and transmission queue. If a new machine is added to the Web tier cluster, we can very easily add it to the MQ cluster.
2. Web tier bound messages will be load balanced between the available Web tier application server machines. This increases the throughput level and adds redundancy to the system.

BACK-END BOUND MESSAGES
The back-end queue manager participates in the MQ cluster and has shared its local queue (ERP_Q). As a result, ERP_Q will automatically appear as a local queue to the Web tier queue managers. We can create a JMS destination queue in the application server that refers to ERP_Q. At this point, any Servlet or EJB can put a message in the ERP_Q. Eventually, these messages will be transferred over to the back-end queue manager (ERP_QM) and physically stored in ERP_Q.

If you are following the Datagram with Context pattern, the Web tier must update the database and put in a message as a part of the same transaction. As a result, a session EJB (preferably stateless) is an ideal choice to perform that task.

WEB TIER-BOUND MESSAGES
Once again, due to MQ clustering, the Web tier local queue (WEB_Q) will appear to be a local queue to the back-end queue manager (ERP_QM). Any message put in this queue by the back-end system will be routed to one of the Web tier queue manager's local queue. The system will perform necessary load balancing and fail over.

MESSAGE FORMAT
A common problem with messaging is that any alteration of the message format creates a major ripple effect among all of the systems participating in the integration. A well-designed format should be relatively easy to extend or modify. Below are commonly used formats and their advantages.

• Character aligned: In this format, the sequence of fields and the number of characters for each field is precisely regulated. Text of this type is easy to read from a C or COBOL program without any need for parsing. Many legacy systems use this format. Writing the code by hand to create a message buffer from a Java object and initialize a Java object from a message buffer can be extremely time consuming. Use IBM's Extended Messaging technology to simplify working with strict messaging formats from a WebSphere application. Also, do not adopt this type of format in a new system. This is the most "brittle" format. Any change in the format will require careful code review and alteration for all systems.
• Comma separated: In this format, the length of a field can be anything. The sequence still matters. No standard parser exists for this format. We have developed an XML-style parser. The parser uses a schema file where the sequence of the fields is defined. This allows us to change the sequence and size of a field without necessarily doing major code changes to the systems.
• XML: This is by far the most powerful message format. It does not assume the order of attributes of an element. The order of elements themselves can be fixed or free. Standard parsers exists in many languages. XML is also great for multilingual text data.
• Java object: Java objects can be serialized and deserialized in a queue. Both JMS and MQ Java API allow us to do that. Systems can send each other fairly complex data structures with very little programming. If there is any change in the Java class code, make sure that you copy the latest class file to all the systems. This format only works when all systems in the integration are Java-based.

By default, WebSphere adds a JMS-specific XML header at the beginning of a textual message. If your back-end system is not using JMS, this will cause obvious problems. To avoid this, set the Target Client property of the queue destination to MQ.

JMS listeners do not require this field to be set to JMS. As a result, you can safely configure the client type of all JMS destinations to MQ.

TRANSACTION
In the datagram with a context communication pattern, it is essential that we perform a distributed transaction involving the database and WebSphere MQ. Fortunately, WebSphere does all of the hard work for us. All we have to do is:

1. Put in a message and update the database from an EJB, preferably a stateless session EJB and MDB (on the receiver side). All JMS and JDBC operations done within an EJB method automatically belong to a distributed transaction.
2. Make sure that the EJB is using a data source to open the database connection. Opening a plain JDBC connection using DriverManager.getConnection() will not give us a distributed transaction.
3. Make sure that the EJB looks up the data source using a resource reference. We have seen WebSphere crash repeatedly when the data source is looked up using its JNDI name and the connection from it is used in a distributed transaction.
4. Make sure that you are using an XA-compatible JDBC driver. We could not get the new DB2 Universal JDBC driver - com.ibm.db2.jcc.DB2XADataSource - to work (the non-XA driver works just fine). In any case, the XA-compatible Universal driver currently supports Type 2 mode only. Given all that, we recommend using the old legacy driver - COM.ibm.db2.jdbc.DB2XADataSource.
5. Make sure that the JMS connection factory has XA enabled.
6. In case of a business rule violation or system error, roll back the transaction (invoke setRollBackOnly() on the MessageDrivenContext or the SessionContext object) (see Listing 1).

JMS Administration Hints
You will need to install WebSphere MQ in all WebSphere Application Server machines. Create the queue managers, local queues, and the cluster. Ideally, this should be scripted using the MQSC commands. Start the listeners and the sender channels. Use the MQ test programs to make sure that remote communication is working.

Now all we have to do is create various JMS objects (such as connection factory and queue destination) in WebSphere administration console.

In the WebSphere administration console, set the MQ_INSTALL_ROOT variable for all nodes. Without this, the JMS server will fail to start up.

WebSphere allows you to create JMS objects for three types of JMS providers.

1. WebSphere MQ JMS provider: This is the provider to use if you are using WebSphere MQ.
2. WebSphere JMS provider: This is a built-in all-Java JMS server, which is used mainly within process messaging.
3. Generic JMS provider: Any other JMS-compliant messaging product can be configured here.

In the case of the WebSphere MQ JMS provider, a queue connection factory object is simply a link to a queue manager. Creating a queue connection factory does not actually create the queue manager. You need to create the queue manager separately (using the crtmqm command). The same concept applies to a JMS queue destination. In this case, a destination is a reference to a MQ queue.

A JMS connection factory or destination can be defined at the cell, node, or application server level. As we discussed in the framework section, the MQ queue manager names must be unique in the network. This means that we should define our queue connection factory at the node level. The factories will share the same JNDI name but will have a different MQ queue manager name. It is important that we keep the JNDI name the same to ensure that the resource references for the queue connection factory in the enterprise application will work in all of the machines.

In an MQ cluster, the shared local queue names in each application server machine must be the same. This allows us to define the JMS destination at the cell level. To be consistent, you may also define them at the node level.

An MDB is bound to a JMS listener port. A listener port is just a JMS connection factory (queue manager) JNDI name and destination (queue) JNDI name pair. In WebSphere, a listener port is defined for an application server. Currently, all application servers in a cluster must be configured individually. Take extra time to define a listener port for each one of them. The port name and the JNDI names will be the same in all application servers. An MDB is bound to a listener port at the enterprise application level. You can look up the valid name of the listener port for an application by opening the application's properties screen in WebSphere administration console and clicking on the Provide Listener Ports for the Messaging Beans link.

Conclusion
Messaging technology solves a very unique problem when all parties involved in a communication may not be present or reachable. WebSphere clustering in conjunction with MQ clustering changes the definition of sender and receiver. We need to think in terms of sending and receiving applications instead of processes. Multiple processes running in multiple machines can constitute a sender or receiver.

The tips and best practices mentioned in this article will help you create a messaging architecture that is robust, fault tolerant, and easy to manage.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...