Table 2‑1 outlines the development process for C++ joint client/server applications.
Because the callback object in a joint client/server application is not transactional and has no object management capabilities, you do not need to create an Implementation Configuration File (filename.icf) for it. However, you still need to create an ICF file for the Oracle Tuxedo objects in your Oracle Tuxedo application. For information about writing an ICF file, see Creating CORBA Server Applications.Figure 2‑1 illustrates how the Chat Room sample application works.Figure 2‑1 How the Chat Room Sample Application Works
2.
4.
5. The Chat Room sample application temporarily passes control over to the ORB to allow the Listener object in the joint client/server application to receive post invocations from the Moderator object.The source files for the Chat Room sample application are located in the TUXDIR\samples\corba\chatroom directory in the Oracle Tuxedo software directory. See “Building and Running the Chat Room Sample Application” on page -23 for more information.
Listing 2‑1 OMG IDL for the Listener InterfaceListing 2‑2 shows the chatroom.idl that defines the Moderator and ModeratorFactory interfaces for the Chat Room sample application. The #include is used to resolve references to interfaces in another OMG IDL file. In the Chat Room sample application, the signon method requires a Listener object as a parameter and its IDL file must #include the OMG IDL file that defines the Listener interface.For example, in the Chat Room sample application, the joint client/server application uses the skeleton and client stub for the Listener object (that is, the callback object) to implement the object. The joint client/server application also uses the client stubs for the Moderator and ModeratorFactory interfaces to invoke operations on the objects. The Oracle Tuxedo server application uses the skeletons for the Moderator and ModeratorFactory objects to implement the objects and the client stub for the Listener object to invoke operations on the object.During the development process, use the idl command with the -P and -i options to compile the OMG IDL file that defines the callback object (for example, the chatclient.idl file in the Chat Room sample application). The options work as follows:
• The -P option creates a skeleton class that inherits directly from the PortableServer::ServantBase class. Inheriting from PortableServer::ServantBase means the joint client/server application must explicitly create a servant for the callback object and initialize the servant’s state. The servant for the callback object cannot use the activate_object and deactivate_object methods as they are members of the PortableServer::ServantBase class.
• The -i option results in the generation of an implementation template file. This file is a template for the code that implements the interfaces defined in the OMG IDL for the Listener object.You then need to compile the OMG IDL file that defines the interfaces in the Oracle Tuxedo server application (for example, the chatroom.idl file in the Chat Room sample application). Use the idl command with only the -i option to compile that OMG IDL file.Table 2‑3 lists the files that are created by the idl command.
Note: In the Chat Room sample application, the generated template files for the ChatClient.idl and ChatRoom.idl files have been renamed to reflect the objects (Listener and Moderator) they implement. In addition, the template file for the Moderator object includes the implementation for the ModeratorFactory object.
Table 2‑3 Files Produced by the idl Command Contains signatures for the methods that implement the operations of the Listener, Moderator, and ModeratorFactory interfaces specified in the OMG IDL file. The Listener_i.h file contains implementation files that inherit from the POA_ChatClient::Listener class. Contains skeletons for each interface specified in the OMG IDL file. During run time, the skeleton maps client requests to the appropriate operation in the server application. The Listener_s.h file contains POA_skeleton class definitions (for example, POA_ChatClient::Listener).
• Optionally, for Oracle Tuxedo objects, the com.beasys.Tobj_Servant.activate_object and com.beasys.Tobj_Servant.deactivate_object methodsWithin the activate_object and deactivate_object methods, you write code that performs any particular steps related to activating or deactivating an object.Listing 2‑3 includes the implemention file for the Listener object, and Listing 2‑4 includes the implementation file for the Moderator and ModeratorFactory objects.
Note: Listing 2‑3 Implementation File for the Listener Object
4. Uses a factory to get an object reference for the desired Oracle Tuxedo object (that is, the Moderator object).The client development steps are illustrated in Listing 2‑5, which includes code from the Chat Room sample application. In the Chat Room sample application, the client portion of the joint client/server application uses a factory to get an object reference to the Moderator object, and then invokes the signon, send, and signoff methods on the Moderator object.
• Transient/System ID (_transient)
• Persistent/System ID (_persistent/systemid)
• Persistent/User ID (_persistent/userid)For a complete description of the object policies for callback objects, see “Object Policies for Callback Objects” on page -5.For a complete description of the Callbacks Wrapper object and its methods, see the CORBA Programming Reference.Listing 2‑6 shows how a Callbacks Wrapper object is used in the Chat Room sample application.Once you have an object reference to a callback object, you can pass the callback object reference as a parameter to a method of an Oracle Tuxedo object. In the Chat Room sample application, the Moderator object uses an object reference to the Listener object as a parameter to the signon method. Listing 2‑7 illustrates this step.Listing 2‑7 Invoking the signon Method-ORBport nnnwhere nnn is the number of the port to be used by the ORB when creating invocations and listening for invocations on the callback object in the joint client/server application.The port number is part of the input to the argv argument of the CORBA::orb_init member function. When the argv argument is passed, the ORB reads that information, establishing the port for any object references created in that process. You can also use the bootstrap object’s register_callback_port operation for the same purpose.For a joint client/server application to communicate with an Oracle Tuxedo object in the same domain, a configuration file for the server application is needed. The configuration file should be written as part of the development of the server application. The binary version of the configuration file, the TUXCONFIG file, must exist before the joint client/server application is started. The TUXCONFIG file is created using the tmloadcf command. For information about creating a TUXCONFIG file, see Getting Started with Oracle Tuxedo CORBA Applications and Setting Up an Oracle Tuxedo Application.If you are using a joint client/server application that uses IIOP version 1.0 or 1.1, the administrator needs to boot the IIOP Server Listener (ISL) with startup parameters that enable outbound IIOP to invoke callback objects not connected to an IIOP Server Handler (ISH). The -O option of the ISL command enables outbound IIOP. Additional parameters allow administrators to obtain the optimum configuration for their Oracle Tuxedo application. For more information about the ISL command, see the Oracle Tuxedo Command Reference.Use the buildobjclient command with the -P option to construct a joint client/server application executable. To build an executable program, the command combines the client stub for the Oracle Tuxedo object, the client stub for the callback object, the skeleton for the callback object, and the implementation for the callback object with the appropriate POA libraries.
Note: Before you can use the -P option of the buildobjclient command, you must have used the -P option of the idl command when you created the skeleton and client stub for the callback object.
Note: Since the root POA does not allow use of bidirectional IIOP, you need to create a child POA. The child POA can use the defaults for LifespanPolicy (TRANSIENT) and IDAssignmentPolicy (SYSTEM). You must specify a BiDirPolicy policy of BOTH.IIOP version 1.2 supports reuse of the TCP/IP connection for both incoming and outgoing requests. Allowing reuse of a TCP/IP connection is the choice of the ORB. To allow reuse, you create an ORB policy object that allows reuse of a TCP/IP connection, and you use that policy object in the list of policies when initializing an ORB. The policy object is created using the CORBA::ORB::create_policy operation. For more information about the CORBA::ORB::create_policy operation, see the CORBA Programming Reference.Listing 2‑8 shows the portion of the Chat Room sample application that uses the POA to create the Listener object.Listing 2‑8 Using the POA to Create the Listener Object
2. Listing 2‑9 shows code that performs these steps.
1. Creates a child POA with a LifespanPolicy set to PERSISTENT and IDAssignmentPolicy set to the default.Listing 2‑10 shows code that performs these steps.// Find the root POA
CORBA::Object_var oref=
orb_ptr->resolve_initial_references("RootPOA")
PortableServer::POA_var root_poa =
PortableServer::POA::_narrow(oref);
// Create and activate a Persistent/System ID POA
CORBA::PolicyList policies(1);
policies.length(1);
policies[0] = root_poa->create_lifespan_policy(
PortableServer::PERSISTENT);
//IDAssignmentPolicy is the default so you do not need to specify it
PortableServer::POA_var poa_ref = root_poa->create_POA(
"poa_ref", root_poa->the_POAManager(), policies);
root_poa->the_POAManager()->activate();
// Create Listener_i servant and activate the Listener object
Listener_i* my_Listener_i = new Listener_i();
PortableServer::ObjectId_var temp_OId =
poa_ref->activate_object ( my_Listener_i );
// Create object reference for Listener object with returned
// system object Id
oref = poa_ref->create_reference_with_id(
temp_OId, ChatClient::_tc_Listener->id() );
ChatClient::Listener_var Listener_oref =
ChatClient::Listener::_narrow(oref);
// Make the call passing the reference to the Listener object
v_moderator_ref->signon( handle, Listener_oref );If a method in the server portion of a joint client/server application invokes ORB::shutdown(), all server activity stops and control is returned to the statement after ORB::run() is invoked in the server portion of the joint client/server application. Only under this condition does control return to the client functionality of the joint client/server application.
4. Execute the ChatSetup command./usr/local/TUXDIR/samples/corba/chatroomUse the files listed in Table 2‑4 to build and run the Chat Room sample application.
The OMG IDL code that declares the Listener interface. The UNIX operating system makefile for the Chat Room sample application. The Windows operating system makefile for the Chat Room sample application. On UNIX operating system platforms, you also need to change the permission of ChatRoom.ksh to give execute permission to the file, as follows:Before building and running the Chat Room sample application, you need to ensure that the TUXDIR environment variable is set on your system. In most cases, this environment variable is set as part of the installation procedure. The TUXDIR environment variable defines the directory path where you installed the Oracle Tuxedo software. For example:
5. Check the setting for TUXDIR.
1. On the Environment page in the System Properties window, click the TUXDIR environment variable.ksh prompt>export TUXDIR=directorypathThe ChatSetup command automates the following steps:Before running the ChatSetup command, you need to check the following:
• On Windows, make sure nmake is in the path of your machine.
• To build and run the sample application, enter the ChatSetup command, as follows:prompt>cd workdirectoryksh prompt> cd workdirectory
•
• The following three TMFFNAME server processes are started:
• The TMFFNAME server process started with the -N and -M options is the Master NameManager service. The NameManager service maintains a mapping of the application-supplied names to object references. This server process is used only by the Oracle Tuxedo system.
•
•
•
• prompt> ChatClient chatroom_name -ORBport nnnwhere chatroom_name is the name of a chat room to which you want to connect. You can enter any value. You will be prompted for a handle to identify yourself. You can enter any value. If the handle you chose is in use, you will be prompted for another handle.