CORBA is a specification for creating distributed object-based applications. The CORBA architecture and specification were developed by the Object Management Group (OMG). The OMG is a consortium of several hundred information systems vendors. The goal of CORBA is to promote an object-oriented approach to building and integrating distributed software applications.
The CORBA specification provides a broad and consistent model for building distributed applications by defining:
The CORBA specification describes how to develop an implementation of CORBA. It also describes programming language bindings that developers use to develop applications.
To illustrate the advantages of using the CORBA architecture, this section compares early client/server application development techniques to CORBA development techniques.
Client/server computing is an application development methodology that allows programmers to distribute processing among networked machine systems, thus enabling more efficient use of machine resources. In client/server computing, an application consists of two parts: the client application and the server application. These two applications typically run on different machines, connected by a network, as shown in the following figure.
The client application makes requests for information or services and typically provides users with a means to display results. The server application fulfills the requests of one or more client applications and usually performs compute-intensive functions.
The key advantages of the client/server model are:
For example, desktop systems provide many business users with an easy-to-use graphical environment for displaying information. However, desktop systems may have restricted disk space and memory and are typically single-user systems. Larger, more powerful machine systems are better suited to perform compute-intensive functions and provide multiple user access and shared database access.
Therefore, larger systems usually run the server portion of the application. In this way, distributed desktop systems and networked servers provide a perfect computing environment for deploying distributed client/server applications.
Although the non-CORBA client/server approach provides the means to distribute processing in a heterogeneous network, it has the following disadvantages:
Client/server applications might use the same, single network protocol or different protocols. If they use multiple protocols, the applications must logically repeat the protocol-specific code for each network.
For example, some machines read an integer value from the lowest byte address to the highest (little endian), while others read the highest byte address to the lowest (big endian). Some machine systems might also use different formats for floating-point numbers or text strings. If an application sends data to a machine that uses a different data format, but the application does not convert the data, the data is misinterpreted.
Transporting data over the network and converting it to its proper representation on the target system is called data marshaling. In many non-CORBA client/server models, applications must perform all data marshaling. Data marshaling requires that the application use features of the network and operating system to move data from one machine to another. It also requires that the application perform all data format translations to ensure that the data is read in the same way it was sent.
The non-CORBA client/server approach ties the client and server applications together. Therefore, if either the client or server application changes, the programmer must change the interface, network address, and network transport. Additionally, if the programmer ports the client and server applications to a machine that supports a different network interface, the programmer must create a new network interface for those applications.
The CORBA model provides a more flexible approach to developing distributed applications. The CORBA model:
A CORBA client application knows only how to ask for something to be done, and a CORBA server application knows only how to accomplish a task that a client application has requested it to do. Because of this separation, developers can change the way a server accomplishes a task without affecting how the client application asks for the server application to accomplish the task.
In object-oriented computing, objects are the entities that make up the application, and operations are the tasks that a server can perform on those objects. For example, a banking application could have objects for customer accounts, and operations for depositing, withdrawing, and viewing the balance in the accounts.
The CORBA model handles all network interfaces. The applications see only objects. The applications can run on different machines and, because all the network interface code is handled by the ORB, the application does not require any network-related changes if it is later deployed on a machine that supports a different network protocol.
The CORBA model allows client applications to make requests to server applications, and to receive responses from them without direct knowledge of the information source or its location. In a CORBA environment, applications do not need to include network and operating system information to communicate; instead, client and server applications communicate with the Object Request Broker (ORB). The following figure shows the ORB in a client/server environment.
CORBA defines the ORB as an intermediary between client and server applications. The ORB delivers client requests to the appropriate server applications and returns the server responses to the requesting client application. Using an ORB, a client application can request a service without knowing the location of the server application or how the server application will fulfill the request.
In the CORBA model, client applications need to know only what requests they can make and how to make the requests; they do not need to be coded with any implementation details of the server or of the data formats. Server applications need only know how to fulfill the requests, not how to return data to the client application.
This means that programmers can change the way a server application accomplishes a task without affecting how the client application asks for the server application to accomplish that task. For example, as long as the interfaces between the client and the server applications do not change, programmers can evolve and create new implementations of a server application without changing the client application; in addition, they can create new client applications without changing the server applications.