Opinion

 

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.

acmqueue

Originally published in Queue vol. 5, no. 4—
Comment on this article in the ACM Digital Library




More related articles:

Martin Kleppmann, Alastair R. Beresford, Boerge Svingen - Online Event Processing
Support for distributed transactions across heterogeneous storage technologies is either nonexistent or suffers from poor operational and performance characteristics. In contrast, OLEP is increasingly used to provide good performance and strong consistency guarantees in such settings. In data systems it is very common for logs to be used as internal implementation details. The OLEP approach is different: it uses event logs, rather than transactions, as the primary application programming model for data management. Traditional databases are still used, but their writes come from a log rather than directly from the application. The use of OLEP is not simply pragmatism on the part of developers, but rather it offers a number of advantages.


Andrew Leung, Andrew Spyker, Tim Bozarth - Titus: Introducing Containers to the Netflix Cloud
We believe our approach has enabled Netflix to quickly adopt and benefit from containers. Though the details may be Netflix-specific, the approach of providing low-friction container adoption by integrating with existing infrastructure and working with the right early adopters can be a successful strategy for any organization looking to adopt containers.


Marius Eriksen - Functional at Scale
Modern server software is demanding to develop and operate: it must be available at all times and in all locations; it must reply within milliseconds to user requests; it must respond quickly to capacity demands; it must process a lot of data and even more traffic; it must adapt quickly to changing product needs; and in many cases it must accommodate a large engineering organization, its many engineers the proverbial cooks in a big, messy kitchen.


Caitie McCaffrey - The Verification of a Distributed System
Leslie Lamport, known for his seminal work in distributed systems, famously said, "A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable." Given this bleak outlook and the large set of possible failures, how do you even begin to verify and validate that the distributed systems you build are doing the right thing?



© ACM, Inc. All Rights Reserved.