The BEA Tuxedo CORBA Programming Environment

This topic includes the following sections:

• Overview of the BEA Tuxedo CORBA Programming Features

• BEA Tuxedo CORBA Object Services

• BEA Tuxedo CORBA Architectural Components

• How BEA Tuxedo CORBA Client and Server Applications Interact

 

---

Overview of the BEA Tuxedo CORBA Programming Features

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:

• IDL Compilers

• Development Commands

• Administration Tools

• ActiveX Application Builder

IDL Compilers

The BEA Tuxedo CORBA programming environment supplies Interface Definition Language (IDL) compilers to facilitate the development of CORBA objects:

• idl—compiles the OMG IDL file and generates client stub and server skeleton files required for interface definitions being implemented in C++.

• idltojava—for building a Java client, compiles IDL files to Java source code based on IDL-to-Java mappings defined by the OMG. This idltojava compiler includes several enhancements, extensions and additions that are not present in the original Sun Microsystems, Inc. version of the compiler. The BEA Tuxedo-specific revisions are summarized below.

  • Differs from that described in the Sun Microsystems, Inc. documentation in behavior and defaults of the flags.

  • Includes a new #pragma tag: #pragma ID name Repository_id.

  • Includes a new #pragma tag: #pragma version name m.n.

  • Extends the #pragma prefix to work on inner scope. A blank prefix reverts.

  • Allows unions with Boolean discriminators.

  • Allow declarations nested inside complex types.

Note: The m3idltojava compiler is deprecated in this release. BEA Systems recommends using the idltojava compiler to generate client stubs for CORBA Java clients and CORBA Java joint client/servers.

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.

For a description of how to use the idltojava command, see the BEA Tuxedo Command Reference and Using the CORBA idltojava Compiler in the BEA Tuxedo online documentation.

Development Commands

Table  2-1 lists the commands that the BEA Tuxedo CORBA programming environment provides for developing CORBA applications and managing the Interface Repository.

Table 2-1 BEA Tuxedo CORBA Development Commands

Development Command	Description
buildobjclient	Constructs a C++ client application.
buildobjserver	Constructs a C++ server application.
genicf	Generates an Implementation Configuration File (ICF). The ICF file defines activation and transaction policies for C++ server applications.
id12ir	Creates the Interface Repository and loads interface definitions into it.
ir2idl	Shows the content of the Interface Repository.
irdel	Deletes the specified object from 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.

Administration Tools

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.

Table 2-2 Administration Commands

Administration Command	Description
tmadmin	Displays information about current configuration parameters.
tmboot	Activates the BEA Tuxedo CORBA application referenced in the specified configuration file. Depending on the options used, the entire application or parts of the application are started.
tmconfig	Dynamically updates and retrieves information about the configuration of a BEA Tuxedo CORBA application.
tmloadcf	Parses the configuration file and loads the binary version of the configuration file.
tmshutdown	Shuts down a set of specified server applications, or removes interfaces from a configuration file.
tmunloadcf	Unloads the configuration file.

 

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.

Figure 2-1 Administration Console Main Window

 

 

 

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.

ActiveX Application Builder

The ActiveX Application Builder is a development tool that you use with a client development tool (such as Visual Basic) to select which CORBA interfaces in a BEA Tuxedo domain you want your ActiveX client application to interact with. In addition, you use the ActiveX Application Builder to create Automation bindings for CORBA interfaces, and to create packages for deploying ActiveX views of CORBA objects to client machines.

Figure  2-2 shows the ActiveX Application Builder main window.

Figure 2-2 ActiveX Application Builder Main Window

 

For a description of the ActiveX Application Builder and how it works, see the online help that is integrated into the ActiveX Application Builder graphical user interface (GUI). For information about creating ActiveX client applications, see Using CORBA ActiveX in the BEA Tuxedo online documentation.

 

---

BEA Tuxedo CORBA Object Services

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:

• Object Life Cycle service

  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-16.

• Security service

  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.

• Transaction service

  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.

• Interface Repository service

  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:

• C++

• Java

• Automation (used by ActiveX client applications)

BEA Tuxedo CORBA also supports the use of the OMG CORBA Interoperable Naming Service (INS) by third-party clients, to obtain initial object references.

 

---

BEA Tuxedo CORBA Architectural Components

This section provides an introduction to the following architectural components of the BEA Tuxedo CORBA programming environment:

• Bootstrapping the BEA Tuxedo Domain

• IIOP Listener/Handler

• ORB

• TP Framework

Figure  2-3 illustrates the components in a BEA Tuxedo CORBA application.

Figure 2-3 Components in a BEA Tuxedo CORBA Application

 

 

 

 

 

 

 

 

 

 

 

Bootstrapping the BEA Tuxedo Domain

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:

• //host:port

• corbaloc://host:port

• corbalocs://host:port

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-2 illustrates how the Bootstrap object or INS mechanism operates in a BEA Tuxedo domain.

Figure 2-4 How the Bootstrap Object or INS Operates

 

IIOP Listener/Handler

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.

ORB

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 and a BEA Systems version of the Java IDL client ORB provided with the Java Development Kit (JDK) from Sun Microsystems, Inc.

Figure  2-5 shows the relationship between an ORB, a CORBA client application, and a CORBA server application.

Figure 2-5 The ORB in a CORBA Client/Server Environment

 

 

When the client application uses IIOP to send a request to the BEA Tuxedo domain, the ORB performs the following functions:

• Validates each request and its arguments to ensure that the client application supplied all the required arguments.

• Manages the mechanisms required to find the CORBA object that can satisfy the request from the CORBA client application. To do this, the ORB interacts with the Portable Object Adapter (POA). The POA prepares an object's implementation to receive the request and communicates the data in the request.

• Marshals data. The ORB on the client machine writes the data associated with the request into a standard form. The ORB receives this data and converts it into the format appropriate for the machine on which the server application is running. When the server application sends data back to the client application, the ORB marshals the data back into its standard form and sends it back to the ORB on the client machine.

TP Framework

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:

• Initializing the CORBA server application and executing startup and shutdown routines

• Creating object references

• Registering and unregistering object factories

• Managing objects and object state

• Tying the CORBA server application to BEA Tuxedo CORBA system resources

• Getting and initializing the ORB

• Performing object housekeeping

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-6 illustrates the TP Framework.

Figure 2-6 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.

 

---

How BEA Tuxedo CORBA Client and Server Applications Interact

The interaction between BEA Tuxedo CORBA client and server applications includes the following steps:

1. The CORBA server application is initialized.

2. The CORBA client application is initialized.

3. The CORBA client application authenticates itself to the BEA Tuxedo domain.

4. The CORBA client application obtains a reference to the CORBA object needed to execute its business logic.

5. The CORBA client application invokes an operation on the CORBA object.

The following topics describe what happens during each step.

Step 1: The CORBA Server Application Is Initialized

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:

1. Uses the Bootstrap object or INS to obtain a reference to the FactoryFinder object.

2. Typically registers any factories with the FactoryFinder object.

3. Optionally gets an object reference to the ORB.

4. Performs any process-wide initialization.

Step 2: The CORBA Client Application Is Initialized

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.

Step 3: The CORBA Client Application Authenticates Itself to 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:

1. Uses the Bootstrap object to obtain a reference to the SecurityCurrent object.

2. Invokes the logon() operation of the PrincipalAuthenticator object, which is retrieved from the SecurityCurrent object.

Note: For information about using certificate based authentication, see Using Security in CORBA Applications in the BEA Tuxedo online documentation.

Step 4: The CORBA Client Application Obtains a Reference to the CORBA Object Needed to Execute Its Business Logic

The CORBA client application needs to perform the following steps:

1. Obtain a reference to the factory for the object it needs.

   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.

   
    

2. Invoke the SimpleFactory object to get a reference to the 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.

   
    

   
    

3. The TP Framework invokes the 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.

Step 5: The CORBA Client Application Invokes an Operation on the CORBA 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.