Bill Venners: Looking at the complexity of distributed systems, then, each process
on the network is like one piece of this whole system. And the interface between
those pieces has traditionally been a protocol. One of the things Jini does is use mobile
objects to be a nexus between the client and the service. And that lets you raise the level
of abstraction between the client and service. Now, when we define a protocol as our interface, there is some handshaking going on
and then there's just data structures. And nowadays, XML is all the rage for structuring data. But in my protocol spec I have
to talk pretty much about all
the details of that data structure. The client-service contract is in terms of information. Whereas in an API, I'm talking about
code, and the contract is more in terms of behavior.

James Gosling: Right.

Bill Venners: And the thing I think I can do with behavior is I can be more vague. I don't have to
say how, just what.

James Gosling: Right. Almost always, the less you can say, the better off you are.

Bill Venners: Because?

James Gosling: Because every commitment you make is a piece of flexibility you've lost.

There is this duality between network protocols and interfaces. They are both kind of the same
thing. They are a way for these
two parties to communicate. When you deal at the level of a network protocol, you don't
have to specify what the program interfaces on the other side look like. So that gives you the
freedom to write a C API here and a Pascal API there and an Ada API there, and they can be completely
different. They just have to arrange the bits on the wire exactly the same.

And then the dual of that is when what you specify is the API. And you say, this is
what it is, and how things get between here and there is, who knows? And that gives you a tremendous
flexibility to have different ways of moving things back and forth. So for instance with RMI, one of
the reasons that it's so popular is you can play all kind of games in that space in between. One
of the things you can do is, if the two sides happen to be on the same box or in the same address
space, all the stuff in the middle collapses out and it's just a direct call.
Whereas, in these other systems, often you'll find that you're encoding and
decoding even though you're not moving the bits anymore.

But you can also play
games with how you encode it. In RMI once upon a time you could put in all kinds of different
encoders. You could put in a binary wire encoder. It was actually possible
to write an XML encoder or an IIOP encoder. People don't do that much, but the ability to drop in
your own encoder is basically there.

You get independence of what the actual transport mechanism is.
And to a certain extent, you can blend these. Because if you are doing the interface version, you can
decide to target a particular binary encoding or not. So, you can get hybrid ways of building
things. Nobody actually does that, although the RMI over IIOP stuff is kind of in that space.

Bill Venners: Or for example, a Jini service proxy isn't necessarily doing remote procedure calls, so it
could actually implement the service locally. Or it could talk to something across the network using any
protocol. There are all these web service things that will probably be coming up in the next few years.
You could wrap one of those in an object that has an interface. And when a client talked to that object, it would be using that
XML-based protocol.

James Gosling: Right. So that gives you pretty tremendous flexibility.