|
|
|
|
|
|
The WLE software supports the following types of client applications:
Overview of Client Applications
This type of client application uses the C++ environmental objects to access the CORBA objects in an WLE domain, and the WLE Object Request Broker (ORB) to process requests to CORBA objects. Use the WLE development commands to build CORBA C++ client applications.
This type of client application uses the Java environmental objects to access CORBA objects in an WLE domain. However, these client applications use an ORB product other than the WLE ORB to process requests to CORBA objects. CORBA Java client applications are built using the ORB product's Java development tools. The WLE software supports interoperability with the following:
This type of client application uses the Automation environmental objects to access CORBA objects in an WLE 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.
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. 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.
The WLE software conforms to The Common Object Request Broker:Architecture and Specification, Version 2.2. For complete information about the OMG IDL to C++ mapping, see The Common Object Request Broker:Architecture and Specification, Version 2.2, Revised: February, 1998.
The WLE 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, Revised: February, 1998.
The WLE software conforms to the OMG COM/CORBA Internetworking Specification, Version 1.1. The mapping of COM data types is included in the OMG COM/CORBA Internetworking Specification, Version 1.1.
The WLE Object Request Broker (ORB) supports two types of client/server invocations: static and dynamic. In both cases, the client application performs a request by gaining access to an object reference for a server application and invoking the operation that satisfies the request. The server application cannot tell the difference between static and dynamic invocations.
When using static invocation, the 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.
While dynamic invocation is more complicated it enables your 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.
When using dynamic invocation, the client application can dynamically build operation requests for a CORBA object interface that has been stored in the Interface Repository. 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 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 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 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 client application must have a stub for each interface it plans to use. You use the idl
command (or your Java 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 client application to request an operation in the server application.
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. Client applications use the Interface Repository for the following reasons:
OMG IDL
OMG IDL to C++ Mapping
OMG IDL to Java Mapping
OMG IDL to COM Mapping
Static and Dynamic Invocation
Figure 1-1 Static Invocation
Figure 1-2 Dynamic Invocation
Client Stubs
Interface Repository
You use the following WLE development commands to manage the Interface Repository:
For a description of the development commands for the Interface Repository, see the C++ Programming Reference.
A domain is a way of grouping objects and services together as a management entity. An WLE domain has at least one IIOP Listener/Handler and is identified by a name. One client application can connect to multiple WLE domains using different Bootstrap objects. For each WLE 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 WLE 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 topic.
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-3 illustrates how an WLE domain works.
The WLE software provides a set of environmental objects that set up communication between client applications and server applications in a particular WLE domain. The WLE software provides the following environmental objects:
Domains
Figure 1-3 How an WLE Domain Works
Environmental Objects
This object establishes communication between a client application and an WLE domain. It also obtains object references for the other environmental objects in the WLE domain.
This CORBA object locates a factory, which in turn can create object references for CORBA objects.
Thisobject can be used to log a client application into an WLE domain with the proper security. The WLE software provides an implementation of the CORBAservices Security Service.
This object allows a client application to participate in a transaction. The WLE software provides an implementation of the CORBAservices Object Transaction Service (OTS).
This object allows a client application to participate in a transaction. The WLE 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.
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 WLE software provides environmental objects for the following programming environments:
The client application creates a Bootstrap object. A list of IIOP Listener/Handlers can be supplied either as a parameter or via the TOBJADDR
environmental variable or 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, TransactionCurrent, SecurityCurrent, and InterfaceRepository.
Figure 1-4 illustrates how the Bootstrap object works in an WLE domain.
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 WLE software offers the FactoryFinder object for this purpose. The factories available to client applications are those that are registered with the FactoryFinder object by WLE server applications at startup.
The client application uses the following sequence of steps to obtain a reference to a CORBA object:
Bootstrap Object
Figure 1-4 How the Bootstrap Object Works
Factories and the FactoryFinder Object
Figure 1-5 illustrates the client application interaction with the FactoryFinder object.
The factories available to client applications are those that are registered with the FactoryFinder object by the WLE server applications at startup. Factories are registered using a key consisting of the following fields:
The FactoryFinder object used by the WLE software is defined in the CORBAservices LifeCycle Service. The WLE 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:
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. For more information about registering factories with the FactoryFinder object, see Creating C++ Server Applications and Creating Java Server Applications.
It is recommended that you either use the actual interface ID of the factory in the OMG IDL file, or specify the the factory ID as a constant in the OMG IDL file. This technique ensures naming consistency between the client application and the server application.
The SecurityCurrent object is an WLE implementation of the CORBAservices Security Service. The WLE 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:
SecurityCurrent Object
No authentication is needed; however, the client application may still authenticate itself, and may specify a user name and a client application name, but no password.
The client application must authenticate itself to the WLE domain and must specify a user name, client application name, and application password.
In addition to the TOBJ_SYSAUTH information, the client application must provide application-specific information. If the default WLE authentication service is used in the application 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 application.
Note: If a client application is not authenticated and the security level is TOBJ_NOAUTH , the IIOP Listener/Handler of the WLE domain registers the client application with the user name and client application name sent to the IIOP Listener/Handler.
In the WLE 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. For a description of the SecurityLevel1::Current
and SecurityLevel2::Current
interfaces, refer to the C++ Programming Reference or the WLE Javadoc.
The TransactionCurrent object is an WLE 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 an WLE application will handle transactions. A transaction policy for each interface is then defined in an Implementation Configuration File (ICF). The transaction policies are:
TransactionCurrent Object
The interface is not transactional. Objects created for this interface can never be involved in a transaction. The WLE 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 client applications, see Using Transactions. For a description of the TransactionCurrent object, see the C++ Programming Reference or the WLE Javadoc.
The InterfaceRepository object returns information about the Interface Repository in a specific WLE 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 client application is seeking information about a specific CORBA interface or browsing the Interface Repository to find an interface. In either case, the 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 WLE domain, the 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 are not aware they are using the Interface Repository object. Like CORBA client applications, ActiveX client applications use the Bootstrap object to obtain a reference to the Interface Repository object.
For information about using the Interface Repository object in CORBA client applications that use DII, see Using the Dynamic Invocation Interface. For a description of the Interface Repository object, see the C++ Programming Reference.
The following sections describe concepts that are specific to ActiveX client applications.
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 WLE and COM object systems. The ActiveX Client transforms the interfaces of CORBA objects in an WLE domain into methods on Automation objects.
ActiveX client applications use views of CORBA interfaces. Views represent the CORBA interfaces in an WLE 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 an WLE 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.
Figure 1-6 illustrates how the ActiveX Client works.
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 };
In CORBA, this interface is named University::Student::Account
. The ActiveX Client translates this name to DIUniversity_Student_Account
for ActiveX.
InterfaceRepository Object
Concepts for ActiveX Client Applications
What is ActiveX?
Views and Bindings
Figure 1-6 How the ActiveX Client Works
Naming Conventions for ActiveX Views
{
module Student
{
interface Account
{//Operations and attributes of the Account interface
};
};
|
|
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|