|
|
Re: HTTP Needs Replacing
|
Posted: Mar 18, 2002 8:47 AM
|
|
> Their reaction was that Jini just moves the problem
> from "define the protocol" to "define the interface".
> However, as you also point out, I believe it's a
> matter of different levels of abstraction.
Yes, the difference involves abstraction. I've thought a lot about what that really means. At first I thought that we can be more abstract when talking about behavior than when talking about data. But that's not really true. I can be abstract when designing data too -- the more detail I leave out, the more abstract I'm being.
For example, I can define an XML DTD for a "dog" document in any number of ways. One real simple way is to just have one attribute that indicates the breed of dog. Or I could include the breed and color. Or I could include the breed, color, and weight, and age. Each of these dog DTDs is less abstract than the previous, because I'm giving progressively more information.
Imagine there's a dog service somewhere on the network. If the client/service contract for the dog service is a protocol, then that protocol probably includes a way to request a dog document and defines the data structure of that doc document. I can then write a client that requests a dog document, then using the information in the document, draws the retrieved dog on the screen for the user.
If, on the other hand, the client/service contract for the dog service is an API, then that API probably has an interface Dog and some set of methods, one of which could be void paint(Graphics g). I could then write a client that gets ahold of a Dog service proxy, and invoke its paint method passing in a graphics context. In this case I delegate the job of rendering the image of the dog onto the screen to the Dog object.
The difference in flexibility between these two approaches isn't that the behavior-oriented contract of paint is inherently more abstract than any data-oriented dog contract. A dog DTD that specifies only the breed is pretty darn abstract. The difference in flexibility comes about because to do something different in the dog drawing code, you often need different dog data.
So for example, assume version 1.0 of these two flavors (protocol and API) of dog service just send the breed of the dog. So any cocker spaniel ends up looking like every other cocker spaniel when rendered on the screen. In version 1.1beta2-3x12 of the dog services, however, the desire is to also render the dog in an appropriate color. Well, to change the code, you need more information. You need to know the dog color.
In the protocol version, you must add color to the DTD. This DTD change will either break existing clients, or if the clients were written to ignore fields that aren't understood, it will not break the client, but then the color field isn't used when those old clients render on the screen.
In the API version, the author of the service proxy can add color as a private field in the Dog service proxy, and can change the code of paint so that it uses that information. This breaks no client, and every client that was invoking paint sees all dogs rendered with appropriate colors.
Now all this is nothing more than an illustration of the kind of flexibility benefit you get with object-oriented programming. An important idea in OO is delegation -- in design you try to delegate responsibility for behavior to objects that have the data required by that behavior. So in the case of dogs, you delegate to Dog objects the responsibility for painting the dog on a graphics context, because that painting requires dog data.
What Jini does is allow programmers of distributed systems to get at that general benefit of OO in their distributed systems. One of my Jiniology articles did a more elaborate comparison and contrast between protocols and APIs:
http://www.artima.com/jini/jiniology/objdoc1.html
I talk a bit more about abstraction and flexibility in this follow up article:
http://www.artima.com/jini/jiniology/objdoc2P.html
|
|
Previous Topic
