Enabling SOA Using WebSphere Messaging

54 Enabling SOA Using WebSphere Messaging

queue hosted on the second queue manager by a distributed or cluster message

channel before the second application could get the message.

Applying shared queues addresses the problem of message availability when a

queue manager becomes unavailable while messages are on its queues. When

a clustered queue manager fails, new requests are routed around that queue

manager, but messages that exist on the failed queue manager cannot be

accessed until the queue manager is made available again. However, if the

queue manager is a member of a QSG, other queue managers within the QSG

can access the messages in the queue, preventing those messages from being

unavailable.

3.2.2 WebSphere Message Broker

WebSphere Message Broker benefits from WebSphere MQ high availability

capabilities such as queue manager clustering and the z/OS shared queue

functionality. To be able to lay out a high availability design for a WebSphere

Message Broker application, the concepts of WebSphere MQ and the

possibilities that they offer must be understood.

There are different levels in a WebSphere Message Broker environment that

need to be considered in order to provide high availability.

First, WebSphere MQ provides the transport layer for WebSphere Message

Broker, utilizing queue managers not only for administering services and

resources but also for providing the connection point for the brokers. These

queue managers should be configured for high availability through queue

manager clustering, hardware clustering, and shared queues (for z/OS).

Also consider the case where a clustered queue manager does not recognize

that a connected broker has failed and is still served messages to be processed.

These messages are not processed until the failed broker is up and running

again. One possible solution would be to provide more than one broker instance

per queue manager. Another possible solution is to set up a monitor for the

broker and input queue that triggers an alert in the event of a failure.

Second it must be guaranteed that the broker functionality is highly available.

This can be achieved by providing multiple message broker instances serving

the same logical hub. The different brokers could even reside on different

machines. Each broker instance could either be mapped to a single queue

manager or to a queue manager cluster.

Figure 3-6 on page 55 shows a topology using two broker instances together with

z/OS shared queues and queue manager clustering. Note that Node C is not