The Common Object Request Broker Architecture (CORBA)

One of the primary tenets of this book is that objects are totally self-contained units. With this in mind, it doesn't take much imagination to consider sending objects over a network. In fact, we have used objects traveling over a network in many of the examples throughout this book. A Java applet is a good example of an object being downloaded from a server to a client (browser).

The entire premise of the enterprise is built on the concept of distributed objects. There are many advantages to using distributed objects; perhaps the most interesting is the fact that a system can theoretically invoke objects anywhere on the network. This is a powerful capability, and is the backbone for much of today's Internet-based business. Another major advantage is that various pieces of a system can be distributed across multiple machines across a network.

The idea of accessing and invoking objects across a network is a powerful technique. However, there is one obvious fly in the ointment ”the reoccurring problem of portability. Although we can, of course, create a proprietary distributed network, the fact that it is proprietary leads to obvious limitations. The other problem is that of programming language. Suppose a system written in Java would like to invoke an object written in C++. In the best of all worlds , we would like to create a non-proprietary, language-independent framework for objects in a distributed environment. This is where CORBA comes in.

OMG

An organization you should become very familiar with is the Object Management Group (OMG). OMG is the keeper of the keys for many standard technologies, including CORBA and UML, among others. Find out more at http://www.omg.org.

The main premise of CORBA (Common Object Request Broker Architecture) is this: Using a standard protocol, CORBA allows programs from different vendors to communicate with each other. This interoperability covers hardware and software. Thus, vendors can write applications on various hardware platforms and operating systems using a wide variety of programming languages, operating over different vendor networks.

CORBA can be considered the middleware for a variety of computer software applications. Whereas CORBA represents only one type of middleware (later we will see some other implementations , like Java's RMI), the concepts behind middleware are consistent, regardless of the approach taken. Basically, middleware provides services that allow application processes to interact with each other over a network. These systems are often referred to as multi-tiered systems . For example, a 3-tiered system is presented in Figure 14.2. In this case, the presentation layer is separated from the data layer by the allocation layer in the middle. These processes can be running on one or more machines. This is where the term distributed comes into play. The processes (or as far as this book is concerned , the objects) are distributed across a network. This network can be proprietary, or it might be the Internet.

Figure 14.2. A 3-tiered system.

This is where objects fit into the picture. The OMG states that "CORBA applications are composed of objects ." So, as you can tell, objects are a major part of the world of distributed computing. The OMG goes on to say that these objects "are individual units of running software that combine functionality and data, and that frequently (but not always) represent something in the real world."

One of the most obvious examples of such a system is that of a shopping cart. We can relate this shopping cart example to our earlier discussions on the instantiation of objects. When you visit an e-commerce site to purchase merchandise, you are assigned your own individual shopping cart. Thus, each customer has her own shopping cart. In this case, each customer will have an object, which includes all the attributes and behaviors of a shopping cart object.

Although each customer object has the same attributes and behaviors, each customer will obviously have different attribute assignments, such as name , address, and so on. This shopping cart object can then be sent anywhere across the network. There will also be other objects in the system that represent merchandise, warehouses, and so on.

Wrappers

As we explained earlier in the book, one common use of objects is that of a wrapper . Today there are a lot of applications written on legacy systems. In many cases, changing these legacy applications is either impractical or not cost-effective . One elegant way to connect legacy applications to newer distributed systems is to create an object wrapper that interfaces with the legacy system.

One of the benefits of using CORBA to implement a system such as our shopping cart application is that the objects can be accessed by services written in different languages. To accomplish this task, CORBA defines an interface to which all languages must conform. The CORBA concept of an interface fits in well with the discussion we had about creating contracts in Chapter 8, "Frameworks and Reuse: Designing with Interfaces and Abstract Classes." The CORBA interface is called the Interface Definition Language ( IDL ) . For CORBA to work, both sides of the wire, the client and server, must adhere to the contract as stated in the IDL.

Yet another term we covered earlier in the book is used in this discussion ”marshaling. Remember that marshaling is the act of taking an object, decomposing it into a format that can be sent over a network, and then reconstituting it at the other end. Thus, by having both the client and the server conform to the IDL, an object can be marshaled across a network regardless of the programming language used.

All the objects that move around in a CORBA system are routed by an application called an Object Request Broker (ORB). You might have already noticed that the acronym ORB is actually part of the acronym CORBA. The ORB is what makes everything go in a CORBA application. The ORB takes care of routing requests from clients to objects, as well as getting the response back to the appropriate destination.

Languages Supported

At this point in time, CORBA supports the following languages: C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLscript.

Again, we can see how CORBA and distributed computing works hand-in-hand with the concepts we have studied throughout this book. The OMG states that

This separation of interface from implementation, enabled by OMG IDL , is the essence of CORBA .

Furthermore,

Clients access objects only through their advertised interface, invoking only those operations that the object exposes through its IDL interface, with only those parameters (input and output) that are included in the invocation.

To get a flavor of what the IDL looks like, consider the e-business example we used in Chapter 8. In this case, let's revisit the UML diagram of Figure 8.7 and create a subset of the Shop class. If we decide to create an interface of Inventory , we could create something like the following:

 interface Inventory  {      string[]  getInventory ();      string[]  buyInventory (in string product); } 

In this case, we have an interface that defines how to list and purchase inventory. This interface is then compiled into two entities:

• Stubs that act as the connection between the client and the ORB

• A skeleton that acts as the connection between the ORB and the object

These IDL stubs and skeletons form the contract that all interacting parties must follow. Figure 14.3 shows an illustration of how the various CORBA parts interact.

Figure 14.3. CORBA parts.

The really interesting thing about all this is that when a client wants the service of some object, it does not need to know anything about the object it is requesting, including where it resides. The client simply invokes the object (and the service) it wants. To the client, it appears that this invocation is local, as though it's invoking an object that's on the local system. This invocation is passed through the ORB. If the ORB determines that the desired object is actually a remote object, the ORB routes the request. If everything works properly, the client will not know where the actual object servicing it resides. Figure 14.4 shows how the ORB routing works over a network.

Figure 14.4. ORB routing.

Internet Inter-ORB Protocol

Just as HTTP is the protocol for Web page transactions, IIOP (Internet Inter-ORB Protocol) is a protocol for distributed objects that can be written in a variety of programming languages. IIOP is a fundamental piece of standards like CORBA and Java RMI.