[Up: Distributed Systems]
[Previous: Middleware] [Next: Object Request Broker]

Evaluation


Table 2.1: Distribution Platform Feature Matrix
Platform Addressing Synchronization Encoding Mobility Interoperability
Sockets no no no no no
PVM yes no yes no yes
Erlang yes no yes no no
Distributed Oz yes yes yes yes no
RPC no yes yes no yes
CORBA yes yes yes (yes) yes


Each of the presented distribution platform comes with its own unique approach to distribution. Diverse as they are, they have in common that all are in use today, and new distributed applications are being implemented with them. As a summary, table 2.1 shows a matrix of the features provided by each distribution platform:

Addressing:
Whether an abstraction of native networking addresses (host name and port number) exists.
Synchronization:
Whether an explicit model of synchronization between the components of a distributed system is enforced. ``No'' means that the developer must take care of proper synchronization.
Encoding:
Whether a common encoding of the transferred data is used, thereby abstracting the hardware.
Mobility:
Whether the distribution platform allows mobile components.
Interoperability:
Whether components can interact regardless of their hardware, operating system or programming language.
Quality of service is not shown for the reason that a distribution platform's support cannot be measured with a simple yes or no.

One might argue that the distinction made between high-level distribution platforms and middleware in section 2.1 is fuzzy. It was argued that remoteness in a high-level distribution platform is transparent, and that seems just as true for client-side stub objects in CORBA.

Certainly, stub objects reach into the application layer. However, with CORBA, the developer is always well aware of holding no more than a stub object: there is a precise distinction that objects of a certain type can be either local or remote, but not both. From an academic point of view it might seem silly to point out the importance of the IDL file: objects whose interface is declared in IDL are always accessed using remote invocation semantics even if their implementation is local, and objects whose interface was not declared in IDL can never be remote. The potential remoteness of an object must be decided on at design time.

On the other hand, the ERLANG or Distributed Oz developer can choose to make an object remote (or mobile) at implementation time, or even at runtime.

The difference between middleware and high-level distribution becomes more obvious on the server side. If ERLANG or Distributed Oz were used to implement a Client/Server system in CORBA fashion, the server program would be the same as if integrated locally with the client. Using CORBA, the programmer cannot use the same code that would be used in a stand-alone, non-CORBA program, but the object implementation must inherit from a special skeleton, must follow a language mapping's rules for parameter passing, and the server program must negotiate with both the ORB and an object adapter before it can offer its services.

Server-side programming using middleware is quite different from both local programming and the server-side programming with a high-level distributed programming language.

The question for the ``best'' distribution platform is impossible to answer. Certainly using communication packages like sockets is cumbersome, but then, they're available everywhere and don't require third-party software, which can also be considered a plus. And some purists will always argue that ``real performance'' can only be achieved by directly using raw IP.

PVM has found its niche despite its shortcomings, and the same is true for high-level languages such as ERLANG. Despite its advantages, high-level distribution will remain in a niche for as long as developers keep sticking to the programming paradigms they are used to, unwilling to commit themselves to a new programming language for various reasons: business, unflexibility or performance concerns.

This is the market exploited by middleware, which allows to use distribution while sticking to the programming environment which the developer is used to. Middleware might not be the best choice in an academic sense, but is a ``common denominator'' with many real-life advantages.


[Previous: Middleware] [Next: Object Request Broker]
[Up: Distributed Systems]

Frank Pilhofer
1999-06-23