To enable communication between Service Component Architecture
(SCA) modules in different cells, you have to configure a communication link
between the two cells. This topic describes the configuration you perform
on the consuming cell to enable the communication from modules that asynchronously
invoke SCA services on other cells.
Before you begin
The task assumes that:
- You are using an administrative console on a consuming cell.
- You have already installed the SCA modules involved, but you have not
yet started the consuming modules.
- There is a different administrator for the cell on which the providing
module runs.
Why and when to perform this task
Before starting an SCA module that requires
the services of an SCA module installed on another cell, you must configure
both cells so they can communicate the requests. For SCA modules that use
asynchronous invocations, the process involves foreign buses and Service Integration
Bus (SIBus) links.
Note: For the purposes of this task,
the consuming service module runs on cell A and the providing service module
runs on cell B.
Figure 1 contains the information to use in the configuration.
Figure 1. Invoking
a SCA module in a different cell
Steps for this task
- Create a server or cluster member and include
it as a member of the SCA system bus. The resulting messaging engine will
be used as the connection to the consuming cells.
- Obtain the information that identifies the cell
providing the service from the administrator of that cell. The
information to provide includes:
- Host IP address
- Port number
- Bus name
- Messaging engine
- Failed Event Queue name
- Give the information about your cell to the administrator of the
cell providing the service your module will invoke. The information
to provide includes:
- Host IP address
- Port number - find this by displaying the BOOTSTRAP_ADDRESS value
at Servers > Application servers > server_name >
Communications > + Ports
- Bus name - find this by clicking Service integration > Buses and
locate the full name of the SCA.SYSTEM bus.
- Messaging engine - find this by clicking on Service integration
> Buses > SCA_SystemBusName > Messaging engines and
locate the messaging engine in use by the service you are providing to the
consuming cells.
- Failed Event Queue name - find this by displaying Service integration
> Buses > SCA_SystemBusName > moduleDest and
examining the Exception destination attribute. If this
attribute has selected:
- Specify, use the value in the text field
- System, click on Service integration
> Buses > SCA_SystemBusName > Destinations and
use the value of the system exception destination.
- Using the information from step 2,
create a foreign bus to represent the bus of this provider cell and set the
routing definition type to Direct, service integration bus link.
Repeat this step for each provider cell if you require multiple provider cells.
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 Cell
A would be SCA.SYSTEM.SRIKANTHCNode01Cell.Bus. The foreign
bus on Cell B would be SCA.SYSTEM.WBIDev-BGMNode01Cell.Bus.
- On the messaging engine created in step 1 set
up a SIB link using the information from step 2.
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 Cell A
would be:
SIB Link: TestCrossCell
Remote ME: SRIKANTHCNode01.server1-SCA.SYSTEM.SRIKANTHCNode01Cell.Bus
Bootstrap: 9.26.237.144:7277: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.
- Display the destinations for each SCA module.
- Modify the forwarding path of outgoing destinations of the consuming
service module that must be wired to targets on the providing system.
The destination to wire will have
importlink in
the destination name, for example on Cell 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 cell is
SCA.SYSTEM.SRIKANTHCNode01Cell.Bus.
The result is
SCA.SYSTEM.SRIKANTHCNode01Cell.Bus:sca/SimpleBoCrsmA/importlink/
test/sca/cros/simple/custinfo/CustomerInfo
- 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.
- Verify the connection. Coordinate with the consuming administrator
to recycle the servers involved with the connection 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.
What to do next
Start the applications.
Last updated: Wed 01 Nov 2006 07:47:12
(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)