From: Cliff Schmidt (cliff_at_bea.com)
Date: Wed Jan 28 2004 - 05:04:52 PST
The fun part about reading the RPC paper was comparing the many similarities
to the way RPC is implemented today -- 20 years later. It appears this
paper had an extremely significant impact on future production
implementations of RPC. While the paper mentions that RPC was mentioned
as early as 1976, it appears that most of the key concepts that are used
in programming languages today such as Java came directly from this paper.
In particular, the authors state that the primary purpose of their project
was to make distributed computing easy. One can imagine that without the
client and server stubs model, the same tasks would have been much more
cumbersome to implement within an application.
Some of the similarities were:
- manufacture of stubs during compile-time (using Lupine)
- RPC runtime to handle all the plumbing without the application seeing
more than just a local procedure call
- interfaces as the basis for building implementations on both the client
and server side, depending on whether the interface is being imported or
"exported" (which would be simply called "implemented" in Java).
- interfaces used for compile-time type checking
- checks to disallow applications from passing arguments by reference
(since there is no shared memory space)
- naming, being factored into type and instance. In Web services today,
one would refer to a WSDL's portType and port.
- locating a binding through a lookup service looked similar to Java's
JNDI service or possibly even UDDI, which allows a client to find a
particular instance, or even any arbitrary instance that implements a
particular type/interface/portType.
- echoing back the caller's process identifier in the response message
is also being employed in a Web service spec named, "WS-Addressing".
Some other parts of this paper that I found interesting:
- justification to create a protocol specific to RPC for performance
reasons, since builk-transfer protocols have very different requirements
- the choice to assign a unique identifier that is not reused if a
server fails and then recovers. Java's JNDI service apparently uses the
same assumption since I've noticed before that a client that has a proxy
to a particular server will not be able to use that proxy if the server
restarts. Instead the client must go back to JNDI for a new handle.
- lots of awareness to avoid having to maintain state any longer then
necessary
- the probe packet that continues to verify a working network between
the client and server while waiting for a server to return from an RPC
call.
- early thoughts on the need/applicability of combining RPC and large
attachments foreshadowed the same debate around SOAP with Attachments.
- interesting that the authors felt that RPC could have been just as
easily designed around message passing rather than procedure calls;
they didn't appear to have a strong bias.
- they state that an exception should be "defined in the package's
interface"; this sounds like what Java does with checked exceptions.
This archive was generated by hypermail 2.1.6 : Wed Jan 28 2004 - 05:04:55 PST