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:
- The Object Request Broker (ORB) -- the core of the OMA, which defines the
Corba object bus.
- 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.
- Corba facilities -- define horizontal or vertical services across
applications and are used directly by business objects.
- 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.
About the Author
Sally J. Cusack is research manager of application-enabling technologies at IDC, Framingham, Mass.