Product Overview
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
The following sections describe the BEA Tuxedo CORBA components built on the BEA Tuxedo infrastructure:
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.
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 CORBA provides businesses and organizations that depend on mission-critical applications with the advantages of the CORBA-compliant programming model, combined with the power, robustness, and proven reliability of the Tuxedo transaction processing technology. BEA Tuxedo CORBA also taps into the existing Tuxedo infrastructure for transaction management, security, message transport, administration and manageability, and XA-compliant database support.
BEA Tuxedo CORBA combines the ORB model with online transaction processing (OLTP) functions to create a top-of-the-line Object Transaction Monitor (OTM). As shown in the following figure, an OTM is an example of a 3-tier client/server architecture, where the OTM supports the application logic between the GUI front-end and the back-end resource managers. Examples of resource managers are object-oriented databases, relational databases, message queues, legacy applications, and other back-end services.
Figure 3-1 3-Tier Client/Server Architecture Using an OTM
By breaking the direct connection between the user interface front-end and the resource managers, an OTM controls all the traffic that links hundreds or thousands or even tens of thousands of clients with run-time objects and the back-end resources. An OTM ensures that global (distributed) transactions are completed accurately, provides load balancing, and improves the overall system performance. An OTM also prestarts pools of objects and provides fault-tolerance. More importantly, an OTM makes an application's server processes independent of the user interface front-end and any resource manager.
BEA Tuxedo CORBA is an object application server that runs server-side distributed objects. Besides managing an application's server objects and managing transactions, BEA Tuxedo CORBA also manages client/server communications.
Object-oriented transactional communications use a highly augmented version of ORB invocations. However, most of the value-added elements are transparent to the programmer: The transactional client/server exchanges look like ordinary exchanges bracketed by start and end transaction calls. The distinguishing factor is that all resource managers and processes invoked through these calls become part of the transaction. An OTM, such as BEA Tuxedo CORBA, orchestrates the actions of all the participants and makes them act as part of a transaction.
The BEA Tuxedo CORBA OTM provides a TP framework, or organized environment, for running server-side distributed objects. A TP framework not only calls the objects and the Tuxedo CORBA services at the appropriate time and in the correct sequence, but it also simplifies the server-side programming model.
BEA Tuxedo CORBA consists of the following main components:
Allows Tuxedo CORBA clients to reside on intelligent workstations and communicate over a network connection with a CORBA server application.
Provides a set of objects for helping Tuxedo CORBA clients and servers work with the Tuxedo CORBA environment.
The BEA Tuxedo infrastructure provides the bedrock client/server architecture for both BEA Tuxedo CORBA and BEA Tuxedo ATMI. The OTM and infrastructure discussed here and illustrated in the following figure constitute the BEA Tuxedo CORBA environment, which provides the communication interfaces, transaction support, and application-processing and administrative services for a distributed CORBA application.
Figure 3-2 BEA Tuxedo CORBA Environment
The BEA Tuxedo system management interface, common to both BEA Tuxedo CORBA and BEA Tuxedo ATMI, can accommodate tools for both application development and administration. For information about the BEA Tuxedo system management interface, see System Management Interface.
The BEA Tuxedo CORBA programming interface consists of a C++ server ORB and a C++ client ORB. On the server side, instead of using the CORBA API directly, application programmers use an API that automates many of the functions required in a standard CORBA application.
The BEA Tuxedo CORBA server-side TP Framework component and client-side environmental objects enable programmers to use the deployment environment with a minimal amount of programming. For information about the TP Framework component, see BEA Tuxedo TP Framework. For information about client-side environmental objects, see BEA Tuxedo CORBA Environmental Objects.
Application programmers develop a Tuxedo CORBA application as a set of CORBA objects, using the OMG Interface Definition Language (IDL) and, optionally, using standard, off-the-shelf programming tools. These objects communicate with other objects using the CORBA Internet Inter-ORB Protocol (IIOP). The following figure identifies the architectural components of the BEA Tuxedo CORBA programming environment.
Figure 3-3 Components in a BEA Tuxedo CORBA Application
BEA Tuxedo CORBA runs the objects in the server processes that it manages. BEA Tuxedo CORBA can also manage server processes that run Tuxedo ATMI services, thereby allowing programmers to combine object-based and service-based components in the same Tuxedo application.
Note: A Tuxedo application has the same meaning as a Tuxedo domain. For a definition of a Tuxedo domain, see Important BEA Tuxedo Terms and Concepts.
The ORB, or Object Request Broker, is a library that enables clients to locate and communicate with servers independently of server location and network connections. The ORB is sometimes referred to as the object bus.
Programmers define their object's interface via OMG IDL, and the ORB takes care of the rest. The ORB serves as an intermediary for requests that CORBA clients send to CORBA server applications, so that the client and server do not need to contain information about each other. The following figure shows the relationship between an ORB, a CORBA application client, and a CORBA server application.
Figure 3-4 The ORB in a CORBA Client/Server Environment
BEA Tuxedo CORBA includes C++ server ORB and C++ client ORB. The ORBs have built-in transaction support, meaning that the CORBA Object Transaction Service (OTS), on which a CORBA OTM is based, is patterned after the XA standard for two-phase commit processing.
The C++ server ORB is linked directly into the Tuxedo CORBA server processes. Other client ORBs can communicate with BEA Tuxedo CORBA via CORBA's IIOP protocol.
The BEA Tuxedo IIOP Listener/Handler allows a CORBA client residing on a remote machine that does not have a full BEA Tuxedo server-side installation (that is, a machine that does not support BEA Tuxedo administration servers or a bulletin board) to be able to communicate with a BEA Tuxedo CORBA server application. All communication between a remote CORBA client and the CORBA server application takes place over a network connection using the IIOP protocol.
Advantages of remote CORBA clients include:
The IIOP Listener/Handler communication architecture involves the following software processes:
A client process that runs on a machine on which the BEA Tuxedo CORBA C++ client ORB software is installed.
A BEA Tuxedo listening process, running on a BEA Tuxedo server machine, that accepts connection requests from CORBA clients and assigns connections to an IIOP Handler also running on the server machine. It balances client connections across handlers. In addition, an IIOP Listener manages the pool of IIOP Handler processes, starting them in response to load demands.
A BEA Tuxedo gateway process, running on the BEA Tuxedo server machine, that handles IIOP communications between CORBA clients and the BEA Tuxedo server application. An ISH process resides within the administrative domain of the application and is registered in the local BEA Tuxedo bulletin board as a client.
Each ISH process can manage multiple CORBA clients. An ISH multiplexes all requests and replies with a particular CORBA client over a single connection.
For more information about the IIOP Listener/Handler, see the following documents:
BEA Tuxedo CORBA provides a set of objects for helping the client work with the Tuxedo CORBA environment; the objects enable client applications to easily log on to a Tuxedo CORBA environment, invoke CORBA objects, and start and end transactions. Like the server-side TP Framework component, these objects interact with the Tuxedo CORBA services.
Here is what these objects do for application clients:
The Bootstrap object provides references to the Tuxedo CORBA objects in a Tuxedo CORBA application. An application client can connect to multiple BEA Tuxedo CORBA applications using different Bootstrap objects.
One of the first things that an application client does after startup is to create a Bootstrap object by supplying the host and port number of the IIOP Listener. After the application client contacts an IIOP Listener, the Listener assigns an IIOP Handler to the application client, and the Boostrap object establishes a communication link with the assigned IIOP Handler.
The Bootstrap object also provides references to well-known objects that application clients use, such as TransactionCurrent, SecurityCurrent, InterfaceRepository, and FactoryFinder.
The CORBA OTS TransactionCurrent object coordinates transaction demarcations with the transaction coordinator.
BEA Tuxedo CORBA provides environmental objects for the C++ programming environment and for the Java programming environment. As of release 8.0, BEA Tuxedo CORBA also supports the use of the OMG CORBA Interoperable Naming Service (INS) by third-party client ORBs, to obtain initial object references.
Each environmental object provides object services to application clients. Application clients access the environmental objects through a bootstrapping process that accesses the services in a particular BEA Tuxedo server application. BEA client ORBs use the BEA Bootstrap object mechanism, and third-party client ORBs use the CORBA INS mechanism. For more information about bootstrapping a BEA Tuxedo application, see BEA Tuxedo CORBA Programming Reference.
The BEA Tuxedo CORBA environmental objects provide 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.
The Security service is accessed through either the SecurityCurrent environmental object or the PrincipalAuthenticator object. The SecurityCurrent and PrincipalAuthenticator objects are used to authenticate an application client attempting to access a BEA Tuxedo server application. The BEA Tuxedo software provides an implementation of the CORBA Services Security Service.
The Transaction service is accessed through either the TransactionCurrent environmental object or the TransactionFactory object. The TransactionCurrent and TransactionFactory objects allow an application client to demarcate a transaction—that is, begin, suspend, resume, and commit a transaction. The BEA Tuxedo software provides an implementation of the CORBA Services Object Transaction Service (OTS).
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 application clients that use Dynamic Invocation Interface (DII).
The TP Framework component, shown in the following figure, 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 API provides routines that perform many of the functions required in a standard CORBA application. Application programmers are responsible only for writing the business logic of the CORBA application and overriding default actions provided by the TP Framework.
The TP Framework and environmental objects help make development easy. The following figure illustrates the BEA Tuxedo CORBA development environment.
Figure 3-6 BEA Tuxedo CORBA Deployment Environment
![]() ![]() |
![]() |
![]() |