--- In [email protected], Bill de hOra
<[EMAIL PROTECTED]> wrote:
>
> If we had a trace on the wire, it would look like a regular HTTP
> request. There's no embedded method call in the request body (or
the
> URL), unless we want to argue that GET is an RPC.
>
Bill,
Sorry for the late response, but I've been distracted on other things
for the past couple of days.
I didn't mean to pick on you, but I do see the "RPC is bad" meme
being parroted quite a lot and not subject to much discussion or
justification. So I have been looking for an opportunity to prompt
more discussion. I'm not so sure that RPC is intrinsically bad and
think that the truth is, as always, somewhat more nuanced.
To explore further and address your points as well as those from
Stefan and Miran, let's look at some definitions of RPC. From the
classic paper by Birrell/Nelson [1], we have:
"...it is proposed that [procedure calls] be extended to provide
for transfer of control and data across a communication network.
When a remote procedure is invoked, the calling environment is
suspended, the parameters are passed across the network to the
environment where the procedure is to execute [...], and the desired
procedure is executed there." (Section 1.1)
Quite a few years later, a certain student wrote the following in his
doctoral dissertation [2]:
"What distinguishes RPC from other forms of network-based
application communication is the notion of invoking a procedure on
the remote machine, wherein the protocol identifies the procedure and
passes it a fixed set of parameters, and then waits for the answer to
be supplied within a return message using the same interface."
(Section 6.5.2)
By both of these definitions, your code example below is RPC:
resp, content = h.request("http://example.org/people/anne ", "GET")
Personally, I don't have a problem with this and do not consider it
inherently bad. Others, particularly Gregor Hohpe [3] criticise the
synchronous "call stack" style of RPC programming, citing the classic
paper by Waldo et al. on the problems of distributed computing [4].
But many RPC mechanisms also support asynchronous calls (e.g.
Microsoft's version of DCE-RPC [5] as well as Java's JAX-WS [6]).
Whilst Hohpe might be happy with those, we still call them RPC, don't
we?
Hohpe seems most concerned that the programmer should *know* that
certain actions involve network activity and therefore be treated
differently. But this is all just in the programmer's mind and could
also be achieved through simple naming conventions, or through IDE
support to clearly identify such actions to the programmer.
So perhaps we need to consider more than just the programmer's view
of RPC. We could go further and break down what we commonly know as
RPC into various elements such as:
. The use of programming language objects to define the data to be
exchanged
. The automatic generation of code for marshalling/unmarshalling
of data into messages
. A request/response message interaction style (or MEP)
. The expectation of immediate response to requests
. A programming construct that makes remote network access look
the same as a local procedure call
Each of these elements has its own pros and cons and we would be hard
pressed to argue that any one of them was fundamentally bad.
So what about the architect's view?
There is something about a network system that allows chunks of
functionality ("procedures") deployed on one network node to be
invoked ("called") from other nodes ("remote) and with the
expectation of an immediate response that characterises RPC. I would
probably struggle to create a really precise definition here, but
intuitively we seem to "know" an RPC system when we see one.
Using this view, and as I described last year in a comment on
Stefan's blog, REST is fundamentally RPC with just four "P"s [7].
Now, before the REST guys pile in to refute this, I don't consider
this to be a problem. It doesn't mean that the systems that you
*construct* with REST are also RPC.
When we compose complex systems, the new system takes on properties
that can be markedly different to those of its constituent parts.
For example, the reliable stream service of TCP is built on the
unreliable IP datagram. The stateless HTTP protocol is built on top
of stateful TCP. And so on.
If you build a house out of bricks, that doesn't make the house also
a brick.
Now, we know that all such engineering abstractions are "leaky" to
some extent [8], that is some of the properties of a system's
component parts are still relevant to the whole system. But that
still doesn't undermine the value of the abstractions.
Perhaps then, our problems with RPC stem more from how it has been
applied in practice, rather than any fundamental flaw. Clearly,
there are many failed attempts at building distributed systems out
there, but this is true whatever the technology: DCE, HTTP, CORBA,
Tibco, MQ Series, etc.
As I've said before, this is, I think where REST scores most highly
over WS-Everything at the moment, by providing practical guidance
("constraints") on how the overall system should be designed to
increase the chances of success.
That doesn't mean, however that similar guidance, whether in the form
of patterns or otherwise could not be applied to RPC, CORBA or even
WS-Everything with equal success.
> Btw, the original fragment is Python code using the httplib2
library
> (http://bitworking.org/projects/httplib2/). The resp, content pair
you
> underlined - resp is a dictionary of HTTP headers and content is
the
> returned entity/representation for the URL.
Yes, I tried to underline just the method invocation, but Yahoo
groups got in the way and removed the leading spaces!
Regards,
-Mike Glendinning.
[1] Implementing Remote Procedure Calls, A.D. Birrell and B.J.
Nelson, ACM TOCS 2.1, February 1984
http://doi.acm.org/10.1145/2080.357392
[2] Architectural Styles and the Design of Network-based Software
Architectures, R.T. Fielding, 2000
http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertati
on.pdf
[3] Programming Without a Call Stack, Gregor Hohpe, 2006
http://www.enterpriseintegrationpatterns.com/docs/EDA.pdf
[4] A Note on Distributed Computing, Jim Waldo et al., SMLI TR-94-
29, Sun Microsystems, November 1994
http://research.sun.com/techrep/1994/abstract-29.html
[5] Microsoft Win32 and COM Development, Overviews, Asynchronous RPC
http://msdn2.microsoft.com/en-US/library/aa373550.aspx
[6] JSR 224: Java API for XML-Based Web Services (JAX-WS) 2.0
http://jcp.org/en/jsr/detail?id=224
[7] More SOAP vs. REST Arguments, February 2006
http://www.innoq.com/blog/st/2006/02/22/more_soap_vs_rest_arguments.ht
ml
[8] The Law of Leaky Abstractions, Joel Spolsky, November 2002
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
