The Artima Developer Community
Sponsored Link

JavaSpaces: Data, Decoupling, and Iteration
A Conversation with Ken Arnold, Part V
by Bill Venners
October 7, 2002

<<  Page 4 of 5  >>

Advertisement

Decoupling Request from Response

Bill Venners: Here's a quote from JavaSpaces: Principles, Patterns, and Practice: "Message passage remote method invocations barricade data structures behind one manager process. Processes must wait in line, but the space enables concurrent access." Why isn't a JavaSpace yet another manager process managing the data?

Ken Arnold: You can describe things in a million ways with all sorts of metaphors, and each way is partially true. So if you want to think of JavaSpaces as a manager, you can. The distinction has to do with decoupling sending the request from receiving the response. If I make an asynchronous call to you and ask you to do something, the job's processing is barricaded behind you. It doesn't mean other people can't send you requests simultaneously, or that I can't send you another request simultaneously in a separate thread. But this particular interaction is blocked on that one call. Whereas with a JavaSpace, if I had 70 things to do, I can write 70 requests into the space and just wait for the results, because the making of the request and the receiving of the result are completely separate operations. In a normal RPC-style system, they are consequent operations. They are serialized one after the other.

By "barricaded," the authors Eric Freeman and Susanne Hupfer basically mean that I make the call to you. If the processing is going to be broken down into partial pieces, you have to break it down. It is all behind you as far as I am concerned. My interface to solving the problem is invoking a method on you. And if the right way to do that is to do a little bit here, a little bit there, and a little bit over there, then you have to handle that. If instead I write an entry into a space and the processing can be broken down, an actor can take out the request and write a partial result back.

Today you could decide that those partial processing tasks have to happen in order— that A happens before B, which happens before C. Tomorrow you may figure out a way to do the tasks in parallel. So if something is already working on one request's part A, and a new request comes in, something else can start on the B part without waiting for the A task to complete. And then tomorrow a new theory can arrive. It is not mediated by my interaction with someone processing my request. Instead, I am tossing the grain into the space and watching it grow. It grows in the sense that the response comes back. All that other stuff is not mediated by anything with which I directly interact. It is mediated by the request-satisfying process, which ever way the entities processing the request are configured to solve the problem.

<<  Page 4 of 5  >>


Sponsored Links



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