Patterns: Implementing Self-Service in an SOA Environment

210 Patterns: Implementing Self-Service in an SOA Environment

Figure 7-32 shows the role of JMS and JNDI relative to a Java application. These

two APIs sit above any specific service providers and encapsulate any

vendor-specific information.

As a result, a developer using these technologies in a messaging-enabled

application need only be familiar with the APIs, not the specific messaging

systems.

Figure 7-32 The role of JMS and JNDI relative to an application

So, how does an administrator put these objects in the JNDI name space? This

step is vendor-specific. If you are using WebSphere MQ V5.3 with WebSphere

Application Server, or just the WebSphere default messaging provider, you can

administer these objects right from the WebSphere administrative console. If you

are using another application server, WebSphere MQ V5.3 provides a tool called

JMSAdmin for this purpose.

7.5.6 Choosing a JMS provider

WebSphere Application Server V6 comes with a JMS 1.1 compliant default

messaging provider. This provider uses the service integration bus for transport.

WebSphere Application Server V6 also provides support for the IBM WebSphere

MQ product as the JMS provider, as well as the capability to define and use

generic JMS providers.

When deciding which JMS provider suits your environment, consider the

following about each provider:

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

messaging provider:

– You have a requirement for your message-driven beans to handle generic

message types, not just JMS messages.

– You would like to use mediations that act on inbound or outbound

messages.

– You are only connecting J2EE applications hosted by WebSphere

Application Server to each other.

MQSeries MSMQ LDAP CORBA

JNDIJMS

Java Application