Patterns: Implementing Self-Service in an SOA Environment

214 Patterns: Implementing Self-Service in an SOA Environment

7.5.8 WebSphere MQ design considerations

If you have elected to use WebSphere MQ as the messaging provider, there are

a few design issues you should consider.

Connection options

A message placed on an IBM WebSphere MQ queue from an application server

may originate directly from a servlet, or may be sent from a command bean or

EJB. We recommend the latter two methods and not so much from servlets.

Regardless of the method, the messages are sent to a queue manager using

one of the two available WebSphere MQ Java APIs by IBM WebSphere MQ.

Each API has certain characteristics that make it appropriate for a situation,

depending on your priorities. However, the API chosen can have an effect on you

options for distributing the application components.

The two APIs that we discuss here are:

򐂰 The IBM WebSphere MQ for Java Message Service package,

com.ibm.mq.jms.jar and com.ibm.jms

IBM WebSphere MQ for JMS classes implements the J2EE Java Message

Service (JMS) interface to enable JMS programs to access a subset of IBM

WebSphere MQ features from a vendor-neutral point of view, as defined by

the JMS specification. The JMS interface is implemented by a set of IBM

WebSphere MQ classes for JMS.

򐂰 The IBM WebSphere MQ for Java package, com.ibm.mq.jar

IBM WebSphere MQ for Java classes enable Java applets, applications,

servlets, and EJBs to issue direct calls and queries to IBM WebSphere MQ

using specific calls designed to take advantage of IBM WebSphere MQ

features.

A JMS Java application uses the vendor-independent JMS interfaces to access

the MQ-specific implementation of the JMS classes.

A key idea in JMS is that it is possible, and strongly recommended, to write

application programs that use only references to the interfaces in javax.jms. All

vendor-specific information is encapsulated in implementations of:

򐂰 QueueConnectionFactory

򐂰 TopicConnectionFactory

򐂰 Queue

򐂰 Top ic

Coding outside the JMS interface to access WebSphere MQ-specific features

will, of course, reduce the portability of the application, because it is now

referencing WebSphere MQ-specific classes directly. If application portability,

Chapter 7. Application and system design guidelines 215

vendor independence, and location transparency are of importance, pure JMS is

the obvious choice. JMS uses abstracted concepts of messaging to provide a

vendor-independent API to messaging, while underneath lies the IBM

WebSphere MQ implementation of the JMS interfaces. The real-world entities

that are IBM WebSphere MQ queue managers and queues are accessed by

JMS clients through the use of the Java Directory and Naming Service (JNDI).

The IBM WebSphere MQ entities are published to JNDI from the WebSphere

Administrative Console, or through a tool called JMSAdmin. MQ JMS supports

both the point-to-point and publish/subscribe models of JMS.

MQ base JMS classes provide two connection options to IBM WebSphere MQ:

򐂰 Bindings mode to connect to a queue manager directly

򐂰 Client mode using TCP/IP to connect to a queue manager (not supported on

z/OS or OS/390®)

All options support connection pooling.

Java bindings mode

In bindings mode, also known as server connection, the communication to the

queue manager utilizes interprocess communications. One of the key factors that

should be kept in mind is that binding mode is available only to programs running

on the WebSphere MQ server that hosts the queue manager.

The key connection parameter in this case is the queue manager name.

Figure 7-33 Java bindings mode

Connecting to the local queue manager has several major advantages:

򐂰 The probability of establishing a connection to a queue manager in your own

host is high, as opposed to a connection with a remote queue manager.

Application Server

Application

Broker1

Queue Manager

Broker2

Queue Manager

Queue

Manager