Understanding JavaSpaces: Problems of distributed applications lost in Space?

Hi,
I am written my master thesis about distributed event systems and
stumbled over spaces (TupleSpaces, JavaSpaces, etc.). I've read
several papers and articles about this topic. Nevertheless I still
have problems with this approach. For me spaces seem to be just a
kind of communication ABSTRACTION that makes it easier to create
certain kinds of distributed applications for example using the
master/worker pattern. But if you see through the wonderful idea of
spaces and come to a concrete implementation you realize that
JavaSpaces are based on "normal" message passing. This wouldn't be a
problem, but many Spaces enthusiasts write that the use of JavaSpaces
alone makes a system more scalable or more robust.

My question is now:
Do I really get any technical advantages(performance, QoS
features, ..) just by using JavaSpaces(or any other kind of space)?
They seem to me rather like a nice high level view on a distributed
system that makes the development of distributed applications easier.
But you don't solve common problems of distributed applications like
the need for high availability or scalability just by using spaces.

For example: I have read several times that services that take data
from the space load-balance themselves, because the space is passive
and the services can take what they want at their own pace. This is
really a nice idea if you think of services acting like humans
picking apples out of a bag.

But how would you implement such a take operation if you would
implement a space? The taker would establish a connection to the
remote space and place some kind of token to tell the space that it
should reserve a matching Entry(described through a template) for him
as soon as it pops up somewhere. Whether it leaves the communication
channel open or not is rather an issue of the underlying implementation.
Several such tokens could match the same Entry, so the space needs to
pick any of those takers(maybe randomly or fifo) and exclusively
reserves a new Entry to be "taken" away by him.
If you look closely at this behavior, all you got here is some
subscribers that make subscriptions via a operation named take and of
which only one will be elected to exclusively consume the Entry. So
it seems to me that JavaSpaces are just a higher abstraction level to
some kind of message passing infrastructure.

Another thing that is always advertised as advantage of spaces is
their in-memory persistence. Entries in contrast to "normal" messages
are not only a part of a communication flow. They have their own life
in space, enabling truly time-decoupled communication.
But where is the difference between an in-memory space that contains
Entries and an JMS message queue, that persists messages until some
lease duration is over (e.g. durable message queues)?

Again the idea of the space where Entries have a life of their own is
very easy to understand and I'm sure that it is easier to implement
some kind of distributed applications (e.g. a Chat) with the spaces-
view of things instead of with the message passing view.
But the benefit of the JavaSpace technology is the abstraction. I
don't get a faster, or more scalable system just because I'm using
spaces.

All the features that are advertised by commercial space
implementations like distributed caching, replication, and
distributed transactions are only advertised. They never make the
connection between these features and the space abstraction. They
just say: "We achieve linear scalability because we use a space based
architecture".
If spaces a just a nice high level view on distributed systems, they
must rather say: "It is easier to implement problems of distributed
computing using a space based architecture. We still have the same
underlying problems like everyone else, but we don't care and just
think as if these problems are lost in space".
GigaSpaces for example talks a lot about distributed caching and data
replication. Caching and replication are two fundamental problem
fields in distributed computing. Every distributed infrastructure has
to cope with these problems (e.g. every major JMS implementation does
too). Where is the advantage if I use JavaSpaces as foundation to
cope with those problems?

Sorry for the long text. I would really appreciate if someone would
share his thoughts on this topic.

Regards, Christian

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html