COMWare Drama Where Components, TPMs Meet

Software Magazine, Feb, 2000 by Roger Sessions

Welcome to the middle tier, where all the real drama takes place. The middle tier is where the business logic executes as it receives its commands from the Web/presentation tier and prepares marching orders for the databases. The middle tier is where we find the infrastructures needed to support business logic that is stressed to the max trying to deal with the demanding needs of the city that never sleeps: the Internet.

This infrastructure, called Component-Oriented Middleware, supports components in the middle tier. The obvious acronym for Component Oriented Middleware is COM, but this is easily confused with the related Microsoft technology, Component Object Model (COM). So I use the acronym COMWare.

COMWare is the result of two different software technologies that evolved independently, until their formal introduction to each other in 1996: components and transaction processing monitors (TPMs).

"Blobs" of Software

A component is a blob of software that lives someplace on a network that can do something for you. It might validate a credit card or process a purchase. Of course, you have to know how to ask. To figure out how to ask, you look at the blob's interface. The interface defines a collection of methods, each of which represents a possible request you can make of the blob.

The general idea of components was first developed in 1990 by The Object Management Group (0MG), a consortium of companies interested in defining a standard architecture for components. The architecture they defined is the Common Object Request Broker Architecture (CORBA).

CORBA had three main pieces. One was the Interface Definition Language (IDL) that gave a programming-language-neutral way of defining interfaces. The second was distributed method architecture for allowing a client living in one process to invoke a method on a blob of software (a component) living in another process. The third was a vendor-neutral distribution mechanism called Internet Inter-ORB Protocol (IIOP) that allowed components living in different vendors' CORBA implementations to interoperate.

The basic distributed component architecture was pretty well set by 1991, and that architecture, especially the notion of IDL and the distributed method architecture, set the tone for all distributed component architectures for the next nine years, including COM/DCOM (Distributed COM) in the Microsoft world and Remote Method Invocation (RMI) in Sun's Java world.

Between 1991 and 1994, the 0MG began a new phase, focusing its energy on defining and solving a series of issues related to distributed component systems, including:

* How do two clients invoke methods on the same component instance?

* How does a component instance store its internal state to and from a database?

* How does a client or component discover relationships between component instances, such as might be found in compound documents?

* How does a component instance verify that a method request is coming from an authorized client?

* How does a component instance participate in a transaction?

Each of these identified issues was answered in the form of a specific application programming interface (API). The API that collectively addressed one of these issues was referred to as an Object Service. So, for example, the API that collectively addressed the issue of transactional integrity was referred to as the CORBA Object Transaction Service. By 1994, more than a dozen CORBA services had been defined and the full CORBA API had exceeded 400 methods.

By 1995, two problems were becoming obvious. First, the CORBA API had gotten too complex for average business programmers to use, and too complex for CORBA vendors to implement. Second, there was a new class of issues facing distributed component developers that seemed to have no API solution. Prominent among these was the issue of scalability, particularly for Web-based systems.

By 1995, it looked like generic component technology a la CORBA might have hit its limits. While there were many successful CORBA applications developed between 1990-1995, those applications had relatively simple needs compared to the needs of distributed commerce applications. They also served a relatively small number of clients compared to the deluge that was anticipated by the Web.

Transaction Processing Monitors

While the OMG was busy defining a distributed component architecture, another technology group in the TPM area was working on the infrastructures necessary to support large commerce systems. The group would eventually prove to be as influential as the OMG in the new field of COMWare. The most prominent member of this group was IBM

The TPM folks had little training in object technology, but they did know about commerce in the large.

The biggest problem TPMs were trying to solve was this: how to get a large number of clients around a machine with a limited amount of resources. The limited resource the TPM community was most concerned about was database connections.

TPMs came up with a number of algorithms for solving this many (clients) to few (resources) problem, all revolving around one fundamental discovery: The way you have many clients share a few resources is by having those resources owned not by the client processes, but by middle-tier processes. The client processes could then indirectiy share those resources by sharing the middle-tier processes that owned those resources.