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.
•
•
Note: See Installing the Oracle Tuxedo System for the specific versions of supported software.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.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.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.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 InvocationWhile 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 InvocationWhen 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.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.
• 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.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.Figure 1‑3 illustrates how an Oracle Tuxedo domain works.Figure 1‑3 How an Oracle Tuxedo Domain Works
Note: 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).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.
•
• 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:For example, //myserver:4000Once 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 WorksThird-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.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.
1. Once the Bootstrap object is created, the resolve_initial_references method is invoked to obtain the reference to the FactoryFinder object.
3. Figure 1‑5 illustrates the CORBA client application interaction with the FactoryFinder object.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 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.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.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.
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.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.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 Oracle Tuxedo software generates an exception (INVALID_TRANSACTION) if an interface with this policy is involved in a transaction.
•
•
• 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.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 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.For information about using the NameService object in a CORBA client application, see Using the CORBA Name Service.