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 an object that wants to know the event occurred. A producer is an ob­ ject that causes the event to occur. In our example, the supply object is the consumer, and the inventory object is the producer of the low-bigDog­ food event.

The Event Service also supports two different programming models for events. In the pull model, the consumer continuously polls the producer to find out if the event occurred. In the push model, the producer tells the consumer the event has occurred.

It is possible, but unusual, for event consumers and event produc­ ers to communicate directly with each other. More often, they com­ municate through event channels. An event channel becomes an inter­mediary between consumers and producers. Event channels allow any number of objects to raise an event and any number of objects to notice the event. In our inventory application, we could have many bigDog­ food suppliers watching for the low­ bigDog-food event who start a bid­ ding war as soon as the stock supply has gone down. They would do this by registering their interest in the low-bigDog-food event with the spe­ cific event channel coordinating the producers and.consumers of low-big­ Dog-food events.

The Naming Service is a funda­ mental service that ties into both the Life Cycle Service and the Event Service. The Life Cycle Service builds its Factory Finder on top of the Naming Service. The Event Service uses the Naming Service to make its event channels known to the world. Anybody who would like to know about low-bigDog-food events would use the Naming Service to find, for example, the object named OutOf­ BigDogFood_Event_Channel. Once one has a reference to the coordinat­ ing event channel object, one can register as either a consumer or a supplier of the relevant event.

The Persistence Service solves the basic problem of having objects co­ ordinate their state changes with data in a database. Our inventory object would almost certainly need to update a corporate database to re­ flect changing supply levels.

Distributed objects do not neces­ sarily need a Persistence Service to store data. An object can decide on its own either to refresh its data from a database or to update a database. But where applications need a stan­ dard interface to store data, the Per­ sistence Service comes in very handy.

The Persistence Service is similar in concept to an object-oriented database. Both are able to store and restore object state. The Persistence Service differs in that it supports a wide range of underlying database products and data formats.

Object-oriented databases are generally difficult or impossible to integrate with standard corporate databases and existing data formats. They offer little or no support for integration with existing applica­ tions. For these reasons, object-ori­ ented databases have had little impact on corporate applications development, and, in fact, may have actually inhibited the adoption of object technology in this area. The Persistence Service, on the other hand, is specifically designed to work well with existing databases, data formats, and applications.

The Persistence Service needs some mechanism for moving data in and out of objects. This function­ ality is provided by the Externaliza­ tion Service. The Externalization Service is based on a mechanism similar to C++ streams.

Most serious commercial applications need to work with objects within the context of traditional transactions. Suppose we have two inventory objects, one that repre­ sents a warehouse and one that rep­ resents a store. Let's say we have an order management system that moves inventory from the ware­ house to the store. If our application fails between the removal from the warehouse and the receipt by the store, we have lost a heap of bigDog food. Not a happy state of affairs.

The Transaction Service ensures that either the bigDog food both leaves the warehouse inventory and enters the store inventory, or neither leaves the warehouse nor enters the store. Millions of dogs all over the world depend on transactional sys­ tems for their health and well-being, as do bank customers (who are obvi­ ously much less important).

In SOM, the Persistence, Externali­ zation, and Transactional Services are closely related. Persistence uses Externalization to move data in and out of the object and coordinates its database update activity through the Transaction Service. A description of SOM 3.0 and the services related to persistence can be found in a brand new book called Object Persistence: Beyond Object-Oriented Databases by yours truly.

The SOM implementation of the Persistence Service ships with support for using the IBM relational database DB/2 as a datastore. This work was a fun collaboration between myself, then of IBM Austin, and Guylaine Cantin, then and now of IBM Toron­ to. I have tried to entice Guylaine away from IBM to ObjectWatch, but so far, no luck.

Back to the waterfall

The implementation of the CORBA Services is an important milestone for SOM. It means that programmers can, for the first time, write truly COREA-compliant distributed appli­ cations using IBM's products. Not only that, but SOM is the industry's most complete implementation of these CORBA services.

If SOM has the first decent CORBA implementation, and finally has its marketing group working well, why do I feel like I am search­ ing for my lost waterfall everytime I look at the IBM SOM strategy? The answer is simple: VisualAge. IBM was trying to deal with a very real issue: lack of tools support for SOM. The response to this prob­ lem was to reorganize the SOM pro­ ject under the Toronto tools group.

This response shouldn't be too sur­prising. The standard IBM response to any problem is to reorganize. In fact, the standard IBM response to the new moon is to reorganize.

Placing SOM under Toronto tools definitely gave SOM some serious tools attention. It also put SOM near the VisualAge product line. Visual­ Age seems to be the class-library equivalent of a black hole, sucking in any framework that has the mis­ fortune to cross its sphere of influ­ ence. SOM was no exception.

The current release of VisualAge includes about 500 classes (including SOM 2.1), most of which intemper­ ate poorly, if at all, with SOM. Ac­cording to John Slitz, the VisualAge scheduled for release next year will include over 2,000 classes, a four­ fold increase over the current num­ ber. When John proudly made this announcement at the Technical In­ terchange, I believe a collective shudder ran through those of us who have actually had to deal with real class libraries.

Robert LeBlanc tells me not to worry, everything is under control. Robert is the object-oriented appli­ cation development technology di­ rector. He owns VisualAge, SOM/ DSOM, OpenDoc, and all of the SOM object services. First, he says tha't IBM will continue to make SOM widely available through other chan­ nels besides VisualAge, including the Web, at little or no cost. Second, he says that VisualAge is maturing into a well-designed tool for developing client-server applications, and that SOM is an absolutely critical founda­ tion technology. Third, he says not to worry about the 2,000 class li­ braries. (I think he felt the shudder.) These classes will be organized into highly structured and layered frame­ works, and most programmers will deal with only a small number of these classes.

I must admit to a bit of skepti­cism here. IBM has not done a great job integrating even 500 classes.

Now they are quadrupling the num­ ber. I'll be hoping for the best, but I'll believe it when I see it. When I asked Mr. LeBlanc what the recom­ mended programming layer will be, he gave me the standard IBM answer: different layers for different players. In other words, the cus­ tomers will have to sort this out.

So where are we with all this? It looks like SOM is well on the road to recovery. A good CORBA implemen­ tation. A good marketing organiza­ tion. A lot of customer interest. But SOM is only one of a very large number of trails, brooks, trees, and flowers. And perhaps more than one waterfall. Let's hope it doesn't get lost in the garden.

Late-Breaking News from the Object Front

IBM has recently announced an "agreement to collaborate" with IONA Technologies Ltd. IONA produces Orbix, one of the most successful products to compete with DSOM. According to the press release "the announced collaboration with IONA provides expand­ed platform support for IBM's SOM technology and increases our customers' choices in platform deployment."

I have been asking all my IBM friends what this "collaboration" means technically, and nobody seems to know. So let me offer my own speculation. SOM offers a rich object model, a full implementation of ll)any CORBA object services, and a relatively nonportable ORB (DSOM). Orbix offers a minimal object model, almost no CORBA object services, but a highly portable and successful ORB. The most logical merger between these two prod­ucts is to replace DSOM by Orbix, keeping the SOM object model and object services and the Orbix ORB.

Should IBM follow this path, a significant delay of SOM 3.0 on all the IBM platforms would likely occur, assuming SOM 3.0 is where the merger will take place. Customers might also become wary of starting to prototype with the currently available beta SOM 3.0, given the widespread changes one can expect as these two products become one.

One of the biggest technical problems IBM will have to face in merging SOM and Orbix will be the SOM "thunk" technology. This technology was introduced in a somewhat mis­ guided effort to support the Direct to SOM C++ compiler technology, and is the least portable part of the entire SOM kernel. My guess is it will have to go, which may put the entire Direct to SOM (++strategy at risk. Personally, I don't feel this is a major loss, but others may not agree.

Although any merger between SOM and Orbix will cause a lot of short-term pain, the long-term gains could be significant. The merger could add some desperately needed plat­ form coverage to SOM and help focus SOM on object distribution. It could improve Orbix's object model and object services story. Overall, I think this announcement may be good news, or at least could be once we figure out what the news really is.