Patterns: Implementing Self-Service in an SOA Environment

Chapter 7. Application and system design guidelines 211

򐂰 The following are some reasons why you might choose to use IBM

WebSphere MQ:

– Your message-driven beans are written following the EJB 2.0

specification.

– You want to use WebSphere MQ specific features.

– Your message-driven beans have to handle JMS messages generated by

non-J2EE applications.

– You want to integrate your solution in a more complex scenario that

requires the use of WebSphere MQ, like using WebSphere Business

Integration Message Broker.

If you decide to use WebSphere MQ, you could decide to use both options, using

the default messaging provider’s MQ Links, to communicate both JMS providers.

For details about the WebSphere MQ Links, refer to WebSphere Application

Server V6 System Management and Configuration Handbook, SG24-6451.

7.5.7 WebSphere default messaging provider design considerations

The service integration technologies of IBM WebSphere Application Server can

act as a messaging system when you have configured a service integration bus

that is accessed through the default messaging provider. This support is installed

as part of WebSphere Application Server, administered through the

administrative console, and is fully integrated with the WebSphere Application

Server runtime.

The JCA 1.5 message inflow management enables a resource adapter to deliver

messages asynchronously to message endpoints residing in the application

server independent of the specific messaging style, messaging semantics, and

messaging infrastructure used to deliver messages. This contract also serves as

the standard message provider pluggability contract that allows a wide range of

message providers (Java Message Service (JMS), Java API for XML Messaging

(JAXM), etc.) to be plugged into any J2EE compatible application server with a

resource adapter.

JMS ActivationSpec bean

An ActivationSpec Java bean instance encapsulates the configuration

information needed to setup asynchronous message delivery to a message

endpoint.

212 Patterns: Implementing Self-Service in an SOA Environment

Service integration bus and WebSphere MQ

The service integration bus is the underlying messaging provider for the default

messaging provider, replacing the embedded messaging provider that was

supported in WebSphere Application Server V5.

If you operate within a WebSphere Application Server environment, sending

messages across a service integration bus, you can also exchange point-to-point

and publish/subscribe messages with applications in a WebSphere MQ network.

The method of exchange uses a component called WebSphere MQ link. The

WebSphere MQ link makes exchanging messages very simple by automatically

converting them so their characteristics are retained or mapped to similar

settings. However, there are some circumstances where the two systems work

differently and you can select from the conversion options available.

In most cases messages will flow either from a:

򐂰 Service integration bus in a WebSphere Application Server to a WebSphere

MQ network

򐂰 WebSphere MQ network directly to a service integration bus in WebSphere

Application Server

However, you can also send messages between two different:

򐂰 WebSphere Application Server service integration buses by way of an

intermediate WebSphere MQ network

򐂰 WebSphere MQ networks through a service integration bus of an

intermediate WebSphere Application Server.

Regardless of the route you implement, the requirements are the same: the

requirements of the receiving WebSphere MQ destination must be recognized,

and the message transformed to achieve a smooth transfer. This is why the

WebSphere MQ link was designed. It handles both styles of messaging familiar

to WebSphere MQ programmers: point-to-point and publish and subscribe.

For details about WebSphere MQ Links, refer to WebSphere Application Server

V6 System Management and Configuration Handbook, SG24-6451.

Message reliability levels (Quality of Service)

Messaging queues and topics are defined as destinations on the bus. It is on a

destination that an administrator specifies the default quality of service levels that

will be applied when a message producer or message consumer interacts with

the destination. An administrator is able to configure a default reliability and a

maximum reliability for each service integration bus destination.