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:

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.