Understanding
CORBA Server-to-Server Communication

 

This topic includes the following sections:

• Overview of CORBA Server-to-Server Communication

• Joint Client/Server Applications

• Object Policies for Callback Objects

 

---

Overview of CORBA Server-to-Server Communication

CORBA Server-to-server communication allows BEA WebLogic Enterprise 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 WebLogic Enterprise domain.

The BEA WebLogic Enterprise 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

In previous versions of the BEA WebLogic Enterprise product, 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 WebLogic Enterprise TP Framework and environmental objects to implement state management, security, and transactions. These CORBA objects as referred to as BEA WebLogic Enterprise 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.

Server-to-server communication allows client applications to now act as server applications for requests from other client applications. In addition, server-to-server communication allows BEA WebLogic Enterprise 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:

• It invokes operations on either BEA WebLogic Enterprise or CORBA objects.

• It implements the operations of a CORBA object.

Callback objects do not use the TP Framework and are not subject to BEA WebLogic Enterprise administration, they should be used 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:

• A portion that performs BEA WebLogic Enterprise client application functions, such as initializing the ORB, using the BEA WebLogic Enterprise environmental objects to establish connections, resolving initial references to the FactoryFinder object, and using factories to create BEA WebLogic Enterprise objects

• A portion that creates a servant for a callback object and activates the callback object using an object ID

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

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

C++ and Java joint client/server applications are supported.

Use of callback objects in Java applets is limited due to Java applet security mechanisms. Any Java applet run-time environment that allows a Java applet to create and listen on sockets (via the proprietary environment or protocol of the Java applet) can act as a joint client/server application. However, if the Java applet run-time environment restricts socket communication, the Java applet cannot act as a joint client/server application.

Note: The ActiveX client software that is included in the BEA WebLogic Enterprise V4.2 kit does not support callback objects, and, therefore cannot be used to develop joint client/server applications.

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

• Bidirectional

  Joint client/server applications are always connected to the same IIOP Server Handler (ISH) in the BEA WebLogic Enterprise domain. That ISH reuses the same connection to send requests to and receive requests from the joint client/server application.

• Dual-paired connection

  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.

• Asymmetric

  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.

  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-WLE) 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 C++ Programming Reference or the Java 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:

• Transient/System ID-the object reference for this type of callback object is valid only for the life of the joint client/server application. The object ID is assigned by the BEA WebLogic Enterprise system. This type of object is used for invocations that a joint client/server application wants to receive only until it terminates.

• Persistent/System ID-the object reference for this type of callback object is valid across multiple invocations in a joint client/server application. The object ID is assigned by the BEA WebLogic Enterprise system. This type of object is useful in joint client/server applications that stop and restart over a period of time. When the Joint client/server application is up, it can receive requests on a particular callback object with that object reference. Typically, the joint client/server application creates the object reference once, saves it in its own permanent storage area, and reactivates the servant for the object every time the joint client/server application comes up.

• Persistent/User ID-this object policy is the same as Persistent/System ID, except that the object ID is assigned by the joint client/server application.

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 WebLogic Enterprise domain as the server applications that invoke it), you cannot use the Persistent/System ID or Persistent/User ID object policies.