CORBA Distributed Software

It is tempting to look at CORBA and quickly determine that it is simply a network transport layer for building software.
Or put another way, that CORBA answers the question: how will application component XYZ talk with component ABC?
While this is true and of significant value, it is nice to have a debugged, optimized tool that allows easy creation of distributed applications - CORBA is actually much more. As we explore CORBA we will see that the specification provides a sophisticated framework for both object and application level services that is designed to be as open as possible at every level. This focus on openness is CORBA's greatest strength. As we move forward, we will repeatedly take the time to ask "Why CORBA?" The Common Object Request Broker Architecture (CORBA) [OMG:95a] is an emerging open distributed object computing infrastructure being standardized by the Object Management Group (OMG). CORBA automates many common network programming tasks such as

1. object registration,
2. location, and
3. activation.

At this point, it's important to realize why the (OMG) Object Management Group got involved. Methodologists like to think that they are important. But I do not think that the requirements would even be heard by the OMG. What got the OMG involved were the requirements of tools vendors, all of which were frightened that a standard controlled by Rational would give Rational tools an unfair competitive advantage. As a result, the vendors energized the OMG to do something about it, under the banner of CASE tool interoperability. This banner was important, as the OMG was all about interoperability. The idea was to create a UML that would allow CASE tools to freely exchange models.

Gain a basic conceptual understanding of what CORBA provides.
CORBA exists as a standardized way to create distributed software systems. CORBA allows the components of an application to exist across a network of computers, while still allowing the components to interact as a whole. The general concept, as depicted below, is often called distributed computing.

You are probably familiar with applications that perform work using other distributed computing models, but that do not make use of CORBA. In fact, the entire World Wide Web is a perfect example. Common Object Request Broker Architecture (CORBA) is an architecture and specification for creating, distributing, and managing distributed program objects in a network. The architecture allows programs at different locations and developed by different vendors to communicate in a network through an "interface broker." CORBA was developed by a consortium of vendors through the (OMG) Object Management Group, which currently includes over 500 member companies. Both International Organization for Standardization (ISO) and X/Open have authorized CORBA as the standard architecture for distributed objects (which are also known as components). CORBA 3 is the latest level.

Question: How does CORBA fit other distributed computing models? Programming with sockets is a much lower level activity than CORBA development. A socket basically consists of two endpoints, usually two computers connected across a network. Those that have done it will tell you that it has a steep learning curve, requires working at the data buffer level, and can be difficult to debug and optimize.

RPCs were a result of the software industry realizing how valuable sockets programming could be, while desiring the ability to build distributed applications at a higher level. RPCs solidified the concepts of client and server by allowing a client to request services and have them provided across a network. The key to the model is that Remote code in a Procedure at the server is run as a result of a Call by the client. RPCs allowed developers to make use of sockets at a higher, more intuitive level. CORBA borrows heavily from the RPC model, but strives to make the entire process as open as possible.

In addition to sockets and RPCs, many database vendors and third party tools vendors have created development tools that allow database access and other forms of distributed computing. The primary weakness in these tools is that they only interoperate with tools from the same vendor and tend to make it very hard to allow distributed applications to keep up with changing business processes. This problem does not exist in CORBA-based systems.

In distributed computing a (RPC) remote procedure call is defined as a computer program that causes a procedure to execute in another address space (commonly on another computer on a shared network), which is coded as if it were a local procedure call, without the programmer explicitly coding the details for the remote interaction. The programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. This is a form of client-server interaction (caller is client, executer is server), typically implemented via a request-response message-passing system. The object-oriented programming analog is remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures is largely the same whether it is local or remote, but usually they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders of magnitude slower and less reliable than local calls, so distinguishing them is important. RPCs are a form of inter-process communication (IPC), in that different processes have different address spaces: if on the same host machine, they have distinct virtual address spaces, even though the physical address space is the same; while if they are on different hosts, the physical address space is different. Many different (often incompatible) technologies have been used to implement the concept.

When the Object Management Group (OMG) issued a Request For Proposals (RFP) for a standard mapping of CORBA to C++, these developers and other groups submitted their mappings to the standardization process. As is common for OMG RFP submissions, the submitting groups joined forces to try to reach consensus and arrive at a single C++ mapping specification that would draw from the strengths of all the submitted mappings. The process of producing a single standard C++ mapping for CORBA took approximately 18 months, lasting from the spring of 1993 until the fall of 1994. For technical reasons, such as the richness of C++ and its support for diverse programming styles, the consensus-building process was not an easy one. At one point, because of the competitive spirit and political nature of some of the parties involved (both characteristics are inevitable in any industry standards group), the C++ mapping standardization effort fell apart completely. However, the need for a standard C++ mapping eventually overcame all obstacles, and the standardization was completed in the fall of 1994.
The C++ mapping was first published with CORBA 2.0. Since its adoption, the mapping has been revised several times to fix flaws and to introduce minor new functionality. Despite this, the mapping has remained surprisingly stable and portable even while the C++ language was undergoing its own standardization process. The standard C++ mapping removed a major obstacle to broad acceptance of CORBA because it created source code portability, at least for the client side. The server side still suffered from portability problems until CORBA 2.2.