[Up: Design and Implementation of]
[Previous: Contents] [Next: Distributed Systems]
As systems become more interconnected, there is a growing need for these systems to cooperate. While basic message interchange (like e-mail or the downloading of files) is already common, the possibilities of distributed systems within this interconnected world are yet somewhat uncharted. One reason is the inherent complexity of a distributed system, which makes distributed components much harder to design, debug and maintain than standalone pieces of software.
But the advantages of a distributed system are too promising to ignore. They offer greater speed by spreading complex tasks over many computers working in parallel, fault-tolerance by using redundant servers, or delegation, where a client contacts the server to perform some type of service. The offering and using of services are of particular interest for the Internet today, where companies are not satisfied with presenting information on the World Wide Web, but also want to present their services, online, to the world-wide user community.
Software - easy to use distribution platforms - is needed to make this feasible.
Communication is provided by networks, and it is certainly possible to build distributed systems with only what the network itself has to offer. However, distribution is much easier to achieve, to maintain and to extend, if the distribution platform provides an abstraction of the network and allows a more natural usage of remote components. Chapter 2 presents and evaluates a number of existing distribution platforms.
A common idea is the middleware approach of introducing a new layer into the program that keeps the complexity from the developer by hiding as many details of distributed programming as necessary. To the developer, the middleware presents seemingly local objects, and invocations on the local proxy cause the necessary data to be transparently sent to the recipient.
One popular example of such middleware is the Common Object Request Broker Architecture (CORBA), which is part of the Object Management Architecture as specified by the Object Management Group. CORBA uses the Object Request Broker as the glue between individual pieces, which is responsible for directing a client's method invocation to the appropriate object implementation.
CORBA is already in widespread use, both in education and business. An Object Request Broker comes built into the popular Netscape Navigator, a freely available hypertext browser for the World Wide Web with a sizable market share. With CORBA technology on desktops everywhere, the above scenario of offering world-wide services is at hand, but not yet reality.
While CORBA can indeed hide many details of Client/Server programming from the client, experience has shown that a much tighter involvement with the Object Request Broker is necessary on the server side. For this, CORBA uses the concept of object adapters which mediate between the ORB and the server on how to represent servants to the outside world; servers can choose an object adapter that best fulfills its requirements.
This thesis focuses on the Portable Object Adapter, which was recently added to the CORBA standard to replace the original Basic Object Adapter. The latter proved to be ill-specified and insufficient for many a server's requirements. However, while the POA's specification drew from its authors' experiences with the BOA's shortcomings, the POA had not been implemented at the time of its writing.
The goal of this thesis was to verify that the POA specification is sensible and complete, by attempting a reference implementation.
An object adapter is not a standalone entity, it is but a part of the architecture and requires an Object Request Broker to cooperate with. Rather than reinventing the wheel, the Open Source CORBA implementation MICO was chosen as platform. MICO was designed to be an extensible ORB; in particular, it allows for pluggable object adapters. Yet, as the implementation of the POA was begun, no object adapter existed in MICO but the ones it was originally designed for. Therefore, a side goal was to see how MICO's extensibility could cope with an object adapter whose requirements had not been anticipated.
After presenting and comparing other solutions for distribution in the second chapter, the world of CORBA is explored in more detail throughout the third chapter.
The fourth chapter takes a look at the server side of CORBA programs, explaining the design principles of object adapters in general and their realization by the two object adapters that have been specified by the Object Management Group themselves, the old Basic Object Adapter and the new Portable Object Adapter. The reasons why the BOA was abandoned will be analyzed, as are the areas the POA improves upon.
After all the abstract discussion in the previous text, chapter 5 first takes a brief glance at MICO and its extension mechanisms, and then presents the hands-on experience that was gathered in the attempt for a complete reference implementation of the POA and the extensions that were required.
The thesis then concludes with a look at the goals presented above, to what extent they have been achieved, and which areas of the Portable Object Adapter still need improvement. A few examples of POA-based server programming are included in the appendix.
At the time of writing in June 1999, version 2.2 of the CORBA specification was current, but draft documents of CORBA 2.3 were available and close to become official. This thesis mainly refers to CORBA 2.2, with frequent annotations about changes in 2.3 being based on the December 1998 draft.
[Previous: Contents] [Next: Distributed Systems]
[Up: Design and Implementation of]