|
|
|
|
|
|
This chapter contains the following topics:
Note: Most of the information in this chapter is taken from Chapter 8 of the Common Object Request Broker: Architecture and Specification. Revision 2.2, February 1998. The OMG information has been modified as required to describe the WLE implementation of the Interface Repository interfaces. Used with permission by OMG.
The WLE Interface Repository contains the interface descriptions of the CORBA objects that are implemented within the WLE domain.
The WLE Interface Repository is based on the CORBA definition of an Interface Repository. It offers a proper subset of the interfaces defined by CORBA; that is, the APIs that are exposed to programmers are implemented as defined by the Common Object Request Broker: Architecture and Specification Revision 2.2. However, not all interfaces are supported. In general, the interfaces required to read from the Interface Repository are supported, but the interfaces required to write to the Interface Repository are not. Additionally, not all TypeCode interfaces are supported.
Administration of the Interface Repository is done using tools specific to the WLE software. These tools allow the system administrator to create an Interface Repository, populate it with definitions specified in Object Management Group Interface Definition Language (OMG IDL), and then delete interfaces. Additionally, an administrator may need to configure the system to include an Interface Repository server. For a description of the Interface Repository administration commands, see Reference.
Several abstract interfaces are used as base interfaces for other objects in the Interface Repository. A common set of operations is used to locate objects within the Interface Repository. These operations are defined in the abstract interfaces IRObject, Container, and Contained described in this chapter. All Interface Repository objects inherit from the IRObject interface, which provides an operation for identifying the actual type of the object. Objects that are containers inherit navigation operations from the Container interface. Objects that are contained by other objects inherit navigation operations from the Contained interface. The IDLType interface is inherited by all Interface Repository objects that represent OMG IDL types, including interfaces, typedefs, and anonymous types. The TypedefDef interface is inherited by all named noninterface types.
The IRObject, Contained, Container, IDLType, and TypedefDef interfaces are not instantiable.
All string data in the Interface Repository are encoded as defined by the ISO 8859-1 character set.
Note:
The Write interface is not documented in this chapter because the WLE software supports only read access to the Interface Repository. Any attempt to use the Write interface to the Interface Repository will raise the exception org.omg.CORBA.NO_IMPLEMENT
.
The Interface Repository consists of two distinct components: the database and the server. The server performs operations on the database.
The Interface Repository database is created and populated using the idl2ir
administrative command. For a description of this command, see Reference. From the programmer's point of view, there is no write access to the Interface Repository. None of the write operations defined by CORBA are supported, nor are set operations on non-read-only attributes.
Read access to the Interface Repository database is always through the Interface Repository server; that is, a client reads from the database by invoking methods that are performed by the server. The read operations as defined by the CORBA Common Object Request Broker: Architecture and Specification, Revision 2.2, are described in this chapter.
The interface to a server is defined in the OMG IDL file. How the OMG IDL file is accessed depends on the type of client being built. Three types of clients are considered: stub based, Dynamic Invocation Interface (DII), and ActiveX.
Client applications that use stub-style invocations need the OMG IDL file at build time. The programmer can use the OMG IDL file to generate stubs, and so forth. (For more information, see Creating CORBA Client Applications.) No other access to the Interface Repository is required.
Client applications that use the Dynamic Invocation Interface (DII) need to access the Interface Repository programmatically. The interface to the Interface Repository is defined in this chapter and is discussed in "Building Client Applications" on page 10-5. The exact steps taken to access the Interface Repository depend on whether the client is seeking information about a specific object, or browsing the Interface Repository to find an interface. To obtain information about a specific object, clients use the org.omg.CORBA.Object._get_interface
method to obtain an InterfaceDef object. (Refer the Java API Reference for a description of this method.) Using the InterfaceDef object, the client can get complete information about the interface.
Before a DII client can browse the Interface Repository, it needs to obtain the object reference of the Interface Repository to start the search. DII clients use the Bootstrap object to obtain the object reference. (For a description of this method, see Chapter 4, Java Bootstrap Object Programming Reference.) Once the client has the object reference, it can navigate the Interface Repository, starting at the root.
Note:
To use the DII, the OMG IDL file must be stored in the Interface Repository.
Client applications that use ActiveX are not aware that they are using the Interface Repository. From the Interface Repository perspective, an ActiveX client is no different than a DII client. ActiveX clients include the Bootstrap object in the Visual Basic code. Like DII clients, ActiveX clients use the Bootstrap object to obtain the Interface Repository object reference. Once the client has the object reference, it can navigate the Interface Repository, starting at the root.
Note:
To use an ActiveX client, the OMG IDL file must be stored in the Interface Repository.
All run-time access to the Interface Repository is via the Interface Repository server. Because there is considerable overhead in making requests of a remote server application, designers need to be aware of this. For example, consider the interaction required to use an object reference to obtain the necessary information to make a DII invocation on the object reference. The steps are as follows:
Structure and Usage
From the Programmer's Point of View
Performance Implications
Java clients that use the Interface Repository need to link in Interface Repository stubs. How this happens is specific to the vendor. If the client application is using the WLE ORB, the WLE software provides the stubs in the org.omg.CORBA package, which you should include as part of your server application jar file. Therefore, programmers do not need to use the Interface Repository OMG IDL file to build the stubs.
If the client application is using a third-party ORB (for example, Orbix) the programmer must use the mechanisms that are provided by that vendor. This might include generating stubs from the OMG IDL file using the IDL compiler supplied by the vendor, simply linking against the stubs provided by the vendor, or some other mechanism.
Some third-party ORBs provide a local Interface Repository capability. In this case, the local Interface Repository is provided by the vendor and is populated with the interface definitions that are needed by that client.
You use the Bootstrap object to get an initial reference to the InterfaceRepository object. For a description of the Bootstrap object method, see Chapter 4, Java Bootstrap Object Programming Reference.
Client applications use the interfaces defined by CORBA to access the Interface Repository. This section contains descriptions of each interface that is implemented in the WLE software.
Several types are used throughout the Interface Repository interface definitions.
module CORBA {
typedef string Identifier;
typedef string ScopedName;
typedef string RepositoryId;
enum DefinitionKind {
dk_none, dk_all,
dk_Attribute, dk_Constant, dk_Exception, dk_Interface,
dk_Module, dk_Operation, dk_Typedef,
dk_Alias, dk_Struct, dk_Union, dk_Enum,
dk_Primitive, dk_String, dk_Sequence, dk_Array,
dk_Repository,
};
};
Identifiers are the simple names that identify modules, interfaces, constants, typedefs, exceptions, attributes, and operations. They correspond exactly to OMG IDL identifiers. An Identifier is not necessarily unique within an entire Interface Repository; it is unique only within a particular Repository, ModuleDef, InterfaceDef, or OperationDef.
A ScopedName is a name made up of one or more identifiers separated by two colons (:: ). The identifiers correspond to OMG IDL scoped names. An absolute ScopedName is one that begins with two colons and unambiguously identifies a definition in a Repository. An absolute ScopedName in a Repository corresponds to a global name in an OMG IDL file. A relative ScopedName does not begin with two colons and must be resolved relative to some context.
A RepositoryId is an identifier used to uniquely and globally identify a module, interface, constant, typedef, exception, attribute, or operation. Because RepositoryIds are defined as strings, they can be manipulated (for example, copied and compared) using a language binding's string manipulation routines.
A DefinitionKind identifies the type of an Interface Repository object.
The IRObject interface (shown below) represents the most generic interface from which all other Interface Repository interfaces are derived, even the Repository itself.
module CORBA {
interface IRObject {
readonly attribute DefinitionKind def_kind;
};
};
The def_kind attribute identifies the type of the definition.
The Contained interface (shown below) is inherited by all Interface Repository interfaces that are contained by other Interface Repository objects. All objects within the Interface Repository, except the root object (Repository) and definitions of anonymous (ArrayDef, StringDef, and SequenceDef), and primitive types are contained by other objects.
module CORBA {
typedef string VersionSpec;
interface Contained : IRObject {
readonly attribute RepositoryId id;
readonly attribute Identifier name;
readonly attribute VersionSpec version;
readonly attribute Container defined_in;
readonly attribute ScopedName absolute_name;
readonly attribute Repository containing_repository;
struct Description {
DefinitionKind kind;
any value;
};
Description describe ();
};
};
An object that is contained by another object has an id attribute that identifies it globally, and a name attribute that identifies it uniquely within the enclosing Container object. It also has a version attribute that distinguishes it from other versioned objects with the same name. The WLE Interface Repository does not support simultaneous containment or multiple versions of the same named object.
Contained objects also have a defined_in attribute that identifies the Container within which they are defined. Objects can be contained either because they are defined within the containing object (for example, an interface is defined within a module) or because they are inherited by the containing object (for example, an operation may be contained by an interface because the interface inherits the operation from another interface). If an object is contained through inheritance, the defined_in attribute identifies the InterfaceDef from which the object is inherited.
The absolute_name attribute is an absolute ScopedName that identifies a Contained object uniquely within its enclosing Repository. If this object's defined_in attribute references a Repository, the absolute_name is formed by concatenating the string "::" and this object's name attribute. Otherwise, the absolute_name is formed by concatenating the absolute_name attribute of the object referenced by this object's defined_in attribute, the string "::" , and this object's name attribute.
The containing_repository attribute identifies the Repository that is eventually reached by recursively following the object's defined_in attribute.
The describe operation returns a structure containing information about the interface. The description structure associated with each interface is provided below with the interface's definition. The kind of definition described by the structure returned is provided with the returned structure. For example, if the describe operation is invoked on an attribute object, the kind field contains dk_Attribute and the value field contains an any , which contains the AttributeDescription structure.
The Container interface is used to form a containment hierarchy in the Interface Repository. A Container can contain any number of objects derived from the Contained interface. All Containers, except for Repository, are also derived from Contained.
module CORBA {
typedef sequence <Contained> ContainedSeq;
interface Container : IRObject {
Contained lookup (in ScopedName search_name);
ContainedSeq contents (
in DefinitionKind limit_type,
in boolean exclude_inherited
);
ContainedSeq lookup_name (
in Identifier search_name,
in long levels_to_search,
in DefinitionKind limit_type,
in boolean exclude_inherited
);
struct Description {
Contained contained_object;
DefinitionKind kind;
any value;
};
typedef sequence<Description> DescriptionSeq;
DescriptionSeq describe_contents (
in DefinitionKind limit_type,
in boolean exclude_inherited,
in long max_returned_objs
);
};
};
The lookup operation locates a definition relative to this container, given a scoped name using the OMG IDL rules for name scoping. An absolute scoped name (beginning with "::" ) locates the definition relative to the enclosing Repository. If no object is found, a nil object reference is returned.
The contents operation returns the list of objects directly contained by or inherited into the object. The operation is used to navigate through the hierarchy of objects. Starting with the Repository object, a client uses this operation to list all of the objects contained by the Repository, all of the objects contained by the modules within the Repository, all of the interfaces within a specific module, and so on.
The IDLType interface (shown below) is an abstract interface inherited by all Interface Repository objects that represent OMG IDL types. It provides access to the TypeCode describing the type, and is used in defining other interfaces wherever definitions of IDL types must be referenced.
module CORBA {
interface IDLType : IRObject {
readonly attribute TypeCode type;
};
};
The type attribute describes the type defined by an object derived from IDLType.
Repository (shown below) is an interface that provides global access to the Interface Repository. The Repository object can contain constants, typedefs, exceptions, interfaces, and modules. As it inherits from Container, it can be used to look up any definition (whether globally defined or defined within a module or an interface) either by name or by id .
module CORBA {
interface Repository : Container {
Contained lookup_id (in RepositoryId search_id);
PrimitiveDef get_primitive (in PrimitiveKind kind);
};
};
The lookup_id operation is used to look up an object in a Repository, given its RepositoryId . If the Repository does not contain a definition for search_id , a nil object reference is returned.
The get_primitive operation returns a reference to a PrimitiveDef with the specified kind attribute. All PrimitiveDefs are immutable and are owned by the Repository.
A ModuleDef (shown below) can contain constants, typedefs, exceptions, interfaces, and other module objects.
module CORBA {
interface ModuleDef : Container, Contained {
};
struct ModuleDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
};
};
The inherited describe operation for a ModuleDef object returns a ModuleDescription.
A ConstantDef object (shown below) defines a named constant.
module CORBA {
interface ConstantDef : Contained {
readonly attribute TypeCode type;
readonly attribute IDLType type_def;
readonly attribute any value;
};
struct ConstantDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
TypeCode type;
any value;
};
};
A TypedefDef (shown below) is an abstract interface used as a base interface for all named nonobject types (structures, unions, enumerations, and aliases). The TypedefDef interface is not inherited by the definition objects for primitive or anonymous types.
module CORBA {
interface TypedefDef : Contained, IDLType {
};
struct TypeDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
TypeCode type;
};
};
The inherited describe operation for interfaces derived from TypedefDef returns a TypeDescription.
A StructDef (shown below) represents an OMG IDL structure definition. It contains the members of the struct.
module CORBA {
struct StructMember {
Identifier name;
TypeCode type;
IDLType type_def;
};
typedef sequence <StructMember> StructMemberSeq;
interface StructDef : TypedefDef, Container{
readonly attribute StructMemberSeq members;
};
};
The members attribute contains a description of each structure member.
The inherited type attribute is a tk_struct TypeCode describing the structure.
A UnionDef (shown below) represents an OMG IDL union definition. It contains the members of the union.
module CORBA {
struct UnionMember {
Identifier name;
any label;
TypeCode type;
IDLType type_def;
};
typedef sequence <UnionMember> UnionMemberSeq;
interface UnionDef : TypedefDef, Container {
readonly attribute TypeCode discriminator_type;
readonly attribute IDLType discriminator_type_def;
readonly attribute UnionMemberSeq members;
};
};
The inherited type attribute is a tk_union TypeCode describing the union.
An EnumDef (shown below) represents an OMG IDL enumeration definition.
module CORBA {
typedef sequence <Identifier> EnumMemberSeq;
interface EnumDef : TypedefDef {
readonly attribute EnumMemberSeq members;
};
};
The inherited type attribute is a tk_enum TypeCode describing the enumeration.
An AliasDef (shown below) represents an OMG IDL typedef that aliases another definition.
module CORBA {
interface AliasDef : TypedefDef {
readonly attribute IDLType original_type_def;
};
};
The inherited type attribute is a tk_alias TypeCode describing the alias.
A PrimitiveDef (shown below) represents one of the OMG IDL primitive types. Because primitive types are unnamed, this interface is not derived from TypedefDef or Contained .
module CORBA {
enum PrimitiveKind {
pk_null, pk_void, pk_short, pk_long, pk_ushort, pk_ulong,
pk_float, pk_double, pk_boolean, pk_char, pk_octet,
pk_any, pk_TypeCode, pk_Principal, pk_string, pk_objref,
pk_longlong, pk_ulonglong, pk_longdouble, pk_wchar, pk_wstring
};
interface PrimitiveDef: IDLType {
readonly attribute PrimitiveKind kind;
};
};
represents an unbounded string. A PrimitiveDef with kind pk_objref
represents the OMG IDL type Object.
The inherited type attribute describes the primitive type.
All PrimitiveDefs are owned by the Repository. References to them are obtained using Repository::get_primitive .
An ExceptionDef (shown below) represents an exception definition. It can contain structs, unions, and enums.
module CORBA {
interface ExceptionDef : Contained, Container {
readonly attribute TypeCode type;
readonly attribute StructMemberSeq members;
};
struct ExceptionDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
TypeCode type;
};
};
The describe operation for a ExceptionDef object returns an ExceptionDescription.
An AttributeDef (shown below) represents the information that defines an attribute of an interface.
module CORBA {
enum AttributeMode {ATTR_NORMAL, ATTR_READONLY};
interface AttributeDef : Contained {
readonly attribute TypeCode type;
attribute IDLType type_def;
attribute AttributeMode mode;
};
struct AttributeDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
TypeCode type;
AttributeMode mode;
};
};
An OperationDef (shown below) represents the information needed to define an operation of an interface.
module CORBA {
enum OperationMode {OP_NORMAL, OP_ONEWAY};
enum ParameterMode {PARAM_IN, PARAM_OUT, PARAM_INOUT};
struct ParameterDescription {
Identifier name;
TypeCode type;
IDLType type_def;
ParameterMode mode;
};
typedef sequence <ParameterDescription> ParDescriptionSeq;
typedef Identifier ContextIdentifier;
typedef sequence <ContextIdentifier> ContextIdSeq;
typedef sequence <ExceptionDef> ExceptionDefSeq;
typedef sequence <ExceptionDescription> ExcDescriptionSeq;
interface OperationDef : Contained {
readonly attribute TypeCode result;
readonly attribute IDLType result_def;
readonly attribute ParDescriptionSeq params;
readonly attribute OperationMode mode;
readonly attribute ContextIdSeq contexts;
readonly attribute ExceptionDefSeq exceptions;
};
struct OperationDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
TypeCode result;
OperationMode mode;
ContextIdSeq contexts;
ParDescriptionSeq parameters;
ExcDescriptionSeq exceptions;
};
};
The inherited describe operation for an OperationDef object returns an OperationDescription.
The inherited describe_contents operation provides a complete description of this operation, including a description of each parameter defined for this operation.
An InterfaceDef object (shown below) represents an interface definition. It can contain constants, typedefs, exceptions, operations, and attributes.
module CORBA {
interface InterfaceDef;
typedef sequence <InterfaceDef> InterfaceDefSeq;
typedef sequence <RepositoryId> RepositoryIdSeq;
typedef sequence <OperationDescription> OpDescriptionSeq;
typedef sequence <AttributeDescription> AttrDescriptionSeq;
interface InterfaceDef : Container, Contained, IDLType {
readonly attribute InterfaceDefSeq base_interfaces;
boolean is_a (in RepositoryId interface_id);
struct FullInterfaceDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
OpDescriptionSeq operations;
AttrDescriptionSeq attributes;
RepositoryIdSeq base_interfaces;
TypeCode type;
};
FullInterfaceDescription describe_interface();
};
struct InterfaceDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
RepositoryIdSeq base_interfaces;
};
};
The describe_interface operation returns a FullInterfaceDescription describing the interface, including its operations and attributes.
The inherited describe operation for an InterfaceDef returns an InterfaceDescription.
The inherited contents operation returns the list of constants, typedefs, and exceptions defined in this InterfaceDef and the list of attributes and operations either defined or inherited in this InterfaceDef. If the exclude_inherited parameter is set to TRUE, only attributes and operations defined within this interface are returned. If the exclude_inherited parameter is set to FALSE, all attributes and operations are returned.
|
|
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|