Understanding the WebLogic Enterprise (WLE) Product

This chapter discusses the following topics:

• Overview of the WLE Product

• WLE Programming Environment

• WLE Object Services

• WLE Components

• How WLE Client and Server Applications Interact

Overview of the WLE Product

The WLE product extends the Object Request Broker (ORB) model with online transaction processsing (OLTP) functions. It uses the CORBA standard as a programming model for developing enterprise applications with high performance, scalability, and reliability. The WLE deployment infrastructure delivers secure, transactional, distributed applications in a managed environment.

Objects built with the WLE product can be accessed from Web-based applications that communicate using the Object Management Group (OMG) Internet Inter-ORB Protocol (IIOP). IIOP is the standard protocol for communications running on the Internet or on an enterprise's Intranet. The WLE product has a native implementation of IIOP, ensuring high-performance, interoperable, distributed-object applications for the Internet, Intranets, and enterprise computing environments. Figure 1-1 illustrates the WLE product.

Figure 1-1 WLE Product

The WLE product provides:

• A set of integrated components that can be used to build robust, distributed client/server applications. These components can be accessed from a set of C++, Java, and COM/OLE/ActiveX application programming interfaces (APIs).

• Support for hetergeneous client and server applications. The WLE product supports C++ and Java server applications, as well as C++, Java, and ActiveX client applications and Java applets.

• Interoperability with other ORB products. The use of IIOP in the WLE product allows client and server applications developed with the product to be used with applications built with CORBA 2.0 compliant ORBs from other vendors.

• Integration with other enterprise resources, such as Oracle and Microsoft SQL Server databases and legacy applications.

• A Simple Network Management Protocol (SNMP) Management Information Base (MIB) that defines the key management attributes of WLE applications.

• A CORBA and XA-compatible Transaction Service to ensure the integrity of your data even when transactions span mulitiple databases and applications.

• A CORBA-based security service that provides authentication for distributed objects and their client applications.

• An interface repository that stores meta information about object types. Meta information stored for CORBA objects includes information about modules, interfaces, operations, attributes, and exceptions.

• Dynamic Invocation Interface (DII) support. DII allows client applications to dynamically create requests for objects that were not defined at compile time.

The topics in Getting Started describe the features of the WLE product and the development process for building a transactional application using the WLE software. This topic does not discuss every feature of the WLE product; instead it gives an general description of building transactional applications. For more information, see the following on the Online Documentation CD:

Creating Client Applications

Creating C++ Server Applications

Creating Java Server Applications

Using Server-to-Server Communication

WLE Programming Environment

The WLE product offers a robust programming environment that makes the development and management of distributed objects easier. The following topics describe the features of the programming environment:

• IDL Compilers

• Development Commands

• Administration Tools

• ActiveX Application Builder

IDL Compilers

The WLE 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++

• 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 the following on the Online Documentation CD:

Creating Client Applications

Creating C++ Server Applications

Creating Java Server Applications

For a description of the idl and m3idltojava commands, see the following on the Online Documentation CD:

C++ Programming Reference

Java Programming Reference

Development Commands

Table 1-1 lists the commands that the WLE product provides for developing application components and managing the Interface Repository.

Table 1-1 Development Commands

For a description of how to use the development commands to develop client and server applications, see the following on the Online Documentation CD:

Creating Client Applications

Creating C++ Server Applications

Creating Java Server Applications

For a description of the development commands, see the following on the Online Documentation CD:

C++ Programming Reference

Java Programming Reference

Administration Tools

The WLE product provides a complete set of tools for administering your WLE environment. You can manage the WLE application through commands, through a graphical user interface, or by including administration utilities in a script.

You can use the commands listed in Table 1-2 to perform administration tasks for your WLE application.

Table 1-2 Administration Commands

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 1-2 shows the main window of the Administration Console.

Figure 1-2 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 WLE 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 human intervention.

For information about the Administration commands, see the Adminstration Guide on the Online Documentation CD

For a description of the Administration Console and how it works, see the Administration Guide on the Online Documentation CD and the online help that is integrated into the Administration Console graphical user interface (GUI).

For information about the AdminAPI, see the BEA TUXEDO Reference on the Online Documentation CD.

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 WLE 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 1-3 shows the ActiveX Application Builder main window.

Figure 1-3 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 a description of how ActiveX client applications use CORBA objects, see Creating Client Applications on the Online Documentation CD.

WLE Object Services

The WLE product includes a set of environmental objects that provide object services to client applications in a WLE domain. You access the environmental objects through a bootstrapping process that accesses the services in a particular WLE 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. WLE applications use the Object Life Cycle service to find object references.

  For information about using the Object Life Cycle Service, see the topic "How WLE 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 WLE domain with the proper security. The WLE software provides an implementation of the CORBAservices Security Service.

  For information about using security, see the topic "Using Security."

• 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 WLE software provides an implementation of the CORBAservices Object Transaction Service (OTS). In addition, the UserTransaction object provides access to Sun Microsystems, Inc.'s Java Transaction API (JTA) defined in the javax.transaction package.

  For information about using transactions, see the topic "Using Transactions."

• Interface Repository service

  The Interface Respository 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 Client Applications on the Online Documentation CD.

The WLE software provides environmental objects for the following programming environments:

• C++

• Java

• Automation (used by ActiveX client applications)

WLE Components

This section provides an introduction to the following WLE components:

• Bootstrap Object

• IIOP Listener/Handler

• ORB

• TP Framework

Figure 1-4 illustrates the components in a WLE application.

Figure 1-4 Components in a WLE Application

Bootstrap Object

The Bootstrap object establishes communication between a client application and a WLE domain. A domain is simply a way of grouping objects and services together as a management entity. A WLE domain has at least one IIOP Listener/Handler and is identified by a name. One client application can connect to multiple WLE 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 as a parameter to its constructor, as follows:

//host:port

For example, //myserver:4000

The client application then uses the Bootstrap object to obtain references to the objects in a WLE 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 1-5 illustrates how the Bootstrap object works in a WLE domain.

Figure 1-5 How the Bootstrap Object Works

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 the Adminstration Guide on the Online Documentation CD.

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 WLE product provides a C++ ORB and a BEA version of the Java IDL ORB provided with the Java Development Kit from Sun Microsystems, Inc.

Figure 1-6 shows the relationship between an ORB, a client application, and a server application.

Figure 1-6 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 Framwork supports the rapid construction of WLE applications, which makes it easier for application programmers to adhere to design patterms associated with successful TP applications.

The TP Framework interacts with the Portable Object Adapter (POA) and the WLE application, thus eliminating the need for direct POA calls in an application. In addition, the TP Framework integrates transactions and state management into the WLE 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 WLE 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 WLE 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 coodinated, predictable manner. The TP Framework calls the objects and services available in the WLE application at the appropriate time, in the correct sequence. In addition, the TP Framework maximizes the reuse of system resources by objects. Figure 1-7 illustrates the TP Framework.

Figure 1-7 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 WLE 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.

For examples of programming with the TP Framework, see Creating C++ Server Applications and Creating Java Server Applications on the Online Documenation CD.

How WLE Client and Server Applications Interact

The interaction between WLE 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 WLE 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 WLE domain to start the WLE 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.

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, and InterfaceRepository objects in the WLE domain.

Step 3: The client application authenticates itself to the WLE domain.

If the WLE domain has a security model in effect, the client application needs to authenticate itself to the WLE domain before it can invoke any operations in the server application. To authenticate itself to the WLE domain, 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

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:

   • If C++, the TP Framework instantiates the SimpleFactory object by invoking the Server::create_servant method on the Server object, shown in the following figure.

   • In Java, the WLE system instantiates the SimpleFactory object dynamically.
     

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.