Lesson 9

In this module, we learned about some of the basic parts of the CORBA architecture at a high level.
We explored CORBA's Object Management Architecure, which provides the foundation for most of the CORBA specification.
The next module drills down on what we have learned thus far and covers things at a more detailed level. We will take CORBA clients and CORBA servers and break them apart and look at how they are structured and what the different components do. Then we will look a bit at the higher level again, to be sure we understand how all of the details fit together as a whole.
Common Object Request Broker Architecture (CORBA) is an open, vendor-independent specification for an architecture and infrastructure that allows applications to communicate over networks. The core features of CORBA are:

1. A high-level Interface Definition Language (IDL), allowing applications to specify their distributed communication in an object-oriented fashion.
2. Standardised protocols, GIOP and IIOP, for on-the-wire CORBA communication.
3. A set of programming APIs to address the middleware needs of client to server connectivity.

These features allow all CORBA-based programs to interoperate, even though they may be written in almost any programming language, and running on almost any operating system or network.

The client application makes requests and the server application receives them and acts on them. Requests flow down from the client application, through the ORB, and up into the server application in the following manner.
The client can choose to make requests either using static stubs compiled into C++ from the object's interface definition or using the (DII) Dynamic Invocation Interface Either way, the client directs the request into the ORB core linked into its process. The client ORB core transmits the request to the ORB core linked with the server application. The server ORB core dispatches the request to the object adapter that created the target object. The object adapter further dispatches the request to the servant that is implementing the target object. Like the client, the server can choose between static and dynamic dispatching mechanisms for its servants. It can rely on static skeletons compiled into C++ from the object's interface definition, or its servants can use the Dynamic Skeleton Interface (DSI). After the servant carries out the request, it returns its response to the client application. CORBA supports several styles of requests.
When a client invokes a synchronous request, it blocks while it waits for the response. These requests are identical to remote procedure calls. A client that invokes a deferred synchronous request sends the request, continues processing, and then later polls for the response. Currently, this style of request can be invoked only using the DII. CORBA also provides a oneway request, which is a best-effort request that may not actually be delivered to the target object and is not allowed to have responses. ORBs are allowed to silently drop oneway requests if network congestion or other resource shortages would cause the client to block while the request was delivered.
A future version of CORBA (very likely version 3.0) will also support asynchronous requests that can be used to allow occasionally connected clients and servers to communicate with one another. It will also add support for making deferred synchronous calls using static stubs as well as the DII. The next few sections describe the CORBA components required to make requests and to get responses.

Before we move on, take this short quiz about the material we've just covered.
Corba Fundamentals - Quiz