Table of Contents Previous Next PDF

Understanding CORBA Server-to-Server Communication

Understanding CORBA Server-to-Server Communication
This topic includes the following sections:
Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle 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 Oracle 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 an Oracle Tuxedo domain.
The Oracle 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 Oracle Tuxedo server applications to invoke objects on other ORBs.
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 Oracle 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:
Figure 1‑1 shows the structure of a joint client/server application.
Figure 1‑1 Structure of a Joint Client/Server Application
C++ joint client/server applications are supported.
Joint client/server applications use IIOP to communicate with the Oracle Tuxedo server applications. IIOP can work in the following ways, depending on the version of the IIOP protocol you are using:
Joint client/server applications are always connected to the same IIOP Server Handler (ISH) in the Oracle Tuxedo domain. That ISH reuses the same connection to send requests to and receive requests from the joint client/server application.
Joint client/server applications use the register_callback_port method of the Bootstrap object to register the listening port of the joint client/server application in the ISH. Invocations from server applications on the callback object in the joint client/server application are routed through the ISH connected to the joint client/server application. This ISH uses a second outbound connection to send requests to and receive replies from the connected joint client/server application. The outbound connection is paired with the incoming connection. This differs from bidirectional IIOP, which uses only one connection.
Joint client/server applications can invoke on any callback object, and are not restricted to invoking callback objects implemented in joint client/server applications connected to an ISH. Asymmetric IIOP forces the ORB infrastructure to search for an available ISH to handle the invocation.
Table 1‑1 lists the requirements for each type of object and outbound IIOP configuration.
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.
Set ISL CLOPT -O option.
If the foreign ORB supports the POA and BiDirPolicy, use the CORBA::ORB::create_policy method to set BiDirPolicy on the POA.
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.

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.