Installation tasks

The following installation tasks must be performed to implement WebSphere MQ intercommunication:

Planning the installation

Before you install and configure the Remote Agent, consider the following points:

Configuring the IBM Java ORB for use with Remote Agents

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.

Configuring the Remote Agent

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.

Native WebSphere MQ

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.

To configure channels for native WebSphere MQ
  1. Channel 1 (MQ1 is the sender and MQ2 is the receiver):
    1. Create the CHANNEL1 sender channel on MQ1.
    2. Create the CHANNEL1 receiver channel on MQ2.
  2. Channel 2 (MQ2 is the sender and MQ1 is the receiver):
    1. Create the CHANNEL2 sender channel on MQ2.
    2. Create the CHANNEL2 receiver channel on MQ1.
  3. 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.
  4. Set the IP Address of sender Channel 1 to the connection name of firewall 2.
  5. Set the IP Address of sender Channel 2 to the connection name of firewall 1.

To configure queues for native WebSphere MQ
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).

  1. MQ1 (queue1 is for server-to-agent communication):
    1. Set queue1 as the remote queue and queue2 as the local queue.
    2. Set MQ2 as the remote queue manager for queue1.
  2. MQ2 (queue2 is for agent-to-server communication):
    1. Set queue2 as the remote queue and queue1 as the local queue.
    2. Set MQ1 as the remote queue manager for queue2.
  3. Set up a transmission queue on each queue manager.
  4. Set up a dead letter queue on each queue manager.
  5. 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.

HTTP/HTTPS

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.

To configure channels for HTTP/HTTPS

  1. Channel 1 (MQ1 is the sender and MQ2 is the receiver):
    1. Create the CHANNEL1 sender channel on MQ1.
    2. Create the CHANNEL1 receiver channel on MQ2.
  2. Channel 2 (MQ2 is the sender and MQ1 is the receiver):
    1. Create the CHANNEL2 sender channel on MQ2.
    2. Create the CHANNEL2 receiver channel on MQ1.
  3. Set the ConnectionName parameter of CHANNEL1 to the IP Address and listener port of MQIPT1.
  4. Set the ConnectionName parameter of CHANNEL2 to the IP Address and listener port of MQIPT2.
  5. Set firewall 1 to forward all traffic on the listener port to MQIPT1.
  6. Set firewall 2 to forward all traffic on the listener port to MQIPT2.

To configure queues for HTTP/HTTPS
Note:
Refer to Configuring WebSphere MQ for JMS for more information on setting up JMS queues.
  1. MQ1 (queue1 is for server-to-agent communication):
    1. Set queue1 as the remote queue and queue2 as the local queue.
    2. Set MQ2 as the remote queue manager for queue1.
  2. MQ2 (queue2 is for agent-to-server communication):
    1. Set queue2 as the remote queue and queue1 as the local queue.
    2. Set MQ1 as the remote queue manager for queue2.
  3. Set up a transmission queue on each queue manager.
  4. Set up a dead letter queue on each queue manager.
  5. 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.

To configure routes for MQIPT1

To configure routes for MQIPT2

Enabling the application to interact with the connector agent

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.

Starting the Remote Agent components

Remote Agent requires that the following be running:

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.

Starting components from the Start menu

This section describes starting components from the Start menu.

Starting a connector controller

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.

Starting a connector agent

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.

Setting up components as Windows services

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.

Copyright IBM Corp. 1997, 2004