Re: Understanding JavaSpaces: Problems of distributed applications lost in Space?

Hi,

I haven't got enough time to address all of this (off to the Jini
Community Meeting) and, given that it's for your thesis, I probably
ought not anyways.

Couple of keys points:

(1) JavaSpaces encourage/support multi-party and bi-directional
conversation between parties.

(2) You've only talked about data - one of the things spaces can be used
for is the passing around of _code_ and/or _data.

(3) How do you find a queue?  Typically through some static lookup via
some fixed name.  Jini provides much more flexibility in how you find a
JavaSpace.

(4) High availability doesn't have to be implemented in the space
itself.  High availability is actually about systems design.  i.e.  It's
in the way you use spaces not in the characteristics of the space
itself.  Again, Jini lookup helps and if you want more examples of this
kind of design, check out google's bigtable or GFS papers.

Hope that helps,

Dan.

Christian Platta wrote:
> 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
>

===========================================================================
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