Using Service Component Architecture services asynchronously across cells

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:

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
Figure showing the environment of two systems involved in the cross-cell invocation.

Steps for this task

  1. 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.
  2. 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
  3. 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.
  4. 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.

  5. 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.
  6. Display the destinations for each SCA module.
  7. 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
  8. 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.
  9. 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.
Related tasks
Providing synchronous access to Service Component Architecture services from outside the cell
Calling Service Component Architecture services in another cell synchronously
Providing Service Component Architecture services asynchronously across cells

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)