Columns

Show me the manual

• By Sally J Cusack
• June 19, 2001

I was having lunch with a colleague in the consultant community recently when he shared with me what he obviously considered to be a ground-breaking revelation.

"Do you realize," he said, waving his fork knowingly, "that if CIOs and I/S directors would just bother to read the manuals we would be out of business?"

"Manuals?" I repeated, not sure I was hearing him correctly.

"Yes, product manuals," he reiterated. "I was discussing this just yesterday with someone. We agreed that if customers would just bother to read the manuals once in a while, most consultants would be out of business."

Needless to say, this was food for thought. Back at the office later that day, I looked at some of the manuals littering my cubicle. I must admit, if my office is a reflection of anyone else's, that most of us collect a lot of product manuals. Some of them I read only when I have a specific problem that needs fixing, such as the manual that came with my now ancient (but still functional) Hewlett-Packard LaserJet printer. I confess I have not read it cover-to-cover. The same is true of my approximately 5,400 Microsoft manuals -- one for each software purchase or upgrade I've done over the past six years. Again, I peruse these only if I am: a) looking to learn how to perform a specific function, or b) in trouble. Does this make me much different than anyone else in the I/S community? I think not.

Product evaluations are another thing, but these are usually demos sometimes accompanied by a full manual and other times by an abstracted instruction sheet. How deeply I delve into either is determined by how much I truly need to know about how the product works.

I will say this, though. As long as one is evaluating or working with a desktop-based product, reading the manual can prove to be an invaluable experience. It is even absolutely essential if one is working in a GUI-based rapid application development (RAD) environment. There are also many fine Web-based development products out there that have terrific step-by-step documentation explaining how all the technology works together.

Once you step out of the cozy, comfy world of Web-GUI-RAD, watch out. In the complex world of multitier, enterprise development, there is no manual. Would that there were.

Take, for example, Corba, that ubiquitous (and sometimes ambiguous) middleware standard put forth by the Object Management Group (OMG) consortium for building distributed object-based component applications. Across the Internet. Across the intranet. Across the enterprise. Around the world. Show me the manual.

Actually, there are many great Corba manuals. Many highly qualified Corba experts have written about the technology, covering such topics as getting started with Corba, the basics of Corba, design patterns in Corba, Event Services in Corba, the Corba Interface Definition Language (IDL), Corba examples and so on. You get the picture. If you want to know more about Corba, there is also the OMG Web site. This is a very helpful site that allows interested parties to download any of the approximately 82,000 pages of useful documentation on any one of the Corba services, facilities or committee proceedings.

To really appreciate how intricate developing in Corba can become, just take a look at the OMG's Object Management Architecture (OMA). There are four main categories comprising the OMA:

1. The Object Request Broker (ORB) -- the core of the OMA, which defines the Corba object bus.
2. Corba services -- currently consists of 16 categories that are implemented as separate executables or as part of the actual applications. Basically, these are the core services necessary to develop applications in a distributed environment.
3. Corba facilities -- define horizontal or vertical services across applications and are used directly by business objects.
4. Application Objects -- the actual business objects and applications utilizing the Corba framework.

All interfaces to servers in the Corba environment are defined using the OMG's IDL, which is platform-, language- and operating system-independent. (Given this, we can see the Java language as a natural fit for the Corba environment.) The caveat is that the IDL defines only the interfaces, not the actual implementation criteria. Users must ascertain which services they must purchase from other vendors or be willing to write it themselves in a Corba environment. I feel compelled to point out that there is no single source manual to help with the latter category.

As previously mentioned, there are currently 16 Corba services, five of which are completed, and the remainder of which are in varying stages of in-process. As with any consortium, proposals must go to committee for approval. Again, users must carefully determine which of the Corba services they may need, which are completed, and what portion (if any) of their own code they need to write. Corba-compliant ORB and middleware vendors can be depended on to fill many of the holes here, but each vendor has different offerings with various levels of functionality.

Problems, problems everywhere

Bleeding-edge organizations, such as those found in finance and insurance sectors, often have teams of research personnel and engineers to evaluate these scenarios. And while this type of resource is a luxury the I/S masses cannot afford, it may be a comfort to know that even the elite have their problems. Case in point: I called an I/S executive I know at a leading brokerage firm to get his input for this column. He has been working with a Corba-based distributed IDE for about six months. When I finally got him on the phone (after several tries), he was very apologetic for the delay, but indicated that he was so busy wrestling with "this thing" he would not be able to talk to anyone for quite a while. Like maybe six months.

"It's tough getting this right," he said wearily. "And we even had experienced object programmers going into this project." The organization has also had to go outside for help from several third-party consultants. When struggling with architectural issues of this magnitude, the manual just doesn't make it.

Christopher Beale is a senior software engineer and architect at Deneb Robotics Inc., Troy, Mich. The company specializes in discrete event simulation, virtual prototyping, telerobotics and virtual reality. "We help ship builders manufacture ships in a virtual environment," said Beale. The company has been around for more than a decade, and is currently looking to replace its core systems -- written in C -- with multithreaded, object-oriented distributed systems. Beale said that any manual or book describing Corba uses the standard illustration of a bank-account server model. However, this is not comparable to the intense number-crunching, real-time environment found in robotics engineering and simulation-based design.

"Corba as a true, distributed object facility has many shortcomings. If you're using it to tie various componentware products together, it's great. For engineering applications, I'm not sure yet," noted Beale. Deneb is using Corba as a concession, not a choice. The company must have Corba compliance in order to get buy-in from its clients -- the government, in particular.

Beale finds that decisions are made and implemented within organizations at two levels. Management is done with glossies, he said, but it's when you go to step two -- actually trying to apply the software design methodology -- that you find you must go beyond the manual. Fortunately for Beale (and Corba), there are tools on the market to make a Corba migration/installation easier. And there will be many more of these tools emerging over the next several months. In Deneb's case, the company is using a set of toolkits from Rogue Wave Software to assist in its move from a procedural C-based API to an object-oriented API.

According to Joseph Dionise, a senior software engineer at Deneb, using the Rogue Wave toolkits has made life much easier. The C++ library defines the necessary containers and data structures for creating classes and objects. "All their toolkits are threadsafe, which is obviously important to us as we try to achieve a multithreaded environment," said Dionise. The synchronization primitives, the threading primitives and so on, are all presented by the toolkits as class objects in C++.

"This elevates us to the object-oriented world, where we can actually manipulate and store objects. We don't have to worry about the low-level stuff, because this allows us to concentrate on writing our code," he noted. Dionise believes this will promote code reusability and extend the life cycle of the product itself.

The point here is that this is all new. Not just distributed object-oriented computing, but Internet-based computing, Java and its related Beans -- none of this has been around a long time. And if your firm is employing a Corba framework, trying to stay up-to-date with the state of the Corba spec itself is like trying to hit a moving target.

The reality is that the OMG, like all standards bodies, moves slowly, said Deneb's Beale. However, when implementing a Corba-based distributed enterprise solution, there is no manual. There will never be a one-size-fits-all approach, and there is certainly no such thing as "21-days to learning Corba," or probably much else, for that matter.

Besides, said Beale, if all you had to do was read the manual -- what happens if you lose the manual?

Food for thought.