The Artima Developer Community
Sponsored Link

James Gosling on Java, May 2001
A Conversation with Java's Creator, James Gosling
by Bill Venners
First Published in JavaWorld, June 2001

<<  Page 17 of 22  >>

Advertisement

APIs versus Protocols

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.

<<  Page 17 of 22  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us