The following installation tasks must be performed to implement WebSphere
MQ intercommunication:
Before you install and configure the Remote Agent, consider the following
points:
- Configurations at the spoke sites. Because the implementer at the
hub site typically has primary responsibility for planning the overall
process, this appendix describes the necessary installation tasks for both the
hub and spoke sites.
- Security needs of the hub and spoke site. Your security
requirements may differ from those of your trading partners, and there may be
different requirements among your trading partners. See Security for information.
- Configuration properties coordination between hub site and spoke
sites. Certain configuration properties, port numbers, and some
security settings, must be coordinated between the hub and spoke sites.
On the hub site, the IBM Java ORB and its Transcient Naming Service are
installed automatically with the ICS installer. For communication
between ICS and adapters over the Internet, configure a fixed port with the
OAport configuration parameter on the spoke and hub sites.
- Note:
- The hub (ICS) port identifying the channel for information flowing from an
adapter to ICS must be different from the spoke port identifying the channel
for information flowing from ICS to an adapter.
For more information on OAport, see its description in the CORBA section of
the ICS configuration file in Appendix A, Configuration parameters.
The Remote Agent can be configured for use with native WebSphere MQ or
HTTP/HTTPS protocols for communication over the Internet. The native
WebSphere MQ option is configured using only the software delivered with the
product. The HTTP option requires WebSphere MQ Internet PassThrough
(MQIPT), which must be purchased separately. This section describes
both configurations.
- Note:
- JMS is the only supported transport for both configurations.
This configuration option uses the WebSphere MQ protocol, along with
Security Socket Layer (SSL) to ensure secure communication over the
Internet. This configuration provides better performance; however,
it requires that a port be opened on the firewall to allow WebSphere MQ
traffic through it. See Figure 13.

Figure 13. Native WebSphere MQ Configuration
You must configure channels for bidirectional communication between
InterChange Server and the remote connector agent. Two channels are
required: one for each direction.
It is possible to have InterChange Server and adapter reside in the
Intranet, with Application Servers in the demilitarized zone (DMZ).
Such a configuration is acceptable provided that the adapter is not configured
as a remote agent. If the adapter and Application Server are in
different subnets then the only way to have the adapter communicate with the
application server is to explicitly include both the hostnames and IP address
of the Application Server in the \\WINNT\system32\drivers\etc\hosts
file of the adapter machine.
- Note:
- The following steps assume that MQ1 and MQ2 in Figure 13are listening on port 1414.
- Channel 1 (MQ1 is the sender and MQ2 is the receiver):
- Create the CHANNEL1 sender channel on MQ1.
- Create the CHANNEL1 receiver channel on MQ2.
- Channel 2 (MQ2 is the sender and MQ1 is the receiver):
- Create the CHANNEL2 sender channel on MQ2.
- Create the CHANNEL2 receiver channel on MQ1.
- Configure firewall 1 to forward traffic on port 1414 to MQ1, and configure
firewall 2 to forward traffic on port 1414 to MQ2.
- Note:
- Assume that MQ1 and MQ2 are listening on port 1414 and that the firewall
allows network traffic based on port forwarding. The actual
configuration may change, depending on the type of firewall.
- Set the IP Address of sender Channel 1 to the connection name of firewall
2.
- Set the IP Address of sender Channel 2 to the connection name of firewall
1.
- Note:
- Refer to Configuring WebSphere MQ for JMS for information on setting up JMS queues.
ICS, by default, creates queue managers with mixed cases, such
as:
ICS430.queue.manager
However, when defining the queues needed for Remote Access, WebSphere MQ
automatically converts everything to uppercase. But the configuration
for remote queue definitions is case sensitive. When this happens, the
messages fail to flow out of the queues. The solution is to go into MQ
Explorer and edit the Remote Queue Manager field for all the Remote Queue
definitions to have the proper case (for both Queue managers).
- MQ1 (queue1 is for server-to-agent communication):
- Set queue1 as the remote queue and queue2 as the local queue.
- Set MQ2 as the remote queue manager for queue1.
- MQ2 (queue2 is for agent-to-server communication):
- Set queue2 as the remote queue and queue1 as the local queue.
- Set MQ1 as the remote queue manager for queue2.
- Set up a transmission queue on each queue manager.
- Set up a dead letter queue on each queue manager.
- Confirm that the fault queue is local to each queue manager.
Refer to the RemoteAgentSample.mqsc and
RemoteServerSample.mqsc sample scripts, located in
ProductDir\mqseries, to configure the queue
managers.
This configuration option uses WebSphere MQ Internet Pass Through (MQIPT)
to pass information over the Internet using HTTP or HTTPS. See Figure 14.

Figure 14. HTTP/HTTPS configuration
You must define routes to specify the port, IP address, and SSL
details. Also, you must configure two routes for bidirectional
communication between InterChange Server and the remote connector
agent. Two routes at each MQIPT are required: one for each
direction.
You must configure channels for bidirectional communication between
InterChange Server and the remote connector agent. Two channels are
required: one for each direction.
- Note:
- The following steps assume that MQ1 and MQ2 in Figure 14 are listening on port 1414.
- Channel 1 (MQ1 is the sender and MQ2 is the receiver):
- Create the CHANNEL1 sender channel on MQ1.
- Create the CHANNEL1 receiver channel on MQ2.
- Channel 2 (MQ2 is the sender and MQ1 is the receiver):
- Create the CHANNEL2 sender channel on MQ2.
- Create the CHANNEL2 receiver channel on MQ1.
- Set the ConnectionName parameter of CHANNEL1 to the IP Address and
listener port of MQIPT1.
- Set the ConnectionName parameter of CHANNEL2 to the IP Address and
listener port of MQIPT2.
- Set firewall 1 to forward all traffic on the listener port to
MQIPT1.
- Set firewall 2 to forward all traffic on the listener port to
MQIPT2.
- Note:
- Refer to Configuring WebSphere MQ for JMS for more information on setting up JMS queues.
- MQ1 (queue1 is for server-to-agent communication):
- Set queue1 as the remote queue and queue2 as the local queue.
- Set MQ2 as the remote queue manager for queue1.
- MQ2 (queue2 is for agent-to-server communication):
- Set queue2 as the remote queue and queue1 as the local queue.
- Set MQ1 as the remote queue manager for queue2.
- Set up a transmission queue on each queue manager.
- Set up a dead letter queue on each queue manager.
- Confirm that the fault queue is local to each queue manager.
Refer to the RemoteAgentSample.mqsc and
RemoteServerSample.mqsc sample scripts, located in
ProductDir\mqseries to configure the queue
managers.
- Route1 - set the following parameters:
- ListenerPort = Port number on which MQIPT1 is listening for messages from
queue manager MQ1
- Destination = Domain name or IP address of MQIPT2
- DestinationPort = Port on which MQIPT2 is listening
- HTTP = True
- HTTPS = True
- HTTPProxy = IP Address of firewall 2 (or a proxy server if there is one in
the DMZ)
- SSLClient = True
- SSLClientKeyRing = Path to the file that contains the MQIPT1 certificate
- SSLClientKeyRingPW = Path to the file that contains the password for the
ClientKeyRing file
- SSLClientCAKeyRing = Path to the file that contains the trusted CA
certificates
- SSLClientCAKeyRingPW = Path to the file that contains the password for the
CAKeyRing file
- Route2 - Set the following parameters:
- ListenerPort = Port on which MQIPT1 is listening for messages from MQIPT2
- Destination = Domain name or IP Address for queue manager MQ1
- DestinationPort = Port on which MQ1 is listening
- SSLServer = True
- SSLServerKeyRing = Path to the file that contains the MQIPT1 certificate
- SSLServerKeyRingPW = Path to the file that contains the password for the
ServerKeyRing file
- SSLServerCAKeyRing = Path to the file that contains the trusted CA
certificates
- SSLServerCAKeyRingPW = Path to the file that contains the password for the
CAKeyRing file
- Route1 - set the following parameters:
- ListenerPort = Port on which MQIPT2 is listening for MQIPT1
- Destination = Domain name of IP Address of queue manager MQ2
- DestinationPort = Port on which MQ2 is listening
- SSLServer = True
- SSLServerKeyRing = Path to the file that has MQIPT2s certificate
- SSLServerKeyRingPW = Path to the file that has the password for the
ServerKeyRing file
- SSLServerCAKeyRing = Path to the file that contains the trusted CA
certificates
- SSLServerCAKeyRingPW = Path to the file that contains the password for the
CAKeyRing file
- Route2 - set the following parameters:
- ListenerPort = Port on which MQIPT2 is listening for messages from MQ2
- Destination = Domain name or IP Address of MQIPT1
- DestinationPort = Port on which MQIPT1 is listening
- HTTP = True
- HTTPS = True
- HTTPProxy= IP Address of firewall1 (or a proxy server if there is one in
the DMZ)
- SSLClient = True
- SSLClientKeyRing = Path to the file that contains the MQIPT2 certificate
- SSLClientKeyRingPW = Path to the file that contains the password for the
ClientKeyRing file
- SSLClientCAKeyRing = Path to the file that has trusted CA certificates
- SSLClientCAKeyRingPW = Path to the file that contains the password for the
CAKeyRing file
For some applications, setup tasks are required to enable the connector
agent to create, update, retrieve, or delete data in the application.
Such setup tasks are described in the appropriate IBM documentation for
specific adapters.
Remote Agent requires that the following be running:
- InterChange Server (ICS). ICS runs at the hub site, and includes
the connector controller.
- Connector agent. The connector agent typically runs at a spoke
site.
- Queue manager at both the hub and spoke sites with channels
configured.
- WebSphere MQ internet pass-thru (MQIPT), which is used for HTTP/HTTPS
configuration option.
For instructions on starting these components on a UNIX system, see the
System Installation Guide for UNIX.
On Windows 2000 systems, all of these components can be started from the
Start menu or can be configured to run as Windows services, as described in
the sections that follow.
This section describes starting components from the Start menu.
To start InterChange Server, including all of the connector controllers
that have been installed, at the hub site choose Start> Programs > IBM
WebSphere InterChange Server > IBM WebSphere InterChange Server > IBM
WebSphere InterChange Server.
To start a connector agent, at the spoke site where the agent is installed
choose Start > Programs > IBM WebSphere Business Integration Adapters
> Adapters > Connectors > ConnectorName.
IBM provides a setup program for configuring components on the hub site to
run as Windows services, including InterChange Server and connector
agents.
Connector agents running on remote machines can also be configured to run
as Windows services. Use the InterChange Server Windows services Setup
utility, as described under in "Running components as Windows services".
The spoke site is presumed not to be using InterChange Server when
configuring a remote connector agent as a Windows service.
