124 Using IBM WebSphere Message Broker as an ESB with WebSphere Process Server
6.4 WebSphere MQ configuration
The WebSphere MQ JMS providers must be prepared for the business scenario
and for global transactions. We performed the following actions, which are
explained in the sections that follow:
? Preparing the transaction manager
? Preparing the resource managers
? Making the libraries available
? Configuring the JMS administered objects
6.4.1 Preparing the transaction manager
In this scenario, the queue manager for WebSphere Message Broker,
TEST.QUEUE.MANAGER manages the global transaction.
We performed the following actions to prepare the queue manager:
1. Create the following queues on TEST.QUEUE.MANAGER:
– TEST/REQUESTQUEUE
This queue holds the request from the business process. The JMSInput
node in the message flow picks up messages that arrive at this particular
queue and starts flow processing.
– TEST/RESPONSEQUEUE
The message flow responds back to the business process with the status
of the transaction in this queue. The listener port listens on this queue for
the response message.
–DLQ
– BOQUEUE
2. Define the XA resource managers to the queue manager.
On distributed systems, the external syncpoint coordinator for the broker is
WebSphere MQ.
Before you deploy a message flow in which the Transaction Coordination
property is set to Global, modify the queue manager qm.ini file to include
definitions for each JMS provider resource manager that participates in
globally-coordinated transactions. The resource managers to be involved in
global units of work are coordinated by the queue manager. One
XAResourceManager stanza is required for each instance of a resource
manager type. Since all the resource managers in this scenario are
WebSphere MQ, one stanza is required.
Chapter 6. Scenario: WebSphere Message Broker acting as a transaction manager 125
If the queue manager resides on a Linux® and UNIX® system, add a stanza
to the queue manager qm.ini file for each JMS provider, for example:
XAResourceManager:
Name=Jms_Provider_Name
SwitchFile=/install_dir/bin/ JMSSwitch.so
XAOpenString=Initial Context,location JNDI,Optional_parms
ThreadOfControl=THREAD
On Windows systems, this information is stored in the Windows registry and
can be added using the WebSphere MQ Explorer. To define an XA resource
manager using the WebSphere MQ Explorer, select Properties → XA
resource managers from the context menu for the queue manager. The Edit
XA Resource window (Figure 6-6) that opens.
Figure 6-6 XA Resource stanza for the JMS providers
z/OS: On z/OS, the external syncpoint manager is Resource Recovery
Services (RRS). Syncpoint control for the JMS provider is managed with
RRS syncpoint coordination of the queue manager of the broker. You do
not need to modify the qm.ini file.
126 Using IBM WebSphere Message Broker as an ESB with WebSphere Process Server
Complete the fields as follows:
a. In the Name field, type JMSPROVIDERS.
This is the name of the resource manager instance. The name must be
unique within one queue manager stanza.
b. For SwitchFile, type WebSphere Message Broker Install
DirectoryMQSI6.0inJMSSwitch.dll
On distributed platforms, an additional component, called the
switch file, is
needed for global transactions. The switch file contains the XA switch
structure of the resource manager. The switch file is a shared library (a
dynamic link library (DLL) on Windows). The SwitchFile setting defines the
path to the JMSSwitch library that is supplied in the bin directory of the
broker.
When the broker’s WebSphere MQ queue manager starts, it loads this
switch file. The switch file forwards XA/Open transaction calls from the
syncpoint coordinator to the JMS provider. (The broker’s queue manager
acts as the syncpoint coordinator in our scenario.) This ensures that the
JMS resources that participate in the transaction can be coordinated in
synchronization with other resource managers that are involved in the
same transaction.
c. For XAOpenString, type com.sun.jndi.fscontext.
RefFSContextFactory,file:/C:/JNDI-Directory.
You enter a string of data that WebSphere MQ passes in its calls to the
resource manager's xa_open function. WebSphere MQ and the queue
manager call the xa_open function when the queue manager starts and
when you make the first call to MQBEGIN in your WebSphere MQ
application process. In this example, a file-based initial context factory has
been used for WebSphere MQ JMS provider.
The XAOpenString parameters are specified as:
Initial_Context,Location_JNDI,Optional_Parms
The values for XAOpenString are as follows:
• Initial Context is the value that is set in the JMSInput node basic
property Initial Context Factory.
• Location JNDI is the value that is set in the JMSInput node basic
property Location of JNDI. This value should include the leading
keyword, such as file:/, iiop:/, or ldap:/.
Important: The values for the Initial Context factory and Location of
JNDI bindings in the stanza must match those specified in the
JMSInput or JMSOutput nodes in the message flows.
Chapter 6. Scenario: WebSphere Message Broker acting as a transaction manager 127
• Optional_Parms as the name suggests refers to optional parameters.
The optional parameters are comma-separated and positional.
Therefore, any parameters that are missing must be represented by a
comma. They could be of the following types:
- LDAP Principal matches the value that is set for the broker by using
the mqsicreatebroker or mqsichangebroker commands.
- LDAP Credentials matches the value that is set for the broker by
using the mqsicreatebroker or mqsichangebroker commands.
- Recovery Connection Factory Name is the JNDI administered
connection factory that is defined in the bindings file.
The recovery connection factory name must match a queue
connection factory name in the JNDI administered objects.
If a value is not specified, you must add a generic queue connection
factory called recoverXAQCF to the bindings file. You can see this in
“Creating the queue connection factories” on page 131. In this
example, we have omitted this value.
Whether the name is specified or a default is used, the recovery
connection factory should be defined as an XA queue connection
factory for the JMS provider that is associated with the initial context
factory.
d. For XACloseString, type com.sun.jndi.fscontext.RefFSContextFactory,
file:/C:/JNDI-Directory
You enter the string to be passed to the resource manager’s xa_close
entry point. The entry should match the values provided for the
XAOpenString.
e. For ThreadOfControl, type Thread.
The queue manager uses this parameter for serialization when calling the
resource manager from a multi-threaded process. A value of Thread
indicates that the resource manager is “thread aware.” XA function calls
can be made to the external resource manager from multiple threads at
the same time.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.