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

Geoffrey Arnold <[email protected]> Thu, 1 May 2008 15:21:00 -0400
Newsgroups gmane.comp.java.sun.javaspaces
Message-ID <[email protected]>
Objects in a space do not change state.  In order to update the
traffic light from red to green, a third-party must remove (read(),
take()) the object from the space, set it's color, and place (write())
it back into the space (preferably under a transaction).  The act of
writing the updated object to the space would trigger the
notification.

Of course, you needn't use spaces at all in your example.  You could
create a Jini-based traffic light service which sends out remote event
notifications to interested parties whenever its color changes.  Take
a look at the Jini distributed event and leasing specifications:

    http://java.sun.com/products/jini/2.0/doc/specs/html/event-spec.html
    http://java.sun.com/products/jini/2.0/doc/specs/html/lease-spec.html

And just to cover all of our bases, you might want to add this to your
reading, paying special attention to Section 4.2:

    http://research.sun.com/techrep/1994/smli_tr-94-29.pdf

Geoff.

On Thu, May 1, 2008 at 2:51 PM, Oliver Plohmann <[email protected]> wrote:
>
>  With regard to distributed event notification ...  I was assuming that
> event notification is only triggered when an entry is written to the space,
> because it says on p.140 of Flenner's book ("Jini and JavaSpaces ..."):
> "JavaSpaces acts as the source of events when an entry is ->written<- to the
> space ...". So I concluded that for being notified about the traffic light
> changing from red to green a traffic light object with color "green" needs
> to be written to the space, that is simply changing the the value of color
> attribute wouldn't do. I admit that I had better played a bit with
> JavaSpaces to figure out whether that is the case or not. As a matter of
> fact, I still don't know whether simply changing the color value would
> trigger the event or not ...
>
>  Regards, Oliver
>
>
>
>  Geoffrey Arnold wrote:
>
> > Wouldn't this work:
> >
> >
> >    public class TrafficLight implements Serializable {
> >        public String color;
> >    }
> >
> >    public class GreenMeansGo implements RemoteEventListener {
> >        public void notify(RemoteEvent event) {
> >            // GO!
> >        }
> >    }
> >
> >    TrafficLight template = new TrafficLight();
> >    template.color = "GREEN";
> >
> >    GreenMeansGo listener = new GreenMeansGo();
> >
> >    BasicJeriExporter listenerExporter = new BasicJeriExporter(
> >        TcpServerEndpoint.getInstance(0),
> >        new BasicILFactory()
> >    );
> >    GreenMeansGo listenerProxy = (GreenMeansGo)
> > listenerExporter.export(listener);
> >
> >    javaSpace.notify(template, null, listenerProxy, Lease.FOREVER, null);
> >
> >
> > Geoff.
> >
> > On Wed, Apr 30, 2008 at 4:55 AM, Oliver Plohmann <[email protected]>
> 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?
> > >
> > > 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 ... ;-)
> > >
> > > Regards, Oliver Plohmann
> > >
> > >
> > > www.objectscape.org
> > >
> ===========================================================================
> > > 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
> >
> >
> >
>
>  --
>
>  www.objectscape.org
>
>

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