Researched by Tom Tenhor
Index
CORBA, the Common Object Request Broker Architecture, is a distributed object standard developed and promoted by the Object Management Group (OMG), a consortium of over 800 companies. CORBA's framework allows distributed applications to be developed that are platform and language-independent. The framework also promotes the use of object-oriented design principles. The key component of the CORBA framework is the Object Request Broker or ORB. The ORB implements the object framework, or what is called an "object bus" that allows a client to call local or remote objects without regard to their location. For a detailed description of an ORB, see IBM's article Demystifying the ORB.
The Object Request Broker, commonly known as an ORB, implements the CORBA framework by acting as the middleware between client and server objects. The ORB allows the client to make the server object invocation, without regard to the location of the server object. The ORB provides location transparency for the client and server objects.
CORBA supports language-independence by describing object interfaces with the Interface Definition Language (IDL). IDL compilers are available to map IDL to many common languages, such as the following:
Ada COBOL C Java C++ Smalltalk
An example of an IDL definition for a banking application may include these definitions.
module Example
{
interface BankServer
{
boolean verifyPIN( in long acctNbr, in long pin );
void getAcctSpecifics( in long acctNbr, in string customerName,
out double balance, out boolean isChecking );
boolean processTransaction( in Transaction t, in long acctNbr );
}
}The IDL compiler takes the IDL source and creates language specific code for both the client and server who will use the object interface. A client stub will be created that acts as a proxy object, providing the client with a local proxy implementation of the object. The client stub code hides the lower level communications and data marshalling from the client code. IDL also creates a server skeleton that is the server's equivalent of the client stub code, helping to export the interface and marshall data.
The interface description is also placed in the Interface Repository (IR). There is a Dynamic Invocation Interface (DII) defined that allows a client to implement a form of run-time binding. At run-time, the client can use the DII to query the IR for the interface description to create and then invoke dynamically. A Dynamic Skeleton Interface (DSI) also exists for the server side.
CORBA defines a General Inter-ORB Protocol (GIOP) that specifies a set of messages and marshalling rules (the data representation) between ORBs. The Internet Inter-ORB Protocol or IIOP is the transport layer that defines how GIOP messages are transmitted via TCP/IP. CORBA 2.0 mandates protocol support for GIOP over IIOP in order to achieve 2.0 compliance. GIOP may also use other transports such as OSI and IPX/SPX. Expersoft has authored a paper that suggests the use of a Message-oriented Middleware (MOM) as the transport used by GIOP instead of IIOP, see Integrating CORBA with Message-oriented Middleware.
In addition to GIOP, CORBA has defined Environment-Specific Inter-ORB Protocols (ESIOPs) that can support interoperation over specific networks. The primary transport defined by CORBA for ESIOPs is DCE. DCE includes such features/services as Kerberos, time services and RPC [Orfali, 98].
These services are listed as defined in the OMG's CORBAservices: Common Object Services Specification, March 1995, last updated November 1997.
- Naming Service - The Naming Service provides the ability to bind a name to an object relative to a naming context. A naming context is an object that contains a set of name bindings in which each name is unique. To resolve a name is to determine the object associated with the name in a given context.
- Event Management Service - The Event Service provides basic capabilities that can be configured together in a very flexible and powerful manner. Asynchronous events (decoupled event suppliers and consumers), event “fan-in,” notification “fan-out,” and (through appropriate event channel implementations) reliable event delivery are supported.
The Event Service design is scalable and is suitable for distributed environments. There is no requirement for a centralized server or dependency on any global service.
Both push and pull event delivery models are supported: that is, consumers can either request events or be notified of events, whichever is needed to satisfy application requirements. There can be multiple consumers and multiple suppliers events.
Suppliers can generate events without knowing the identities of the consumers. Conversely, consumers can receive events without knowing the identities of the suppliers.
- Persistent Object Service - The Persistent Object Service (POS) provides a set of common interfaces to the mechanisms used for retaining and managing the persistent state of objects.
- Lifecycle Service - The Life Cycle Service defines conventions for creating, deleting, copying and moving objects. Because CORBA-based environments support distributed objects, life cycle services define services and conventions that allow clients to perform life cycle operations on objects in different locations.
- Concurrency Service - The Concurrency Control Service enables multiple clients to coordinate their access to shared resources. Coordinating access to a resource means that when multiple, concurrent clients access a single resource, any conflicting actions by the clients are reconciled so that the resource remains in a consistent state.
- Externalization Service - The Externalization Service defines protocols and conventions for externalizing and internalizing objects. Externalizing an object is to record the object state in a stream of data (in memory, on a disk file, across the network, and so forth) and then be internalized into a new object in the same or a different process. The externalized object can exist for arbitrary amounts of time, be transported by means outside of the ORB, and be internalized in a different, disconnected ORB. For portability, clients can request that externalized data be stored in a file whose format is defined with the Externalization Service Specification.
- Relationships Service - The Relationship Service allows entities and relationships to be explicitly represented. Entities are represented as CORBA objects. The service defines two new kinds of objects: relationships and roles. A role represents a CORBA object in a relationship. The Relationship interface can be extended to add relationship-specific attributes and operations. In addition, relationships of arbitrary degree can be defined. Similarly, the Role interface can be extended to add role-specific attributes and operations.
- Transactions Service - The Transaction Service supports multiple transaction models, including the flat (mandatory in the specification) and nested (optional) models.
The Object Transaction Service supports interoperability between different programming models. For instance, some users want to add object implementations to existing procedural applications and to augment object implementations with code that uses the procedural paradigm. To do so in a transaction environment requires the object and procedural code to share a single transaction.
Network interoperability is also supported, since users need communication between different systems, including the ability to have one transaction service interoperate with a cooperating transaction service using different ORBs.
- Query Service - The purpose of the Query Service is to allow users and objects to invoke queries on collections of other objects. The queries are declarative statements with predicates and include the ability to specify values of attributes; to invoke arbitrary operations; and to invoke other Object Services.
- Licensing Service - The purpose of the Query Service is to allow users and objects to invoke queries on collections of other objects. The queries are declarative statements with predicates and include the ability to specify values of attributes; to invoke arbitrary operations; and to invoke other Object Services.
- Property Service - Provides the ability to dynamically associate named values with objects outside the static IDL-type system.
Defines operations to create and manipulate sets of name-value pairs or name-value-mode tuples. The names are simple OMG IDL strings. The values are OMG IDL anys. The use of type is significant in that it allows a property service implementation to deal with any value that can be represented in the OMG IDL-type system. The modes are similar to those defined in the Interface Repository AttributeDef interface.
- Time Service - Enables the user to obtain current time together with an error estimate associated with it. Consists of two services, hence defines two service interfaces:
- Time Service manages Universal Time Objects (UTOs) and Time Interval Objects (TIOs), and is represented by the TimeService interface.
- Timer Event Service manages Timer Event Handler objects, and is represented by the TimerEventService interface.
- Security Services - The security functionality defined by this specification comprises:
- Identification and authentication of principals (human users and objects which need to operate under their own rights) to verify they are who they claim to be.
- Authorization and access control - deciding whether a principal can access an object, normally using the identity and/or other privilege attributes of the principal (such as role, groups, security clearance) and the control attributes of the target object (stating which principals, or principals with which attributes) can access it.
- Security auditing to make users accountable for their security related actions. It is normally the human user who should be accountable. Auditing mechanisms should be able to identify the user correctly, even after a chain of calls through many objects.
- Security of communication between objects, which is often over insecure lower layer communications. This requires trust to be established between the client and target, which may require authentication of clients to targets authentication of targets to clients. It also requires integrity protection and (optionally) confidentiality protection of messages in transit between objects.
- Non-repudiation provides irrefutable evidence of actions such as proof of origin of data to the recipient, or proof of receipt of data to the sender to protect against subsequent attempts to falsely deny the receiving or sending of the data.
- Administration of security information (for example, security policy) is also needed.
- Trader Object Service - The Object Trader Service provides a matchmaking service for objects.
The Service Provider registers the availability of the service by invoking an export operation on the trader, passing as parameters information about the offered service. The export operation carries an object reference that can be used by a client to invoke operations on the advertised services, a description of the type of the offered service (i.e., the names of the operations to which it will respond, along with their parameter and result types), information on the distinguishing attributes of the offered service.
The offer space managed by traders may be partitioned to ease administration and navigation. This information is stored persistently by the Trader. Whenever a potential client wishes to obtain a reference to a service that does a particular job, it invokes an import operation, passing as parameters a description of the service required. Given this import request, the Trader checks appropriate offers for acceptability. To be acceptable, an offer must have a type that conforms to that requested and have properties consistent with the constraints specified by an imported.
Trading service in a single trading domain may be distributed over a number of trader objects. Traders in different domains may be federated. Federation enables systems in different domains to negotiate the sharing of services without losing control of their own policies and services. A domain can thus share information with other domains with which it has been federated, and it can now be searched for appropriate service offers.
- Collection Service - Collections are groups of objects which, as a group, support some operations and exhibit related to the nature of the collection rather than to the type of object they contain. Examples of collections are sets, queues, stacks, lists, binary, and trees. The purpose of the Collection Object Service is to provide a uniform way to create and manipulate the most common collections generically. Examples of collections are sets, queues, stacks, lists, binary, and trees. For example, sets might support the following operations: insert new element, membership test, union, intersection, cardinality, equality test, emptiness test, etc.
CORBA Overview, by Doug Schmidt
The Java Tutorial - JavaTM IDL
Tutorial
on Distributed Objects
CORBA
White Papers