BEA Logo BEA Tuxedo Release 8.0

  BEA Home  |  Events  |  Solutions  |  Partners  |  Products  |  Services  |  Download  |  Developer Center  |  WebSUPPORT

   http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary

 

   Tuxedo Documentation   |   Setting Up a BEA Tuxedo Application   |   Local Topics   |   Previous Topic   |   Next Topic   |   Contents

 

Configuring Outbound IIOP for Remote Joint Client/Servers

Support for outbound IIOP provides native clients and servers acting as native clients the ability to invoke on a remote object reference outside of the BEA Tuxedo domain. This means that calls can be invoked on remote clients that have registered for callbacks, and objects in remote servers can be accessed.

Administrators are the only users who interact directly with the outbound IIOP support components. Administrators are responsible for booting the ISLs with the correct startup parameters to enable outbound IIOP to objects not located in a connected client. Administrators may need to adjust the number of ISLs they boot and the various startup parameters to obtain the best configuration for their installation's specific workload characteristics.

Administrators have the option of booting the ISLs with the default parameters. However, the default BEA Tuxedo ISL startup parameters do not enable use of outbound IIOP.

Note: Outbound IIOP is not supported for transactions or security.

Functional Description

Outbound IIOP support is required to support client callbacks. In BEA WebLogic Enterprise versions 4.0 and 4.1, the ISL/ISH was an inbound half-gateway. Outbound IIOP support adds the outbound half-gateway to the ISL/ISH. (See Figure 12-2.)

There are three types of outbound IIOP connections available, depending on the version of GIOP supported by the native server and the remote joint client/server application:

Bi-directional and dual-paired connection outbound IIOP provides outbound IIOP to object references located in joint client/servers connected to an ISH. Asymmetric outbound IIOP provides outbound IIOP to object references not located in a joint client/server connected to an ISH, and also allows BEA Tuxedo CORBA clients to invoke on any object reference, not only object references located in clients currently connected to an ISH.

Each type of outbound IIOP is described in more detail in the following sections.

Joint Client/Server IIOP Connections Supported


 

Bidirectional Outbound IIOP

With bidirectional outbound IIOP, the following operations are executed (see Figure 12-3):

  1. A client creates an object reference and invokes on a BEA Tuxedo CORBA server. The client ORB identifies the connection as being bidirectional using the service context. The service context travels with the message to the BEA Tuxedo CORBA server.

  2. When unmarshaling the object reference, the BEA Tuxedo CORBA server compares the host/port in the service context with the host/port in the object reference. If they match, the ORB adds the ISH client information needed for routing to the ISH. This client information travels with the object reference whenever it is passed to other BEA Tuxedo CORBA servers.

  3. At some point in time, a BEA Tuxedo CORBA server or native client invokes on the object reference, and the routing code invokes on the appropriate ISH, given the client information.

  4. The ISH sends the request to the client over the same client connection.

  5. The client executes the method and sends the reply back to the ISH via the client connection.

  6. The ISH receives the reply and sends it to the BEA Tuxedo CORBA server.

    Bidirectional Connection


     

Asymmetric Outbound IIOP

With asymmetric outbound IIOP, the following operations are executed (see Figure 12-4):

  1. A server gets an object reference from some source. It could be a naming service, a string_to_object, or it could be passed in through a client, but not located in that client. Since the object reference is not located in a client connected to an ISH, the outgoing call cannot be made using the bidirectional method. The BEA Tuxedo CORBA server invokes on the object reference.

  2. On the first invoke, the routing code invokes a service in the ISL and passes in the host/port.

  3. The ISL selects an ISH to handle the outbound invoke and returns the ISH information to the BEA Tuxedo CORBA server.

  4. The BEA Tuxedo CORBA server invokes on the ISH.

  5. The ISH determines which outgoing connection to use to send the request to the client. If none is connected, the ISH creates a connection to the host/port.

  6. The client executes the method and sends the reply back to the ISH.

  7. The ISH receives the reply and sends it to the BEA Tuxedo CORBA server.

    Asymmetric Outbound IIOP


     

Dual-paired Connection Outbound IIOP

With dual-paired connection outbound IIOP, the following operations are executed (see Figure 12-5):

  1. A client creates an object reference and calls the Bootstrap function (register_callback_port) and passes the object reference.

  2. The ISH gets the host/port from the IOR and stores it with the client context.

  3. The client invokes on a BEA Tuxedo CORBA server and passes the object reference. From the register_callback_port call, the ISH creates a service context containing the host/port. The service context travels with the message to the BEA Tuxedo CORBA server.

  4. When unmarshaling the object reference, the BEA Tuxedo CORBA server compares the host/port in the service context with the host/port in the object reference. If they match, the ORB adds the ISH client information to the object reference. This client information travels with the object reference whenever it is passed to other BEA Tuxedo CORBA servers.

  5. At some point in time, a BEA Tuxedo CORBA server or native client invokes on the object reference. The routing code invokes on the appropriate ISH, passing the client information.

  6. The ISH creates a second connection to the client. It sends the request to the client over the second connection.

  7. The client executes the method and sends the reply back to the ISH via the first client connection.

  8. The ISH receives the reply and sends it to the BEA Tuxedo CORBA server. If the client disconnects from the ISH, the second connection is also disconnected.

    Dual-paired Connections Outbound IIOP


     

How the Routing Code Finds an ISL

The steps to finding an ISL are as follows:

  1. A service is advertised in each ISL.

  2. The routing code invokes on that service name.

    Note: Normal BEA Tuxedo routing is used to find an ISL.

  3. An idle ISL on the same machine is always chosen, if available. If not available, NETLOAD ensures that a local ISL is chosen most often.

    Note: Some invokes may be made to ISLs on nonlocal machines.

 

back to top previous page  

 

Copyright © 2001 BEA Systems, Inc. All rights reserved.
Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.