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 Oracle Tuxedo system. For more information about object references, see Creating CORBA Server Applications in the Oracle Tuxedo online documentation.
3. The object is instantiated. The object is instantiated by the TP Framework by invoking the Server::create_servant method, which exists in the Server object.
4. The Oracle Tuxedo domain invokes the activate_object operation on the object, which causes the record containing state to be read into memory.The Oracle 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 Oracle Tuxedo online documentation.
Note:
•
•
•
•
• 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 Oracle 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.
1. If no servant is currently available for the needed object, the Oracle Tuxedo system invokes the Server::create_servant method on the Server object.The 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 Oracle Tuxedo domain creates.The servant that the Oracle 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.
2. The Oracle Tuxedo domain passes control to the servant, and optionally invokes the servant’s activate_object method, if you have implemented it. Invoking the activate_object method gives life to the CORBA object, as follows:
a. You write the code for the activate_object method. The parameter to the activate_object method 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.Implementing the 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 Oracle Tuxedo online documentation.For more information about creating object implementations, see Creating CORBA Server Applications in the Oracle Tuxedo online documentation.
• 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 Oracle 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 Oracle Tuxedo Object Request Broker.For more information about generating client stubs and skeletons, see Creating CORBA Client Applications and Oracle Tuxedo ATMI C Function Reference in the Oracle Tuxedo online documentation.