Article:		Space-Based Programming
Subject:		There's an inherent problem with JavaSpaces
Date:		2003-03-20 06:57:25
From:		anonymous2
We looked into JavaSpaces as a way to distribute requests to servers, as with the Master-Worker architecture mentioned in the article. The Master would be a web server that would attach an ID to a request, put it in the space and wait for a result object with that ID. Workers would grab the next available request, crunch it, and put the result back in the space. The problem with this is that there is no guarantee in the JavaSpaces specification that a particular request will eventually be picked up. There is the possibility of a request sitting in the space forever or expiring, so requests on the web server are never serviced even though they could be. There are ways to implement FIFO queues in JavaSpaces, but at that point you're better off going with a JMS-based architecture. You get just about all the benefits mentioned in the article for the JavaSpaces based approach, but setup of most JMS queuing systems are MUCH simpler than setting up a JavaSpace. With the JMS based approach you're passing data-only objects around, not objects that can be executed remotely. Not many people want to do that, though, and you still have the issue of insuring that every object in the space gets picked up eventually. The "global data" (blackboard) approach can probably be done with a database you have running already on a big project, and keeping the data there can let processes written in other languages also participate. As someone who's tried this on a real project I can see why JavaSpaces hasn't taken off.

Showing messages 1 through 3 of 3.

• There's an inherent problem with JavaSpaces
  2003-04-02 12:27:53  anonymous2 [Reply | View]
  
  
  Part 6 in the JavaWorld article talks about a solution using a "channel" pattern,
  
  http://www.javaworld.com/javaworld/jw-10-2000/jw-1002-jiniology_p.html
  

• There's an inherent problem with JavaSpaces
  2003-03-20 18:05:49  tcopeland [Reply | View]
  
  
  Hm.... you're certainly more familiar with your project than I am... and that's true, putting an entry in a space doesn't mean it'll get picked up. But it's the same with a JMS message - if you're doing publish/subscribe and there's no one subscribed, you can publish all you want and no one will get it. A JavaSpace client can call notify() to get a callback when something gets put in the space - why wouldn't that work with your app?
  
  I've used JavaSpaces on a small utility that searches for copied/pasted code and was suprised at how easy it was to program JavaSpaces. There's an initial hump to get over what with the rmid and all that stuff, but once I got that stuff worked out and wrote some scripts to automate deployment of new clients and such, all was well.
  
  Yours,
  
  Tom
• "Point to point", not publish/subscribe
  2003-04-09 06:39:10  anonymous2 [Reply | View]
  
  
  What I'm doing is based on queues, not publish/subscribe. The quotes around point to point comes in where I can have multiple clients putting messages in a queue, and multiple servers getting messages off the queue to service.
  
  The clients will attach unique ID's to their request and put it in the request queue. Multiple servers listen on the request queue for the next available message; this does automatic load balancing, the faster servers process more requests. The servers put the respones in the response queue, using the unique ID that was with the message. Clients listen on the response queue for their message keyed off of the unique ID.
  
  This gives us the Master/worker behavior we wanted, without the JavaSpaces setup hassle. And it is a hassle, escpecially on standalone laptops that aren't connected to the Internet sometimes.