Hi Wolfgang,

Privately, I've pointed this out to Will as well, but apparently that
still doesn't solve his issue.  Does anyone out there have any
experience in integrating a JavaSpaces implementation such as
GigaSpaces with Jess proper?  The basic question, apart from Will's
current implementation, is: What is the best practice for reasoning
with objects in a JavaSpace using available Jess mechanisms?

My understanding so far is:

* GigaSpaces tosses property change events itself when space objects change.
* GigaSpaces exposes no API to allow you to toss property change
events from space objects or to wrap space objects with a
PropertyChangeListener decoration, therefore you cannot simply
definstance an object directly from space.
* GigaSpaces writes a copy of an original object into space.  No
reference to that original object is preserved in the space.

Also, Will's team is not currently using GigaSpaces in a distributed
sense -- space is in-process in the same JVM as Jess.  Obviously, they
would like to retain GigaSpaces as a distribution layer in their
architecture for scalability.

Cheers,
Jason
-- 
-----------------------------------------------------------
Jason Morris
Morris Technical Solutions LLC
http://www.morris-technical-solutions.com

On Dec 11, 2007 5:48 AM, Wolfgang Laun <[EMAIL PROTECTED]> wrote:
> I have understood Will's problem to be within a single Rete object.
> Basically, the Rete.add() method returns a reference to the created
> jess.Fact. As a shadow fact in good standing it'll have a slot OBJECT
> containing a reference to the original Java object. "Therefore, the
> original object is always easily available." (The Jess Manual, 5.3.2)
>
>
> Hal Hildebrand wrote:
>
> > Wouldn't the fact id be (potentially) different in different
> > instances  of the rules engine?  I believe these are assigned in
> > declaration  order, so unless every instance is defining instances in
> > precisely the  same order, then you'd end up with the same logical
> > fact having  different ids in different VMs.
> >
> > FWIW, there's a good paper by someone who did something remarkably
> > similar: www.waset.org/pwaset/v4/v4-18.pdf
> >
> > Myself, I've taken another route, which is using shadow facts for
> > everything I want distributed.  The facts all have generated UUIDs,
> > so  there's no issues with locally generated ids in a distributed
> > system.   Then it's  a fairly simple matter to translate to the local
> > facts when  the shadow changes and vice versa.
> >
> > On Dec 10, 2007, at 1:07 PM, Will Edwards wrote:
> >
> >> We're attempting to integrate a JavaSpaces implementation with Jess.
> >>
> >> When an object changes in the JavaSpace we receive a notification
> >> that the
> >> object has changed and a copy of the changed object which we want to
> >> add or
> >> modify as a Jess shadow fact in the rules engine.
> >>
> >> Our problem is that in this environment we do not get a reference to
> >> the
> >> original object but a new (by value) copy of the object.  So, we
> >> want to
> >> modify the existing Jess fact with the new copy. Assuming we have the
> >> FactIDValue (from the original rete.add) is there a reasonably
> >> simple way to
> >> do this?
> >>
> >> Currently we are using a FactFilter to get the existing object, call
> >> rete.remove() to remove the old copy and then rete.add() with the
> >> new copy.
> >> This is of course prone to potential race conditions, etc.
> >>
> >> What we would like to do is use modify() or updateObject() but both
> >> of these
> >> seem to require that the original object reference be maintained.
> >>
> >> Thanks in advance.
> >>
> >> --------------------------------------------------------------------
> >> To unsubscribe, send the words 'unsubscribe jess-users  [EMAIL PROTECTED]'
> >> in the BODY of a message to [EMAIL PROTECTED], NOT to the list
> >> (use your own address!) List problems? Notify
> >> [EMAIL PROTECTED] .
> >> --------------------------------------------------------------------
> >>
> >
> > --------------------------------------------------------------------
> > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> > in the BODY of a message to [EMAIL PROTECTED], NOT to the list
> > (use your own address!) List problems? Notify
> > [EMAIL PROTECTED]
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the list
> (use your own address!) List problems? Notify [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
>

--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to