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

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

Hi Christian, many of the big posters here are on their way to Brussels, to the
10th Jini Community meeting.  What Dan Creswell stated, is in line with any
comments I would make.  One of the primary issues is code mobility.  There is
versioning accounted for in code mobility, which many don't really appreciate.

With just data operations, the data has to always be exactly what the users of
the data need.  If you need to change the data, you have to change the impacted
users first, and you have to do that in a way which won't impact operations in a
negative way.

With mobile code involved, in the data, it is possible for new data values and
types to be visible in a legacy interface implementation for old clients, while
still allowing new clients to take advantage of new or different data with a new
API.

A simple example might help.  If I had some limited data uses of a particular
value, and I had a interface which had definition as

public interface MyData extends Remote {
     public String getType() throws RemoteException;
     ...
}

Later it was decided that more control over the possible values that getType()
returns was needed.  The returned value of getType() now needs to be MyDataType.
  If I change the interface to use MyType instead of String, then all existing
users are broken.  If instead, I define a new interface, MyDataVersion2 as in

public interface MyDataVersion2 extends MyData {
     public MyDataType getDataType();
}

then I now have a new implementation that has a specific type.  New users can
use the new version (deprecate getType() with a reference to getDataType()).

The interface MyData has not changed, and in the value returned as the
MyDataVersion2, I can use either a smart proxy, or a server side implementation
to make the String compatible with existing users.

In a simple DATA only queuing system, I can still pass MarshalledObjects as we
are in Javaspaces.  However, that is not usually what happens, and that is one
of the larger, definining attributes of the Jini "way".  If you "get" mobile
code, you should understand more of the power of what is available when you use it.

 From a simple perspective, Javaspaces, as a communications mechanism, is
similar to the overall capabilities of any messaging system that has
persistence.  But, there are some subtle issues around the whole multi-user read
implementation that messaging systems don't provide.  That allows the Javaspace
to be a distributed memory system, more than a messaging system.

Gregg Wonderly

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