Lost in the Garden

Monday, I got lost in a gar­ den. I was so sure I knew exactly which path to follow that I didn't bother to look carefully at the trail markings. When I should have been in my hotel room, I was under a waterfall.

I stood under an outgrowth of rock while the water formed a perfect curtain before me. I was surrounded by plants that seemed vaguely famil­ iar and smells that seemed connected to an earlier time. Finding my hotel room now didn't seem so important.

The Opryland Hotel in Nashville, Tennessee, is a series of buildings strung together like giant pearls on a string. To get from the main hotel to the conference rooms one must pass through the Conservatory, a very large, elaborate greenhouse. Actually, II greenhouse" fails to convey the scope of the Conservatory. The com­ plex is almost a self-contained eco­ system with trails, brooks, flowers, trees, and the waterfall at which I had found myself.

I gave several talks at the IBM Technical Interchange about SOM (System Object Model) and distrib­ uted objects, and I made this nature trek many more times. Each time, I tried to retrace my steps back to the waterfall, but I was never again able to find this peaceful little spot. Per­ haps it had been nothing more than my imagination. Several times dur­ ing the week, I wondered if this interlude was symbolic of the IBM SOM strategy.

SOM 3.0

Over the last several months, I have been feeling much better about SOM. In the past, I've criticized the SOM marketing strategy. Since then, the SOM 3.0 beta has been made widely available on the IBM SOM­ Objects Web site. All of the major hardware groups within IBM have announced plans to support SOM. IBM has set up a focused SOM mar­ keting group under the leadership of Anthony Brown.

I've met Anthony Brown several times and have been impressed. The SOM brand manager assisting Mr. Brown is Chris von Schweinitz. Chris has been a strong advocate for port­ing SOM to other hardware platforms and is an effective spokesperson for SOM. Also assisting _Mr. Brown is Rick Clark, manager of Object Mar­ keting and Support. All of these peo­ ple are very capable.

I called John Slitz, the IBM vice president of marketing for object­ oriented (00) technology and Mr. Brown's boss, just to make sure this group's future is secure. John assured me that having a marketing group completely focused on SOM is criti­cal to the whole OO technology stra­tegy, and that this group has his full support.

So for the first time, SOM's future seems to be in the hands of a group that understands its potential. Rath­er than presenting an inconsistent 11SOM solves all the world's prob­lems" story, we actually may have a group that is focused on the raison d'etre of this product: distributed objects.

SOM as a COABA implementation

SOM 3.0 is first and foremost the industry's most complete implemen­ tation of the OMG CORBA specification. The OMG (Object Management Group) is a consortium of hardware and software companies based in Framingham, Massachusetts. Its charter is to develop architectural standards for Distributed Object Computing (DOC).

I believe DOC is an exciting field, and over the next five years will become the technology of choice for doing distributed computing appli­cations. SOM is one of the industry's leading DOC technologies. With SOM, IBM is well positioned to lead in this whole technology area.

The basic SOM architecture implements the OMG-defined CORBA (Common Object Request Broker Architecture). This architecture defines mechanisms for invoking methods on remote objects. I gave a general introduction to this architecture as implemented in SOM 2.1 in the April 1996 issue.

There are at least three reasons you might use a CORBA architec­ ture. The first is that you want to use objects, but want them in a different process. T9at way, if they crash, they don't tak¢ you down with them. The second is that you want to invoke methods on an object, but the meth­ ods can be implemented more effi­ciently on another machine because, say, the methods need to access data on that machine. The third reason is that you want to share objects with other processes.

This third reason for using CORBA, sharing objects, is the most important from the perspective of DOC. When sharing objects, two or more processes make method call on the same remote object. As one process updates the state of the remote object (through remote meth­ od calls), those state changes are vis­ ible to other processes (also through remote method calls). If, for exam­ ple, one process orders two tons of bigDog food from an inventory object and another process checks the amount of bigDog food on hand in that same inyentory object, the second process will see the invento­ry reduction resulting from the first process's order.

SOM 3.0 has a number of impor­tant enhancements over and above SOM 2.1, the current version. First of all, it is the first version of SOM to support the CORBA IIOP (Internet Inter- ORB Protocol): This protocol specifies how different imple­ mentations of the CORBA architecture interoperate with each other. With IIOP sup- port, SOM clients can invoke methods on objects living in non-IBM CORBA implemen­ tations, and vice versa.

Object services

The second set of SOM 3.0 enhancements has to do with the so-called CORBA Services. This group of OMG-defined frameworks is intended to solve common programming problems in distributed applica­tions. Let's take a look at some of these problems and the solutions CORBA offers.

The first problem is instantiation. Instantiating objects in a distrib­uted-object system is a bit more complicated than instantiating ob­jects in a simple single-process sys tem. Traditional C++ programmers simply call for a new object of a giv­en type to be created. Distributed programmers need to specify not only the type of the object, but also its location.

The process of instantiating ob­ jects is defined by the CORBA Life Cycle Service. In this model, objects are instantiated by special purpose objects called factories. A given fac­tory object knows how to instantiate a given type of object in a particular process.

To find the appropriate factory object, we use a factory finder object. A factory finder takes a descrip­tion of what you want instantiated and where you want it instantiated, a:[ld finds a factory capable of doing that instantiation.

The Life Cycle Service is actually much less important than you might think. The reason is that in distrib­ uted applications most processes do not instantiate objects. Most use ex­isting objects. Consider our two pro­cesses using an inventory object to order and track bigDog food. Neither process creates the inventory object.

One uses the inventory object to place an order. The other uses it to check inventory levels. If the second process instantiated a new inventory object, that object would have a new state that would not include the updates made by the first process. This state discrepancy, obviously, would defeat the whole purpose of the distributed application.

Web pages offer a useful analogy to a distributed object application. We do not-usually-create Web pages. Most of the time we are using existing Web pages, then moving on and using some new Web pages. The pages were there before we came, and they will be there for others to use after we are finished.

The next CORBA problem has to do with finding objects. If our two inventory processes want to invoke methods on this existing inventory object, they must somehow reach out into the CORBA ether and find the object they want to use. The mechanism CORBA defines to find objects is the Naming Service.

The Naming Service can be thought of as a well-known black box. Everybody has a reference to the same black box. Anybody can insert an object into the black box and assign a name to that object. Anybody can ask the black box to find the object associated with a par­ticular name, reducing the problem of finding shared, distributed objects to a much simpler problem of agree- ing on names. As long as I know the name of the inven­tory object, I can ask the Naming Service black box to find the inventory object.

Most distributed applica­tions fall into one of three categories. Initialization pro- grams are those that instan­tiate objects, assign names to them, and place them into the Naming Service. Applica tion programs find and use these objects. Our inventory processes are such programs. The vast majority of pro­grams will fall into this category.

Clean-up programs do an ordered shutdown of a system. They remove the objects from the Name Ser­vice and de-instantiate the objects, freeing up whatever re­ sources the objects are using. The initialization and clean-up programs are run by system administrators. The rest of us will be running appli­cation programs.

The next CORBA problem has to do with discovering that something important has happened. Suppose, for example, we want to have two distributed objects working together. One is an inventory object that keeps track of stock levels of various items. The other is a supply object that knows how to bring in new supplies when stocks of a particular item run low. How does the supply object know when the inventory object is running low on some item?

The CORBA solution uses the Event Service. Objects have a de­fined mechanism for defining, rais­ing, and noticing events. An object might, for example, define a low­ bigDog-food event. The inventory item will automatically raise this event. A supply object could be look­ing out for this event, and, when it "notices" the event has occurred, jumps into action.

The Event Service divides objects interested in a given event into con­sumers and producers. A consumer is