To enable service components on different servers to communicate,
you have to configure the servers similarly. This topic describes the configuration
you perform to enable the communication for applications that asynchronously
invoke services on a different server.
Before you begin
The task assumes that you have already installed
WebSphere® Process Server on the systems for which
you are configuring the communications but have not yet installed the applications
involved. You are using an administrative console that can examine and change
the configuration for both servers involved.
Why and when to perform this task
Before installing an application that requires the services of a
service component installed on another system, you must configure the systems
so they can communicate the requests. For service modules that use asynchronous
invocations, the process involves foreign buses and Service Integration Bus
(SIBus) mediations.
Note: For the purposes of this task,
the invoking service module resides on system A and the target resides on
system B.
For the purposes of this task,
Figure 1 contains the information to use in the configuration.
Figure 1. Invoking a service
on a different system
Note: For simplicity, only the servers involved in
this communication in each cell is shown and each server resides on a different
physical machine.
Steps for this task
- Collect information about each server involved in the communication. You will need the following information for both the originator and
target servers:
- Host IP address
- Cell
- Node
- Server
- Bus name
- Messaging engine
- Failed Event Queue name
- Install the applications.
- Create a foreign bus on each server pointing to the other server
and set the routing definition type to Direct, service integration
bus link.
See "Adding a foreign bus" in the WebSphere Application Server Network Deployment, version
6 information center for
more information.
From the example, the foreign bus on System A would
be SCA.SYSTEM.SRIKANTHCNode01Cell.Bus. The foreign bus
on System B would be SCA.SYSTEM.WBIDev-BGMNode01Cell.Bus.
- Set up an SIB mediation link on each server pointing to the messaging
engine on the other server.
See "Adding a service integration
bus link" in the WebSphere Application Server Network Deployment, version
6 information
center for more information.
From the example, the SIB mediation link
on System A would be:
SIB Link: TestCrossCell
Remote ME: SRIKANTHCNode01.server1-SCA.SYSTEM.SRIKANTHCNode01Cell.Bus
Bootstrap: 9.26.237.144:7277:BootstrapBasicMessaging
The
SIB mediation link on System B would be:
SIB Link: TestCrossCell
Remote ME: WPSNode.server1.SCA.SYSTEM.WBIDev-BGMNode01.Cell.Bus
Bootstrap: 9.26.237.118.7276:BootstrapBasicMessaging
Attention: The port number in the bootstrap is the SIB endpoint address
port. If you enabled security, you must use the secure SIB endpoint address
port.
- Synchronize the SIB mediation links by restarting the servers.
You should see messages similar to: [8/24/05 11:00:09:741
PDT] 00000086 SibMessage I [SCA.SYSTEM.WBIDev-BGMNode01Cell.Bus:WPSNode.server1-SCA.SYSTEM.WBIDev-BGMNode01Cell.Bus] CWSIP0382I: messaging engine 2D7333574B0CD70B responded to subscription request,
Publish Subscribe topology now consistent.
- Display the destinations for each service module.
- Modify the forwarding path of outgoing destinations of the invoking
service module that must be wired to targets on the other system.
The
destination to wire will have
importlink in the destination
name, for example on System A the destination would be
sca/SimpleBoCrsmA/importlink/test/sca/cros/simple/custinfo/CustomerInfo. Modify the path by prefixing the foreign bus name to the destination name.
From the example, the foreign bus name for the second system is
SCA.SYSTEM.SRIKANTHCNode01Cell.Bus.
The result is
SCA.SYSTEM.SRIKANTHCNode01Cell.Bus:sca/SimpleBoCrsmA/importlink/
test/sca/cros/simple/custinfo/CustomerInfo
- Create two destinations on the target server and configure them
to point back to the invoking service module on the other server.
From
the example, on System B you would create:
sca/SimpleBOCrsmA/import/test/sca/cros/simple/custinfo/CustomerInfo
sca/SimpleBOCrsmA/component/test/sca/cros/simple/cust/Customer
Then
set the forwarding paths to point to their counterparts on invoking server.
This would look like:
SCA.SYSTEM.WBIDev-BGMNode01Cell.Bus:
sca/SimpleBOCrsmA/import/test/sca/cros/simple/custinfo/CustomerInfo
SCA.SYSTEM.WBIDev-BGMNode01Cell.Bus:
sca/SimpleBOCrsmA/component/test/sca/cros/simple/cust/Customer
- Set the exception destination to the Failed Event queue for
both of the destinations you created.
From the example, the
value would be:WBI.FailedEventSRIKANTHCNode01.server1.
- Optional: Add sender roles to the foreign buses, if
you enabled security on the systems. Make sure to define the user
each application uses on both systems from the operating system command prompt. The command to add the role is:
wsadmin $AdminTask addUserToForeignBusRole -bus busName
-foreignBus foreignBusName -role roleName -user userName
Where:
- busName
- Is the name of the bus on the system you enter the command.
- foreignBusName
- Is the foreign bus to which you are adding the user.
- userName
- Is the userid to add to the foreign bus.
What to do next
Start the applications.