Understanding CORBA Objects

 

This section provides information on what a CORBA object is and the object terminology used throughout the eLink Adapter for CORBA information set.

Topics covered in this section include:

• Definition of a CORBA Object

• How a CORBA Object Comes Into Being

• Components of a CORBA Object

• How Object Invocation Works

• Understanding the CORBA Name Service

There are a number of variations of the definition of an object, depending on what architecture or programming language is involved. For example, the concept of a C++ object is significantly different from the concept of a CORBA object. Also, the notion of a COM object is quite different from the notion of a CORBA object.

The definition of a CORBA object is consistent with the definition presented by the Object Management Group (OMG). The OMG has a number of specifications and other documents that go into complete details on objects. For additional information, refer to the OMG web site located at HTTP://www.omg.org.

 

---

Definition of a CORBA Object

A CORBA object is a virtual entity that does not exist on its own until a client application refers to that object and requests a method on that object. The reference to the CORBA object is called an object reference. The object reference is the only means by which a CORBA object can be addressed and manipulated in a WLE system.

For more information about object references, see Creating CORBA C++ Server Applications or Creating CORBA Java Server Applications in the WebLogic Enterprise online documentation.

When the client or server application issues a request on an object via an object reference, the WLE server application instantiates the object specified by the object reference if the object is not already active in memory. (Note that a request always maps to a specific method invocation on an object.)

Instantiating an object typically involves the server application initializing the object's state, which may include having the object's state read from durable storage, such as a database.

The object contains all the data necessary to do the following:

• Execute the object's methods

• Store the object's state in durable storage when the object is no longer needed

 

---

How a CORBA Object Comes Into Being

The data that makes up a CORBA object may have its origin as a record in a database. The record in the database is the persistent or durable state of the object.

This record becomes accessible via a CORBA object in a WLE domain when the following sequence has occurred:

1. The server application's factory creates a reference for the object. The object reference includes information about how to locate the record in the database.

2. Using the object reference created by the factory, the client application issues a request on the object.

3. The object is instantiated. If the server application is implemented in C++, the object is instantiated by the TP Framework by invoking the Server::create_servant method, which exists in the Server object.

   If the server application is implemented in Java, the object is instantiated dynamically by the WLE system. (The create_servant method is not available to Server objects written in Java.)

4. The WLE domain invokes the activate_object method on the object, which causes the record containing state to be read into memory.

Whereas a language object exists only within the boundaries of the execution of the application, a CORBA object may exist across processes and machine systems. The WLE system provides the mechanism for constructing an object and for making that object accessible to the application.

The WLE server application programmer is responsible for writing the code that initializes an object's state and the code that handles that object's state after the object is no longer active in the application. If the object has data in durable storage, this code includes the methods that read from and write to durable storage.

 

---

Components of a CORBA Object

CORBA objects typically have the following components, shown in the figure below:

• An ID, also known as an object ID, or OID

• An interface, which specifies the CORBA object's data and methods
  
  

The sections that follow describe each of these object components in detail.

The Object ID

The object ID (OID) associates an object, such as a database record,with its state and identifies the instance of the object. When the factory creates an object reference, the factory assigns an OID that may be based on parameters that are passed to the factory in the request for the object reference.

Note: The server application programmer must create the factories used in the WLE client/server application.The programmer is responsible for writing the code that assigns OIDs.

A WLE system can determine how to instantiate the object by using the following information:

• The OID

• Addressing data in the object reference

• The group ID in the object reference

The Object Interface

The object's interface, described in the application's OMG Interface Definition Language (IDL) file, identifies the set of data and methods that can be performed on an object. For example, the interface for a university teller object would identify:

• The data types associated with the object, such as a teller ID, cash in the teller's drawer; and the data managed by the object, such as an account

• The methods that can be performed on that object, such as obtaining an account's current balance, debiting an account, or crediting an account

One distinguishing characteristic of a CORBA object is the run-time separation of the interface definition from its data and methods. In a CORBA system, a CORBA object's interface definition may exist in a component called the Interface Repository. The data and methods are specified by the interface definition, but the data and methods exist in the server application process when the object is activated.

The Object's Data

The object's data includes all of the information that is specific to an object class or an object instance. For example, within the context of a bank application, a typical object might be a teller. The data of the teller could be:

• ID

• The amount of cash in the teller's drawer

• The number of transactions the teller has processed during a given interval, such as a day or month

You can encapsulate the object's data in an efficient way, such as by combining the object's data in a structure to which you can get access by means of an attribute. Attributes are a conventional way to differentiate the object's data from its methods.

The Object's Methods

The object's methods are the set of routines that can perform work using the object's data. For example, some of the methods that perform functions using teller object might include:

• get_balance()

• credit()

• debit()

In a CORBA system, the body of code you write for an object's methods is sometimes called the object implementation. You can think of the implementation as the code that defines the behavior of the object.

 

---

How Object Invocation Works

Since CORBA objects are meant to function in a distributed environment, OMG has defined an architecture for how object invocation works. A CORBA object can be invoked in one of two ways:

• By means of generated client stubs and skeletons - sometimes referred to as stub-style invocation

• By means of the dynamic invocation interface - referred to as dynamic invocation

For the purposes of this document, the following section describes stub-style invocation, which is simpler to use than dynamic invocation.

When you compile your application's OMG IDL file, one file that the complier generates is a source file called the client stub. The client stub maps OMG IDL method definitions for an object type to the methods in the server application that the system invokes to satisfy a request. The client stub contains code generated during the client application build process that is used in sending the request to the server application. Programmers should never modify the client stub code.

Another file produced by the IDL compiler is the skeleton, which is also a C++ or Java source file. The skeleton contains code used for method invocations on each interface specified in the OMG IDL file. The skeleton is a map that points to the appropriate code in the CORBA object implementation that can satisfy the client request. The skeleton is connected to both the object implementation and the WLE Object Request Broker (ORB).

When a client application sends a request, the request is implemented as an method on the client stub. When the client stub receives the request, the client stub sends the request to the ORB, which then sends the request through the WLE system to the skeleton. The ORB interoperates with the TP Framework and the Portable Object Adapter (POA) to locate the correct skeleton and object implementation.

 

---

Understanding the CORBA Name Service

The WebLogic Enterprise Name Service (referred to throughout this document as the CORBA Name Service) allows WebLogic Enterprise CORBA server applications to advertise object references using logical names. WebLogic Enterprise CORBA client applications can then locate an object by asking the CORBA Name Service to look up the name.

The CORBA Name Service provides:

• An implementation of the Object Management Group (OMG) Interoperable Name service (INS) specification.

• Application programming interfaces (APIs) for mapping object references into a hierarchical naming structure (referred to as a namespace).

• Commands for displaying bindings and for binding and unbinding naming context objects and application objects into the namespace.

The CORBA Name Service is a layered product. The CORBA Name Service is installed as part of the WebLogic Entrerprise product. For a complete description of the supported platforms and the installation procedure, see the BEA WebLogic Enterprise Installation Guide.

When using the CORBA Name Service:

1. WebLogic Enterprise CORBA server applications bind a name to one of its application objects or a naming context object within a namespace.

2. WebLogic Enterprise CORBA client applications can then use the namespace to resolve a name and obtain an object reference to the application object or the naming context object.