|
|
This topic includes the following sections:
The WLE 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:
Overview of the WLE CORBA Programming Features
The WLE product comes with two IDL compilers that make object development easier:
IDL Compilers
For a description of how to use the IDL compilers, see Developing WebLogic Enterprise (WLE) CORBA Applications.
For a description of the idl, idltojava,
and m3idltojava
commands, see WLE Reference in the WebLogic Enterprise online documentation.
Table 2-1 lists the commands that the WLE product provides for developing CORBA application components and managing the Interface Repository.
Development Commands
Table 2-1 WLE CORBA Development Commands
For a description of how to use the development commands to develop client and server applications, see Developing WebLogic Enterprise (WLE) CORBA Applications.
For a description of the development commands, see WLE Commands Reference in the WebLogic Enterprise online documentation.
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 2-2 to perform administration tasks for your WLE application.
Administration Tools
Table 2-2 WLE 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 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 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 manual intervention.
For information about the Administration commands, see WLE Commands Reference and Administration Guide 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 AdminAPI, see BEA TUXEDO Reference in the WebLogic Enterprise online documentation.
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 2-2 shows the 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 WLE ActiveX Client Developer's Guide in the WebLogic Enterprise online documentation.
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:
Figure 2-1 Administration Console Main Window
ActiveX Application Builder
Figure 2-2 ActiveX Application Builder Main Window
WLE CORBA Object 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 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 How WLE CORBA Client and Server Applications Interact in the WebLogic Enterprise online documentation.
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 Using Security in the WebLogic Enterprise online documentation.
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 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.
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 Using DII in the WebLogic Enterprise online documentation.
The WLE software provides environmental objects for the following programming environments:
This section provides an introduction to the following WLE components:
WLE CORBA Components
Figure 2-3 illustrates the components in a WLE application.
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 using one of the following URL address formats:
Figure 2-3 Components in a WLE Application
Bootstrap Object
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 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 2-4 illustrates how the Bootstrap object works in a WLE domain.
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 Guide and the description of the ISL command in the WLE Reference in the WebLogic Enterprise online documentation.
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 (JDK) from Sun Microsystems, Inc.
Figure 2-5 shows the relationship between an ORB, a client application, and a server application.
When the client application uses IIOP to send a request to the domain, the ORB performs the following functions:
Figure 2-4 How the Bootstrap Object Works in a WLE Domain
IIOP Listener/Handler
ORB
Figure 2-5 The ORB in a Client/Server Environment
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 WLE 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 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:
TP Framework
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 WLE 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.
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.
The interaction between WLE CORBA client and server applications includes the following steps:
Figure 2-6 The TP Framework
How WLE CORBA Client and Server Applications Interact
The following topics describe what happens during each step.
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:
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.
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 using TUXEDO authentication, the client application:
Note: For information about using certificate-based authentication, see Using Security in the WebLogic Enterprise online documentation.
The 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.
If the SimpleFactory object is not active, what happens next depends on the programming language in which the server application is implemented:
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.
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 WLE 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, shown in the following figure.
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.
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|