Overview

Depending on which transaction scenario (MEP) you are using - and, in the case of JMS, what JMS Provider you are using - there are two operations that may need to be configured before you can use Universal Command Agent for SOA:

• Outbound JMS Configuration Using WAS
• Outbound MQ Configuration - MQ Client Jar Files

Outbound JMS Configuration Using WAS

Although, there is no outbound configuration needed for HTTP and SOAP outbound operations, some configuration may be needed for JMS operations, depending on which JMS Provider you are using.

This section explains what configuration is required if you are using IBM's WebSphere Application Server (WAS) as your JMS provider.

Currently, Universal Command Agent for SOA: JMS Connector has been tested against Apache's ActiveMQ JMS provider and IBM's WebSphere Application Server, WebSphere Application Server Network Deployment, and WebSphere Application Server Extended Deployment.

Using the properties.xml File

This properties file is not specific to WebSphere; it could, for example, be named message.properties.xml or bob.properties.xml. In general, the name should reflect the system to which the properties pertain. If you are using BEA as your JMS Provider, you might want to call it bea.properties.xml.

Also note that this properties file is an XML file, with a very simple format. Its purpose is to set properties to be passed to the JMS connection or JMS message, depending on whether jms.initialcontext or jms.hearder is used. The format of the properties is in name / value pairs.

A vendor-specific properties.xml file should be located in the Universal/UAI directory of the UAC install.

For WebSphere, you must specify the class for the IBM ORB in order for the client jar files to process the message before UAC sends it to the specified WebSphere queue or topic.

Specifically, the values to set are:

• Name - set to jms.initialcontext.com.ibm.CORBA.ORBInit.
• Value - set to com.ibm.ws.sib.client.ORB.

The following figure illustrates a sample properties.xml file. Remember, these values are specific to the JMS Provider that you are using.

For the JMS Request / Reply operation, you must specify the reply-to queue name:

• Name - set to jms.header.JMSReplyTo.
• Value - set to jms/IntegrationTestQueue1 or the appropriate queue name.

The following figure illustrates a sample operation.

JMS Provider Client Jar Files

As is the case for inbound, you must have the JMS provider client jar files for outbound or request/reply operations as well. Since each JMS provider implementation is vendor-specific, you must acquire the client jar files that allow third-party applications to connect and communicate with your JMS provider.

For example, if you are using the JMS functions in IBM's WebSphere Application Server, you need the sibc.jms.jar, sibc.jndi.jar, and sibc.orb.jar files.

You would place the JMS provider client jar files in the following location:

The names of the jar files differ depending on which JMS provider you are using.

The Universal Command Agent for SOA: JMS Connector does not provide the queue or topic infrastructure. You must have a JMS provider with queues or topics configured to use the JMS outbound or request / reply operations.

Outbound MQ Configuration - MQ Client Jar Files

As is the case for inbound, you must have the IBM MQ client jar files for outbound or request / reply operations.

Place the MQ client jar files in the following location:

The following jar files are required:

• com.ibm.mq.commonservices.jar
• com.ibm.mq.jar
• com.ibm.mq.pcf.jar
• com.ibm.mq.headers.jar
• com.ib.mq.jmqi.jar
• connector.jar

The Universal Command Agent for SOA: MQ Connector does not provide the queue or topic infrastructure. You must have a WebSphere MQ Message Broker with queues configured to use the MQ outbound or request/reply operations.

The MQ Client for Java version 7.0 package with the latest fix pack is recommended.

When using a MQ CCDT to establish connections to queue managers, 7.0.1.3 or later is highly recommended.