Ten Rules for Distributed Object Systems

by Roger Sessions

It's sad watching a client fail. Recently one of my clients failed. The company had attempted to build a relatively simple distributed object system. About 10 person-years had been invested in the project. The company had promised that the next major release of this product would be based on distributed objects. The project had high visibility. And the whole thing went down the drain.

Like most failures, this one was predictable. The developers had little experience in object-oriented pro­ gramming, no expertise in distributed object systems, and almost no time allocated for training. They immedi­ ately started designing an overly com­plex system with no provision for testing or debugging.

As the second extension of the project due date approached, the pro­ject managers started getting desper­ ate. The system was slow and lacked much of the committed functionality. What functionality it did have would occasionally work, but more often would hang or crash. No one had any idea why it worked when it worked, and why it didn't when it didn't.

So the managers made a desperate move. They called in a consultant: me. They told me they had to ship within two weeks. They wanted me to tell them how to fix their problems­ in less than two days.

I spent a day with them reviewing the design. I had no choice but to deliver the bad news. The design was a mess. The implementation was hopelessly flawed. The best option was to flush it all and start again.

I tried to sound as positive as I could, given the depressing circum­stances. I used phrases like, "This is an excellent prototype that should help clarify your goals," and "This is a real­ly nice demonstration of a system bot­tleneck-see how all these little arrows are all pointing at the same object?" But the message was clear. The team had no hope of meeting its deadline. The system had no more chance of working than a dog has of flying.

This situation started me thinking. Obviously, this client had violated many of the basic rules of developing distributed object systems. But just what are these rules?

Over the many years that I've been in this field, I've designed, implement­ed, and consulted on many distributed object systems. I've given lectures at more conferences than I can count and spoken to more people than I can even guess at about using distributed objects. I've heard and witnessed many stories of success and many of failure. So what determines success or failure when using this technology?

When a distributed object system works well, it is beautiful and harmo­nious. When it doesn't, it's repugnant and irritating. So what makes one distributed system a symphony, and what makes another a cacophony?

I believe in 10 basic rules for imple­menting distributed object systems; rules so basic that anyone observing all 10 is almost guaranteed success, and anyone who ignores even one is headed down a dark path indeed.

Rule one

Understand what a distributed object is (and isn't). This is a funny rule, isn't it? Why would people use dis­ tributed objects without understanding what they are? However, this rule is commonly violated.

Many people begin with an in­ complete understanding of object-ori­ented programming and then try to extrapolate this pseudo-understanding to distributed objects. Others who do understand object-oriented program ming then assume distributed objects are the same thing. They are not.

Distributed objects are more like components than objects. They are large things that know how to per­ form specific functions for you. They generally provide some kind of busi­ness capability. Let's consider a few of the traits that differentiate nondistributed objects (such as C++ objects) from distributed objects.

• Purpose. The purpose of a nondis­tributed object is to manage the complexity of the data and algo­rithms required to solve some pro­gramming problem. A good exam­ple of a nondistributed object is a collection class. The purpose of a distributed object is to perform a related set of business functions for multiple remote clients. A good example of a distributed object is Jil inventory object.

• Client view. The client view of a nondistributed object is a class, which includes the definitions of methods, the algorithms for those methods, and the internal data of a nondistributed object. A given class can have only one implemen­tation. The client view of a distrib­uted object is an interface, which only defines the behaviors that clients can expect the distributed object to perform. A given inter­ face can (and often does) have many implementations.

• Performance. The cost of a method invocation on a nondis­tributed object is measured in tenths of a microsecond. For a non­ distributed object, you can ignore the invocation costs of methods when determining its performance. The cost of an operation invoca­tion on a distributed object is mea­ sured in milliseconds. You must consider this cost very carefully when analyzing the overall system performance.

• Complexity. A nondistributed ob­ject is typically low in complexity and is often composed of only a few hundred lines of code. The de­ sign goal of nondistributed objects is to be simple. A distributed object is usually quite complex and com­ posed of perhaps hundreds of thou­ sands of lines of code-a single dis­tributed object may actually consist of dozens, or even hundreds, of local, nondistributed objects, but if so, their existance is invisible to the client.

• Number. Nondistributed-object­ based systems are typically com­ posed of a large number of classes (perhaps thousands) and an even larger number of nondistributed objects. Distributed-object-based systems are typically composed of a small number of interfaces (per­ haps 10) and not many more dis­ tributed objects (perhaps dozens at most).

• Location. Nondistributed objects are always located in the address space of their clients. Distributed objects are never located in the address space of their clients.

• Concurrency. Nondistributed ob­ jects are only used by a single cli­ ent and don't have to worry about concurrency. Distributed objects are used by a large number of cli­ ents and have to deal with com­ plex concurrency issues.

Rule two

Use a standard. Distributed object systems by their very nature need to span languages, computers, operating systems, and network protocols. Your only hope of managing this complexity is to base your distributed object sys­tems on well-understood standards with many available implementations.

The most widely recognized dis­tributed object standard is the CORBA standard, based on work done by the Object Management Group (OMG). Fortunately, one of the industry's best implementations of this standard is available to OS/2: SOMobjects. SOM­ objects will soon be available on all IBM platforms and many non-IBM platforms as well. OS/2 is therefore an ideal platform for developing distributed object systems.

Basing your distributed object sys­tem on the CORBA standard will give you the following important benefits:

• You will have the widest possible choice of machines on which to place objects. Objects that need close integration to databases can be placed on the database host. Objects that need high reliability and scalability can be placed on a Tandem machine, which has port­ ed a version of SOM designed to support such features. Objects that make use of special AS/400 features can live on that host.
• You won't have to worry about underlying communications pro­tocols. The CORBA architecture hides communications protocols under operation invocations. You will never know what communica­tions protocol you are using.
• You won't have to worry about the language that is being used to im­plement your objects. Because CORBA is a well-accepted standard, it is or will be supported by most popular programming languages.
• You will have access to objects being developed by independent software houses. The CORBA stan­dard is expected to enable a whole software components industry.
• You will have access to a host of well-defined object services, such as persistence, security, naming, events management, and many others. These services will simplify your systems development and increase the portability of your products.