Overview

This Help topic provides an overview of the ActiveX client application development process and the concepts that you need to understand before you develop ActiveX client applications for the BEA Tuxedo CORBA environment.

The following sections are included:

• What Is ActiveX?

• How It Works

• Naming Conventions for ActiveX Views

• OMG IDL

• Interface Repository

 

---

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 a 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 ActiveX Application Builder to create Automation bindings for the interfaces.

The combination of the ActiveX client application and the generated binding creates the ActiveX view of the object.

 

---

How It Works

The BEA ActiveX Client makes it possible for ActiveX client applications to interact with CORBA objects in a BEA Tuxedo domain. The ActiveX client application uses the Automation environmental objects to access CORBA objects in the BEA Tuxedo domain. The ActiveX Client creates ActiveX views of the CORBA objects. The ActiveX views of CORBA objects convert and forward all requests they receive from ActiveX client applications to the appropriate CORBA object in the BEA Tuxedo domain.

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.

The Application Builder is the primary user interface to the ActiveX Client. The Application Builder can be used to select which CORBA objects are available to desktop applications, to create ActiveX views of the CORBA objects, and to create packages for deploying ActiveX views of CORBA objects to client computers.

Figure  1-1 illustrates how the ActiveX Client works.

Figure 1-1 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:

module University
{
   module Student
     {
       interface Account
           {//Operations and attributes of the Account interface
           };
     };

};

In CORBA, this interface is named University::Student::Account. The ActiveX Client translates this name to DIUniversity_Student_Account for ActiveX.

ActiveX client applications use OLE Automation environmental objects to access CORBA objects in a BEA Tuxedo domain. ActiveX client applications use the BEA ActiveX Client to process requests to CORBA objects. You use the ActiveX 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 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.

Generally, the application designer provides the OMG IDL files for the available CORBA interfaces and operations to the programmer who creates the client applications.

 

---

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.

ActiveX client applications are not aware that they are using the Interface Repository. The BEA ActiveX Client uses CORBA operations to obtain information about CORBA objects from the Interface Repository.

You use the following BEA 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.

 

---

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 Server Listener/Handler (ISL/ISH) and is identified by a name. One client application can connect to multiple BEA Tuxedo domains using different Bootstrap objects. For each BEA Tuxedo domain, a client application can get a FactoryFinder object, an InterfaceRepository object, a SecurityCurrent object, and a TransactionCurrent object, which correspond to the services offered within the BEA Tuxedo domain. For a description of the Bootstrap object, the FactoryFinder object, the InterfaceRepository object, the SecurityCurrent object, and the TransactionCurrent object, see Environmental Objects in this chapter.

Note: Only one TransactionCurrent object and one SecurityCurrent object can exist at the same time, and they must be associated with the same Bootstrap object.

Figure  1-2 illustrates how an BEA Tuxedo domain works.

Figure 1-2 How a BEA Tuxedo Domain Works

 

 

---

Environmental Objects

The BEA Tuxedo software provides a set of environmental objects that set up communication between client applications and server applications in a particular BEA Tuxedo domain. The BEA Tuxedo software provides the following environmental objects:

• Bootstrap

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

• FactoryFinder

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

• SecurityCurrent

  This object can be used to log a client application into a BEA Tuxedo domain with the proper security. The BEA Tuxedo software provides an implementation of the CORBAservices Security Service.

• TransactionCurrent

  This object allows a client application to participate in a transaction. The BEA Tuxedo software provides an implementation of the CORBAservices Object Transaction Service (OTS).

• UserTransaction

  This object allows a client application to participate in a transaction. The BEA Tuxedo software provides an implementation of the Sun Microsystems, Inc. Java Transaction Application Programming Interface (JTA API). This object is supported with Java client and server applications only.

• 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.

The BEA Tuxedo software provides environmental objects for the Automation programming environment.

Bootstrap Object

The client application creates a Bootstrap object. A list of ISLs/ISHs can be supplied either as a parameter or via the TOBJADDR environmental variable or Java property. A single ISL/ISH 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, TransactionCurrent, SecurityCurrent, and InterfaceRepository.

Figure  1-3 illustrates how the Bootstrap object works in a BEA Tuxedo domain.

Figure 1-3 How the Bootstrap Object Works

 

Factories and the FactoryFinder Object

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 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 client applications are those that are registered with the FactoryFinder object by BEA Tuxedo server applications at startup.

The 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. Client applications query the FactoryFinder object for object references to the desired factory.

3. Client applications call the factory to obtain an object reference to the CORBA object.

Figure  1-4 illustrates the client application interaction with the FactoryFinder object.

Figure 1-4 How Client Applications Use the FactoryFinder Object

 

Naming Conventions and BEA Tuxedo Extensions to the FactoryFinder Object

The factories available to client applications are those that are registered with the FactoryFinder object by the BEA Tuxedo server applications at startup. Factories are registered using a key consisting of the following fields:

• The Interface RepositoryId of the factory's interface

• An object reference to the factory

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 Naming 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 client applications to locate factories by extending the interface with simpler method calls.

The extensions are intended to provide the following simplifications for the client application:

• Let the client application locate factories by ID, using a simple string parameter for the ID field. This reduces the work needed by the 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 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 client applications. This method accepts a simple string for factory ID as input and returns one factory to the client application. The 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 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.

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 client application and the server application.

SecurityCurrent Object

The SecurityCurrent object is a BEA Tuxedo implementation of the CORBAservices Security Service. The BEA Tuxedo security model is based on authentication. You use the SecurityCurrent object to specify the appropriate level of security. The following levels of authentication are provided:

• TOBJ_NOAUTH

  No authentication is needed; however, the client application can still authenticate itself, and must specify a username and a client name, but no password is required.

• TOBJ_SYSAUTH

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

• TOBJ_APPAUTH

  The client application must provide information in addition to that which is required by TOBJ_SYSAUTH. If the default BEA Tuxedo CORBA authentication service is used in the BEA Tuxedo domain configuration, the client application must provide a user password; otherwise, the client application provides authentication data that is interpreted by the custom authentication service in the BEA Tuxedo domain.

Note: If a client application is not authenticated and the security level is TOBJ_NOAUTH, the ISL/ISH of the BEA Tuxedo domain registers the client application with the username and client application name sent to the ISL/ISH.

In the BEA Tuxedo CORBA, 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.

TransactionCurrent Object

The TransactionCurrent object is a BEA Tuxedo implementation of the CORBAservices Object Transaction Service. The TransactionCurrent object maintains a transactional context for the current session between the client application and the server application. Using the TransactionCurrent object, the 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 BEA Tuxedo application will handle transactions. A transaction policy for each interface is then defined in an Implementation Configuration File (ICF). The transaction policies are:

• Never

  This 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 implementation with this policy is involved in a transaction. An AUTOTRAN policy specified in the UBBCONFIG file for the interface is ignored.

• Optional (The is the default transaction_policy.)

  This interface may be transactional. Objects can be involved in a transaction if the request is transactional. If the AUTOTRAN parameter is specified in the UBBCONFIG file for the interface, AUTOTRAN is on.

• Always

  This 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 transaction is committed when the method ends. (This is the same behavior that results from specifying AUTOTRAN for an object with the optional transaction policy, except that no administrative configuration is necessary to achieve this behavior, and it cannot be overridden by administrative configuration.)

• Ignore

  This interface is not transactional. This interface can be included in a transaction, however, the AUTOTRAN policy specified for this implementation in the UBBCONFIG file is ignored.

For information about using the TransactionCurrent object in client applications, see Using Transactions.

InterfaceRepository Object

The InterfaceRepository object returns information about the Interface Repository in a specific 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.

ActiveX client applications are not aware they are using the InterfaceRepository object. ActiveX client applications use the Bootstrap object to obtain a reference to the InterfaceRepository object.