The Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA®) middleware standard enables software applications to invoke operations on distributed objects without concern for object location, programming language, operating system platform, communication protocols, interconnections or hardware.
CORBA remains the most successful open standard in supporting distributed heterogeneous mission critical systems that require exceptional levels of performance and QoS. PrismTech's OpenFusion provides the most comprehensive range of CORBA middleware products available from any vendor.
CORBA uses an interface definition language (IDL) to specify the interfaces that objects will present to the outside world. CORBA then specifies a “mapping” from IDL to a specific implementation language such as C++ or Java. Standard mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Ruby, Erlang, Tcl and even VHDL implemented by object request brokers (ORBs) written for those languages.
A language mapping requires the developer to create some IDL code that represents the interfaces to his objects. Typically, a CORBA implementation comes with a tool called an IDL compiler which converts the developer's IDL code into some language-specific generated code. A traditional compiler then compiles the generated code to create the linkable-object files for the application. the figure below illustrates how the generated code is used within the CORBA infrastructure.
The CORBA specification dictates that there shall be an object request broker (ORB) through which the application interacts with other objects. In practice, the application simply initializes the ORB, and accesses an internal Object Adapter which maintains such issues as reference counting, object (& reference) instantiation policies, object lifetime policies, etc. The Object Adapter is used to register instances of the generated code classes. Generated Code Classes are the result of compiling the user IDL code which translates the high-level interface definition into an OS- and language-specific class base for use by the user application. This step is necessary in order to enforce the CORBA semantics and provide a clean user processes for interfacing with the CORBA infrastructure.
The key components of a CORBA ORB are as follows:
- Object - This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant.
- Servant - This is an implementation programming language entity that defines the operations that support a CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada.
- Client - This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args). The remaining components in Figure 1 help to support this level of transparency.
- Object Request Broker (ORB) - The ORB provides a mechanism for transparently communicating client requests to target object implementations. The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.
- ORB Interface - An ORB is a logical entity that may be implemented in various ways (such as one or more processes or a set of libraries). To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB. This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface described below.
- CORBA IDL stubs and skeletons - CORBA IDL stubs and skeletons serve as the "glue" between the client and server applications, respectively, and the ORB. The transformation between CORBA IDL definitions and the target programming language is automated by a CORBA IDL compiler. The use of a compiler reduces the potential for inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler optimizations.
- Dynamic Invocation Interface (DII) - This interface allows a client to directly access the underlying request mechanisms provided by an ORB. Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and oneway (send-only) calls.
- Dynamic Skeleton Interface (DSI) - This is the server side's analogue to the client side's DII. The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing. The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons.
- Object Adapter - This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).
Related Technologies
Real-Time CORBA | CORBA/e | MinimumCORBA | CORBA IDL | CORBA CCM | CORBA COS | CORBA & DDS | Open Source CORBA
Related PrismTech OpenFusion CORBA Products
OpenFusion TAO | OpenFusion JacORB | OpenFusion CORBA Services | OpenFusion RTOrb Java Edition | OpenFusion RTOrb Ada Edition | OpenFusion e*ORB | Xtradyne Security
