Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Rete Networks and Tuple Spaces

5 replies on 1 page. Most recent reply: Sep 30, 2004 7:33 AM by Dale Asberry

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 5 replies on 1 page

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Rete Networks and Tuple Spaces (View in Weblogs)

Posted: Sep 28, 2004 7:46 AM

Reply

Summary
I've been doing a lot of work around rule engines lately and am starting to feel that there are a number of similarities/parallels between a Rete knowledge base and a Javaspace.

Advertisement

Observations

These are the similarities I see:

both are heavily information dependent (tuple entries, rule base facts)
both are heavily rule dependent (tuple templates, rules)
both are operationally similar with only two essential operations: rulebase - assert/retract, tuplespace - write/take
both have a conceptual LHS (left-hand-side, conditionals) and RHS (actions)
generally speaking, the facts change faster than the rules

Would a Rete network model be more appropriate than a relational model for a Javaspace?

(Half-Baked?) Conclusion

Currently, the JavaSpaces spec only provides for a single template type to match. Providing an API to match multiple types (and object values) would allow for a distributed rules engine. Taking this idea one step further: distributed workflow engine.

Resources

Overviews of the Rete Algorithm:

Wikipedia - Rete Algorithm

JESS - The Rete Algorithm

Dan Creswell

Posts: 49
Nickname: dancres
Registered: Apr, 2003

Re: Rete Networks and Tuple Spaces

Posted: Sep 28, 2004 8:22 AM

Reply

> <p>Would a Rete network model be more appropriate than a
> relational model for a Javaspace?</p>

Don't think so. Conceptually, I think it's a nice model for implementing matching of newly written Entry's against blocked match calls but, one still requires some form of DBMS to persist Entry's in along with a whole pile of other state such as registered notifies, event id's etc.

So I think you might be able to mix the two together in an implementation to give you something different but I dunno that it'll be better in any quantifiable way.

> <p>Currently, the JavaSpaces spec only provides for a
> single template type to match. Providing an API to match
> multiple types (and object values) would allow for a
> distributed rules engine. Taking this idea one step
> further: distributed workflow engine.</p>

Well, of course, we have the upcoming spec's for bulk operations and iterator which provide for matching against multiple templates which might go some way toward where you're heading.

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: Rete Networks and Tuple Spaces

Posted: Sep 28, 2004 1:11 PM

Reply

> > <p>Would a Rete network model be more appropriate than
> a
> > relational model for a Javaspace?</p>
>
> Don't think so. Conceptually, I think it's a nice model
> for implementing matching of newly written Entry's against
> blocked match calls but, one still requires some form of
> DBMS to persist Entry's in along with a whole pile of
> other state such as registered notifies, event id's etc.

Persistence is actually less important than the in-memory representation and execution. However, the same parallels that I see in JS and Rete are quite similar to the index pages of a DBMS and a Rete network. Rete networks are very efficient at "sorting" large amounts of data. However, I don't have any concrete ideas about how this all might pan out... yet :-)

> So I think you might be able to mix the two together in an
> implementation to give you something different but I dunno
> that it'll be better in any quantifiable way.

One of the frustrations that I've had with distributed data structures in a JavaSpace is "tying" the various related entries together coherently. Putting these ideas together would make using them a little less surprising and require less client side code.

In a single entry/template JavaSpace, probably not. But in one that is capable of matching arbitrary multiple entries or templates, a Rete-based network could significantly outperform other algorithms (memory and CPU time).

> > <p>Currently, the JavaSpaces spec only provides for a
> > single template type to match. Providing an API to
> > match multiple types (and object values) would allow for
> > a distributed rules engine. Taking this idea one step
> > further: distributed workflow engine.</p>
>
> Well, of course, we have the upcoming spec's for bulk
> operations and iterator which provide for matching against
> multiple templates which might go some way toward where
> you're heading.

Quite possibly.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Rete Networks and Tuple Spaces

Posted: Sep 29, 2004 1:03 AM

Reply

I implemented a prototype expert system with JavaSpaces some years ago in the field of insurance claims management. I really thought at that time that JavaSpaces would be an excellent platform for such a system, since it would be able to manage large rule sets and facts in a distributed manner.

The metaphore for the initial JavaSpaces-based system was that of streams - each stream representing facts matching a set of rules, and each fact arranged in a stream according to how closely it matched those rules (or how "relevant" that fact was to a set of rules.) I thought that that was how users thought about a system, and simple user experiments showed that intuition to be true. The problem was that of implementation - JavaSpaces did not provide an easy way to deal with complex cases, and most of our cases proved to be complex ones.

JavaSpaces worked well with simple rules and facts. The problem was with distributed data structures. As facts and rules became more complex, the data structures based on those entries became a *lot* more complex. In fact, managing those data structures became an overwhelming proposition. For each business-related entry, I soon had to add and modify dozens of metadata-related entries for the data structures that business entity was a members of. Managing metadata soon started to dominate the project, and I decided to use a more traditional approach. We then switched to using Jess (a Java rules engine), and relegated JavaSpaces the role of a backing store for Jess facts and rules.

I'd love to hear of others' experiences in using JavaSpaces in the rules engine/expert system space.

Dan Creswell

Posts: 49
Nickname: dancres
Registered: Apr, 2003

Re: Rete Networks and Tuple Spaces

Posted: Sep 30, 2004 4:00 AM

Reply

> Persistence is actually less important than the in-memory
> representation and execution. However, the same parallels
> that I see in JS and Rete are quite similar to the index
> pages of a DBMS and a Rete network. Rete networks are
> very efficient at "sorting" large amounts of data.
> However, I don't have any concrete ideas about how this
> s all might pan out... yet :-)

See, I didn't get this comment about persistence to start with. Now I think I do and I'm wondering if you're talking about doing a Rete network kind of thing on top of JavaSpaces and suggesting this might be a good pattern to adopt?

If that's the case, I think the answer is yes because a Rete network could easily be modelled as a flow of objects which Arnold, Hupfer and Freeman said was the best kind of a thing to put on JavaSpaces.

Dale Asberry

Posts: 161
Nickname: bozomind
Registered: Mar, 2004

Re: Rete Networks and Tuple Spaces

Posted: Sep 30, 2004 7:33 AM

Reply

> See, I didn't get this comment about persistence to start
> with. Now I think I do and I'm wondering if you're
> talking about doing a Rete network kind of thing on top of
> JavaSpaces and suggesting this might be a good pattern to
> adopt?
>
> If that's the case, I think the answer is yes because a
> Rete network could easily be modelled as a flow of objects
> which Arnold, Hupfer and Freeman said was the best kind of
> a thing to put on JavaSpaces.

More specifically, JavaSpaces are difficult to use as a distributed data type store. By providing an API to match multiple templates/template types and returning multiple entries that match, distributed data types become much easier to use. However, this got me to thinking... this is exactly the sort of thing that the Rete algorithm does. In other words, a JavaSpace matching algorithm (that handles the more difficult situation of matching multiple templates/types) would be best implemented using Rete. It would fit above the persistence and below the API. Take a look at the Jess documentation describing the Rete algorithm to get an idea of why I'm inclined to think like this.

Using a JavaSpace as a knowledge base, the developer would have access to an "always-on", distributed rule engine. Taking this a step further, creating a distributed workflow engine around this would be fairly straightforward and easier to implement than Frank's approach.

Flat View: This topic has 5 replies on 1 page

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use