Table of Contents Previous Next PDF


CORBA Interface Repository Interfaces

CORBA Interface Repository Interfaces
This chapter describes the Oracle Tuxedo CORBA Interface Repository interfaces.
Notes:
Most of the information in this chapter is taken from Chapter 10 of the Common Object Request Broker: Architecture and Specification, Revision 2.4.2, February 2001. The OMG information has been modified as required to describe the Oracle Tuxedo CORBA implementation of the Interface Repository interfaces. Used with permission of the OMG.
The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported in Tuxedo 9.x. All Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB text references, associated code samples, etc. should only be used:
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.
The Oracle Tuxedo CORBA Interface Repository contains the interface descriptions of the CORBA objects that are implemented within the Oracle Tuxedo domain.
The 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.4. 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 Oracle Tuxedo 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 the Oracle Tuxedo Command Reference and Setting Up an Oracle Tuxedo Application.
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:
Structure and Usage
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 the Oracle Tuxedo Command Reference and Setting Up an Oracle Tuxedo Application. 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 nonread-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.4, are described in this chapter.
Programming Information
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).
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‑4. 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 CORBA::Object::_get_interface method to obtain an InterfaceDef object. (Refer to CORBA::Object::_get_interface 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 the section Tobj_Bootstrap::register_callback_port.) Once the client has the object reference, it can navigate the Interface Repository, starting at the root.
To obtain a reference to a Interface Repository in the domain to which a client application is associated, the client application can use either of two bootstrapping mechanisms:
Invoke the Tobj_Bootstrap::resolve_initial_references operation with a value of “CORBA::Repository”. This operation returns a reference to a InterfaceRepository object that is in the domain to which the client application is currently attached. You should use this mechanism if you are using the Oracle Tuxedo client software. For more information, see the section Tobj_Bootstrap::resolve_initial_references.
Invoke the CORBA::ORB::resolve_initial_references operation with a value of “CORBA::Repository”. This operation returns a reference to a InterfaceRepository object that is in the domain to which the client application is currently attached. You should use this mechanism if you are using a third-party client ORB. For more information, see the section CORBA::ORB::resolve_initial_references.
Note:
Performance Implications
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:
1.
The client application invokes the _get_interface operation on the CORBA::Object to get the InterfaceDef object associated with the object in question. This causes a message to be sent to the ORB that created the object reference.
2.
3.
The client invokes one or more _is_a operations on the object to determine what type of interface is supported by the object.
4.
After the client has identified the interface, it invokes the describe_interface operation on the Interface object to get a full description of the interface (for example, version number, operations, attributes, and parameters). This causes a message to be sent to the Interface Repository, and a reply is returned.
5.
Building Client Applications
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 Oracle Tuxedo ORB, the Oracle Tuxedo software provides the stubs in the form of a library. Therefore, programmers do not need to use the Interface Repository OMG IDL file to build the stubs. The Interface Repository definitions are contained within the CORBA.h file, but they are not included by default.
Note:
To use the Interface Repository definitions, you must define the ORB_INCLUDE_REPOSITORY macro before including CORBA.h in your client application code (for example: #Define ORB_INCLUDE_REPOSITORY).
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.
Getting Initial References to the InterfaceRepository Object
You use the Bootstrap object to get an initial reference to the InterfaceRepository object. For a description of the Bootstrap object method, see the command Tobj_Bootstrap::resolve_initial_references.
Interface Repository Interfaces
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 Oracle Tuxedo software.
Note:
Supporting Type Definitions
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,
dk_Wstring, dk_Fixed,
dk_Value, dk_ValueBox, dk_ValueMember,
dk_Native
};
};
Identifiers are the simple names that identify modules, interfaces, value types, value members, value boxes, constants, typedefs, exceptions, attributes, operations, and native types. 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, ValueDef, or OperationDef.
A ScopedName is a name made up of one or more identifiers separated by double colons (::). They correspond to OMG IDL scoped names. An absolute ScopedName is one that begins with double 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 double colons (::) and must be resolved relative to some context.
A RepositoryId is an identifier used to uniquely and globally identify a module, interface, value type, value member, value box, native type, 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.
IRObject Interface
The base interface IRObject (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.
Contained Interface
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 Oracle Tuxedo CORBA 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 or ValueDef 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 within operation returns the list of objects that contain the object. If the object is an interface or module, it can be contained only by the object that defines it. Other objects can be contained by the objects that define them and by the objects that inherit them.
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.
Container Interface
The base interface Container 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 double colons (::)) 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 and value types within a specific module, and so on.
limit_type
If limit_type is set to dk_all, objects of all types are returned. For example, if this is an InterfaceDef, the attribute, operation, and exception objects are all returned. If limit_type is set to a specific interface, only
objects of that type are returned. For example, only attribute objects are returned if limit_type is set to dk_Attribute.
exclude_inherited
If set to TRUE, inherited objects (if there are any) are not returned. If set to FALSE, all contained objects (whether contained due to inheritance or because they were defined within the object) are returned.
The lookup_name operation is used to locate an object by name within a particular object or within the objects contained by that object. The describe_contents operation combines the contents operation and the describe operation. For each object returned by the contents operation, the description of the object is returned (that is, the object’s describe operation is invoked and the results are returned).
The lookup_name operation is used to locate an object by name within a particular object or within the objects contained by that object.
search_name
Specifies which name is to be searched for.
levels_to_search
Controls whether the lookup is constrained to the object the operation is invoked on, or whether the lookup should search through objects contained by the object as well. Setting levels_to_search to -1 searches the current object and all contained objects. Setting levels_to_search to 1 searches only the current object. Use of values of levels_to_search of 0 or of negative numbers other than -1 is undefined.
The describe_contents operation combines the contents operation and the describe operation. For each object returned by the contents operation, the description of the object is returned (i.e., the object’s describe operation is invoked and the results returned).
max_returned_objs
Limits the number of objects that can be returned in an invocation of the call to the number provided. Setting the parameter to -1 indicates return all contained objects.
IDLType Interface
The base interface IDLType (shown below) is 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 Interface
Repository (shown below) is an interface that provides global access to the Interface Repository. The Repository object can contain constants, typedefs, exceptions, interfaces, value types, value boxes, native types, 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.
Since the Repository derives only from Container and not from Contained, it does not have a RepositoryId associated with it. By default, it is deemed to have the RepositoryId “”(the empty string) for purposes of assigning a value to the defined_in field of the description structure of ModuleDef, InterfaceDef, ValueDef, ValueBoxDef, TypedefDef, ExceptionDef, and ConstantDef that are contained immediately in the Repository object.
module CORBA {
interface Repository : Container {
Contained lookup_id (in RepositoryId search_id);
TypeCode get_canonical_typecode(in TypeCode tc);
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_canonical_typecode operation looks up the TypeCode in the Interface Repository and returns an equivalent TypeCode that includes all repository IDs, names, and member_names. If the top level TypeCode does not contain a RepositoryId, such as array and sequence TypeCodes, or TypeCodes from older ORBs, or if it contains a RepositoryId that is not found in the target Repository, then a new TypeCode is constructed by recursively calling get_canonical_typecode on each member TypeCode of the original TypeCode.
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.
ModuleDef Interface
A ModuleDef (shown below) can contain constants, typedefs, exceptions, interfaces, value types, value boxes, native types, 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.
ConstantDef Interface
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;
};
};
type
Specifies the TypeCode describing the type of the constant. The type of a constant must be one of the simple types (long, short, float, char, string, octet, and so on).
type_def
Identifies the definition of the type of the constant.
value
Contains the value of the constant, not the computation of the value (for example, the fact that it was defined as “1+2”).
The describe operation for a ConstantDef object returns a ConstantDescription.
TypedefDef Interface
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.
StructDef
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.
UnionDef
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;
};
};
discriminator_type and discriminator_type_def
Describes and identifies the union’s discriminator type.
members
Contains a description of each union member. The label of each UnionMemberDescription is a distinct value of the discriminator_type. Adjacent members can have the same name. Members with the same name must also have the same type. A label with type octet and value 0 (zero) indicates the default union member.
The inherited type attribute is a tk_union TypeCode describing the union.
EnumDef
An EnumDef (shown below) represents an OMG IDL enumeration definition.
module CORBA {
typedef sequence <Identifier> EnumMemberSeq;
interface EnumDef : TypedefDef {
readonly attribute EnumMemberSeq members;
};
};
members
Contains a distinct name for each possible value of the enumeration.
The inherited type attribute is a tk_enum TypeCode describing the enumeration.
AliasDef
An AliasDef (shown below) represents an OMG IDL typedef that aliases another definition.
module CORBA {
interface AliasDef : TypedefDef {
readonly attribute IDLType original_type_def;
};
};
original_type_def
Identifies the type being aliased.
The inherited type attribute is a tk_alias TypeCode describing the alias.
PrimitiveDef
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,
pk_value_base
};

interface PrimitiveDef: IDLType {
readonly attribute PrimitiveKind kind;
};
};
kind
Indicates which primitive type the PrimitiveDef represents. There are no PrimitiveDefs with kind pk_null. A PrimitiveDef with kind pk_string
represents an unbounded string. A PrimitiveDef with kind pk_objref represents the OMG IDL type Object. A PrimitiveDef with kind pk_value_base represents the IDL type ValueBase.
The inherited type attribute describes the primitive type.
All PrimitiveDefs are owned by the Repository. References to them are obtained using Repository::get_primitive.
StringDef
A StringDef represents an IDL bounded string type. The unbounded string type is represented as a PrimitiveDef. As string types are anonymous, this interface is not derived from TypedefDef or Contained.
module CORBA {
interface StringDef : IDLType {
attribute unsigned long bound;
};
};
The bound attribute specifies the maximum number of characters in the string and must not be zero.
The inherited type attribute is a tk_string TypeCode describing the string.
WstringDef
A WstringDef represents an IDL wide string. The unbounded wide string type is represented as a PrimitiveDef. As wide string types are anonymous, this interface is not derived from TypedefDef or Contained.
module CORBA {
interface WstringDef : IDLType {
attribute unsigned long bound;
};
};
The bound attribute specifies the maximum number of wide characters in a wide string, and must not be zero.
The inherited type attribute is a tk_wstring TypeCode describing the wide string.
ExceptionDef
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;
};
};
type
tk_except TypeCode that describes the exception.
members
Describes any exception members.
The describe operation for a ExceptionDef object returns an ExceptionDescription.
AttributeDef
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;
};
};
type
Provides the TypeCode describing the type of this attribute.
type_def
Identifies the object that defines the type of this attribute.
mode
Specifies read only or read/write access for this attribute.
The describe operation for an AttributeDef object returns an AttributeDescription.
OperationDef
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;
};
};
result
A TypeCode that describes the type of the value returned by the operation.
 
result_def
Identifies the definition of the returned type.
params
Describes the parameters of the operation. It is a sequence of ParameterDescription structures. The order of the ParameterDescriptions in the sequence is significant. The name member of each structure provides the parameter name. The type member is a TypeCode describing the type of the parameter. The type_def member identifies the definition of the type of the parameter. The mode member indicates whether the parameter is an in, out, or inout parameter.
mode
The operation’s mode is either oneway (that is, no output is returned) or normal.
contexts
Specifies the list of context identifiers that apply to the operation.
exceptions
Specifies the list of exception types that can be raised by the operation.
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.
InterfaceDef
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;
readonly attribute boolean is_abstract;

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;
boolean is_abstract;
};

FullInterfaceDescription describe_interface();
};

struct InterfaceDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
RepositoryIdSeq base_interfaces;
boolean is_abstract;
};
};
The base_interfaces attribute lists all the interfaces from which this interface inherits.
The is_abstract attribute is TRUE if the interface is an abstract interface type.
The is_a operation returns TRUE if the interface on which it is invoked either is identical to or inherits, directly or indirectly, from the interface identified by its interface_id parameter. Otherwise, it returns FALSE.
The describe_interface operation returns a FullInterfaceDescription describing the interface, including its operations and attributes. The operations and attributes fields of the FullInterfaceDescription structure include descriptions of all of the operations and attributes in the transitive closure of the inheritance graph of the interface being described.
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 © 1994, 2017, Oracle and/or its affiliates. All rights reserved.