CORBA TUTORIAL

In this tutorial, we will introduce a concept that relates to distributed networks. The mentioned concept, eventually was translated to a tool that makes our life easier. That tool is actually an architecture and is called CORBA.

(CORBA – an acronym for Common Object Request Broker Architecture).

To understand what CORBA is, let us start with an analogy that will clarify the problem, and the motivation for developing CORBA. After that, we continue by defining some keywords that we will use along the tutorial, and finally we will get straight to the point – understanding the architecture.

Suppose you are a client, sitting at home, and you want to buy something that is called “Chakalaka”.

The only thing you know is that the mentioned thing does exist, but you do not know in which country, in which shopping-network etc. In order to achieve this thing, you might open golden-pages, ask friends and so on. Suppose that after a great deal of effort you realize that you can get the Chakalaka only in Iran. So, you have a problem because the Iranians refuse talking to you in English on the phone, and you are not familiar with the Iranian mentality, way of talking, places etc.

As you are perplexed, a friend tells you a priceless secret. He tells you that there is a place called “ORB”.

You can reach that place by phone. That place is a nerves-center. Meaning, that it is a very big building and you can find there many people. Those people are like ambassadors. They are representatives from a large range of countries. You can find there an Israeli, an American, a Frenchman, a Japanese man, a woman from Libya, an Iranian and other. All those people can communicate between themselves in English.

Now, suppose you are an Israeli that lives in Tel-Aviv, and the only language you know is Hebrew. You pick up the phone and dial the ORB number. The Israeli representative answers you and you ask for the desired “Chakalaka” (Although you two speaking by English, the sure thing is that you both have the same mentality). He collects your request, check out with his friends in the room if somebody is familiar with “Chakalaka” and the Iranian person say that he is.

The Iranian person, who knows exactly how to search things in his origin country, makes all the arrangements to satisfy your request. After a couple of days, you get your “Chakalaka” By mail.

Now, you ask yourself: Should I know the Persian language ? Should I know how to communicate Iran by phone? Should I know places in Iran ? Should I know at all, where on the globe, the Chakalaka exist?

The answer to all of these questions is NO. The only thing that you should know is how to dial the phone-number of the ORB, and ask for your request. The people that are manning the ORB, set things right, and communicate a server in other place in the world, to satisfy you.

A great idea Ha ?

The analogy above is the essence of the CORBA concept.

As software became more complex, a new feature was invented – called “Object”. An object is a software item that encapsulates data and methods. The methods are operations that can manipulate the data. The way of programming and thinking by objects, rather than the way we used before – procedures, functions and structures, is called “Object-Oriented Programming”.

So, an object is a basic computational unit of a defined data and operations. Requests made on an object are called messages (or methods). Objects may support more than one method.

The object has several methods that implement its interface. An interface to an object is the message protocol used to request services from it. An object’s interface consists of an object name and its set of valid methods.

By the method’s name, you can send it parameters along with return values and exceptions.

A method’s implementation is the code that is executed and produces the desired operation.

The interface of an object is the contract that it offers publicly. An object’s contract is a guarantee that invoking one of its methods using the specified signature produces either the result or exceptions that are specified. A contract consists of invariants which are properties that must always remain true.

The provider of a contract (services) is a server. The beneficiary of a contract is a service requester also known as a client. A client requests a service. A requester invokes a method on a provider. Sometimes this is referred to as the client sending a message to a server.

There are two more object-oriented programming properties:

Inheritance – The ability to define a new (specialized) class by reusing a previous (generalized) class while adding additional behavior or attributes.

Polymorphism – “Same interface, Different methods” – the capability of maintaining the same message, but with different implementations, at compile-time (overloading) or run-time (overriding).

A client is an application (process) that requests services from other applications (i.e., server processes).

A server is a software module (process) that accepts requests from clients and other servers and returns replies.

Client/Server is a relationship between two processes in which one makes a request to the other. It is possible for the server to in turn make a request to the client and thereby reverse the roles.

A client and a server can live together on the same platform, at separate platforms connected via intranet (LAN) or via the internet (WAN).

Clients are consumers of services and resources. Servers are providers of services and resources.

Task division between clients and servers is a difficult problem. In the traditional Client/Server we have a GUI on the client and a database on the server. One architecture can use the server to manipulate the data that it contains, and send the results to the client for its request, while the other can use the server only for containing large amounts of data, but the computations occur on the client.

This is a typical two-tier client-server environment.

Distribution is implemented in order to gain specialization, and resources economy. For example, suppose we have two computers – one fast and one slow, and a hardisk. So, if we want to maintain a database, the right thing to do is to make the faster one a client, the slower one a server, and of course, put the hardisk on the server. In that case, every platform is specialized in what it can do best, without losing efficiency (processing power).

Distributed Objects are often deployed in Client/Server co. Objects are servers. They respond to message requests. The server-side objects offer services and resources. Client-side objects request services and resources. The requester and the provider may live on separate machines within the network.

The combination of object-oriented and client-server brings the best of both worlds:

• Abstraction to reduce complexity and make development easier.
• Distribution to specialized hardware and consolidate shared data into a single maintainable location.

The interface is very important in distributed objects. The interface states what types of requests such an object is willing to receive.

O.M.G. – short for: Object Management Group

The Object Management Group is a non-profit consortium in 1989 with the purpose of promoting theory and practice of object technology in distributed computing systems. In particular, its goal is to reduce the complexity, lower the costs, and hasten the introduction of new software applications. Originally formed by 13 companies, OMG membership grew to over 650 software vendors, developers and users. It also has a good reputation for the ability to adopt specifications very quickly.

The OMG isn’t a standards organization. They don’t set industry standards. They promote the early adoption of de-facto standards. They do this by achieving consensus among the participants. OMG don’t produce software, Only specifications which are put together using ideas of OMG members who respond to Requests For Information (RFI) and Requests For Proposals (RFP). The strength of this approach is that OMG include the most powerful software companies interested in distributed object development

Now, is the first time you should recall the analogy that appears in the introduction of that tutorial. Remember the representatives of the leading countries that work in the ORB? So, they are not analogous to the leading companies but the languages they use, force little countries to use languages of leading countries, as little companies should accept the dictations of the big companies that are members of the OMG.

The Object Management Group invented CORBA.

CORBA – short for Common Object Request Broker Architecture. CORBA is OMG’s answer to the need for interoperability among the rapidly proliferating number of hardware and software products available today. CORBA is an architecture that enables pieces of programs, called objects, to communicate with one another regardless of what programming language they were written in or what operating system they are running on.

CORBA is an Application Programming Interface (API) and system definition specification; it is not a piece of code. It provides mechanism by which objects transparently make requests to and receive responses from other objects on different platforms in heterogeneous distributed environments.

In this model, clients request services from objects through a well-defined interface. This interface is specified in IDL (Interface Definition Language – defined by OMG). A client accesses an object by issuing a request to the object. The request is an event, and it carries information including an operation, the object reference of the service provider, and actual parameters.

The CORBA is composed of five major components:

• ORB Core
• IDL (Interface Definition Language)
• DII (Dynamic Invocation Interface)
• Interface Repository
• Object Adapters

 The figure above describes the basic CORBA architecture.

The central component of CORBA is the ORB (Object Request Broker). It encompasses all of the communication infrastructure necessary to identify and locate objects, handle connection management and deliver data. The ORB Core is the most crucial part of the ORB. It is responsible for communication of requests.

That explanation clarifies why, in the analogy, we have called the ORB – a nerves-center.

Stubs are a client-side invocation mechanism.

Skeletons are the server-side interface for requests.

CORBA takes care of passing requests from the client to wherever the object (server) is implemented.

An object adapter is something that supports various styles of object implementations.

It is unlikely that the ORB is a single component. It is defined by its interfaces. It delivers requests to objects and returns any output values back to clients. By using an ORB, the client can transparently invoke a method on a server object. After receiving the call the ORB finds an object that can implement the request. The client knows nothing about this object as we mentioned before. There are two ways in which clients can issue requests:

1. Static invocations via interface – specific stubs
2. Dynamic invocations via the DII (Dynamic Invocation Interface)

Once the ORB receives a request it performs the following operation:

• Locating an appropriate implementation code.
• Sending parameters to the object implementation and passing the control to it.
• Sending output values back to the client and passing the control to it.

Recall the analogy that appears in the introduction. We had there a person that dialed the ORB building, and delivered his request by English, although his mother tongue is Hebrew. And why is that? Because English is an international language. That is the idea by defining the IDL by OMG.

IDL describes object interfaces in a simple way. The clients should know just the object's interface to make requests. The servers reply these requests using the same interfaces. The specific details of the implementation are encapsulated in the server below its interface.

IDL is not another new programming language, it provides the client a way to define modules, interfaces, type-definitions and constants.

IDL compilers translate IDL modules into specific programming language modules.

The IDL syntax resembles the C++ syntax. In the following table we can see a short comparison between both syntax:

Stubs and skeletons are the intermediate adapter between client and server applications and the ORB. The transformation is performed by compiling IDL definitions using an IDL compiler and by that maintaining unity in definitions between the client and server applications.

The client side generates a mapping called 'stub'. The server side generates a mapping called 'skeleton'.

Each stub represents an object operation (request) which a client invokes (e.g. by calling a subroutine which represents the operation).

Each skeleton provides the interface through which a method receives a request.

For using the stubs, the client application has to call the methods in the stub that request a service from the object.

The following diagram shows the relationship between stub, skeleton and ORB:

The DII makes it possible to construct dynamically object invocations. I.e., the client can specify an object to be invoked with an operation to be performed and a set of parameters for the operation. The client's code gives an information about the performed operation and type of the parameters. The DII is not uniform, i.e. it is programming language mapping dependent.

Unlike IDL stubs, the DII allows clients to send one way or two way calls.

The invocation may be synchronous or asynchronous and the requests are reusable.

The DSI allows objects to be implemented using a dynamic implementation routine. Such a routine gets the entire request context and implements the operation in whatever way it chooses.

The Interface Repository is a component of the ORB which provides persistent storage of object interface definitions. In addition, it is also provides the following operations:

• The client can access interface definitions in order to dynamically build a request to a service unknown at compile time
• Request signatures type can be dynamically checked
• ORB to ORB interoperability

The Object Adapter helps the ORB with transferring requests to the objects and activating it. It also associates objects implementations with the ORB.

Other services the Object Adapter handles are generation and interpretation of object references and security of interactions.

It is most common that there are many different Object Adapters to fulfill needs of specific systems.

There are three policies that the OMG specifies on how Object Adapter may handle object implementation activation:

• Shared Server Policy - Multiple objects may be implemented in the same program.
• Unshared Server Policy - New server is started each time a request is received.
• Persistent Server Policy - The objects implementation is constantly active.

The CORBA components that we described before work together in thfollowing manner:

Let's assume that the client has a valid object reference to object implementation, it invokes an operation supported by that object. The request passes to the IDL and then directed by the IDL to the ORB. The ORB uses object reference in order to locate the object implementation. The ORB delivers the request into the Object Adapter that is managing that object. The Object Adapter brings the request to the IDL skeleton and from there it is passed to the object implementation. Return values, if there are any, are passed through the reversed route back to the client application.

As we have seen in the above tutorial, CORBA is a necessity in the new computerized world. As the English language plays the primary roll of communicating between people in far countries, cultures and mentalities after the age of Babylon-Tower, CORBA plays the roll of communicating between objects on far platforms and programming languages.

CORBA eventually helps us to keep our world a global-village, and it is clear that CORBA has a great future in front of it.

We won't be surprised if you heard nothing about CORBA yet. It is because CORBA is not an invention of one company, but a need of many companies that decided to cooperate and define it. Such a process takes time.

Lately we heard that BORLAND INTERNATIONAL company released version 4.0 of DELPHI that includes CORBA support. We are sure that in the near future, we will see much more releases such as BORLAND's.