The WebLogic Enterprise CORBA Programming Environment

 

This topic includes the following sections:

• Overview of the WebLogic Enterprise CORBA Programming Features

• WebLogic Enterprise CORBA Object Services

• WebLogic Enterprise Architectural Components

• How WebLogic Enterprise CORBA Client and Server Applications Interact

 

---

Overview of the WebLogic Enterprise CORBA Programming Features

The WebLogic Enterprise product 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 WebLogic Enterprise product comes with two IDL compilers that make object development easier:

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

• idltojava-compiles IDL files to Java source code based on IDL-to-Java mappings defined by the OMG. The idltojava compiler provided with the WebLogic Enterprise product includes several enhancements, extensions and additions that are not present in the original Sun Microsystems, Inc. version of the compiler. The WebLogic Enterprise 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> <Repostitory_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.

• m3idltojava-compiles the OMG IDL file and generates client stub and server skeleton files required for interface definitions being implemented in Java.

For a description of how to use the IDL compilers, see Developing WebLogic Enterprise CORBA Applications.

For a description of the idl, idltojava, and m3idltojava commands, see Commands, Server Processes, and MIB Reference in the WebLogic Enterprise online documentation.

Development Commands

Table 2-1 lists the commands that the WebLogic Enterprise product provides for developing CORBA application components and managing the Interface Repository.

Table 2-1 WebLogic Enterprise CORBA Development Commands

Development Command	Description
buildjavaserver	Constructs a server application JAR file for a Java server application.
buildobjclient	Constructs a C++ client application.
buildobjserver	Constructs a C++ server application.
buildXAJS	Constructs an XA resource manager to be used with a Java server application group.
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 WebLogic Enterprise CORBA Applications.

For a description of the development commands, see Commands, Server Processes, and MIB Reference in the WebLogic Enterprise online documentation.

Administration Tools

The WebLogic Enterprise product provides a complete set of tools for administering your WebLogic Enterprise environment. You can manage the WebLogic Enterprise application 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 WebLogic Enterprise application.

Table 2-2 WebLogic Enterprise Administration Commands

Administration Command	Description
tmadmin	Displays information about current configuration parameters.
tmboot	Activates the WebLogic Enterprise 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 WebLogic Enterprise 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 remotely manage your WebLogic Enterprise applications. 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 WebLogic Enterprise 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 Commands, Server Processes, and MIB Reference and Administration in the WebLogic Enterprise 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 Admin API, see BEA Tuxedo Reference in the WebLogic Enterprise 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 WebLogic Enterprise 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 the PDF version of the WebLogic Enterprise ActiveX Client Developer's Guide in the WebLogic Enterprise online documentation.

 

---

WebLogic Enterprise CORBA Object Services

The WebLogic Enterprise product includes a set of environmental objects that provide object services to client applications in a WebLogic Enterprise domain. You access the environmental objects through a bootstrapping process that accesses the services in a particular WebLogic Enterprise domain.

The following services are provided:

• 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 CORBAservices Life Cycle Service. WebLogic Enterprise applications use the Object Life Cycle service to find object references.

  For information about using the Object Life Cycle Service, see How WebLogic Enterprise CORBA Client and Server Applications Interact.

• Security service

  The Security service is accessed through the SecurityCurrent environmental object. The SecurityCurrent object is used to authenticate a client application into a WebLogic Enterprise domain with the proper security. The WebLogic Enterprise software provides an implementation of the CORBAservices Security Service.

  For information about using security, see Using Security in the WebLogic Enterprise online documentation.

• Transaction service

  The Transaction service is accessed through either the TransactionCurrent environmental object or the UserTransaction object. The TransactionCurrent object allows a client application to participate in a transaction. The WebLogic Enterprise software provides an implementation of the CORBAservices Object Transaction Service (OTS). In addition, the UserTransaction object provides access to the Sun Microsystems, Inc. Java Transaction API (JTA) defined in the javax.transaction package.

  For information about using transactions, see Using Transactions in the WebLogic Enterprise online documentation.

• Interface Repository service

  The Interface Repository service is accessed through the IntefaceRepository 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 Interface Repository object is used with client applications that use DII.

  For information about using DII, see Creating CORBA Client Applications.

The WebLogic Enterprise software provides environmental objects for the following programming environments:

• C++

• Java

• Automation (used by ActiveX client applications)

 

---

WebLogic Enterprise Architectural Components

This section provides an introduction to the following architectural components of the WebLogic Enterprise system:

• Bootstrap Object

• IIOP Listener/Handler

• ORB

• TP Framework

Figure 2-3 illustrates the components in a WebLogic Enterprise application.

Figure 2-3 Components in a WebLogic Enterprise Application

Bootstrap Object

The Bootstrap object establishes communication between a client application and a WebLogic Enterprise domain. A domain is simply a way of grouping objects and services together as a management entity. A WebLogic Enterprise domain has at least one IIOP Listener/Handler and is identified by a name. One client application can connect to multiple WebLogic Enterprise domains using different Bootstrap objects.

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 the WebLogic Enterprise online documentation.

The client application then uses the Bootstrap object to obtain references to the objects in a WebLogic Enterprise 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 domain that provide CORBA services. The valid values for string id are FactoryFinder, TransactionCurrent, SecurityCurrent, and InterfaceRepository.

Figure 2-4 illustrates how the Bootstrap object works in a WebLogic Enterprise domain.

Figure 2-4 How the Bootstrap Object Works in a WebLogic Enterprise Domain

IIOP Listener/Handler

The IIOP Listener/Handler is a process that receives the client request, which is sent using IIOP, and delivers that request to the appropriate server application. The IIOP Listener/Handler serves as a communication concentrator, providing a critical scalability feature. The IIOP Listener/Handler removes from the server application the burden of maintaining client connections. For information about configuring the IIOP Listener/Handler, see Adminstration and the description of the ISL command in the Commands, Server Processes, and MIB Reference in the WebLogic Enterprise online documentation.

ORB

The ORB serves as an intermediary for requests that client applications send to server applications, so that client applications and server 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 WebLogic Enterprise product provides a C++ ORB and a BEA version of the Java IDL ORB provided with the Java Development Kit (JDK) from Sun Microsystems, Inc.

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

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

When the client application uses IIOP to send a request to the 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 client application's request. 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 WebLogic Enterprise 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 WebLogic Enterprise application, thus eliminating the need for direct POA calls in an application. In addition, the TP Framework integrates transactions and state management into the WebLogic Enterprise 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 WebLogic Enterprise 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 server application and executing startup and shutdown routines

• Creating object references

• Registering and unregistering object factories

• Managing objects and object state

• Tying the server application to WebLogic Enterprise 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 WebLogic Enterprise 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 your WebLogic Enterprise application's data and business logic.

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 implemented in C++, the TP Framework instantiates the CORBA objects needed to satisfy a client request.

If a client request that requires an object that is not currently active and in memory in the server application arrives, 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 WebLogic Enterprise CORBA Client and Server Applications Interact

The interaction between WebLogic Enterprise CORBA client and server applications includes the following steps:

1. The server application is initialized.

2. The client application is initialized.

3. The client application authenticates itself to the WebLogic Enterprise domain.

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

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

The following topics describe what happens during each step.

Step 1: The Server Application Is Initialized

The system administrator enters the tmboot command on a machine in the WebLogic Enterprise domain to start the WebLogic Enterprise 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. Gets the Bootstrap object and 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 Client Application Is Initialized

During initialization, the client application uses the Bootstrap object in the domain to obtain initial references to the environmental objects available in the domain.

The Bootstrap object returns references to the FactoryFinder, SecurityCurrent, TransactionCurrent, NameService, and InterfaceRepository objects in the WebLogic Enterprise domain.

Step 3: The Client Application Authenticates Itself to the WebLogic Enterprise Domain

If the WebLogic Enterprise domain has a security model in effect, the client application needs to authenticate itself to the WebLogic Enterprise domain before it can invoke any operations in the server application. To authenticate itself to the WebLogic Enterprise domain using Tuxedo authentication, the client application:

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 the WebLogic Enterprise online documentation.

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

The 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, what happens next depends on the programming language in which the server application is implemented:

   • In Java, the WebLogic Enterprise system instantiates the SimpleFactory object dynamically.

   • In C++, 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 implicitly use the activate_object() operation for the SimpleFactory object.

Step 5: The 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.

If the server application were implemented in Java, the Simple object required for the client request is instantiated dynamically by the WebLogic Enterprise system.

The TP Framework invokes the activate_object() operation on the Simple object and the SimpleFactory object to allow the object to initialize any object state necessary.

Object state initialization often involves reading durable state information from disk for that object. The TP Framework invokes the operation on the object, returning the response to the client application.