Corba Architecture Conclusion
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'll look a bit at the higher level again, to be sure we understand how all of the details fit together as a whole.
General Request Flow
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.
Corba Fundamentals - Quiz