Configuring servers to invoke services asynchronously

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 systemThe figure shows two systems A and B. System A is hosted on IP address 9.26.237.118 and System B is hosted at IP address 9.26.237.144. The node names are WPSNode on System A and SRIKANTHCNode01 on System B. The cell names are WBIDev-BGMNode01Cell on System A and SRIKANTHCNode01Cell on System B. Each system has 2 servers, Server1 and Server2. Server1 on both systems contains an application and module, on System A these are SimpleBOCrsmAApp and DiffModA, respectively; on System B these are SimpleBOCrsmBApp and DiffModB, respectively. The bus name is SCA.SYSTEM.WBIDEV-BGMNode01Cell.Bus on System A and SCA.SYSTEM.SRIKANTHCNode01Cell.Bus on System B. The messaging engine is WPSNode.server1-SCA.SYSTEM.WBIDEVBGMNode01Cell.Bus on System A and SRIKANTHCNode01Cell.server1.SCA.SYSTEM.SRIKANTHCNode01Cell.Bus on System B. The Failed Event queue is WBI.FailedEvent.WBSNode.server1 for System A and WBI.FailedEvent.SRIKANTHCNode01.server1 on System B.
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

  1. 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
  2. Install the applications.
  3. 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.

  4. 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.
  5. 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.

  6. Display the destinations for each service module.
  7. 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
  8. 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
    1. 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.

  9. 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.
Related tasks
Configuring servers to invoke services synchronously

Terms of use |

Last updated: Tue Feb 21 17:21:49 2006

(c) Copyright IBM Corporation 2005.
This information center is powered by Eclipse technology (http://www.eclipse.org)