DBMS, May 1997
The trouble with most articles on these emerging technologies is that they ignore -- or at best soft-peddle -- the downside of whatever they're presenting. Case experiences are usually even worse; to make themselves and their companies look good, the IS people who write these articles make it sound like everything went smoothly. The disasters (such as with U.S. West), which would probably provide more useful lessons, are kept quiet because of the possible firings, loss of prestige, and even pending lawsuits.
What I'm getting at is that the balancing articles, such as Hart's, are rare and instructive. Although I've seldom liked Microsoft products, I can see the advantage of going with DCOM. A vendor who has a single, unified strategy, even a flawed one, starts with a huge advantage.
Although I think that Microsoft manipulates its standards to benefit its own product line, I hadn't known that the CORBA standard is similarly, but less obviously, manipulated by the larger OMG players. Thanks for pointing it out. I started my subscription to DBMS today.
Ken Nichols
ken_nichols@acm.org
For example, the use of CORBA's Dynamic Invocation Interface (DII) is identified as a necessary but inefficient interface. The reason cited for its necessity is that large applications cannot statically link all possible client stubs. It's difficult to refute unquantified assertions, yet if this were to become a problem it should be a warning that the system's client/server or peer-peer workflow needs revision. A well-designed distributed system cultivates paths of flow through the application set so that all clients do not call all servers. A direct analogy can be made to single-process program design, where layered software is developed (libraries use other more specialized libraries internally), so that the top level of logic is not exposed to all linked APIs. Similarly, in distributed systems, the flow of remote procedure calls should be built with well-defined paths from high- to low-level CORBA interfaces. It has been our experience that, even in very complex systems, no more than a handful (10 would be a large number) of interfaces need to be linked to an application at one time. But beyond this observation, the further conclusion that DII increases network traffic ignores the obvious solution: caching fetched interface definitions once read. We use DII as an interface between HTTP requests and a Web server, with a set of CORBA applications behind. By simply caching interface definitions when read from the interface repository, we find that almost no additional network traffic is generated by DII.
Hart curiously claims that "you can't inherit from (CORBA) objects" and "you can't navigate the top object to get to the embedded object." CORBA supports inheritance explicitly in its IDL, and in its language bindings it allows any form of inheritance found in that language (see for example the C++ and Java bindings). Furthermore, any object can be "narrowed" to its inherited types, allowing straightforward navigation from top to bottom.
Finally, Hart claims that CORBA is more complex than DCE and asserts that it should not be run on your local LAN. Generally speaking, CORBA is as "complex" as the application that you build with it. On our LANs we run CORBA without fear or mishap.
I think that some readers may be misled to believe that CORBA is the cause of your garden-variety distributed-system woe. By understanding what CORBA does well, and by building on its basic capabilities, we have found that it greatly simplifies our development task.
Tom Speeter
Healtheon Corporation
ths@healtheon.com
ODMG (Object Database Management Group) fetched objects are flat as a pancake. These are objects returned from a database fetched with the ODMG mechanism and offer no benefit over a traditional database view returned from an SQL call. They cannot be navigated without your own software doing it.
Any time you hit the repository, you hit the database. This causes delay and performance hits. But, again, you had to do something in addition to what CORBA provides to solve the problem. When the problem is fixed, your solution may be nonstandard to CORBA. The DII is notorious for creating performance problems.
As I stated in the article, if you want to use this technology, be prepared to make your own mechanisms to overcome its inefficiencies and wait for them to become nonstandard once they are fixed.
--T. J. Hart
In 1994, a group of companies in the U.K., interested in promoting the use of RAD, got together as a result of some well-publicized disasters. They wanted to come up with a public-domain method for how to use RAD successfully. The DSDM (Dynamic Systems Development Method) Consortium brought together experienced and inexperienced RAD practitioners from software houses, tool vendors, hardware vendors, and end-user organizations. Our goal was to come up with a "magic" recipe. In February 1995, version 1 of the DSDM was released. It is based on practical experience, both good and bad, and it serves as a framework for using RAD with repeatable success.
I have been involved with the consortium since its inception, and I was involved in one of the early adopter projects with The Boston Globe. The purpose of the early adopter projects was to verify the method and enable it to be revised in light of practical use of the framework. The result was the release of version 2 of DSDM in December 1995. The method does not say what tools to use or what design and analysis techniques to use but concentrates on providing a formula, or recipe, that -- as long as you follow all of the steps -- leads to a successful RAD project. The consortium started in the U.K. but has spread to a number of countries and now includes the U.S. A Web site at www.dsdm.org provides case studies, including The Boston Globe's, details of the consortium, its members, and where they can be contacted.
Articles such as David Linthicum's help to highlight the pitfalls of not following a structured approach to RAD that cannot be done without good design and analysis. We have always said that with RAD you don't do anything different, you just do it in a different way. I look forward to reading his articles in the future. Keep up the good work.
Bob Longman
Origin UK Limited
rlongman@origin-at.co.uk
Jim Cain
j_cain@earthlink.net
I can't agree with you more. I have found that the support section becomes slack in monitoring that the backups were correctly processed. Then, when you need the backups, they are close to useless. Also, when they have to apply the recovery part of the plan, the support people are clueless as to what to do.
(The trained people have since moved on, and the new people haven't bothered to study and "practice" the recovery plan. OK, I'm exaggerating a bit to get my point across.) But that is why I tried to stress ongoing testing and "rehearsing" of the backup-and-recovery plan.
-- Martin Rennhackkamp