CORBA defanged (Part I)
by Niranjan Ramakrishnan

Network means Net Worth
If asked to point out an area of computer technology where signal (no pun intended) progress has been achieved over the last decade, most insiders would put networking among the top three, if not at the top. Not that any certificate is required from these experts. The rise of a phalanx of networking companies bears ample witness to the success of the technology. The mascot of the networking pageant is without doubt the Internet - the rate at which whose doubling rate is touted is itself doubling by the minute.

Networking spawns Client/Server
Networking forms the bedrock of the client/server computing model. Companies have for many years now focused on what is called Client/Server technology, that is, technology which enables part of the processing to be done on a central machine (called the server), and part to be done on a peripheral computer (called the client). Thus, the client could be as complex or simple as the needed, while the server would be a repository of data and processing power. The efficacy of this scheme lies in its similarity to existing business models, where the Head Office or Corporate Office makes major decisions, while branch offices make smaller, more localized, decisions.

Client/Server can be restrictive
Clearly, for such a setup to work, a program on the client computer would need to communicate with a program on the server computer, and the era of client server applications was upon us. Applications were designed such that the tasks to be performed on the server and client were suitably apportioned. While this worked for specific needs, it did not have the flexibility which would allow a client application to be written which could, say, take advantage of a server application not specifically written for that client.

Enter the Object...
This is where object technology began to engage the serious attention of the client/server industry. Objects, by their very nature, are written to advertise a set of services, and do not depend on who uses them. As such they were the ultimate servers - theirs not to question why (or who, when or wherefore), but merely to execute their contracts. Several solutions emerged out of this need, but a couple of survivors remain - CORBA and DCOM. We shall discuss CORBA in this article, discuss COM/DCOM in an upcoming article, and discuss their relative merits thereafter. The subject of object-interoperability became a hot one.

What is CORBA?
One of the developments in the mid-late 1980's was the formation of the Object Management Group (http://www.omg.org), a consortium of a large number of organizations (claimed to be the largest such consortium in the computer industry) to put together some standards for object-interoperability. The result was a specification for a Common Object Request Broker Architecture (CORBA). The idea was that if applications were written to conform to this architecture, they would be able to interact with other applications which also used this architecture - and since a wide variety of companies were signed up to conform to this architecture, applications would have access to a world of other applications with whom they could communicate and trade services.

The best way to visualize CORBA is to draw an analogy to brokers in the real world.

When you buy or sell a stock, you never deal directly with the other party. When you buy or sell a home, you seldom pick up the phone and call the seller or buyer. Instead, you go through your broker. You put in an order (CORBA, not wishing to offend the sensibilities of anyone in its large membership, calls it a Request) to your broker. The broker finds a suitable match for your request, and endeavors to fulfill it. The benefits this scheme offers over your keeping track of all the people who are trading stock or all those who are buying or selling real estate is too obvious to elaborate.

This is CORBA's way. A broker program, called the Object Request Broker (ORB) is running on your computer. It also runs on all other computers which are participants in this grand scheme of interoperability. Thus, when you make a request to your broker, it is in contact with all other brokers, and can find out if there is an object residing on some other machine which can supply the services you need. Likewise, your program can advertise its services, and other brokers seeking those services on behalf of their (client) objects will know from your broker that you are offering those services. (The 'you' is strictly not true - the actual object offering services may be anonymous to the client).

1. You can request services from an object without having to worry about where it resides (Location Transparency)
2. It does not matter that in which the server object is written is different from the language in which your software is written (Language Transparency)
3. It does not matter that the object service provider is not running when client request services. Its broker will start it if a request is received (Wakefulness Transparency :))

These are advantages when you are a client.

If you are writing servers, the advantages are obvious too - you have immediately enlarged your clientele, for more software can access your services.

So, why isn't the world on CORBA right now?
Althought the standard is comprehensive (or maybe because it is comprehensive) each implementation is partial, or does things in slightly different ways. However, there is a large body of commonality which can be used for practical purposes.

What do you need to do to use CORBA?
The currently available implementations of ORBs are in the following languages:

So, if your application is written in a different language, it would need to call something in one of the above languages. This in itself is not a huge problem. A much larger problem is that different ORB implementations follow slightly varying protocols to invoke and use the ORBs. Thus, if you are using an ORB from Vendor A on your machine, and wish to access a must-have object on another machine running an ORB from Vendor B - you are out of luck...or were.

Enter IIOP
The Internet Inter-ORB Protocol (IIOP), which most major vendors have implemented, is a means for ORBs to translate client calls to non-native ORBs by communicating with a different ORB. This makes clients not only language-independent in their use of CORBA but also, equally importantly, ORB-independent, paving the way for true interoperability.

Bring on the ORBs!
Currently, if you are using Java, there are three major sources of ORBs:

You can download evaluation copies of all of these products for a limited period. Check the respective websites for details.

The brass tacks
Be prepared for a severe learning curve. Aside from the language, which you should be fairly comfortable with, you must get used to the idea of an interface definition language (IDL), which is the standard way to define interfaces in CORBA programming. For historical reasons, the CORBA IDL syntax is skewed towards C++. It is instructive (make that 'inescapable') to study the code generated by the IDL compiler, and understand each file. A basic understanding of client/server architectures, including the notions of stubs and skeletons (proxies), is useful.

To make things even more interesting, each vendor supplies their own IDL compiler, which generates a set of files somewhat different in organization and structure from those of the others. However, the fundamental architecture is uniform, which makes life somewhat bearable.

Top
Journal Archives | Send Feedback

Copyright© Pantheon Systems, Inc., All rights reserved.