November/December issue of acmqueue

The November/December issue of acmqueue is out now


Distributed Development


Corba: Gone But (Hopefully) Not Forgotten

There is no magic and the lessons of the past apply just as well today.

Terry Coatta

Back in the June 2006 issue of Queue, Michi Henning wrote a very good condensed history of CORBA and discussed how some of its technical limitations contributed to its downfall. While those limitations certainly aided CORBA's demise, there is a very widespread notion that the ultimate cause was the ascendance of Web Services, a notion that is compounded with the further belief that Web Services' dominance of the distributed computing landscape is indicative of its technical superiority to the systems that preceded it, such as CORBA and DCOM.

Having worked in distributed systems for a number of years—indeed far enough back in time that building a distributed system meant actually packing bits into UDP packets with lovingly hand-crafted C code—I think this assumption is unwarranted. Worse, it indicates a failure to appreciate the aspects of these previous systems that were well-engineered. This is a symptom of a "silver bullet" mentality that sees Web Services as a radical departure from the past that will finally remove the complexity from designing and building distributed systems.

Is Web Services really that different from the systems that preceded it? One of the significant benefits attributed to Web Services, indeed to such a degree that it's part of its name, is that it is focused on Service Oriented Architectures (SOA). This is frequently contrasted with the style of fine-grain distributed objects that is considered the defining characteristic of CORBA-based systems. It is certainly true that CORBA provided distributed access at the level of individual objects. However, it should be noted, CORBA also supported recursively defined data structures that made it simple to exchange complex data structures by value.

In fact, back in the mid-90's I was part of team that designed and implemented a CORBA-based system that exchanged software management information using this capability. We designed a CORBA data structure representing a tree of nodes. Each node had a name, a value, and some other attributes. It also contained a number of child nodes, each with the same structure. Leaf nodes, of course, contained no children. This data structure was relatively straightforward to represent in CORBA IDL using structs, unions, and arrays. Any tree of such nodes could be easily passed through a CORBA method call—the runtime would serialize the tree and transmit it in bulk to the receiver. Furthermore, the tree contained no object references at all, and so represented a purely value-based exchange of information. Finally, one may note that the structure and contents of this tree bear more than a passing resemblance to the DOM representation of an XML document.

I think that this demonstrates that while CORBA certainly could support fine-grained object architectures, it by no means forced one to adopt that style. Certainly, the ease of implementing a fine-grained architecture may have been beguiling to developers who had little experience with building distributed systems. But it�s not as though fine-grain objects are totally without value. If you happen to be dealing with a multi-processor system where bandwidth and latency considerations are quite different from those of an application that is distributed across the internet, then fine grain objects have some appeal.

And that is the crux of the issue. Back when we built that system, we could have chosen to define a bunch of object interfaces and pass around references to them. But we knew that the management information would generally be accessed in bulk and that making a bunch of round trips to pick the information up piece by piece didn't make any sense. Rather than assuming that CORBA would somehow solve our problems for us, we made sure to choose those elements of CORBA that provided the behavior we needed. We created a "service oriented" solution because that was what made sense.

Using Web Services is no more a guarantee of building a good distributed system than using CORBA was a guarantee of building a bad one. Web Services cannot magically confer on a system design the ability to effectively deal with limitations in latency and bandwidth. It cannot remove the difficulties that arise from partial failures and dependencies on systems that may be temporarily inaccessible. Fortunately, people have been designing and building distributed systems for many years, often using technologies like CORBA, DCOM, and their predecessors. Don't assume that all that work has been superseded by the magic of Web Services, because there is no magic and the lessons of the past apply just as well today.


Originally published in Queue vol. 5, no. 4
see this item in the ACM Digital Library



Andrew Leung, Andrew Spyker, Tim Bozarth - Titus: Introducing Containers to the Netflix Cloud
Approaching container adoption in an already cloud-native infrastructure

Marius Eriksen - Functional at Scale
Applying functional programming principles to distributed computing projects

Caitie McCaffrey - The Verification of a Distributed System
A practitioner's guide to increasing confidence in system correctness

Philip Maddox - Testing a Distributed System
Testing a distributed system can be trying even under the best of circumstances.


(newest first)

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.