![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Reviewing WebSphere MQ concepts
In the following section, you'll look at the key components used by the WebSphere MQ server. This list is a brief review of the core concepts if you're already familiar with message-oriented middleware. For a more in-depth discussion, please visit the WebSphere MQ library (see Resources).
- Queue. A named destination to which messages can be sent. Messages accumulate on queues until they are retrieved by programs that service them. The queues defined on a queue manager are called local queues.
- Queue manager. Queues reside in, and are managed by, a queue manager. The queue manager provides an API so that programs can put messages on, and get messages from, queues. A queue manager has a definition for each of its queues. It can also have definitions for queues owned by other queue managers, which are called remote queue definitions. Applications can also put messages targeted at these remote queues.
- Transmission queue. A special type of local queue on which messages are stored until they can be successfully transmitted and stored at a remote queue manager.
- Channel. A one-way communication link between two queue managers. It can carry messages destined for any number of queues at the remote queue manager. If your application requires messages to be returned from the remote queue manager, you need to define another channel to run in the opposite direction between the queue managers.
Deployment with a central queue manager
In the previous article in the series, "Deployment in a clustered environment," you explored a deployment environment where a single instance of a WebSphere MQ server hosted a central queue manager with Business Process Choreographer (BPC) queues. The application deployed to the environment executed on WebSphere Business Integration Server Foundation (Server Foundation) servers organized into a cluster. The individual servers in the cluster communicated with WebSphere MQ server by sending and receiving messages through the network. You can see an example of this deployment topology in Figure 1. Although the article focuses on the scenario in which WebSphere MQ is installed on a physically separate server, in practice WebSphere MQ could be nstalled on one of the other servers in the environment.
Figure 1. Production topology with a central queue manager
The topology in Figure 1 is characterized by high scalability of the Server Foundation cluster, but shows only a partial balancing of the messaging workload. The topology can be scaled up by adding additional Server Foundation cluster members on each of the individual nodes or scaled out by adding additional Server Foundation nodes to the cluster. However, this approach means the topology does not achieve full workload balancing because adding Server Foundation nodes results in higher throughput demands on the central queue manager. Distributing the incoming requests across the cluster members increases the likelihood of contention when the cluster members exchange messages with WebSphere MQ. The delays resulting from the contentions are exacerbated by the overhead of the network communication.
The following section introduces the core concepts of a WebSphere MQ cluster. In a traditional WebSphere MQ network using distributed queuing, every queue manager is independent. If one queue manager needs to send messages to another queue manager, it must define a transmission queue, a channel to the remote queue manager, and a remote queue definition for every queue to which it wants to send messages. A cluster is a network of queue managers that are logically associated in some way and need to share data. They can communicate directly with one another across a single network, without the need for extra channel definitions, remote-queue definitions, or transmission queues. This approach leads to easier administration of the network. Take a look at these in more detail:
- Cluster queue manager. A queue manager that is a member of a cluster. It can host cluster queues and advertise them to the other queue managers in the cluster. A cluster queue manager does not have to host or advertise any queues. It can simply feed messages into the cluster and receive only responses that are directed explicitly to it.
- Repository. A collection of information about the cluster queue managers. This information includes queue manager names, locations, channels, which queues they host, and so forth. A full repository contains a complete set of information about every cluster queue manager, while a partial repository contains a subset of this information.
- Repository queue manager. A cluster queue manager that holds a full repository. To ensure availability, set up at least two repository queue managers in a cluster. The remaining queue managers can hold a partial repository. The full repository queue managers receive information sent by the other queue managers in the cluster and update their repositories accordingly. They also send messages to each other to be sure that they are both kept up to date with new information about the cluster.
To enable workload balancing, all of the queue managers used by the application servers in the Server Foundation cluster must be a part of the same WebSphere MQ cluster. Each WebSphere MQ server in the MQ cluster requires the following queue managers for supporting BPC:
- get. A queue manager that owns all of the BPC queues. It is used by the process engine to get messages from the cluster.
- put. A queue manager that owns no queues. It is used by the process engine to send messages to the cluster.
It is also required that each queue manager participating in the cluster has the following channels dedicated to processing cluster messages:
- Cluster receiver channel. Used by the queue manager to receive messages from the other queue managers in the cluster. The messages from the other queue managers are addressed to a connection name specified in the definition of the receiver channel. The connection name is stored in cluster repositories to allow any two queue managers in a cluster to sent messages to each other.
- Cluster sender channel. Once defined, it is used by the queue manager to announce its membership in the cluster and the availability of the cluster receiver channel for communication with the other queue managers in the cluster. The cluster sender channel must point to one of the queue managers that hosts a cluster repository. All future changes to the queues and queue managers in the cluster will be communicated through this repository.
The cluster repository mentioned earlier is the mechanism used to keep track of the members in a cluster and to communicate any changes to the members of a cluster. In a deployment, some of the queue managers are chosen to store and maintain these repositories. To avoid a single point of failure, it is recommended that you pick another queue manager in the cluster to host a second repository. This queue manager should be located on another node.
A key consideration in the design of a WebSphere MQ cluster is ensuring that all of the repositories have a communication pathway to each other through cluster sender channels. In general, the cluster robustness increases with the number of the interconnections you have across the repositories in a cluster. (Note: Nuances of cluster design and repository placement for WebSphere MQ are outside the scope of this article.) The cluster topology installed and configured in the next sections is a common topology for organizing queue managers and repositories. For more information about how to design a WebSphere MQ cluster, consult the "WebSphere MQ Queue Managers Clusters manual." (See Resources.)
Benefits of WebSphere MQ clustering
Clustering WebSphere MQ servers in your Server Foundation deployment has a number of advantages, including the following:
- Improved workload balancing through clustering. When a message is placed on a queue in a queue manager that participates in a cluster, the message can be handled by any of the queue managers in the cluster -- improving utilization of the individual servers.
- Improved performance through local binding. The WebSphere MQ server can be installed on the same physical server as Server Foundation. In this case, the Java™ Message Service (JMS) connections used by the BPC can be configured to use the bindings mode of communication between WebSphere Application Server and MQ. The binding mode uses Java Native Interface (JNI) to call directly to the MQ application programming interface (API), avoiding the overhead of network communication.
- High availability through redundancy. In production, co-locating WebSphere MQ and Server Foundation servers may not be an option, despite the performance advantages of running the two applications on the same physical server. In this situation, higher availability can be achieved by maintaining a separate physical server for each WebSphere MQ instance.
In a clustered WebSphere MQ deployment, each of the MQ servers will host a pair of queue managers that are called "get" and "put." The get queue manager owns a set of queues defined by the BPC and the put queue manager has no queues because it is only used for sending messages. Since all of the queues belong to the same cluster, when a message arrives to a queue manager, WebSphere MQ invokes a workload-balancing algorithm to decide which queue should receive the message. As a result, the requests are shared across the queues in the cluster.
A sample topology focusing on Server Foundation interaction with a clustered WebSphere MQ deployment is shown in Figure 2. Notice that the messages sent from Server Foundation nodes may be placed on any of the put queue managers that belong to a cluster, which then balances the associated workload across the individual MQ servers in the cluster.
Figure 2. Production topology with a cluster of queue managers
Unfortunately, some applications that rely on server affinity cannot take advantage of the workload balancing benefits of MQ clustering. Server affinity implies that messages in an application must be processed in a specific order, which has to be guaranteed by a single server processing the messages. Applications that exhibit server affinity can still take advantage of improved communication performance through co-location of WebSphere MQ and BPC on the same physical server, as shown in Figure 2.
Install and configure a WebSphere MQ cluster
The following section gives you step-by-step instructions.
Required software Installation
- WebSphere MQ V5.3 or higher
- WebSphere Business Integration Server Foundation 5.1.1
- WebSphere Application Server Network Deployment 5.1.1 (with Server Foundation extensions)
- IBM DB2® Universal Database™ (UDB) 8.1 or higher
NOTE:The business processes in the cluster must all run on UNIX™ only or Windows® machines only. A combination of UNIX and Windows machines is not supported. The installation described here took place on a Windows platform. When installing on other platforms, make sure that your system meets the required prerequisites. On your platform, as on Windows, you will need to install the Java messaging and client features in your installation.
This article assumes that you are going to install WebSphere MQ servers on the same node as your Server Foundation installation to improve performance through local binding between the BPC and WebSphere MQ. If you are planning to have separate servers for both, you can find more information about how to specify appropriate BPC settings in the section Configuring MQ resources for the business process container using the administrative console. (See Resources.)
The createQueues script is located in WBISF_HOME\ProcessChoreographer directory. Create NODE01.BPC.GET and NODE01.BPC.PUT as the BPC get and put queue managers, respectively and name the cluster BPCCLUSTER. Listing 1 shows an example.
Listing 1. Create queue managers
createQueues NODE01.BPC.GET BPCCLUSTER NODE01.BPC.PUT
|
When the script has executed successfully, repeat this step on the other nodes that will host WebSphere MQ. In your configuration, you can replace NODEXX with the respective hostnames of the servers where you have installed WebSphere MQ. Throughout this article, the configuration is described using NODE01 and NODE02 as the hostnames.
Using MQ Explorer
- Start the NODE01.BPC.PUT queue manager.
- Create and start a new channel listener on port 1414 for the NODE01.BPC.PUT queue manager.
- Configure the NODE01.BPC.PUT as the repository for the BPCCLUSTER cluster.
Repeat these steps for the remaining queue managers in the cluster.
To make the queue manager available to the cluster, two additional channels have to be defined: a cluster receiver and a cluster sender channel. In the topology used in this article, the cluster sender channels of both put queue managers will point to each other. In other words, the cluster sender of NODE01.BPC.PUT will point to NODE02.BPC.PUT and the reverse is also true. The two nodes point to each other to exchange messages describing cluster events, such as adding a new queue to a cluster.
The channel definitions can be created using MQ Explorer from Advanced > Channels folder under the NODE01.BPC.PUT queue manager. When both of the nodes are configured, you'll see that the icons on the channels light up green, indicating that they are communicating. (See Figure 3.)
Figure 3. Cluster repository channels
With the cluster repositories defined, you can add the get queue managers on each of the WebSphere MQ servers to the BPCCLUSTER using an MQ Explorer wizard. From a context menu for the NODE01.BPC.GET queue manager, invoke the Join Cluster task to start a wizard and specify the following information:
- Port 1415 for the channel listener
- Local repository on NODE01.BPC.PUT for the cluster
Repeat the steps for NODE02 server, using NODE02.BPC.PUT for the cluster repository.
Configure Business Process Choreographer
During the Business Process Choreographer installation (described in Part 13), each application server in a cell is configured to point to a central queue manager. To take advantage of the WebSphere MQ cluster configuration described earlier in this article, the configuration needs to change to use the cluster queue managers.
From the administrative console for your Server Foundation cluster, open Resources > WebSphere MQ JMS Providers. Choose one of the servers in the cluster and open the WebSphere MQ Queue Connection Factory configuration for the server.
The two connection factories configured for BPC need to be modified: BPECF should be using the NODE01.BPC.GET queue manager and BPECFC should be using NODE01.BPC.PUT queue manager. Both connection factories should also be changed to use BINDINGS as the transport type. Each of the servers in the cluster needs to be updated with its appropriate settings for BPECF and BPECFC connection factories.
High availability and security considerations
The topology in this article trades off availability for performance by co-locating the WebSphere MQ server with Server Foundation on the same physical server. In a situation where the server fails while handling a request, the processing of messages on a queue will not continue until after the server is restarted.
In some applications, the delays from server reboots are unacceptable. To improve the availability of this topology, consider installing WebSphere MQ on a separate server along with a high-availability solution, such as High Availability Cluster Multi-Processing (HACMP) on IBM AIX®. At a minimum, your high availability solution for WebSphere MQ should:
- Take over the IP address of the failed server.
- Take over the shared disk used by the queue manager to store the queue files.
- Restart the queue manager and associated processes.
For this topology, the communication between WebSphere MQ and Server Foundation uses a bindings mode, which is a JNI interface between the Server Foundation Java process and the WebSphere MQ API. In addition to high performance, binding mode is secure because all of communication between the systems occurs in the Java process.
Transitioning to the high-availability setup implies that the communication between WebSphere MQ and Server Foundation takes place over the network. Since the binding mode is not applicable in this situation, you need to ensure the WebSphere MQ queue connection factories are reconfigured to use the client mode for communication. To guarantee security of the messages traveling over the network, the client mode must be configured to support SSL and J2C authentication alias. (More information about high availability and security issues is available in the resources section.)
In this article, you explored the clustering options available in IBM WebSphere MQ and you learned how clustered messaging can be used to improve workload balancing. You also found out about both core and clustering-specific concepts used in WebSphere MQ and other messaging-oriented middleware. Using clustering improves the overall scalability of an IBM WebSphere Business Integration Server Foundation deployment architecture; however, if you plan to enhance an architecture with WebSphere MQ clustering, you should consider the benefits, as well as the availability and security considerations, explained in this article.
Learn
-
Get more details on messaging by referencing the WebSphere MQ Library.
-
Visit WebSphere Business Integration Server Foundation InfoCenter to read about:
- Configuring MQ resources for the business process container using the administrative console
- Process choreographer scenarios for clustering
-
High-availability middleware on Linux, Part 2: IBM WebSphere MQ
-
JMS transport security, Part 1
-
Business process choreography in WebSphere: Combining the power of BPEL and J2EE
Get products and technologies
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
Karl Lvoff is a Software Engineer working with the On Demand Incubation and Development organization in the IBM Software Group. His skills are in the area of distributed computing and service oriented architecture as well as speech application development and natural language understanding. He has published and presented on the subject of dialog management to peers in the industry and academia. Contact Karl at osipov@us.ibm.com.
Terrence White is an Advisory IT Specialist from IBM Global Services. He is currently working with the Service-Oriented Architecture Plus team, with a focus on Web services and business process development using process choreography. You can contact Terrence at tewhite@us.ibm.com.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
