"... an application in which clients access data from a large number of sources is particularly well-suited to CORBA."

Back to Table of Contents

When to use CORBA

by Jeremy Rosenberger

Distributed Computing Defined

The client/server computing model has become increasingly popular over the last several years. Properly implemented, systems based on client/server technologies are more flexible and less expensive to build and maintain than the mainframe-based systems they generally replace. Of course, mainframe systems will continue to have their place, but client/server technology is definitely here to stay.

But client/server is only the tip of a larger iceberg known as distributed computing. Client/server is distributed computing in its most basic form: a server, which presumably has access to a database and perhaps business rules, talks to one or more clients, which may also perform business logic processing, but primarily serve to display data to the end user of a typical client/server application. This type of application is commonly referred to as a two-tier client/server system: the database and (usually) business logic resides in one tier; the presentation layer resides in the other.

Taking the distributed computing model one step beyond two-tier client/server yields the three-tier client/server system. In this model, a database server resides in one tier; the presentation layer resides in another; and the business logic lies in the "middle" tier. It is this distinct separation of functionality which distinguishes a three-tier system from a two-tier system that happens to consist of more than two components.

We can further extend the client/server model to n-tier by adding additional data sources and/or business logic servers. In such a system, a client might access any number of servers, which might in turn access multiple databases or other servers. The application data could be distributed across a local area network, an intranet or even the Internet, and the processing load of the application could be distributed just as widely. Here we have a true distributed application: when the realm of an application can transcend processes, machines, subnets -- even entire networks.

Distributed Computing Meets Object-Oriented Design

While object-oriented technology has existed for many years, it still has yet to gain wide acceptance in many areas of the software industry. In particular, the application of object-oriented technology to distributed systems is a relatively new practice. This is where CORBA enters the picture. CORBA, the Common Object Request Broker Architecture, is a standard architecture for developing distributed object-oriented applications. The CORBA specification is set forth by the Object Management Group (OMG), an industry consortium consisting of hundreds of members, all with a shared interest in establishing open standards for object interoperability.

An Overview of CORBA

The CORBA architecture centers around the idea of an Object Request Broker, or ORB. It is the ORB which allows objects to communicate with one another; the ORB handles issues such as network communication, pushing and pulling parameters to and from the network stream (known as marshalling and unmarshalling), contacting other ORBs, and handling some error conditions.

So just how do objects communicate? In a non-distributed, object-oriented application, Object "A" may call a method of Object "B", perhaps passing some parameters as input and receiving other parameters back as output. Since the application is not distributed, the objects and parameters all exist in the same address space; they are said to be local to each other. In a distributed application, Object "A" may exist on one machine and Object "B" on another; these objects are said to be remote. With CORBA, Object "A" can invoke the method of Object "B" just as if Object "B" were local to Object "A". This is accomplished through the ORB: the parameters with which Object "A" calls the method are marshalled by the ORB on Object "A"'s machine and transmitted to the ORB on Object "B"'s machine. This ORB then unmarshals the parameters and passes them to Object "B"'s method, which then executes. Any return parameters are marshalled and unmarshalled in a similar manner. Again, note that Objects "A" and "B" have no knowledge of the workings of the ORBs: Object "A" thinks that Object "B"'s method has executed locally, and Object "B" thinks that its method was invoked by a local object. That the objects are actually remote to each other is completely transparent to the objects themselves.

For those readers who are unfamiliar with object-oriented programming, but who are familiar with Remote Procedure Call (RPC), it may help to think of CORBA as a sort of "object-oriented RPC." In the case of a CORBA application, each of a remote object's methods behave similarly to an RPC.

So now that we understand how a CORBA application works, just how is a CORBA application built, anyway? Is CORBA a language? Is it a protocol? The answer, of course, is "yes and no."

CORBA is not a language; in fact, CORBA is language-neutral as well as platform-neutral. CORBA applications may be written in a number of languages, including C, C++, Smalltalk, Java and even COBOL. In addition, CORBA applications may be deployed on a number of platforms, such as Windows 3.x/95/NT, MacOS, just about any Unix flavor, and, with the introduction of a number of products last year, on any platform for which a Java Virtual Machine exists.

Here's where things get really interesting: although CORBA is not a language, it does define a language. This language, called Interface Definition Language (IDL), is just that: a language used to define interfaces. An interface, like a Java interface, simply specifies the methods a class will define; it is the class' responsibility to provide the implementations for these methods.

This article is not meant to be a CORBA tutorial; a number of decent (and not-so-decent) tutorials exist already, many of them included in the documentation for CORBA-related products. In short, the process of building a CORBA application consists of these steps: First, define the object interfaces in IDL. Generally, the IDL code is then run through an IDL compiler, which generates skeletons of the code necessary to implement the object interfaces. Then, implement the interfaces using your language of choice (the language is usually determined by the particular CORBA product being used). Finally, implement a client which makes use of the services provided by the objects you have defined. All that remains is to deploy the application!

Why CORBA?

Okay, all this is great. So when would someone want to use CORBA to develop a real-world application? The short answer is this: the more complex the application, the more likely it would benefit from using CORBA. Distributed applications are difficult enough to implement already; using an object-oriented architecture such as CORBA can help to manage that complexity. The list of benefits to object-oriented design is a long one; most, if not all, of these benefits also apply directly to CORBA-based systems as well.

In particular, an application in which clients access data from a large number of sources is particularly well-suited to CORBA. Each data source and business logic server could be "wrapped" in a CORBA object, giving a standard interface to every piece of information within the enterprise. Such a model could be extended outside the company to provide information to the business' customers as well. Consumers of information need not be concerned with where the information resides or in what format, as long as they are given access to the proper CORBA objects and are aware of the interfaces to those objects. Given that CORBA is a widespread--and open--standard, this is a highly effective way of making information accessible to those who need it.

Experience with CORBA has convinced me that even though the architecture still has a few shortcomings, it offers a great deal of potential. I believe that CORBA is one of the single most powerful tools that a developer can put in his arsenal today. Furthermore, I see a great deal of synergy between CORBA and Java. Either of these technologies by itself shows a lot of potential. Used together, the possibilities are nearly endless. With tools like these at our disposal, now is a very exciting time to be a software developer.

---

Author footnote...

Jeremy Rosenberger is a software engineer and consultant currently living in the Denver, Colorado area. He is currently employed by Hughes Aircraft in Aurora, CO, where he serves on a project evaluating Java and Java-related products such as CORBA tools and object-oriented databases. His immediate goals are to leverage a buyout of Microsoft Corporation, and to own a Porsche Boxster. So far he's not getting very far with that last goal.