Have years of struggle to bring order to chaos in the object market paid off?
The toughest challenge for system architects has always been those environments where a variety of computing platforms from heterogeneous vendors must be melded together behind the scenes into what appears to the user as a seamless, interoperating, homogeneous system. The traditional way to build such systems has been to buy or build software that coordinates the interfaces between two (and occasionally more) specified environments. A large industry sprang up, for example, to provide middleware interfaces between IBM Corp.'s CICS and other vendors' interactive environments.
Most people recognized that a better solution could be found in universal middleware that would make it possible for anyone to build systems comprised of specialized, reusable components. The key to such a solution would rely on providing a common language for defining interfaces between components and a mechanism for arbitrating the requests between the components.
In order to make this vision a reality, programmers first had to learn a new way of looking at building systems -- a way called object-oriented programming and object-oriented design. This required a sociological revolution as much as a technological one, and as a result it has taken the object revolution 20 years to move from bleeding edge to mainstream practice. But as developers slowly absorbed the new paradigm, the encapsulation of data and function into components called objects became a natural way to view application design and development.
CORBA, an acronym for Common Object Request Broker Architecture, was designed to provide the specification for an object-oriented "universal middleware" that would allow programmers -- without requiring any knowledge of how or where that object was implemented -- to write objects that could interact with other objects. OMG accomplished this by specifying two primary tools for the architect and programmer: the IDL and the ORB.
When a programmer from Russia meets a programmer from the U.S., the chances are slim that they both speak the same native language. The chances are good, however, that they will discover they both speak English. The IDL -- Interface Definition Language -- serves somewhat the same purpose for objects as English does for our conversing programmers; it provides a lingua franca, or common language. However, using the OMG IDL is only part of the battle in getting objects to communicate. The other part involves using a piece of software to arbitrate -- or broker -- the requests from the objects.
The software that brokers requests from objects is called, fittingly enough, an object request broker, or ORB. If you add a "C" as a prefix, representing "Common" and an "A" as a suffix, representing "Architecture," the resulting acronym is CORBA. The Common Object Request Broker Architecture, then, is an architecture (or specification) that defines the least common denominator to which all object request brokers must adhere in order to be compliant. This distinction is important, because it emphasizes that the software product, such as Iona Technologies Inc.'s Orbix, is an ORB -- an object request broker -- that has been written to be compliant with the CORBA specification.
One final point about the OMG deserves mention before I delve into the meaning of CORBA for database programmers. The Object Management Group did not create the CORBA specification, nor does it create any software products. Instead, the OMG posts requests to the software development community asking for proposals for technology specifications. The members of the appropriate committees appointed by the OMG evaluate those proposals and eventually produce a specification that is the result of a common agreement as to the desired features for the product defined by the specification. As such, the resulting specification is as much a political as technological document, reflecting in many ways the marketing strategies of the companies (such as IBM) that dominate the OMG. The specifications are notable also for which companies didn't actively contribute -- notably Microsoft Corp., although Microsoft is a member of OMG.
Although the OMG specifications may not be bias-free, they at least represent the democratic process at work in which many voices are heard -- although perhaps not acted upon. This is why the CORBA specification is at once more robust and at the same time slower getting products to market than Microsoft's competing Distributed Component Object Model (DCOM). This article is not intended to be a debate of the relative merits of CORBA vs. DCOM, but it's worth noting that because Microsoft enjoys the luxury of a single technological model, it doesn't have to take competing viewpoints into consideration. As a result, it means CORBA has been subjected to a much more robust technical review that must represent multiple, often conflicting, viewpoints of how the technology should be implemented. On the flip side, the review process also means there is a chance that the resulting product will resemble the proverbial camel, which resulted from a committee's efforts to build a horse.
One of the most important things to realize about the CORBA OTS is that it was designed with heavy input from Transarc Corp. Transarc is one of the two biggest players in the transaction monitor business; the technology of its TP monitor, Encina, is also incorporated into the Distributed Computing Environment (DCE). The other major player in the TP marketplace, BEA/Novell's Tuxedo, was used as the model for the X/Open specification for distributed transaction processing monitors. The relationship of the X/Open DTP model derived from Tuxedo assumes importance to those considering CORBA OTS because OTS was designed to interoperate with X/Open-compliant transaction monitors.
The committees that designed OTS knew they had to provide a safe and reliable path for those shops that had already made a significant investment in nonobject transaction processing technology. As a result, the CORBA OTS was designed to interact simultaneously and concurrently with both ORB-based and traditional TP monitor-based transaction services. This means that a client can initiate a recoverable transaction comprised of a mix of resources managed by an object as well as resources managed by a TP monitor. Further, the OTS offers the capability of supporting recoverable nested transactions --again, in a heterogeneous environment, if desired -- that fully support ACID and two-phase commit protocols.
Part of the secret behind effective transaction processing lies in good control over concurrency -- the locks that the transaction places upon the resources during the commit phases of the transaction. CORBA partners OTS with products written to another CORBA specification called the Concurrency Control Service (CCS) to provide these services. The locks available span the gamut from the usual read and write to intention read and intention write. The latter two locks queue reading and writing, respectively, behind currently held locks. In addition, an upgrade lock gives programmers a tool to help prevent deadlocks. These locks can be specified as transactional and nontransactional. I'll return later to a description of the specific lock tools available via the CCS.
As with traditional (in other words, nonobject) transaction processing environments, work in the Object Transaction Service is divided between clients and servers. Clients issue requests for transaction services, which are filled by the transaction servers. A wrinkle added by the object environment is found in the recoverable server, which groups all transaction objects for a particular transaction request. Four interfaces are defined in the OTS; after a look at each of the interfaces, I follow a typical transaction through the OTS and see how the IDL and ORBs come into play.
The OTS consists of four important interfaces: Current, Coordinator, Resource, and SubtransactionAwareResource. The Current interface lets the programmer establish a context for a transaction; as objects are created and destroyed during the course of the transaction's life, this context is attached to each object and permits the ORB to pass requests from client services to servers controlling resources. When a response from a server object is received at the ORB, the ORB maintains the context of the request and is able to return the desired data to the originating client. As the sidebar, "Important Object Transaction Service Interfaces," shows, most of the client-side functionality is incorporated into the Current interface, including messages to begin, commit, and roll back transactions, as well as messages to interrogate the object regarding the name, status, and other information related to the context of the transaction.
The Resource provides an interface to objects implementing the two-phase commit protocol. Multiple Resource objects can participate in a transaction, but as with all two-phase commit implementations, each participating Resource votes on whether it can fulfill the request submitted to it. If any one Resource votes no, then the transaction is rolled back or suspended, depending upon how the client message was coded. If the vote from a Resource object is ambiguous, you can write code to send a forget message to the Current interface, which causes the transaction to drop the Resource sending the ambiguous message but allows the rest of the transaction to continue. To increase efficiency in environments where there is only one Resource, OTS Current interface provides the option of using the commit_one_phase message, which bypasses the unnecessary overhead of the two-phase commit protocol.
So far, I've shown few differences between the coding used to write X/Open-style and CORBA transactions. The Coordinator interface enables the programmer to invoke services within the CORBA Object Transaction Service itself. My sidebar shows the messages available to the programmer who needs to interact directly with OTS. These messages are used primarily by servers to create subtransactions and to coordinate recovery efforts should the current transaction require termination. With the range of messages available in the Coordinator interface, the server-side programmer using the OTS services of the ORB in use has a wide range of granularity available to permit interaction at whatever level of specificity is required.
Under versions of the CORBA specification prior to 2.0, when you installed an ORB from a given vendor, you were locked into that vendor's implementation of CORBA for your system architecture. That is, the programs you wrote using IDL would, in theory, run under any vendor's ORB; but you would not be able to run two vendors' ORBs at the same time and expect them to understand messages from one another. That capability changed with the CORBA 2.0 specification, which was released in December 1994, in which the most significant change was the addition of a specification defining inter-ORB communication. The specification defines TCP/IP as the bus by which multiple ORBs can communicate.
Inter-ORB communication via TCP/IP takes on the greatest significance in the most heterogeneous environment of all: the World Wide Web, which is why Netscape Communications Corp. has become one of the strongest forces behind CORBA. The Netscape ONE -- Open Network Environment -- envisions using the message-based Internet Inter-ORB (IIOP) protocol as a replacement for the file-based HTTP protocol used today. (See David Linthicum's article, "Distributed Objects Get New Plumbing," in the January 1997 issue of Internet Systems.) When it's realized, this should bring significant bandwidth benefits, because the overhead for IIOP is much less than that required for HTTP.
But, you may be asking, why should you care about inter-ORB communication? The answer is that each vendor's ORB may add value to the CORBA specification to differentiate itself from other vendors. Let's return to my example of the Russian and U.S. programmers communicating, this time over the telephone. The Russian phone system may not provide some of the more advanced features available in the U.S., such as call waiting or three-way conferencing. Yet the mechanism that defines the basic connection between the Russian and U.S. phone systems is well known and controlled by international agreements. In the same way, CORBA 2.0 serves as an international agreement that defines how basic message-passing between ORBs is implemented.
Thus, for activities intensive in transaction-processing functionality, a shop may elect to implement one vendor's ORB optimized for TP, and the area responsible for groupware functionality may employ another ORB. CORBA 2.0 helps make certain that the two ORBs are, indeed, speaking the same language.
Another vendor offering a CORBA 2.0-compliant ORB is Visigenic Software Inc., whose VisiBroker for C++ (formerly marketed as ORBeline) is a complete CORBA 2.0 Object Request Broker implementation that supports IIOP. Because CORBA 2.0 provides a bus for inter-ORB communication via TCP/IP, VisiBroker can communicate with the VisiBroker for Java ORB. VisiBroker for Java, formerly known as Black Widow, is written entirely in Java and is designed for building, managing, and deploying distributed Java applications.
Another product that will intrigue those who want to integrate CORBA with existing relational databases is available from Persistence Software Inc. The central concept of the Persistence product is that of a live object cache, which provides the benefits of the object-oriented concept of persistence (that is, a resource object that has a life longer than the object invoking it; this enables the calling object to maintain state information for an extended terminal session even though several objects may be created and destroyed during the session). Persistence has also partnered with Iona. The value of this relationship is found in the mapping of relational databases to objects that use the CORBA IDL. Some Persistence customers had created these objects manually, but the Iona/Persistence collaboration means that for other customers the mapping has been done for them.
The CORBA 2.0 Internet Inter-ORB Protocol has enabled users to break beyond the single-vendor Object Request Broker barriers imposed by earlier versions of CORBA. With that software bus available and the growing implementation of Object Transaction Services --particularly its near-seamless integration with X/Open-compliant transaction monitors -- the future looks very bright for system architects seeking true object-oriented vendor-independent solutions to implementing transaction processing in heterogeneous environments.
The following list will give you an idea of what types of services are available through some of the various OTS interfaces in CORBA 2.0. In the first two interfaces, the services are divided into two groups. The first of the two specifies the actions available through that interface, and the second of the two specifies the status information that can be retrieved through the interface.