![]() |
![]() |
|
|
CORBA Client Application Development Concepts
This topic reviews the types of client applications supported by the CORBA environment in the BEA Tuxedo product and introduces the concepts that you need to understand before you develop CORBA client applications.
This topic includes the following sections:
Overview of Client Applications
The BEA Tuxedo software supports the following types of client applications:
This type of client application uses C++ environmental objects to access the CORBA objects in a BEA Tuxedo domain and the CORBA C++ Object Request Broker (ORB) to process requests to CORBA objects. Use the BEA Tuxedo development commands to build CORBA C++ client applications.CORBA C++ client applications now support object by value and the CORBA Interoperable Naming Service (INS).
This type of client application uses the Java environmental objects to access CORBA objects in an BEA Tuxedo domain. However, these client applications use an ORB product other than the BEA Tuxedo CORBA ORB to process requests to CORBA objects. CORBA Java client applications are built using the ORB product's Java development tools. The BEA Tuxedo software supports interoperability with the Sun Java Development Kit (JDK) Java client.
Note: See Installing the BEA Tuxedo System for the specific versions of supported software.
This type of client application uses the Automation environmental objects to access CORBA objects in a BEA Tuxedo domain, and the BEA ActiveX Client to process requests to CORBA objects. Use the Application Builder to select the CORBA interfaces that are available to ActiveX client applications, to create ActiveX views of the CORBA interfaces, and to create packages for deploying ActiveX views of CORBA interfaces to client machines. These client applications are built using an Automation development tool such as Visual Basic or PowerBuilder.
OMG IDL
With any distributed application, the client/server application needs some basic information to communicate. For example, the CORBA client application needs to know which operations it can request, and the arguments to the operations.
You use the Object Management Group (OMG) Interface Definition Language (IDL) to describe available CORBA interfaces to client applications. An interface definition written in OMG IDL completely defines the CORBA interface and fully specifies each operation's arguments. OMG IDL is a purely declarative language. This means that it contains no implementation details. Operations specified in OMG IDL can be written in and invoked from any language that provides CORBA bindings. C++ and Java are two of the supported languages.
Generally, the application designer provides the OMG IDL files for the available CORBA interfaces and operations to the programmer who creates the client applications.
OMG IDL-to-C++ Mapping
The BEA Tuxedo software conforms to The Common Object Request Broker:Architecture and Specification, Version 2.3. For complete information about the OMG IDL-to-C++ mapping, see The Common Object Request Broker:Architecture and Specification, Version 2.3.
OMG IDL-to-Java Mapping
The BEA Tuxedo software conforms to The Common Object Request Broker:Architecture and Specification, Version 2.2. For complete information about the OMG IDL-to-Java mapping, see The Common Object Request Broker:Architecture and Specification, Version 2.2.
OMG IDL-to-COM Mapping
The BEA Tuxedo software conforms to the OMG IDL to COM mapping as defined in the Common Object Request Broker:Architecture and Specification, Version 2.3. For complete information about the OMG IDL to COM mapping, see The Common Object Request Broker:Architecture and Specification, Version 2.3.
Static and Dynamic Invocation
The CORBA ORB in the BEA Tuxedo product supports two types of client/server invocations: static and dynamic. In both cases, the CORBA client application performs a request by gaining access to a reference for a CORBA object and invoking the operation that satisfies the request. The CORBA server application cannot tell the difference between static and dynamic invocations.
When using static invocation, the CORBA client application invokes operations directly on the client stubs. Static invocation is the easiest, most common type of invocation. The stubs are generated by the IDL compiler. Static invocation is recommended for applications that know at compile time the particulars of the operations they need to invoke and can process within the synchronous nature of the invocation. Figure 1-1 illustrates static invocation.
Figure 1-1 Static Invocation
While dynamic invocation is more complicated, it enables your CORBA client application to invoke operations on any CORBA object without having to know the CORBA object's interfaces at compile time. Figure 1-2 illustrates dynamic invocation. Figure 1-2 Dynamic Invocation
When using dynamic invocation, the CORBA client application can dynamically build operation requests for a CORBA object interface that has been stored in the Interface Repository. CORBA server applications do not require any special design to be able to receive and handle dynamic invocation requests. Dynamic invocation is generally used when the CORBA client application requires deferred synchronous communication, or by dynamic client applications when the nature of the interaction is undefined. For more information about using dynamic invocation, see Using the Dynamic Invocation Interface
Client Stubs
Client stubs provide the programming interface to operations that a CORBA object can perform. A client stub is a local proxy for the CORBA object. Client stubs provide a mechanism for performing a synchronous invocation on an object reference for a CORBA object. The CORBA client application does not need special code to deal with the CORBA object or its arguments; the client application simply treats the stub as a local object.
A CORBA client application must have a stub for each interface it plans to use. You use the idl command (or your Java ORB product's equivalent command) to generate a client stub from the OMG IDL definition of the CORBA interface. The command generates a stub file and a header file that describe everything that you need if you want to use the client stub from a programming language, such as C++ or Java. You simply invoke a method from within your CORBA client application to request an operation on the CORBA object.
Interface Repository
The Interface Repository contains descriptions of a CORBA object's interfaces and operations. The information stored in the Interface Repository is equivalent to the information defined in an OMG IDL file, but the information is accessible programmatically at run time. CORBA client applications use the Interface Repository for the following reasons:
CORBA client applications that use static invocation do not access the Interface Repository at run time. The information about the CORBA object's interfaces is included in the client stub.
You use the following BEA Tuxedo development commands to manage the Interface Repository:
For a description of the development commands for the Interface Repository, see the BEA Tuxedo Command Reference.
Domains
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 CORBA client application can connect to multiple BEA Tuxedo domains using different Bootstrap objects. For each BEA Tuxedo domain, a CORBA client application can get objects which correspond to the services (for example, transactions, security, naming, events) offered within the BEA Tuxedo domain. For a description of the Bootstrap object and the CORBA services available in a BEA Tuxedo domain, see Environmental Objects.
Note: Only one environmental object per service can exist at the same time and the environmental objects must be associated with the same Bootstrap object.
Figure 1-3 illustrates how a BEA Tuxedo domain works.
Figure 1-3 How a BEA Tuxedo Domain Works
Environmental Objects
The BEA Tuxedo software provides a set of environmental objects that set up communication between CORBA client and server applications in a BEA Tuxedo domain and provide access to the CORBA services provided by the domain. The BEA Tuxedo software provides the following environmental objects:
This object establishes communication between a CORBA client application and a BEA Tuxedo domain. It also obtains object references for the other environmental objects in the BEA Tuxedo domain.
Note: Third-party client ORBs can also use the CORBA Interoperable Naming Service (INS) to access the services within a BEA Tuxedo domain. For more information, see the CORBA Bootstrap Object Programming Reference topic in the CORBA Programming Reference.
This CORBA object locates a factory, which in turn can create object references for CORBA objects.
This CORBA object contains interface definitions for all the available CORBA interfaces and the factories used to create object references to the CORBA interfaces.
This BEA-proprietary object is used to log a CORBA client application into a BEA Tuxedo domain with the proper security credentials. The BEA Tuxedo software provides an implementation of the CORBAservices Security Service.
This BEA-proprietary object allows a CORBA client application to participate in a transaction. The TransactionCurrent object provides an implementation of the CORBAservices Object Transaction Service (OTS).
This CORBA object allows a CORBA client application to obtain a reference to the event channel factory (CosNotifyChannelAdmin::EventChannelFactory) in the CosNotification Service. In turn, the EventChannelFactory is used to locate the Notification Service channel.
In addition, a Tobj_SimpleEventsService object is provided. This BEA-proprietary object allows a CORBA client application to obtain a reference to a BEA-proprietary events interface. The events interface passes standard, structured events as defined by the CosNotification Service, however, the API has been simplified for easier use.
This CORBA object allows a CORBA client application to use a namespace to resolve object references. The BEA Tuxedo software provides an implementation of the CORBAservices Name Service.
The BEA Tuxedo software provides environmental objects for the following programming environments:
Bootstrap Object
A CORBA client application creates a Bootstrap object which defines the address of an IIOP Listener/Handler. The IIOP Listener/Handler is the access point to a BEA Tuxedo domain and the CORBA services provided by the domain. A list of IIOP Listener/Handlers can be supplied either as a parameter or via the TOBJADDR environmental variable or a Java property. A single IIOP Listener/Handler is specified as follows:
//host:port
For example, //myserver:4000
Once the Bootstrap object is instantiated, the resolve_initial_references method is invoked, passing in a string ID, to obtain a reference to an available object. The valid values for the string ID are FactoryFinder, Interface Repository, SecurityCurrent, TransactionCurrent, NotificationService, TObj_SimpleEventsService, and NameService.
Figure 1-4 illustrates how the Bootstrap object works in a BEA Tuxedo domain.
Figure 1-4 How the Bootstrap Object Works
Third-party client ORBs can also use the CORBA Interoperable Naming Service (INS) mechanism to gain access to a BEA Tuxedo domain and its services. The Interoperable Naming Service allows third-party client ORBs to use their ORB's resolve_initial_references() function to access CORBA services provided by the BEA Tuxedo domain and use stubs generated from standard OMG IDL to act on the instances returned from the domain. For more information about using the Interoperable Naming Service, see the CORBA Programming Reference. Factories and the FactoryFinder Object CORBA client applications get object references to CORBA objects from a factory. A factory is any CORBA object that returns an object reference to another CORBA object and registers itself with the FactoryFinder object. To use a CORBA object, the CORBA client application must be able to locate the factory that creates an object reference for the CORBA object. The BEA Tuxedo software offers the FactoryFinder object for this purpose. The factories available to CORBA client applications are those that are registered with the FactoryFinder object by CORBA server applications at startup. The CORBA client application uses the following sequence of steps to obtain a reference to a CORBA object:
Figure 1-5 illustrates the CORBA client application interaction with the FactoryFinder object.
Figure 1-5 How Client Applications Use the FactoryFinder Object
Naming Conventions and BEA Tuxedo Extensions to the FactoryFinder Object The factories available to CORBA client applications are those that are registered with the FactoryFinder object by the CORBA server applications at startup. Factories are registered using a key consisting of the following fields:
The FactoryFinder object used by the BEA Tuxedo software is defined in the CORBAservices Life Cycle Service. The BEA Tuxedo software implements extensions to the COS::LifeCycle::FactoryFinder interface that make it easier for client applications to locate a factory using the FactoryFinder object.
The CORBAservices Life Cycle Service specifies the use of names as defined in the CORBAservices Naming Service to locate factories with the COS::LifeCycle::FactoryFinder interface. These names consist of a sequence of NameComponent structures, which consist of ID and kind fields.
The use of CORBA names to locate factories is cumbersome for client applications; it involves many calls to build the appropriate name structures and assemble the CORBA Name Service name that must be passed to the find_factories method of the COS::LifeCycle::FactoryFinder interface. Also, since the method can return more than one factory, client applications must manage the selection of an appropriate factory and the disposal of unwanted object references.
The FactoryFinder object is designed to make it easier for CORBA client applications to locate factories by extending the interface with simpler method calls.
The extensions are intended to provide the following simplifications for the CORBA client application:
The most straightforward application design can be achieved by using the Tobj::FactoryFinder::find_one_factory_by_id method in CORBA client applications. This method accepts a simple string for factory ID as input and returns one factory to the CORBA client application. The CORBA client application is freed from the necessity of manipulating name components and selecting among many factories.
To use the Tobj::FactoryFinder::find_one_factory_by_id method, the application designer must establish a naming convention for factories that CORBA client applications can use to easily locate factories for specific CORBA object interfaces. Ideally, this convention should establish some mnemonic types for factories that supply object references for certain types of CORBA object interfaces. Factories are then registered using these conventions. For example, a factory that returns an object reference for Student objects might be called StudentFactory. For more information about registering factories with the FactoryFinder object, see Creating CORBA Server Applications.
It is recommended that you either use the actual interface ID of the factory in the OMG IDL file, or specify the factory ID as a constant in the OMG IDL file. This technique ensures naming consistency between the CORBA client application and the CORBA server application.
InterfaceRepository Object
The InterfaceRepository object returns information about the Interface Repository in a BEA Tuxedo domain. The InterfaceRepository object is based on the CORBA definition of an Interface Repository. It offers the proper set of CORBA interfaces as defined by the Common Request Broker Architecture and Specification Version 2.2.
CORBA client applications that use the Dynamic Invocation Interface (DII) need to access the Interface Repository programmatically. The exact steps taken to access the Interface Repository depend on whether the CORBA client application is seeking information about a specific CORBA interface or browsing the Interface Repository to find an interface. In either case, the CORBA client application can only read to the Interface Repository, it cannot write to the Interface Repository.
Before a CORBA client application using DII can browse the Interface Repository in an BEA Tuxedo domain, the CORBA client application needs to obtain an object reference for the InterfaceRepository object in that domain. CORBA client applications using DII use the Bootstrap object to obtain the object reference.
ActiveX client applications also use the Interface Repository. Like CORBA client applications, ActiveX client applications use the Bootstrap object to obtain a reference to the InterfaceRepository object.
For information about using the InterfaceRepository object in CORBA client applications that use DII, see Using the Dynamic Invocation Interface For a description of the InterfaceRepository object, see the CORBA Programming Reference.
SecurityCurrent Object
CORBA C++, CORBA Java, and ActiveX client applications use security to authenticate themselves to the BEA Tuxedo domain. Authentication is the process of verifying the identity of a client application. By entering the correct logon information, the client application authenticates itself to the BEA Tuxedo domain. The BEA Tuxedo software uses authentication as defined in the CORBAservices Security Service and provides extensions for ease of use.
CORBA client applications use the SecurityCurrent object to log on to the BEA Tuxedo domain and pass security credentials to the domain. The SecurityCurrent object is an BEA Tuxedo implementation of the CORBAservices Security Service. The CORBA security model in the BEA Tuxedo product is based on authentication.
You use the SecurityCurrent object to specify the appropriate level of security for the domain. The following levels of authentication are provided:
No authentication is needed; however, the CORBA client application may still authenticate itself, and may specify a username and a client application name, but no password.
The CORBA client application must authenticate itself to the BEA Tuxedo domain and must specify a username, client application name, and application password.
In addition to the TOBJ_SYSAUTH information, the CORBA client application must provide application-specific information. If the default BEA Tuxedo authentication service is used in the application configuration, the CORBA client application must provide a user password; otherwise, the CORBA client application provides authentication data that is interpreted by the custom authentication service in the application.
Note: If a CORBA client application is not authenticated and the security level is TOBJ_NOAUTH, the IIOP Listener/Handler of the BEA Tuxedo domain registers the CORBA client application with the username and client application name sent to the IIOP Listener/Handler.
In the BEA Tuxedo software, only the PrincipalAuthenticator and Credentials properties on the SecurityCurrent object are supported.
For information about using the SecurityCurrent object in client applications, see Using Security in CORBA Applications. For a description of the SecurityLevel1::Current and SecurityLevel2::Current interfaces, refer to the CORBA Programming Reference.
TransactionCurrent Object
The TransactionCurrent object is an BEA Tuxedo implementation of the CORBAservices Object Transaction Service. The TransactionCurrent object maintains a transactional context for the current session between the CORBA client application and the CORBA server application. Using the TransactionCurrent object, the CORBA client application can perform transactional operations, such as initiating and terminating a transaction and getting the status of a transaction.
Transactions are used on a per-interface basis. During design, the application designer decides which interfaces within a CORBA application will handle transactions. A transaction policy for each interface is then defined in an Implementation Configuration File (ICF). The transaction policies are:
The interface is not transactional. Objects created for this interface can never be involved in a transaction. The BEA Tuxedo software generates an exception (INVALID_TRANSACTION) if an interface with this policy is involved in a transaction.
The interface may be transactional. Objects can be involved in a transaction if the request is transactional.
The interface must always be part of a transaction. If the interface is not part of a transaction, a transaction will be automatically started by the TP framework.
The interface is not transactional. The interface can be included in a transaction, however, the AUTOTRAN policy specified for this interface in the UBBCONFIG file is ignored.
For information about using the TransactionCurrent object in CORBA client applications, see Using CORBA Transactions. For a description of the TransactionCurrent object, see the CORBA Programming Reference.
NotificationService and Tobj_SimpleEventsService Objects
The NotificationService and Tobj_SimpleEventsService objects provide access to a CORBA event service. The event service in the CORBA environment of the BEA Tuxedo product offers similar capabilities to those of the EventBroker in the ATMI environment. However, the CORBA event service offers a programming model and interface that is natural for CORBA programmers.
The event service receives event posting messages, filters them, and distributes them to subscribers. A poster is a CORBA application that detects when an event of interest has occurred and reports (posts) it to the event service. A subscriber is a CORBA application that requests some notification action to be taken when an event of interest is posted.
The CORBA event service provides two sets of interfaces:
Both sets of interfaces pass standard, structured events as defined by the CORBA Notification Service specification. The two sets of interfaces are compatible with each other; that is, events posted using the NotificationService interfaces can be subscribed to by the Tobj_SimpleEventsService interfaces and vice versa.
For information about using the NotificationServer and Tobj_SimpleEventsService objects, see Using the CORBA Notification Service.
NameService Object
The NameService object provides access to a CORBA Name Service which allows CORBA server applications to advertise object references using logical names. CORBA client applications can then locate an object by asking the CORBA Name Service to look up the name.
The CORBA Name Service provides:
For information about using the NameService object in a CORBA client application, see Using the CORBA Name Service.
Concepts for ActiveX Client Applications
The following sections describe concepts that are specific to ActiveX client applications.
What Is ActiveX?
ActiveX is a set of technologies from Microsoft that enables software components to interact with one another in a networked environment, regardless of the language in which the components were created. ActiveX is built on the Component Object Model (COM) and integrates with Object Linking and Embedding (OLE). OLE provides an architecture for document embedding. Automation is the part of COM that allows applications such as Visual Basic, Delphi, and PowerBuilder to manipulate Automation objects, ActiveX controls, and ActiveX documents.
The BEA ActiveX Client provides interoperability between the BEA Tuxedo and COM object systems. The ActiveX Client transforms the interfaces of CORBA objects in a BEA Tuxedo domain into methods on Automation objects.
Views and Bindings
ActiveX client applications use views of CORBA interfaces. Views represent the CORBA interfaces in an BEA Tuxedo domain locally as Automation objects. To use an ActiveX view of a CORBA object (referred to as an ActiveX view), you need to create a binding for ActiveX. The binding describes the interface of a CORBA object to ActiveX. The interfaces of the CORBA objects are loaded into the Interface Repository. You then use the BEA Application Builder to create Automation bindings for the interfaces.
The Application Builder is a development tool that you use along with a client development tool (such as Visual Basic) to select which CORBA objects in a BEA Tuxedo domain you want your ActiveX client application to interact with. For a description of the Application Builder and how it works, see the online help that is integrated into the Application Builder graphical user interface (GUI).
The combination of the ActiveX client application and the generated binding creates the ActiveX view of the object.
For a complete description of creating and using ActiveX client applications, see Creating ActiveX Client Applications
Figure 1-6 illustrates how the ActiveX Client works.
Figure 1-6 How the ActiveX Client Works
Naming Conventions for ActiveX Views Naming conventions describe an algorithm for mapping CORBA interfaces to ActiveX to avoid type and variable name conflicts. Naming conventions also indicate how to use a given object. The names of all ActiveX methods begin with DI. The ActiveX Client observes this naming convention when it creates Automation bindings for CORBA interfaces. If a CORBA interface has the name Account, the Automation binding for that interface has the name DIAccount. CORBA interface names are often scoped within nested levels known as modules; however, in ActiveX, there is no scoping. To avoid name conflicts, the ActiveX Client exposes a CORBA interface into ActiveX with the name of the different scopes prepended to the name of the interface. For example, a CORBA interface named Account is defined in the OMG IDL file as: }; In CORBA, this interface is named University::Student::Account. The ActiveX Client translates this name to DIUniversity_Student_Account for ActiveX.
module University
{
module Student
{
interface Account
{//Operations and attributes of the Account interface
};
};
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|