Re: Reshaping the JavaSpaces architecture. Just some thoughts ...

Oliver Plohmann wrote:
> Hi there!
> 
> I had a look at tuple spaces and JavaSpaces a while ago and really liked 
> the approach. I think a central data store is a good idea for 
> distributed processing of data (calculations, data analysis, etc.). 
> However, there is a problem if it's not only about distributed 
> processing. Let's say you need to be notified if some traffic light 
> changes from red to green. You don't want to poll the traffic light all 
> the time, right?

A blocking Javaspaces "take" is a pretty limited consumer of resources in a 
distributed system.

> So what I'm thinking of is to add distributed message passing to 
> JavaSpaces for distributed event notification. In that context it would 
> make sense to reshape the JavaSpaces architecture to be fit for todays 
> needs in enterprise computing: replace the Jini stuff with JNDI or an 
> ESB, use a cache provider such as JBoss Cache, or some other cache 
> system, or use the respective parts of the Blitz project if permitted, 
> add JMS for distributed event notification and communication with the 
> central tuple space, use Spring for XML configuration and/or IoC if 
> needed, extend the JavaSpaces API to address the new architecture, make 
> sure the API remains simple and consistent, and, and, and, ...
> 
> I guess the Jini folks will now get mad at me. What I'm mentioning here 
> are just some ideas. I just want to see what other people think about 
> this and share some opinions. Maybe some guys could be found to start an 
> open source project. Would be fun ... ;-)

This is all possible without changing Javaspaces.  What you are suggesting is 
the age old "lets make our service do this too" line of thinking.  Instead, the 
Jini service architecture (and SOA from most perspectives) is "let's add a 
service to provide this feature".

You can park a Jini service on your network that uses subscriptions on JMS (or 
MQTT might be better for high volume, non-Java clients), to perform READ/TAKE on 
the Javaspace, and then forward the appropriate messages to the subscribers.

The "JBoss Cache" business, I'm not sure what you are asking for.  Do you think 
that there are bandwidth or storage capacity issues with JS that JBoss Cache 
would solve?

I've not talked about it much lately, but my http://griddle.dev.java.net project 
is a recast of the Javaspaces APIs with separation of keys from data, and the 
addition of an iterator (which Javaspaces5 has) and an executor mechanism.  I 
also removed the use of "marshalled only" tuples, allowing that to be done 
explicitly if needed, but letting the application decide.  Typically, you'd use 
native types for keys, unmarshalled, and use marshalled data for the bits you 
are storing.

The code out there does work, but it's still a preliminary design of the 
concepts with no attention to performance details.

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