This topic includes the following sections:
Note: | The BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only. |
Note: | Technical support for third party CORBA Java ORBs should be provided by their respective vendors. BEA Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs. |
BEA Tuxedo offers a robust CORBA programming environment that simplifies the development and management of distributed objects. The following topics describe the features of the programming environment:
The BEA Tuxedo CORBA programming environment supplies Interface Definition Language (IDL) compilers to facilitate the development of CORBA objects:
For a description of how to use the IDL compiler, see Developing BEA Tuxedo CORBA Applications. For a description of the idl
command, see the BEA Tuxedo Command Reference in the BEA Tuxedo online documentation.
Table 2-1 lists the commands that the BEA Tuxedo CORBA programming environment provides for developing CORBA applications and managing the Interface Repository.
For a description of how to use the development commands to develop client and server applications, see Developing BEA Tuxedo CORBA Applications.
For a description of the development commands, see the BEA Tuxedo Command Reference in the BEA Tuxedo online documentation.
The BEA Tuxedo CORBA programming environment provides a complete set of tools for administering your CORBA applications. You can manage BEA Tuxedo CORBA applications through commands, through a graphical user interface, or by including administration utilities in a script.
You can use the commands listed in Table 2-2 to perform administration tasks for your CORBA application.
The Administration Console is a Java-based applet that you can download into your Internet browser and use to manage your BEA Tuxedo CORBA applications remotely. The Administration Console allows you to perform administration tasks, such as monitoring system events, managing system resources, creating and configuring administration objects, and viewing system statistics. Figure 2-1 shows the main window of the Administration Console.
In addition, a set of utilities called the AdminAPI is provided for directly accessing and manipulating system settings in the Management Information Bases (MIBs) for the BEA Tuxedo product. The advantage of the AdminAPI is that it can be used to automate administrative tasks, such as monitoring log files and dynamically reconfiguring an application, thus eliminating the need for manual intervention.
For information about the Administration commands, see File Formats, Data Descriptions, MIBs, and System Processes Reference in the BEA Tuxedo online documentation.
For a description of the Administration Console and how it works, see the online help that is integrated into the Administration Console graphical user interface (GUI).
For information about the AdminAPI, see Setting Up a BEA Tuxedo Application in the BEA Tuxedo online documentation.
The BEA Tuxedo product includes a set of environmental objects that provide object services to CORBA client applications in a BEA Tuxedo domain. You access the environmental objects through a bootstrapping process that accesses the services in a particular BEA Tuxedo domain.
BEA Tuxedo CORBA provides the following services:
The Object Life Cycle service is provided through the FactoryFinder environmental object. The FactoryFinder object is a CORBA object that can be used to locate a factory, which in turn can create object references for CORBA objects. Factories and FactoryFinder objects are implementations of the CORBA Services Life Cycle Service. BEA Tuxedo CORBA applications use the Object Life Cycle service to find object references.
For information about using the Object Life Cycle Service, see How BEA Tuxedo CORBA Client and Server Applications Interact on page 2-13.
The Security service is accessed through either the SecurityCurrent environmental object or the PrincipalAuthenticator object. The SecurityCurrent and PrincipalAuthenticator objects are used to authenticate a client application into a BEA Tuxedo domain with the proper security. The BEA Tuxedo software provides an implementation of the CORBA Services Security Service.
For information about using security, see Using Security in CORBA Applications in the BEA Tuxedo online documentation.
The Transaction service is accessed through either the TransactionCurrent environmental object or the TransactionFactory object. The TransactionCurrent and TransactionFactory objects allow a client application to participate in a transaction. The BEA Tuxedo software provides an implementation of the CORBA
Services Object Transaction Service (OTS).
For information about using transactions, see Using CORBA Transactions in the BEA Tuxedo online documentation.
The Interface Repository service is accessed through the InterfaceRepository object. The InterfaceRepository object is a CORBA object that contains interface definitions for all the available CORBA interfaces and the factories used to create object references to the CORBA interfaces. The InterfaceRepository object is used with client applications that use DII.
For information about using DII, see Creating CORBA Client Applications.
BEA Tuxedo CORBA provides environmental objects for the following programming environments:
BEA Tuxedo CORBA also supports the use of the OMG CORBA Interoperable Naming Service (INS) by third-party clients, to obtain initial object references.
This section provides an introduction to the following architectural components of the BEA Tuxedo CORBA programming environment:
Figure 2-2 illustrates the components in a BEA Tuxedo CORBA application.
A domain is a way of grouping objects and services together as a management entity. A BEA Tuxedo domain has at least one IIOP Listener/Handler and is identified by a name. One client application can connect to multiple BEA Tuxedo domains using different Bootstrap objects.
Bootstrapping the BEA Tuxedo domain establishes communication between a client application and the domain. There are two mechanisms available for bootstrapping, the BEA mechanism and the CORBA Interoperable Naming Service (INS) bootstrapping mechanism specified by the OMG. Use the BEA mechanism if you are using BEA CORBA client software. Use the CORBA INS mechanism if you are using a client ORB from another vendor. For more information about bootstrapping the BEA Tuxedo domain, see the CORBA Programming Reference in the BEA Tuxedo online documentation.
One of the first things that client applications do after startup is create a Bootstrap object by supplying the host and port of the IIOP Listener/Handler using one of the following URL address formats:
For more information about the Bootstrap URL address formats, see Using Security in CORBA Applications in the BEA Tuxedo online documentation.
The client application then uses the Bootstrap object or the INS bootstrapping mechanism to obtain references to the objects in a BEA Tuxedo domain. Once the Bootstrap object is instantiated, the resolve_initial_references()
method is invoked by the client application, passing in a string id
, to obtain a reference to the objects in the BEA Tuxedo domain that provide CORBA services.
Figure 2-3 illustrates how the Bootstrap object or INS mechanism operates in a BEA Tuxedo domain.
The IIOP Listener/Handler is a process that receives the CORBA client request, which is sent using IIOP, and delivers that request to the appropriate CORBA server application. The IIOP Listener/Handler serves as a communication concentrator, providing a critical scalability feature. The IIOP Listener/Handler removes from the CORBA server application the burden of maintaining client connections. For information about configuring the IIOP Listener/Handler, see Setting Up a BEA Tuxedo Application and the description of the ISL command in the BEA Tuxedo Command Reference in the BEA Tuxedo online documentation.
The ORB serves as an intermediary for requests that CORBA client applications send to CORBA server applications, so that these applications do not need to contain information about each other. The ORB is responsible for all the mechanisms required to find the implementation that can satisfy the request, to prepare an object's implementation to receive the request, and to communicate the data that makes up the request. The BEA Tuxedo CORBA product includes a C++ client/server ORB.
Figure 2-4 shows the relationship between an ORB, a CORBA client application, and a CORBA server application.
When the client application uses IIOP to send a request to the BEA Tuxedo domain, the ORB performs the following functions:
The TP Framework provides a programming model that achieves high levels of performance while shielding the application programmer from the complexities of the CORBA interfaces. The TP Framework supports the rapid construction of CORBA applications, which makes it easier for application programmers to adhere to design patterns associated with successful TP applications.
The TP Framework interacts with the Portable Object Adapter (POA) and the CORBA application, thus eliminating the need for direct POA calls in an application. In addition, the TP Framework integrates transactions and state management into the BEA Tuxedo CORBA application.
The application programmer uses an application programming interface (API) that automates many of the functions required in a standard CORBA application. The application programmer is responsible only for writing the business logic of the CORBA application and overriding default actions provided by the TP Framework.
The TP Framework API provides routines that perform the following functions required by a CORBA application:
The TP Framework ensures that the execution of a client request takes place in a coordinated, predictable manner. The TP Framework calls the objects and services available in the BEA Tuxedo application at the appropriate time, in the correct sequence. In addition, the TP Framework maximizes the reuse of system resources by objects. Figure 2-5 illustrates the TP Framework.
The TP Framework is not a single object, but is rather a collection of objects that work together to manage the CORBA objects that contain and implement the data and business logic in your CORBA application.
One of the TP Framework objects is the Server object. The Server object is a user-written programming entity that implements operations that perform tasks such as initializing and releasing the server application. For server applications the TP Framework instantiates the CORBA objects needed to satisfy a client request.
If a client request arrives requiring an object that is not currently active and in memory in the server application, the TP Framework coordinates all the operations that are required to instantiate the object. This includes coordinating with the ORB and the POA to get the client request to the appropriate object implementation code.
The interaction between BEA Tuxedo CORBA client and server applications includes the following steps:
The following topics describe what happens during each step.
The system administrator enters the tmboot
command on a machine in the BEA Tuxedo domain to start the BEA Tuxedo CORBA server application. The TP Framework invokes the initialize()
operation in the Server
object to initialize the server application.
During the initialization process, the Server object does the following:
During initialization, the CORBA client application obtains initial references to the objects available in the BEA Tuxedo domain.
The Bootstrap object returns references to the FactoryFinder, SecurityCurrent, TransactionCurrent, NameService, and InterfaceRepository objects in the BEA Tuxedo domain.
If the BEA Tuxedo domain has a security model in effect, the CORBA client application needs to authenticate itself to the BEA Tuxedo domain before it can invoke any operations in the CORBA server application. To authenticate itself to the BEA Tuxedo domain using authentication, the CORBA client application completes these steps:
Note: | For information about using certificate based authentication, see Using Security in CORBA Applications in the BEA Tuxedo online documentation. |
The CORBA client application needs to perform the following steps:
For example, the client application needs a reference to the SimpleFactory object. The client application obtains this factory reference from the FactoryFinder object, shown in the following figure.
Simple
object.
If the SimpleFactory object is not active, the TP Framework instantiates the SimpleFactory object by invoking the Server::create_servant
method on the Server object, shown in the following figure.
activate_object()
and find_simple()
operations on the SimpleFactory object to get a reference to the Simple object, shown in the following figure.
The SimpleFactory object then returns the object reference to the Simple
object to the client application.
Note: | Because the TP Framework activates objects by default, the Simpapp sample application does not explicitly use the activate_object() operation for the SimpleFactory object. |
Using the reference to the CORBA object that the factory has returned to the client application, the client application invokes an operation on the object. For example, now that the client application has an object reference to the Simple object, the client application can invoke the to_upper()
operation on it. The instance of the Simple object required for the client request is created as shown in the following figure.