CORBA 2.3.3 Administration Guide (NonStop CORBA 2.3.7+)

For each object type, such as your shopping cart, you define its interface in OMG IDL. The interface definition fixes the
operations that can be performed on objects of that type, and the input and output parameters for each. This interface
definition is independent of your programming language, but maps to all of the popular programming languages through a set
of OMG standards: OMG has standardized mappings for C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, and
IDLscript.
This is the essence of CORBA. It enables interoperability, with all of the transparencies claimed. The interface to each object
is defined very strictly. But, in contrast, the implementation of an objectits running code, and its datais hidden from the rest
of the system (that is, encapsulated) behind a boundary that the client may not cross. Clients access objects only through their
advertised interface, invoking only those operations that a specific object chooses to expose, with only those input and output
parameters that are included in the invocation, as shown in Figure 11.
Figure 1.1. A Request Passing From Client to Object Implementation
You compile your IDL into client stubs and object skeletons, and write your object (shown on the right) and a client for it (on
the left). Stubs and skeletons serve as proxies for clients and servers, respectively. Because IDL defines interfaces so strictly,
the stub on the client side has no trouble meshing perfectly with the skeleton on the server side, even if the two are compiled
into different programming languages, or even running on different ORBs from different vendors.
In CORBA, every object instance has its own unique object reference, an identifying electronic token. Clients use the object
references to direct their invocations, identifying to the ORB the exact instance they want to invoke (ensuring, for example,
that the books you select go into your own shopping cart, and not into your neighbors.) The client acts as if it is invoking an
operation on the object instance, but it is actually invoking the IDL stub which acts as a proxy. Passing through the stub on
the client side, the invocation continues through the ORB and the skeleton on the implementation side, to get to the object
where the invocation is executed.
The ORB is just one element within the OMG's Object Management Architecture. Also specified are interfaces for
lower-level Object Services and higher-level Common Facilities for building robust applications and systems. Examples
include the naming service for locating objects, event service for subscribing to and publishing messages, security,
transaction support, and object license and metering.
Server Side
The server side of CORBA begins with the specification of an interface in IDL. IDL is an object-oriented declarative
language for specifying server interfaces. IDL is not a programming language; that is, server implementations are not written
in IDL. Rather, IDL interface descriptions are mapped to a programming language for implementing the server. In IDL an