Chapter 1
Since the mid-nineties, the computing industry has been using object-oriented middleware platforms, such as DCOM
[3] and CORBA
[4]. Object-oriented middleware was an important step forward toward making distributed computing available to application developers. For the first time, it was possible to build distributed applications without having to be a networking guru: the middleware platform took care of the majority of networking chores, such as
marshaling and
unmarshaling (encoding and decoding data for transmission), mapping logical object addresses to physical transport endpoints, changing the representation of data according to the native machine architecture of client and server, and automatically starting servers on demand.
•
Although CORBA was available from a variety of vendors, it was rarely possible to find a single vendor that could provide an implementation for all of the environments in a heterogeneous network. Despite much standardization effort, lack of interoperability between different CORBA implementations continued to cause problems, and source code compatibility for languages such as C or C++ was never fully achieved, usually due to vendor-specific extensions and CORBA’s lack of a specification for multi-threaded environments.
•
Performance issues have plagued both platforms through their respective histories. For DCOM, only one implementation was available, so shopping around for a better-performing implementation was not an option. While CORBA was available from a number of vendors, it was difficult (if not impossible) to find standards-compliant implementations that performed well, mainly due to the complexity imposed by the CORBA specification itself (which, in many cases, was feature-rich beyond need).
DCOM was superseded by the Microsoft .NET platform [11] in 2002. While .NET offers more powerful distributed computing support than DCOM, it is still a Microsoft-only solution and therefore not an option for heterogeneous environments. On the other hand, CORBA has been stagnating in recent history and a number of vendors have left the market, leaving the customer with a platform that is no longer widely supported; the interest of the few remaining vendors in further standardization has waned, with the result that many defects in the CORBA specifications are not addressed, or addressed only years after they are first reported.
Simultaneously with the decline of DCOM and CORBA, a lot of interest arose in the distributed computing community around SOAP
[26] and web services
[27]. The idea of using the ubiquitous World Wide Web infrastructure and HTTP to develop a middleware platform was intriguing—at least in theory, SOAP and web services had the promise of becoming the lingua franca of distributed computing on the Internet. Despite much publicity and many published papers, web services have failed to deliver on that promise: as of this writing, very few commercial systems that use the web services architecture have been developed. There are a number of reasons for this:
•
The lack of higher-level abstractions prompted a number of vendors to provide application development platforms that automate the development of SOAP-compliant applications. However, these development platforms, lacking any standardization beyond the protocol level, are by necessity proprietary, so applications developed with tools from one vendor cannot be used with middleware products from other vendors.
•
There are serious concerns [15] about the architectural soundness of SOAP and web services. In particular, many experts have expressed concerns about the inherent lack of security of the platform.
These options look very much like a no-win scenario: you can choose a platform that will run only with limited languages or platforms, you can choose a platform that is complex and suffering from gradual abandonment, or you can choose a platform that is inefficient and, due to the lack of standardization, proprietary.
