featuresmatrix intro page0. Intended Use
1. Basic Concepts
The CORBA Specification, published by the Object Management Group, isboth an architecture which encompasses an object model and a specificationwhich defines among other things, an Interface Definition Language (IDL).IDL permits interfaces to objects to be defined independent of an objectsimplementation. After defining an interface in IDL, the interface definitionis used as input to an IDL compiler which produces output that can be compiledand linked with an object implementation and its clients.
CORBA supports clients making requests to objects. The requests consistof an operation, a target object, zero or more parameters and an optionalrequest context. A request causes a service to be performed on behalf ofa client and results of executing the request returned to the client. Ifan abnormal condition occurs during execution of the request an exceptionis returned.
Interfaces can be used either statically or dynamically. An interfaceis statically bound to an object when the name of the object it is accessingis known at compile time. In this case, the IDL compiler generates thenecessary output to compile and link to the object at compile time. Inaddition, clients that need to discover an object at run time and constructa request dynamically, can use the Dynamic Invocation Interface (DII).The DII is supported by an interface repository which is defined as partof CORBA. By accessing information in the interface repository, a clientcan retrieve all of the information necessary about an objects interfaceto construct and issue a request at run time. Since the static and dynamicrequests are equally expressive semantically there will be no further distinctionin this discussion between these two methods of invoking operations onobjects.
CORBA has been postured as being both language-neutral and independentof ORB and CORBA object implementations. CORBA supports bindings for Cbut it is anticipated that it will eventually support language mappingsfor C++, Smalltalk and COBOL.
2. Objects
An object is an identifiable, encapsulated entity that provides oneor more services that can be requested by a client [CORBA Specification2.2.1 Objects].
2.1 Operations
An operation is an identifiable entity that denotes a service that canbe requested. An operation is identified by an operation identifier. Anoperation has a signature that describes the legitimate values of requestparameters and returned results. The signature consists of a specificationof parameters, the result of the operation, a specification of the exceptionsthat may be raised by a request and the types of parameters accompanyingthem, a specification of any contextual information and an indication ofthe execution semantics the client should expect [CORBA Specification 2.2.6Operations].
2.2 requests
A request is an event, i.e. something that occurs at a particular time.The information associated with a request consists of an operation, a targetobject, zero or more actual parameters, and an optional request context[CORBA Specification 2.2.2 Requests].
2.3 messages
Messages are not explicitly identified in the CORBA Specification.
2.4 specification of behavioral semantics
The CORBA specification does not specify the behavior of objects. Itdefines interfaces and allows interfaces to be defined in terms of operationsignatures. These operations can be invoked on objects resulting in methodsbeing dispatched which execute the service requested by the operation.The behavior of the object is defined by the methods that implement theobjects behavior. The actual semantics of an objects implementation isdefined by the object implementer and is outside the scope of the CORBAspecification.
2.5 methods
Code that is executed to perform a service is called a method. Whena client issues a request, a method of the target object is called. Theinput parameters passed by the requester are passed to the method and theoutput parameters and return value are passed back to the requester [CORBASpecification 2.3.1 The Execution Model: Performing Requests].
2.6 state
The state of CORBA objects is accessed through IDL defined interfacesto the object. Invoking operations on objects may cause state changes.
2.7 object lifetime
Objects can be created and destroyed. From a client's point of view,there is no special CORBA mechanism for creating or destroying an object.Objects are created and destroyed as an outcome of issuing requests. Theoutcome of object creation is revealed to the client in the form of anobject reference that denotes the new object [CORBA Specification 2.2.2Requests].
2.8 behavior/state grouping
CORBA uses the classical object model in that a target object must bespecified for each operation.
2.9 communication model
CORBA provides a layer of abstraction above the communications layer,thus shielding clients from needing to know about the underlying communicationsmechanisms or where in the network the target object resides.
2.10 events
2.11 transition rules
3. Binding
CORBA provides support for both early and late binding which are referredto as static and dynamic respectively. See entry under 1. Basic Concepts.
4. Polymorphism
Polymorphism is not addressed in the CORBA specification since the specificationonly deals with interfaces and not the object implementation. The specificationdoes not preclude multiple object implementations supporting the same CORBAinterface.
5. Encapsulation
Access to the state of CORBA objects is through the operations thatmake up the objects interface. IDL supports full encapsulation for CORBAobjects.
6. Identity, Equality, Copy
An object reference is used to refer to a CORBA object. While the objectreference itself can be duplicated there are no operations supporting copyingor comparing CORBA object implementations. This is outside the scope ofthe CORBA specification.
7. Types and Classes
A type is an identifiable entity with an associated predicate definedover values. A value satisfies a type if the predicate is true for thattype. A value that satisfies a type is called a member of the type. Theextension of a type is the set of values that satisfy the type at any particulartime [CORBA Specification 2.2.4 Types].
Types are used in signatures to restrict a possible parameter or tocharacterize a possible result. An object type is a type whose membersare objects. Basic data types are 16 and 32 bit signed and unsigned 2'scomplement integers, 32 bit and 64 bit IEEE floating point numbers, charactersas defined in ISO Latin-1 (8859.1), a boolean type taking the values TRUEand FALSE, and 8-bit opaque data type, guaranteed to not undergo any conversionduring transfer between systems, enumerated types consisting of orderedsequence of identifiers, a string type which consists of a variable-lengtharray of characters, a type any which can represent any possible basicor constructed type [CORBA Specification 2.2.4 Types].
Constructed types consist of a record type(called struct), consistingof an ordered set of (name, value) pairs, a discriminated union type consistingof a discriminator followed by an instance of a type appropriate to thediscriminator value, a sequence type which consists of a variable-lengtharray of a single type, an array type which consists of a fixed-lengtharray of a single type, and an interface type which specifies the set ofoperations, which an instance of that type must support [CORBA Specification2.2.4 Types].
8. Inheritance and Delegation
CORBA supports interface inheritance, meaning that one interface canbe derived in terms of another. A derived interface may redefine any ofthe type, constant, and exception names which have been inherited. Multipleinheritance is supported in that an interface may be derived from a numberof base interfaces.
CORBA does not address object implementation inheritance.
9. Noteworthy Objects
CORBA does not define specific objects, however. CORBA does define pseudoobjects. Pseudo objects have interfaces just like ordinary CORBA objectsbut may be implemented in the ORB instead of as a real CORBA objects. Pseudoobjects defined as part of the CORBA specification include the ORB itself.The other pseudo objects are not listed here because they have no directbearing on the analysis of this model.
9.1 relationships
Not addressed.
9.2. attributes
An interface may have attributes. An attribute is logically equivalentto declaring a pair of accessor functions: one to retrieve the value ofthe attribute and one to set the value of the attribute. An attribute maybe read-only, in which case only the retrieval accessor function is defined[CORBA Specification 2.2.7 Attributes].
9.3 literals
See entry under 7. Types and Classes.
9.4 containment
See entry under 7. Types and Classes.
9.5 aggregates
Not addressed.
9.6 other
10. Extensibility
The CORBA Specification itself is extensible and there is a workinggroup within OMG that is active in working on extensions to the specification.
10.1 dynamic
CORBA objects can be accessed by using the Dynamic Invocation Interface(DII) to construct requests to objects at run time. The DII provides accessto the ORB's Interface Repository which contains type information aboutobjects. Clients access this information and use it to construct a requestwhich can be invoked on an object at run time.
10.2 metaclasses/metaobject protocol
CORBA does not define a meta-object or meta-class protocol.
10.3 introspection
11. Object Languages
CORBA supports a C language mapping. Future mappings are expected toinclude C++, Smalltalk and COBOL.
12. Semantics of Base Classes (+type constructors)
CORBA defines "interfaces". Interfaces are equivalent to classes.An interface can be derived in terms of another interface. A derived interfacemay declare new elements. In addition, the elements of a base interface(parent interface) can be referred to as if they were elements of the derivedinterface. A derived interface may redefine any of the type, constant,and exception names which have been inherited.
An interface may be derived from any number of base interfaces (multipleinheritance). Reference to base interface elements must be unambiguous.It is illegal to inherit from two interfaces with the same operation orattribute name.
13. Background and References
[CORBA Specification} The Common Object Request Broker: Architectureand Specification, Revision 1.1. Object Management Group, 1992.