Before any discussion of CORBA programming can be meaningful, it is important to have a clear understanding of what a CORBA object is and the object terminology used throughout the BEA Tuxedo information set.
This topic includes the following sections:
There are a number of variations on 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 Component Object Model (COM) object is quite different from the notion of a CORBA object.
Most importantly, the notion of a CORBA object in this chapter 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.
A CORBA object is a virtual entity in the sense that it does not exist on its own, but rather is brought to life when, using the reference to that CORBA object, the client application requests an operation 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 an BEA Tuxedo system. For more information about object references, see Creating CORBA Server Applications in the BEA Tuxedo online documentation.
When the client or server application issues a request on an object via an object reference, the BEA Tuxedo 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 operation 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:
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 an BEA Tuxedo domain when the following sequence has occurred:
Server::create_servantmethod, which exists in the Server object.
activate_objectoperation 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 BEA Tuxedo system provides the mechanism for constructing an object and for making that object accessible to the application.
The BEA Tuxedo CORBA 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 operations that read from and write to durable storage. For more information about developing server applications, see Creating CORBA Server Applications in the BEA Tuxedo online documentation.
CORBA objects typically have the following components, shown in the figure that follows:
The sections that follow describe each of these object components in detail.
The object ID (OID) associates an object with its state, such as a database record, 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 BEA Tuxedo client/server application. The programmer is responsible for writing the code that assigns OIDs. Factories, and examples of creating them, are discussed in Creating CORBA Server Applications.|
The BEA Tuxedo system can determine how to instantiate the object by using the following information:
The object's interface, described in the application's OMG IDL file, identifies the set of data and operations that can be performed on an object. For example, the interface for a university teller object would identify:
One distinguishing characteristic of a CORBA object is the run-time separation of the interface definition from its data and operations. In a CORBA system, a CORBA object's interface definition may exist in a component called the Interface Repository. The data and operations are specified by the interface definition, but the data and operations exist in the server application process when the object is activated.
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 university application, a typical object might be a teller. The data of the teller could be:
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 operations.
The object's operations are the set of routines that can perform work using the object's data. For example, some of the operations that perform functions using teller object might include:
In a CORBA system, the body of code you write for an object's operations is sometimes called the object implementation, which is explained in the next section.
As explained in the preceding section, the data that makes up a CORBA object may exist in a record in a database. Alternatively, the data could be established for a CORBA object only when the object is active in memory. This section explains how to write operations for a CORBA object and how to make the operations a part of the object.
The operations you write for a given CORBA object are also known as the object's implementation. You can think of the implementation as the code that provides the behavior of the object. When you create an BEA Tuxedo CORBA client/server application, one of the steps you take is to compile the application's OMG IDL file. The OMG IDL file contains statements that describe the application's interfaces and the operations that can be performed on those interfaces.
If you are implementing your server application in C++, one of the several files optionally produced by the IDL compiler is a template for the implementation file. The template for the implementation file contains default constructors and method signatures for your application's objects. The implementation file is where you write the code that implements an object; that is, this file contains the business logic of the operations for a given interface.
The BEA Tuxedo system implements an interface as a CORBA object. The IDL compiler also produces other files, which get built into the BEA Tuxedo CORBA client and server application, that make sure that the implementation you write for a given object gets properly connected to the correct object data during run time.
This is where the notion of a servant comes in. A servant is an instance of the object class; that is, a servant is an instance of the method code you wrote for each operation in the implementation file. When the BEA Tuxedo CORBA client and server applications are running, and a client request arrives in the server application for an object that is not active -- that is, the object is not in memory -- the following events occur:
Server::create_servantmethod on the Server object.
Server::create_servant method is entirely user-written. The code that you write for the
Server::create_servant method instantiates the servant needed for the request. Your code can use the interface name, which is passed as a parameter to the
Server::create_servant method, to determine the type of servant that the BEA Tuxedo domain creates.
The servant that the BEA Tuxedo domain creates is a specific servant object instance (it is not a CORBA object), and this servant contains an executable version of the operations you wrote earlier that implement the CORBA object needed for the request.
activate_objectmethod, if you have implemented it. Invoking the
activate_objectmethod gives life to the CORBA object, as follows:
activate_objectmethod. The parameter to the
activate_objectmethod is the string value of the object ID for the object to be activated. You may use the object ID as a key to how to initialize the object.
activate_object method on an object is optional. For more information about when you want to implement this operation on an object, see Creating CORBA Server Applications in the BEA Tuxedo online documentation.
|Note:||A servant is not a CORBA object. In fact, the servant is represented as a language object. The server performs operations on an object via its servant.|
For more information about creating object implementations, see Creating CORBA Server Applications in the BEA Tuxedo online documentation.
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:
Creating CORBA Client Applications describes how dynamic invocation works. This 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 compiler generates is a source file called the client stub. The client stub maps OMG IDL operation definitions for an object type to the operations in the CORBA server application that the BEA Tuxedo 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 source file. The skeleton contains code used for operation 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 BEA Tuxedo Object Request Broker.
The following figure shows the client application, the client stub, the skeleton, and the CORBA object implementation:
When a client application sends a request, the request is implemented as an operation on the client stub. When the client stub receives the request, the client stub sends the request to the Object Request Broker (ORB), which then sends the request through the BEA Tuxedo 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.
For more information about generating client stubs and skeletons, see Creating CORBA Client Applications and BEA Tuxedo ATMI C Function Reference in the BEA Tuxedo online documentation.