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.