NAME

CORBA - Common Object Request Broker Architecture


DESCRIPTION

The CORBA standard is defined by the Object Management Group, or OMG. (http://www.omg.org/). CORBA allows software components on diverse and distributed platforms to interoperate by standardizing the way clients interact with objects, and specifies some aspects of the way objects are implemented. Distributed applications may be created transparently: it is usually unnecessary, except when considering performance, to be aware of an object's or client's location.

This page provides an overview of CORBA, the architecture. It is to be distinguished from the module of the same name, described in CORBA(3corba). The latter is one of several namespaces containing other definitions, defined by the CORBA specifications.

CORBA defines the following:

Object Request Broker (ORB)

Interactions between a client and an object are mediated by an ORB. ORBs may be created for each application, or they may be shared among applications. Client applications make requests to ORBs, and object implementations offering services to clients do so by associating themselves with an ORB through one of the ORB's object adapters.

Interface Definition Language (IDL)

IDL describes data structures, interfaces, functions, and other items relevant to client-object interaction. IDL has a syntax similar to C and C++. However, IDL is descriptive, and not procedural.

Object Adapters

An ORB's adapters connect the ORB to the object implementation. Client requests are passed by the ORB to the implementations through the adapters. Adapters also offer an API to the implementations. Implementations may, themselves, be clients of objects in the same or different ORBs.

The Portable Object Adapter is a well-defined adapter available on all ORBs. However, ORBs may also offer other adapters.

Language Mappings

IDL is not specific to any programming language. In order to use CORBA with C++, Java, or some other programming language, a mapping is defined from IDL to each such language. The mapping is strictly defined, allowing IDL compilers to be constructed. An IDL compiler takes IDL as an input, and creates definitions for the target language in the form of header files or other appropriate code. Theoretically, this makes an application portable to any ORB which supports that application's programming language.

The IDL compiler also creates a stub for each function call defined by the IDL definition. The client application calls the stub, and the stub talks to the ORB. Although (because of the language mapping) the API is portable, its interaction with the ORB is implementation specific. For this reason, each IDL compiler is specific to one ORB implementation.

There is an analogous mechanism one the adapter side, used for object implementations. For that, the IDL compiler must create a skeleton for each function and interface. There is a correspondence between a function's stub API and its skeleton API; however, the API at the client end is not exactly the same as the API at the server end. The language mapping defines the server mapping as it defines the client mapping, making object implementations theoretically portable among different ORBs supporting the implementations' programming language.

Inter-ORB Protocols

When an object is implemented on the same ORB used by a client application, then the ORB simply passes the request to the implementation through the appropriate adapter. However, when the client invokes the request on one ORB and the servant implementation is on a different ORB, the two ORBs must communicate between themselves to effect the request and to return the result. CORBA defines the general inter-ORB protocol (GIOP) for this purpose. GIOP may be layered over a variety of transport protocols. The specialization of GIOP for TCP/IP networks is the internet inter-ORB protocol (IIOP).

Interoperability with Other Object Models

An ORB optionally may support interoperability with non-CORBA object systems. Such ORBs must support non-CORBA protocols to talk with the other systems.

CORBA Component Model (CCM)

With object adapters, the implementation is intimately involved in the process of object creation, deployment, and destruction. For complex implementations, the model is unwieldy. The CCM introduces the concept of object containers, within which objects are deployed. The container itself participates in the lifecycles of the objects it encapsulates. CCM makes the implementation of object libraries feasible.

CORBA Services and Facilities

Although not part of the CORBA specification itself, OMG defines a variety of services and facilities which can be implemented as a partial basis for object based systems. These are roughly equivalent to standardized APIs. The syntax of each service and facility function is defined using IDL. Some of these services are required when implementing portions of CORB; for instance, CCM requires the availability of certain services.


CONTENTS

The interfaces and data structures described by CORBA are defined within IDL modules, which may be thought of as namespaces. The modules defined by CORBA and some important related specifications include:

BiDirPolicy

Defines a policy object specifying, for an inter-ORB connection, whether requests may be issued in both directions, or by one of the ORBs only.

Components

Contains basic definitions for the CORBA Component Model.

CORBA

Contains the primary, basic definitions for the CORBA specification.

CosClockService

Defines clocks of various types, synchronization, and related entities.

CosCollection

Contains definitions of services and structures to support the grouping of objects and for the manipulation of objects as a group.

CosConcurrencyControl

This module contains definitions belonging to the Concurrency Service, which mediates concurrent access to an object. (Think of locks, semaphores, mutexes, and the like.)

CosEventComm, CosEventChannelAdmin, CosTypedEventComm, CosTypedEventChannelAdmin

The modules define the Event Service, which interposes an "event channel" between objects to decouple communication between them.

CosExternalization, CosStream, CosExternalizationContainment, CosExternalizationReference

These modules define the Externalization Service, which defines protocols and conventions for externalizing and internalizing objects.

CosLicensing

Contains definitions of the Licensing Service, which provides mechanisms for producers to control the use of their intellectual property.

CosLifeCycle

Includes definitions of services and conventions for creating, deleting, copying, and moving objects.

CosNaming, NamingContext, BindingIterator

These modules define the Naming Service, which allows the creation of a form of tree-structured directory of object references. (It is not limited to trees, but that is how it is almost always used.)

CosNotification, CosNotifyFilter, CosNotifyComm, CosNotifyChannelAdmin, CosTypedNotifyComm, CosTypedNotifyChannelAdmin

These modules contain definitions for the Notification Service, which offers additional functionality beyond that provided by the Event Service.

CosPersistentState

Contains definitions allowing persistent information to be managed and used as storage objects.

CosPropertyService

This module defines the Property Service, which associates typed, named values with objects.

CosQuery, CosQueryCollection

This module defines query operations on collections of objects.

CosRelationships, CosObjectIdentity, CosGraphs

These contain definitions of services and structures allowing the explicit representation of entities and the relationships among them.

CosTrading, CosTradingDynamic, CosTradingRepos

These modules contain definitions belonging to the Trading Object Service, which facilitates the offering and the discovery of instances of services of particular types.

CosTransactions, CosTSPortability, CosTSInteroperation

The modules define the Transaction Service, which enables multiple, distributed objects to cooperate, providing atomic, consistent, isolated, and durable transactions to clients.

CSI

Contains definitions for Common Secure Interoperability.

CSSIOP

Defines Common Secure Interoperability tags for Interoperable Object References.

Dynamic

Defines some interfaces used by the PortableInterceptor module.

DynamicAny

Defines a facility for the interpretation of CORBA::Any values.

FT

Contains definitions for Fault Tolerant CORBA, which replicates service objects and recovers from failures among the replicate service objects. Clients normally are unaware of replication or of recovery; these operations are performed transparently.

GIOP

Defines the messages and data structures for the General Inter-ORB Protocol.

GSSUP

Defines Generic Security Service username and password tokens.

IIOP

Defines the messages and data structures for the Internet Inter-ORB Protocol.

IOP

Contains definitions for object references encoded for exchange among ORBs.

MessageRouting

Contains definitions for communication among request and reply routers.

Messaging

Defines structures and interfaces used for messaging quality of service and asynchronous method invocation.

MIOP

Contains definitions for the Unreliable Multicast Inter-ORB Protocol.

PortableInterceptor

Defines structures and interfaces for hooks within an ORB that permit interruption and modification of normal operations and data flow by applications.

PortableServer

Contains definitions for the interfaces between an ORB's object adapter and object implementations.

Reflection

Defines mechanisms for an application to learn the interfaces and attributes of an object.

RTCORBA

Contains definitions of features to facilitate the construction of real time, distributed applications.

RTPortableServer

Contains extensions to PortableServer to allow implementations which are aware of scheduling and related real-time characteristics.

Security, SecurityLevel1, SecurityLevel2, SecurityAdmin, NRService, SecurityReplaceable, SECIOP, SSLIOP, DCE_CIOPSecurity

These modules define various aspects of the Security Service, which offers various features such as authentication, access control, non-repudiation, and auditing.

SendingContext

Defines a call-back mechanism so that a receiving ORB can interrogate the sending ORB regarding a received message.

TimeBase, CosTime, CosTimerEvent

These modules contain definitions of services and structures enabling a client to get and manipulate time, to manage time-triggered event handlers and the events that they handle.


NOTES

(none)


SEE ALSO

CORBA(3corba)


COPYRIGHT

Copyright 2012 Michael Marking. This document is distributed as part of corbadoc, a documentation-only package with the goal of describing the main CORBA-related definitions from the OMG specifications. This is version corbadoc-0.1.3-prototype, released 2011.12.23. corbadoc is an incomplete work in progress; this is a snapshot release. New releases will be posted at http://www.tatanka.com/software/corbadoc/.

The corbadoc documents, including this one, are licensed under the GNU Free Documentation License, v.1.3.