Re: Question for the Sun people

dave - i enjoy baiting folks as much as the next fellow, but i do believe
you're overfishing the pond.

a well-designed rpc works just fine in a tightly-coupled environment. for
example, nfs is a tightly-coupled system using RPCs. when running in a
properly configured LAN, a ermote disk accessible via NFS is virtually
indistinguishable from a local disk. to achieve these kinds of performance
characteristics, tightly-coupled systems tend to:

- use connectionless transport mappings

- be implemented as operating system functions (or in hardware) rather than
as user-level programs

- operate in a high-throughput, low-latency, low-loss networking environment

- use compact encoding schemes

- have a single administrative control (a side-effect of some of these
engineering constraints)

there's nothing new here, anyone working at xerox parc (in the late 70's)
could recite a longer list than the one i've just enumerated.

although i won't claim to speak for jini, to me their story seems to be on
building systems that operate in environments that meet many, if not all, of
those conditions. so, i'd say that their use of rpc is an appropriate one.
they claim only that they're a great way to connect thin devices in your
home or office, etc. although i haven't used their stuff, from an
engineering perspective, they are on solid ground. as a further example of
their high-cluefulness, they understand that when you splice a network in
between a procedure call and the execution of the procedure, then you can
get exceptions to the vanilla procedure call model.

as to whether jini/rmi is cool or not, frankly, that's a matter of taste.
java's not my thing, but a lot of people get a lot of value out of it, so i
have to call it a good thing.

historically, the people who have designed and built protocols for use in an
internet environment haven't used the rpc paradigm. certainly those folks
had a lot of interactions with the folks at parc (since the world was much
smaller back then). however, the thinking is that the internet (nee catenet)
model doesn't provide these engineering constraints, e.g., routers can
experience congestion, links have varying thoughput and latency
characteristics, etc.

as to why xml-rpc and soap are cool or not, that too is a matter of taste.

/mtr

ps: i build loosely-coupled systems; accordingly, i am blessed with a
complete lack of affiliation with any of the rpc guys mentioned above.


----- Original Message -----
From: "Dave Winer" <dave@userland.com>
To: <xml-dist-app@w3.org>
Sent: Monday, June 05, 2000 22:26
Subject: Question for the Sun people


> I just was reviewing some of the material for the Java One conference, and
> re-read the What is Jini? page..
>
> http://www.jini.org/whatisjini.html
>
> "Devices in a network employing Jini technology are tied together using
Java
> Remote Method Invocation (RMI). By using the Java programming language, a
> Jini connection architecture is secure. The discovery and join protocols,
as
> well as the lookup service, depend on the ability to move Java objects,
> including their code, between Java virtual machines."
>
> Is this RPC?
>
> And if it is, how is it different from other forms of RPC?
>
> In other words, why are Jini and RMI cool, but XML-RPC and SOAP not?
>
> Dave
>
>

Received on Tuesday, 6 June 2000 11:51:13 UTC