CORBA Client Application Development Concepts

This topic reviews the types of client applications supported by the CORBA environment in the Oracle Tuxedo product and introduces the concepts that you need to understand before you develop CORBA client applications.

Notes:

The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All Oracle Tuxedo CORBA Java client and Oracle 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.

Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle 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

•

OMG IDL

•	Static and Dynamic Invocation

•	Client Stubs

•	Interface Repository

•

Domains

•	Environmental Objects

Overview of Client Applications

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

•

CORBA C++

This type of client application uses C++ environmental objects to access the CORBA objects in an Oracle Tuxedo domain and the CORBA C++ Object Request Broker (ORB) to process requests to CORBA objects. Use the Oracle 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).

Note:

See Installing the Oracle Tuxedo System for the specific versions of supported software.

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 Oracle 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 Oracle 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 Oracle 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 Oracle 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 dynamic invocation use the Interface Repository to learn about a CORBA object’s interfaces, and to invoke operations on the object.

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 Oracle Tuxedo development commands to manage the Interface Repository:

•	The idl2ir command populates the Interface Repository with CORBA interfaces. This command creates an Interface Repository if an Interface Repository does not exist. Also use this command to update the CORBA interfaces in the Interface Repository.

•	The ir2idl command creates an OMG IDL file from the contents of the Interface Repository.

•	The irdel command deletes CORBA interfaces from the Interface Repository.

For a description of the development commands for the Interface Repository, see the Oracle Tuxedo Command Reference.

Domains

A domain is a way of grouping objects and services together as a management entity. An Oracle Tuxedo domain has at least one IIOP Listener/Handler and is identified by a name. One CORBA client application can connect to multiple Oracle Tuxedo domains using different Bootstrap objects. For each Oracle Tuxedo domain, a CORBA client application can get objects which correspond to the services (for example, transactions, security, naming, events) offered within the Oracle Tuxedo domain. For a description of the Bootstrap object and the CORBA services available in an Oracle 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 an Oracle Tuxedo domain works.

Figure 1‑3 How an Oracle Tuxedo Domain Works

Environmental Objects

The Oracle Tuxedo software provides a set of environmental objects that set up communication between CORBA client and server applications in an Oracle Tuxedo domain and provide access to the CORBA services provided by the domain. The Oracle Tuxedo software provides the following environmental objects:

•

Bootstrap

This object establishes communication between a CORBA client application and an Oracle Tuxedo domain. It also obtains object references for the other environmental objects in the Oracle Tuxedo domain.

Note:

Third-party client ORBs can also use the CORBA Interoperable Naming Service (INS) to access the services within an Oracle Tuxedo domain. For more information, see the “CORBA Bootstrap Object Programming Reference” topic in the CORBA Programming Reference.

•	FactoryFinder

This CORBA object locates a factory, which in turn can create object references for CORBA objects.

•	InterfaceRepository

This CORBA object contains interface definitions for all the available CORBA interfaces and the factories used to create object references to the CORBA interfaces.

•	SecurityCurrent

This Oracle-proprietary object is used to log a CORBA client application into an Oracle Tuxedo domain with the proper security credentials. The Oracle Tuxedo software provides an implementation of the CORBAservices Security Service.

•	TransactionCurrent

This Oracle-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).

•	NotificationService

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 Oracle-proprietary object allows a CORBA client application to obtain a reference to an Oracle-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.

•	NameService

This CORBA object allows a CORBA client application to use a namespace to resolve object references. The Oracle Tuxedo software provides an implementation of the CORBAservices Name Service.

The Oracle Tuxedo software provides environmental objects for the following programming environments:

•

C++

•

Java

•	Automation

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 an Oracle 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 an Oracle 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 an Oracle 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 Oracle 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 Oracle 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

Naming Conventions and Oracle 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 Interface Repository ID of the factory’s interface

•	An object reference to the factory

The FactoryFinder object used by the Oracle Tuxedo software is defined in the CORBAservices Life Cycle Service. The Oracle 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:

•	Let the CORBA client application locate factories by ID, using a simple string parameter for the ID field. This reduces the work needed by the CORBA client application to build name structures.

•	Permit the FactoryFinder object to implement a load balancing scheme by choosing from a pool of available factories.

•	Provide methods that return one object reference to a factory, instead of a sequence of object references. This eliminates the need for CORBA client applications to provide code to handle the selection of a single factory from a sequence, and then dispose of the unneeded references.

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.

Interface Repository Object

The InterfaceRepository object returns information about the Interface Repository in an Oracle 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 Oracle 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 Oracle 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 Oracle Tuxedo domain. The Oracle 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 Oracle Tuxedo domain and pass security credentials to the domain. The SecurityCurrent object is an Oracle Tuxedo implementation of the CORBAservices Security Service. The CORBA security model in the Oracle 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:

•	TOBJ_NOAUTH

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.

•	TOBJ_SYSAUTH

The CORBA client application must authenticate itself to the Oracle Tuxedo domain and must specify a username, client application name, and application password.

•	TOBJ_APPAUTH

In addition to the TOBJ_SYSAUTH information, the CORBA client application must provide application-specific information. If the default Oracle 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 Oracle Tuxedo domain registers the CORBA client application with the username and client application name sent to the IIOP Listener/Handler.

In the Oracle 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 Oracle 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:

•

Never

The interface is not transactional. Objects created for this interface can never be involved in a transaction. The Oracle Tuxedo software generates an exception (INVALID_TRANSACTION) if an interface with this policy is involved in a transaction.

•

Optional

The interface may be transactional. Objects can be involved in a transaction if the request is transactional.

•

Always

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.

•

Ignore

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 Oracle 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:

•	The NotificationService object provides a minimal subset of the CORBA-based Notification Service interfaces (referred to as the CosNotification Service interface).

•	The Tobj_SimpleEventsService object provides Oracle-proprietary interfaces designed to be easy to use.

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:

•	An implementation of the Object Management Group (OMG) Interoperable Name Service (INS) specification.

•	Application programming interfaces (APIs) for mapping object references into an hierarchical naming structure (referred to as a namespace).

•	Commands for displaying bindings and for binding and unbinding naming context objects and application objects into the namespace.

For information about using the NameService object in a CORBA client application, see Using the CORBA Name Service.