Creating CORBA Client Applications

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

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.

Notes: The BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.
Note: Technical support for third party CORBA Java ORBs should be provided by their respective vendors. BEA Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.

This topic includes the following sections:

 


Overview of Client Applications

The BEA Tuxedo software supports the following types of client applications:

 


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

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

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

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:

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

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:

  1. Once the Bootstrap object is created, the resolve_initial_references method is invoked to obtain the reference to the FactoryFinder object.
  2. CORBA client applications query the FactoryFinder object for object references to the desired factory.
  3. CORBA client applications then call the factory to obtain an object reference to the 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

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.

AFor 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++ 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:

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:

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.


  Back to Top       Previous  Next