Using CORBA Server-to-Server Communication

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Understanding CORBA Server-to-Server Communication

This topic includes the following sections:

Notes: The BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.
Note: Technical support for third party CORBA Java ORBs should be provided by their respective vendors. BEA Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.


Overview of CORBA Server-to-Server Communication

CORBA server-to-server communication allows BEA Tuxedo applications to invoke CORBA objects and handle invocations from those CORBA objects (referred to as callback objects). The CORBA objects can be either inside or outside of a BEA Tuxedo domain.

The BEA Tuxedo product offers an implementation of the Internet Inter-ORB Protocol (IIOP) version 1.2, which provides inbound and outbound communication with the CORBA objects. Server-to-server communication provides more efficient use of network resources and provides integration with third-party Object Request Brokers (ORBs). In addition, server-to-server communication is supported with CORBA objects that are implemented using IIOP versions 1.0 and 1.1.


Joint Client/Server Applications

Server-to-server communication allows client applications to act as server applications for requests from other client applications. In addition, server-to-server communication allows BEA Tuxedo server applications to invoke objects on other ORBs.

Note: In earlier versions of the BEA Tuxedo and WebLogic Enterprise products, client applications invoked operations defined in Object Management Group (OMG) Interface Definition Language (IDL) on a CORBA object. The server applications implemented the operations of the CORBA object. The CORBA objects in the server application used BEA Tuxedo TP Framework and environmental objects to implement state management, security, and transactions. These CORBA objects are referred to as BEA Tuxedo objects. Server applications could act as client applications for other server applications; however, client applications could not act as server applications for other client applications.

The server-to-server communication functionality is available through a callback object. A callback object has two purposes:

Callback objects do not use the TP Framework and are not subject to BEA Tuxedo administration. You should use them only when transactional behavior, security, reliability, and scalability are not important.

Callback objects are implemented in joint client/server applications. A joint client/server application consists of the following:

Note: Release 8.0 of the CORBA environment in the BEA Tuxedo CORBA product continues to include the BEA client environmental objects provided in earlier releases of BEA WebLogic Enterprise for use with the BEA Tuxedo 8.0 CORBA clients. BEA Tuxedo 8.0 clients should use these environmental objects to resolve initial references to bootstrapping, security, and transaction objects. In this release, support has been added for using the OMG Interoperable Naming Service (INS) to resolve initial references to bootstrapping, security, and transaction objects. For information on INS, see Chapter 4, "CORBA Bootstrapping Programming Reference" in the CORBA Programming Reference.

Figure 1-1 shows the structure of a joint client/server application.

Figure 1-1 Structure of a Joint Client/Server Application

Structure of a Joint Client/Server Application

C++ joint client/server applications are supported.

Joint client/server applications use IIOP to communicate with the BEA Tuxedo server applications. IIOP can work in the following ways, depending on the version of the IIOP protocol you are using:

Note: Depending on the type of remote object and the desired outbound IIOP configuration, you may have to perform additional programming tasks.

Table 1-1 lists the requirements for each type of object and outbound IIOP configuration.

Table 1-1 Programming Requirements for Using Outbound IIOP 
Types of Objects
Asymmetric Requirements
Paired-connection Requirements
Bidirectional Requirements
Remote joint client/servers
Set ISL CLOPT -O option.
Use the Tobj_Bootstrap::register_callback_port method to register the callback port.
Use the CORBA::ORB::create_policy method to set BiDirPolicy on the POA.
Foreign (non
BEA-Tuxedo) ORBs
Set ISL CLOPT -O option.
Not applicable.
If the foreign ORB supports the POA and BiDirPolicy, use the CORBA::ORB::create_policy method to set BiDirPolicy on the POA.
Remote clients
Remote clients are not servers, so outbound IIOP is not possible.
Native joint client/servers
Outbound IIOP is not used.
Native clients
Outbound IIOP is not used.

For a more detailed description of bidirectional, dual-paired connnection, and asymmetric IIOP, see the CORBA Programming Reference.


Object Policies for Callback Objects

Callback objects are assigned policies that control how long an object reference is valid and how an object ID is assigned to the object. Object policies are defined when the reference to the callback object is created. In addition, they can be defined in the Callbacks Wrapper object, which simplifies the development of joint client/server applications.

The following object policies are supported for callback objects:

When creating a callback object with an object policy of transient, the object reference is valid only until the joint client/server application is terminated or until the stop_all_objects method is called.

When creating a callback object with an object policy of persistent, the object reference is valid even after the termination of the joint client/server application. If the joint client/server application terminates, restarts, and activates a servant for the same object ID, the servant accepts requests made on that object reference.

Note: If you are creating a native joint client/server application (that is, a joint client/server application that is located in the same BEA Tuxedo domain as the server applications that invoke it), you cannot use the Persistent/System ID or Persistent/User ID object policies.

  Back to Top       Previous  Next