Web Services: Its So Crazy, It Just Might Not Work

Jeff Bone jbone@jump.net
Tue, 31 Jul 2001 15:48:55 -0500


Clay Shirky wrote:

> Channeling the spirits of FoRK, I think Dave's answer would be "That's
> what I've been saying for years" while Mark's would be "Nothing will
> help, because the brokeness is in the idea of RPC, not in the
> implementations."

So:  I believe that Mark believes this, but I'm at a total loss to
understand why.  Let me explain why I'm at a loss:  by my way of thinking,
RPC (or RMI, in a general interpretation, though it has a subtly
difference) is nothing more than a syncronous request / response paradigm
which invokes a named chunk of code, passes some parameters, and gets a
result.  It's exactly the same as message passing, function invocation,
etc. etc. etc.  RPC is just the nonlocal case of the same thing that *all*
software is based upon, locally.  Message passing has been shown in the
past at great length to be a computationally complete paradigm.

Even our various protocols (SMTP, HTTP, POP, etc.) considered *with* their
application semantics constitute nothing more than a particular set of
RPCs at an abstract level;  admittedly, the way operations are invoked,
parameters passed, and results returned are each case done in different,
idiosyncratic and ad-hoc ways.  Nonetheless, they're RPCs;  to believe
otherwise is to take an extremely narrow view.  And if you believe they
are sets of specific operations bound to an RPC-like paradigm, then surely
you have to question why marshalling / unmarshalling, naming of
operations, etc. are done in different ways, when a common substrate would
serve better.

I'm a bit at a loss to understand what other paradigms Mark might find
acceptable;  the only three other distributed communication paradigms I
can imagine are asynchronous notifications --- which can easily be built
atop RPC, or vice versa --- and actual code passing / code migration /
remote execution as is done with database engines and as has been broadly
attempted in the mobile agent community.  (The latter, like the former, is
usually built *atop* RPCs, rather than the other way around.)  Finally, a
third paradigm is the shared memory / data paradigm found in various
loosely-coupled mechanisms such as Linda, database-mediated communication,
etc.

So help me out, Mark:  do you really believe that application protocols
such as HTTP are qualitatively and significantly different than RPCs, or
can you see clear to the realization that they are just specific and
specifically-constrained sets of RPCs?  Or do you see HTTP (in particular)
as an example of a shared memory / data paradigm?  (IFF the latter, then
this is an interesting view, although IMO it misses the point:  regardless
of the higher-level abstractions, you still have to deal with marshalling
/ unmarshalling, naming / addressing, and transport.  IMO that is the
minimalist set of lowest-common-denominator concerns, and all the various
HTTP-RPC efforts should attempt to do is deal with those issues.)


> > Loose coupling and remote method invocation sound like they are
> > opposites.  But I suppose anything to help loosen the coupling in an
> > RMI/RPC situation will help.

Actually, they're not at all opposed.  You're referring to a special case
of the general binding problem.  This is simply a more acute case of the
problem that we've had (and solved) in local operating systems for years;
in the local case, it's solved by a host of mechanisms including the
filesystem namespace, dynamic loaders, registries, local IPC port spaces
and mappers, etc.

If Mark's objection to RPC/RMI revolves around the assertion that
distributed systems must be built on loose coupling / late binding, then I
wholeheartedly agree, and will even go further:  it's an imperative that a
distributed system be late bound for scalability, reliability,
availability, extensibility, maintenance, and a host of other issues.  But
while I agree with the argument, I don't agree with the conclusion;
there's no requirement that RPCs be early bound or tightly coupled.  We've
solved this problem over and over in the distributed systems community;
we've got all kinds of naming services and schemes, discovery and location
services, message routers, queueing and spooling systems, etc.

Mark's objection is absurd in the face of overwhelming evidence;  our
network world is full of existing services and applications built atop
old-school RPC mechanisms.  Proposing to use (for example) XML as a
marshalling format instead of XDR, the URI space instead of some other
space, and HTTP (sp. POST) as the transport is simply exercising a
reasonable set of engineering trade-offs.  There's no reason to believe
that it shouldn't succeed (i.e., enjoy use in as great a variety of
widely-deployed applications and services) at least as well as other,
earlier RPCs --- and many good reasons to believe it should.  And in
particular, the "secular" / neutral stance of SOAP, etc. -wrt- object
model particulars should allow it to avoid the kinds of religious crusades
/ jihad that have plagued the distributed object community for years,
-wrt- CORBA, DCOM, Java RMI, and other efforts.

jb