Perhaps the best way to illustrate the workings of a CORBA object is to walk through the interactions between a CORBA Client and a CORBA Server. Lets start by looking at the client side of the application.
An application invokes a CORBA object by calling a client-side IDL stub. This stub acts as a static interface to a remote object's services. Client (and server) IDL stubs are precompiled by an IDL compiler. A client has a separate IDL stub for each interface it invokes on the server. To the client, the IDL stub acts like a local procedure call. The calling program has no notion that it may be invoking a service on a physically remote object. The IDL stub performs an operation called marshaling. Marshaling encodes and decodes the method being invoked and its parameters so that it can be passed transparently over networks between clients and servers created using different languages, different compilers, and even different host operating systems and hardware platforms.
An application may also use CORBA's Dynamic Invocation Interface (DII) to discover at run time additional object methods that it may want to invoke. The dynamic invocation interface uses a standard API for looking up metadata used to define the server's interface, generating the parameters, issuing the remote object call, and getting back the results.
The application may also use CORBA's Interface Repository APIs to obtain and possibly modify the description of any registered CORBA object, including the methods supported and their parameters. This runtime distributed database acts as a dynamic metadata repository for the ORB. Every object that lives in the ORB is self-describing using information contained in the interface repository.
Finally, a client application can make use of the ORB Interface to perform local services that may be needed by the application. Such services include things like converting object references to text strings and vice versa. For purposes of identification, every CORBA object has a globally unique repository ID. This ID is a string consisting of a three level name hierarchy that is globally unique across any ORB, independent of the vendor or physical location of the object.
Once a client side stub is invoked, the method information travels over the ORB (and possibly between ORBs using the IIOP) to a server object. A description of what happens on the server follows .
The client call is sent to a Server IDL Stub, also referred to as a skeleton. The skeleton provides static interfaces for a service provided by the server. A separate skeleton is created for each exported server service by an IDL compiler. Just like on the client side, the IDL compiler hides all the specifics of data marshaling and network protocols from the application programmer.
The Dynamic Skeleton Interface (DSI) is the server counterpart to the Dynamic Invocation Interface (DII) on the client. The DSI provides a runtime binding mechanism for incoming method calls that do not have IDL-based skeletons. This is done by examining the parameter values of the incoming message and determining the target object and method.
An Object Adapter provides the runtime environment for instantiating server objects, passing requests to them, and assigning them object IDs. The Object Adapter also is responsible for registering the classes it supports and their runtime instances with the Implementation Repository. In the current CORBA 2.0 specification, each ORB must support a Basic Object Adapter (BOA). The upcoming CORBA 3.0 specification also includes a portable version of the BOA, called the Portable Object Adapter (POA).
The Implementation Repository provides a runtime repository of information for every class a server supports, all instantiated objects, and their object IDs. The Implementation Repository is also used to store other administrative data such as security information and debugging information.