CORBA (Common Object Request Broker Architecture)
Distributed objects are the next wave in Internet innovation.
CORBA, the Common Object Request Broker Architecture defined by the
Object Management Group (OMG), specifies how software objects
distributed over a network can work together without regard to client
and server operating systems and programming languages. CORBA is a
complete distributed object platform. It extends applications across
networks, languages, component boundaries, and operating systems. A
CORBA Object Request Broker (ORB) connects a client application with the
objects it wishes to use. The client application does not need to know
whether the object resides on the same computer or on a remote computer
elsewhere on the network. The client application needs to know only two
pieces of information: the object's name and how to use the object's
interface. The ORB takes care of the details of locating the object,
routing the request, and returning the result.
CORBA grew at the same time as three influential trends, which lent credence to the CORBA vision. First, the software development community realized the importance of object-oriented programming techniques, even though they’d been around for the better part of two decades. Second, industry leaders - including IBM, Microsoft, and Apple - were advocating new application models based on small, task-specific components instead of large, general-purpose monoliths. The components would be easy to write and update, since they were small. Developers could more conveniently, and cheaply, upgrade only those parts of their software that were out of date, and users wouldn't have to purchase entirely new versions of the entire package. And the small components could be distributed over a network more easily than their gargantuan ancestors. The more enlightened of these component architectures promised a cross-platform future, where all components could work together entirely independent of the underlying operating system.
CORBA grew at the same time as three influential trends, which lent credence to the CORBA vision. First, the software development community realized the importance of object-oriented programming techniques, even though they’d been around for the better part of two decades. Second, industry leaders - including IBM, Microsoft, and Apple - were advocating new application models based on small, task-specific components instead of large, general-purpose monoliths. The components would be easy to write and update, since they were small. Developers could more conveniently, and cheaply, upgrade only those parts of their software that were out of date, and users wouldn't have to purchase entirely new versions of the entire package. And the small components could be distributed over a network more easily than their gargantuan ancestors. The more enlightened of these component architectures promised a cross-platform future, where all components could work together entirely independent of the underlying operating system.
Introduction of CORBA Technology
The Common Object Request Broker Architecture (CORBA) is an
emerging open distributed object computing infrastructure being
standardized by the Object Management Group (OMG). CORBA automates many
common network programming tasks such as object registration, location,
and activation; request demultiplexing; framing and error-handling;
parameter marshalling and demarshalling; and operation dispatching. The
following figure illustrates the primary components in the OMG
Reference Model architecture.
• Object Services -- These are
domain-independent interfaces that are used by many distributed object
programs. For example, a service providing for the discovery of other
available services is almost always necessary regardless of the
application domain. Two examples of Object Services that fulfill this
role are:
o The Naming Service -- which allows clients to find objects based on names;
o The Trading Service -- which allows clients to find objects based on their properties.
• Common Facilities -- Like Object Service interfaces, these interfaces are also horizontally-oriented, but unlike Object Services they are oriented towards end-user applications. An example of such a facility is the Distributed Document Component Facility (DDCF), a compound document Common Facility based on OpenDoc. DDCF allows for the presentation and interchange of objects based on a document model, for example, facilitating the linking of a spreadsheet object into a report document.
• Domain Interfaces -- These interfaces fill roles similar to Object Services and Common Facilities but are oriented towards specific application domains. For example, one of the first OMG RFPs issued for Domain Interfaces is for Product Data Management (PDM) Enablers for the manufacturing domain. Other OMG RFPs will soon be issued in the telecommunications, medical, and financial domains.
• Application Interfaces - These are interfaces developed specifically for a given application. Because they are application-specific, and because the OMG does not develop applications (only specifications), these interfaces are not standardized. However, if over time it appears that certain broadly useful services emerge out of a particular application domain, they might become candidates for future OMG standardization.
o The Naming Service -- which allows clients to find objects based on names;
o The Trading Service -- which allows clients to find objects based on their properties.
• Common Facilities -- Like Object Service interfaces, these interfaces are also horizontally-oriented, but unlike Object Services they are oriented towards end-user applications. An example of such a facility is the Distributed Document Component Facility (DDCF), a compound document Common Facility based on OpenDoc. DDCF allows for the presentation and interchange of objects based on a document model, for example, facilitating the linking of a spreadsheet object into a report document.
• Domain Interfaces -- These interfaces fill roles similar to Object Services and Common Facilities but are oriented towards specific application domains. For example, one of the first OMG RFPs issued for Domain Interfaces is for Product Data Management (PDM) Enablers for the manufacturing domain. Other OMG RFPs will soon be issued in the telecommunications, medical, and financial domains.
• Application Interfaces - These are interfaces developed specifically for a given application. Because they are application-specific, and because the OMG does not develop applications (only specifications), these interfaces are not standardized. However, if over time it appears that certain broadly useful services emerge out of a particular application domain, they might become candidates for future OMG standardization.
How CORBA Works:
A CORBA Object Request Broker (ORB) is the middleware that
establishes the client-server relationship between objects. Using an
ORB, a client object can invoke a method on a server object that can be
on the same machine or across a network. The ORB intercepts the call and
finds an object that can implement the request, pass it the
parameters, invoke its method, and return the results. CORBA, like
SQL, provides both static and dynamic interfaces to its services. The
client does not have to know the object's location, its programming
language, its operating system, or any other system aspects that are not
part of an object's interface. Also, the client and server roles are
dynamic: an object on the ORB can act as either client or server,
depending on the occasion
An object can be both a client and a server: when it provides services to another object, it's a server; when it requests services from another object, it's a client. The CORBA architecture provides a set of services that help objects interact with each other. (In the CORBA world, services means both the services provided by the CORBA architecture to help objects communicate and the functionality provided by the objects themselves.)
Interface Definition Language
CORBA also defines a special language - IDL -which provides a
language-neutral way of describing a specification for a CORBA object
and the service(s) it provides. IDL lets components written in different
languages communicate with each other using IIOP and the rest of the
CORBA architecture. (Objects with IDL-defined interfaces are said to be
CORBA-compliant.). Currently, it’s easiest to provide an IDL
specification for objects written in C, C++, and Java, because the OMG
has completed mapping schemes - or translation guides - from IDL to
those languages. Also, there are already compilers that employ those
mapping schemes to translate IDL to C, C++, and Java. (OMG is currently
working on IDL mappings for ADA, SmallTalk, and other languages.)CORBA objects may sit on different types of systems - Windows or Unix servers, IBM 3090 or DEC VAX mainframes. They may even be written in different languages. In fact, the objects don't need any inherent knowledge of each others' existence. As long as the interface to the service provided by the object is written in IDL, all the objects can communicate and use each others' services through ORBs sitting on clients, servers, database systems, mainframes, and other systems on the network.
