The CORBA Programming Model

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:

•	An object model for building distributed applications.

•	A common set of application programming objects to be used by the client and server applications.

•	A syntax for describing the interfaces of objects used in the development of distributed applications.

•	Support for use by applications written in multiple programming languages.

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.

Pre-CORBA Approach to Client/Server Development

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:

•	Computing functions run on the most appropriate machine system.

•	Developers can balance the load of application processing among several servers.

•	Server applications can be shared among numerous client applications.

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:

•	For communications, the client application must know how to access the server application, including any necessary network protocol information.

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.

•	Applications must handle data format conversions when they are integrated with machines that use different data formats.

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.

•	There is less flexibility for extension of the application.

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.

CORBA Approach to Client/Server Development

The CORBA model provides a more flexible approach to developing distributed applications. The CORBA model:

•	Formally separates the client and server portions of the application

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.

•	Logically separates an application into objects that can perform certain tasks, called operations

CORBA is based on the distributed object computing model, which combines the concepts of distributed computing (client and server) and object-oriented computing (based on objects and operations).

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.

•	Provides data marshaling to send and receive data with remote or local machine applications

For example, the CORBA model automatically formats for big or little endian as needed. (Refer to the preceding section for a description of data marshaling.)

•	Hides network protocol interfaces from the applications

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.