Providing 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 providing 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. Define the IP addresses that you will expose to other cells to use to connect to this cell. Choose one of these methods:
    • When a stand-alone profile hosts the service, use the IP address of the server hardware.
    • When you need isolation between the cells, use a virtual IP address.
      Tip: Using virtual IP addresses will improve the availability of the service when maintenance requires replaceing or upgrading the hardware.
    • When you require availability to the service, use multiple IP addresses, for example 9.26.237.144 and 9.26.427.123.
      Note: Defining at least two hosts keeps the service available even if one of the hosts fails for some reason.
  2. 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.
  3. Give the information that identifies the providing cell to the administrator of the cell that runs the module consuming the service. This information 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.
    Notes:
    • SCA_SystemBusName has the format SCA.SYSTEM.cellname.Bus.
    • moduleDest has the format of sca/moduleName
  4. Get the information that identifies the consuming cell from the administrator of that cell. This information includes:
    • Host IP address
    • Port number
    • Bus name
    • Messaging engine
    • Failed Event Queue name
  5. Create a foreign bus 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.
  6. Optional: For each destination that requires a response to be sent to the invoking system, create a destination on the providing server and configure it to point back to the consuming SCA module in the other cell. This involves creating destinations, setting up forward routing paths, and setting exception destinations.
    Note: If the invoking system does not require a response, skip this step.
    1. Create destination.
      From the example on Cell B, based on the information from the consuming module in Cell A, you would create additional destinations on the bus in cell A:
      sca/SimpleBOCrsmA/import/test/sca/cros/simple/custinfo/CustomerInfo
      sca/SimpleBOCrsmA/component/test/sca/cros/simple/cust/Customer
    2. Set the forwarding paths to point to their counterparts on consuming cell.
      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
    3. 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.

  7. On the messaging engine created in step 2 set up an SIB link using the information from step 4.

    See Adding a service integration bus link in the WebSphere Application Server Network Deployment, version 6 information center for more information.

    For example, on Cell B:
    SIB Link: TestCrossCell
    Remote ME: WPSNode.server1.SCA.SYSTEM.WBIDev-BGMNode01.Cell.Bus
    Bootstrap: 9.26.237.118:7276:BootstrapBasicMessaging
    Restriction: When providing a service that sends a response to the invoking system, there can be only one invoking system for each link.
    Important: 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.
  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.
  10. Repeat steps 4 through 9 for each consuming cell.

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
Using 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)