6:12 a.m.
All,
I reached a point where I need to make a design decision and would like
your opinion about it.
Imagine the following scenario:
A user has a domain model like this:
package a.b.c;
public interface Event { ... }
package x.y.z;
public class MyEvent implements a.b.c.Event {...}
Then, in his DRL file he writes:
package p.q.r;
import event a.b.c.*;
rule X
when
Event( ... )
then
...
end
So, it is clear that a.b.c.Event should be handled as an event by the
engine.
At runtime, the user asserts an object of the class x.y.z.MyEvent into
the working memory. Seems clear to me (and probably to the user) that
MyEvent should be handled as an event, since by DRL semantics, a.b.c.* are
all events, and by OO class hierarchy concept, since a.b.c.Event is an
event, x.y.z.MyEvent is an event too.
My question is: how the engine knows that MyEvent is an event, since it
only has the x.y.z.MyEvent class as input?
The only answer I have is that when the first MyEvent instance is
asserted into the working memory, we must get the class name and iterate
over all event import declarations checking for a match. In case no one is
found, we need to repeat the process for each interface and each class up in
the MyEvent hierarchy. Once this process is complete, we cache the results
in the ObjectTypeConf.
This may be a quite heavy process to be executed each time a fact of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
The alternatives would be intrusive, IMO, breaking the drools premise to
work with user-defined POJOs as facts: use anotations to annotate classes
that are events, or mandate users implement a specific interface for events.
Any better idea?
[]s
Edson
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
10:08 p.m.
Edson Tirelli <tirelli <at> post.com> writes:
All, I reached a point where I need to make a design decision and would
like
your opinion about it. Imagine the following scenario: A user has a
domain model like this:package a.b.c
;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
event
a.b.c.*; rule Xwhen
Event( ... )then ...end So, it is clear that a.b.c.Event
should be
handled as an event by the engine. At runtime, the user asserts an
object of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and probably
to the user) that MyEvent should be handled as an event, since by DRL semantics,
a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how the
engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
class as input? The only answer I have is that when the first
MyEvent
instance is asserted into the working memory, we must get the class name
and
iterate over all event import declarations checking for a match. In case no one
is found, we need to repeat the process for each interface and each class up in
the MyEvent hierarchy. Once this process is complete, we cache the results in
the ObjectTypeConf.
This may be a quite heavy process to be executed each time a fact
of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
The alternatives would be intrusive, IMO, breaking the drools
premise to
work with user-defined POJOs as facts: use anotations to annotate classes
that
are events, or mandate users implement a specific interface for events.
Any better idea? []s Edson -- Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson,
I got your striving not to mandate users implement a specific interface for
events. However, why not at least introducing an empty event interface (i.e. a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event interface
(by means of 'instanceof'). Moreover, while parsing the import statements of a
rule file, it enables you to double-check whether all the "event imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any restrictions
on the structure for a user defined event class, how do you make sure it has all
the required attributes of an event (which in my opinion must be a timestamp,
at least) and how do you access them (necessary for temporal relationships)?
Having said this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a method returning
the event's occurrence date (i.e. the timestamp) at least... Or how would you
handle this issue?
Matthias
11:27 p.m.
Here's my 2 cents - as a non-contributor to Drools codebase ;-)
You could add insertEventFactTypeThingie to the API? Then you need just
check that the class has been declared as an event in the DRL similar to
what must already happen for normal DRL imports. I personally don't have
issue with implementing a marker interface (this is what frameworks like
Hibernate, EJB3 and Spring etc have been imposing for years). What "wiring"
does the POJO need to become an Event for use in Drools? Are you trying to
internalise too much at the risk of making the event mechanism inflexible?
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] Determining if a class is an event or not
Edson Tirelli <tirelli <at> post.com> writes:
All, I reached a point where I need to make a design decision and
would
like your opinion about it. Imagine the following scenario: A user has a
domain model like this:package a.b.c
;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
event
a.b.c.*; rule Xwhen
Event( ... )then ...end So, it is clear that a.b.c.Event
should
be
handled as an event by the engine. At runtime, the user asserts an object
of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and
probably
to the user) that MyEvent should be handled as an event, since by DRL
semantics,
a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how the engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
class as input? The only answer I have is that when the first
MyEvent
instance is asserted into the working memory, we must get the class name
and
iterate over all event import declarations checking for a match. In case no
one
is found, we need to repeat the process for each interface and each class up
in
the MyEvent hierarchy. Once this process is complete, we cache the results
in
the ObjectTypeConf.
This may be a quite heavy process to be executed each time a fact
of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
The alternatives would be intrusive, IMO, breaking the drools
premise
to
work with user-defined POJOs as facts: use anotations to annotate classes
that
are events, or mandate users implement a specific interface for events.
Any better idea? []s Edson -- Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson,
I got your striving not to mandate users implement a specific interface for
events. However, why not at least introducing an empty event interface (i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event
interface
(by means of 'instanceof'). Moreover, while parsing the import statements of
a
rule file, it enables you to double-check whether all the "event imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
restrictions
on the structure for a user defined event class, how do you make sure it has
all
the required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for temporal relationships)?
Having said this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a method
returning
the event's occurrence date (i.e. the timestamp) at least... Or how would
you
handle this issue?
Matthias
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
11:44 p.m.
Matthias,
Thanks for the feedback. Since you are starting to dig into drools inner
workings, I think it is good to dig a bit more on this subject and detail my
comments, so that we can have your opinion on the broader subject of the
platform design.
However, why not at least introducing an empty event interface (i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement?
We always tried to avoid mandating the user to change its domain model to
use Drools and "contaminating" it with Drools specific classes/interfaces.
This way, different from other engines, we work with simple POJOs as facts.
There are also other reasons for that, like we want to implement support for
other fact types, like ontologies, etc, but the main one I still thing is
the one above.
So, we can have an Event interface or an annotation that the user may
use to explicit mark a Java class as an event, but IMO, we should use the
Event interface as an alternative way of doing it, and not as the only way.
A simpler solution we could go for is to mandate that the user declares
all its event classes/interfaces with a declare like statement in the DRL
instead of using the "import event" syntax. Something like that:
declare event a.b.c.Foo;
So the engine can load the class/interface a.b.c.Foo and check each
asserted fact to see if it is an a.b.c.Foo instance. That would be easier
from an engine perspective, but would be verbose from a users perspective,
since we would not be able to allow wildcards in such declaration. Would
that be better?
The other question you asked is really interesting and I also don't have
a definitive answer, but have some ideas:
In this regard, for me another question raises: Without making any
restrictions on the structure for a user defined event class, how do you
make sure it has all the required attributes of an event (which in my
opinion must be a timestamp, at least) and how do you access them (necessary
for temporal relationships)?
In the paper "Discarding unused temporal information in a Production
System", by Dan Teodosiu and Günter Pollak, they state that "Events carry an
additional *implicit* attribute that represents the timestamp. The value of
this attribute is automatically set upon creation of an event to the current
value of the system-clock."
I agree with them, except for the "system-clock" part. Replace
"system-clock" by "engine-clock" and I think we get the best
compromise.
We know that most real-world events are generated with an explicit
timestamp attribute, but since we may be handling events coming from
different sources without any guarantee that the sources have synchronized
clocks, we can not rely on the eventual explicit timestamp attribute for
reasoning in the engine. Not relying on that also give us the ability to
handle events that do not contain the explicit timestamp attribute.
What I am thinking is:
1. In current Drools implementation, each fact asserted into the rules
engine is wrapped in a FactHandle implementation. This FactHandle
implementation contains metadata attributes that are used by the engine
during fact manipulation and reasoning. What I'm suggesting is we derive a
new EventFactHandle implementation that would contain all event's implicit
attributes and metada we need, including the timestamp. This would allow us
to also support different semantic-models for the timestamp, and that is why
I asked you about the point-interval semantics. The easiest one would be the
point-in-time semantic, obviously.
2. We also will need to create the engine clock abstraction, and, as we
discussed previously, we will probably need 4 implementations:
- "System Clock": a clock that periodically synchronizes with the machine
clock
- "Event based clock": a clock that is updated every time a given event
arrives
- "Pseudo Clock": a generic implementation that is arbitrarily updated by
application code
- "Event Attribute Clock": a clock that is updated by a configured event
attribute
3. Every time a new event is inserted into the engine, we would then
populate the "implicit" attributes by using a configurable strategy. For
instance, if a user wants to use the explicit value of the object timestamp
as the event timestamp, the configurable strategy would simply copy the
value of the attribute to the implicit event attribute. If the user wants to
use the engine clock timestamp at assertion time as the event timestamp, the
configurable strategy would simply request the current value to the engine
clock and populate the event timestamp with this attribute.
What do you think about the above?
Thanks,
Edson
2007/11/8, Matthias <matthias.groch(a)sap.com>:
>
> Edson Tirelli <tirelli <at> post.com> writes:
>
> >
> >
> > All, I reached a point where I need to make a design decision and
> would
> like your opinion about it. Imagine the following scenario: A user has
> a
> domain model like this:package a.b.c
> > ;public interface Event { ... }package x.y.z;public class MyEvent
> implements
> a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
> event
> a.b.c.*; rule Xwhen
> > Event( ... )then ...end So, it is clear that a.b.c.Event should
> be
> handled as an event by the engine. At runtime, the user asserts an
> object of
> the class x.y.z.MyEvent into the working memory. Seems clear to me (and
> probably
> to the user) that MyEvent should be handled as an event, since by DRL
> semantics,
> > a.b.c.* are all events, and by OO class hierarchy concept, since
> a.b.c.Event
> is an event, x.y.z.MyEvent is an event too. My question is: how the
> engine
> knows that MyEvent is an event, since it only has the x.y.z.MyEvent
> > class as input? The only answer I have is that when the first MyEvent
> instance is asserted into the working memory, we must get the class name
> and
> iterate over all event import declarations checking for a match. In case
> no one
> is found, we need to repeat the process for each interface and each class
> up in
> the MyEvent hierarchy. Once this process is complete, we cache the results
> in
> the ObjectTypeConf.
> > This may be a quite heavy process to be executed each time a fact of
> a
> different class is asserted in the working memory for the first time, but
> I
> can't think a different user-friendly way to solve the question.
> > The alternatives would be intrusive, IMO, breaking the drools premise
> to
> work with user-defined POJOs as facts: use anotations to annotate classes
> that
> are events, or mandate users implement a specific interface for events.
> > Any better idea? []s Edson -- Edson Tirelli Software
> Engineer
> - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
> 9287-5646
> > JBoss, a division of Red Hat <at> www.jboss.com
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev <at> lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
>
>
> Edson,
>
> I got your striving not to mandate users implement a specific interface
> for
> events. However, why not at least introducing an empty event interface (
> i.e. a
> marker interface, similar to the Serializable interface in Java) the
> user-defined event class(es) have to implement? This way, when inserting a
> MyEvent instance, you can simply check whether it implements the event
> interface
> (by means of 'instanceof'). Moreover, while parsing the import statements
> of a
> rule file, it enables you to double-check whether all the "event imports"
> really
> refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
> restrictions
> on the structure for a user defined event class, how do you make sure it
> has all
> the required attributes of an event (which in my opinion must be a
> timestamp,
> at least) and how do you access them (necessary for temporal
> relationships)?
> Having said this, in my opinion defining an empty event interface may not
> be
> sufficient; in addition, it must force the user to implement a method
> returning
> the event's occurrence date (i.e. the timestamp) at least... Or how would
> you
> handle this issue?
>
> Matthias
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
11:54 p.m.
Michael,
Yes, the session.insertEvent() API is something other engines (like iLog
JRules) have. I initially discarded that idea, but since you mentioned, we
may need to reconsider it.
Anyway, the API would solve this part of the problem, but the whole
scenario is:
The engine must know at the compile time exactly what classes/interfaces
used in rules are events, so that it can optimize the network. That is
achievable by using any of the syntaxes bellow (I'm not sure which one to
use yet):
import event a.b.c.Foo; (or)
import event a.b.c.*;
or explicit saying:
declare event a.b.c.Foo;
Once the user declared that something is an event, do you think it is
fair/acceptable to force the user to use a different API to insert events
into the engine?
session.insert(); for regular facts
session.insertEvent(); for events
[]s
Edson
2007/11/8, Anstis, Michael (M.) <manstis1(a)ford.com>:
Here's my 2 cents - as a non-contributor to Drools codebase ;-)
You could add insertEventFactTypeThingie to the API? Then you need just
check that the class has been declared as an event in the DRL similar to
what must already happen for normal DRL imports. I personally don't have
issue with implementing a marker interface (this is what frameworks like
Hibernate, EJB3 and Spring etc have been imposing for years). What
"wiring"
does the POJO need to become an Event for use in Drools? Are you trying to
internalise too much at the risk of making the event mechanism inflexible?
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] Determining if a class is an event or not
Edson Tirelli <tirelli <at> post.com> writes:
>
>
> All, I reached a point where I need to make a design decision and
would
like your opinion about it. Imagine the following scenario: A user has
a
domain model like this:package a.b.c
> ;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
event
a.b.c.*; rule Xwhen
> Event( ... )then ...end So, it is clear that a.b.c.Event should
be
handled as an event by the engine. At runtime, the user asserts an
object
of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and
probably
to the user) that MyEvent should be handled as an event, since by DRL
semantics,
> a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how the
engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
> class as input? The only answer I have is that when the first MyEvent
instance is asserted into the working memory, we must get the class name
and
iterate over all event import declarations checking for a match. In case
no
one
is found, we need to repeat the process for each interface and each class
up
in
the MyEvent hierarchy. Once this process is complete, we cache the results
in
the ObjectTypeConf.
> This may be a quite heavy process to be executed each time a fact of
a
different class is asserted in the working memory for the first time, but
I
can't think a different user-friendly way to solve the question.
> The alternatives would be intrusive, IMO, breaking the drools premise
to
work with user-defined POJOs as facts: use anotations to annotate classes
that
are events, or mandate users implement a specific interface for events.
> Any better idea? []s Edson -- Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
> JBoss, a division of Red Hat <at> www.jboss.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
Edson,
I got your striving not to mandate users implement a specific interface
for
events. However, why not at least introducing an empty event interface (
i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event
interface
(by means of 'instanceof'). Moreover, while parsing the import statements
of
a
rule file, it enables you to double-check whether all the "event imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
restrictions
on the structure for a user defined event class, how do you make sure it
has
all
the required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for temporal
relationships)?
Having said this, in my opinion defining an empty event interface may not
be
sufficient; in addition, it must force the user to implement a method
returning
the event's occurrence date (i.e. the timestamp) at least... Or how would
you
handle this issue?
Matthias
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
12:18 a.m.
I can turn that question around...
If the user has written objects MyFact and MyEvent is it fair to expect them
to have to declare it in the DRL?
I don't know what Events are to do in Drools so don't which is the more
reasonable approach. Is it just for network optimisation as you say, or will
Drools be calling into members?
This is much more interesting than (my) work ;-)
_____
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Edson Tirelli
Sent: 08 November 2007 14:54
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Michael,
Yes, the session.insertEvent() API is something other engines (like iLog
JRules) have. I initially discarded that idea, but since you mentioned, we
may need to reconsider it.
Anyway, the API would solve this part of the problem, but the whole
scenario is:
The engine must know at the compile time exactly what classes/interfaces
used in rules are events, so that it can optimize the network. That is
achievable by using any of the syntaxes bellow (I'm not sure which one to
use yet):
import event a.b.c.Foo; (or)
import event a.b.c.*;
or explicit saying:
declare event a.b.c.Foo;
Once the user declared that something is an event, do you think it is
fair/acceptable to force the user to use a different API to insert events
into the engine?
session.insert(); for regular facts
session.insertEvent(); for events
[]s
Edson
2007/11/8, Anstis, Michael (M.) <manstis1(a)ford.com
<mailto:manstis1@ford.com> >:
Here's my 2 cents - as a non-contributor to Drools codebase ;-)
You could add insertEventFactTypeThingie to the API? Then you need just
check that the class has been declared as an event in the DRL similar to
what must already happen for normal DRL imports. I personally don't have
issue with implementing a marker interface (this is what frameworks like
Hibernate, EJB3 and Spring etc have been imposing for years). What "wiring"
does the POJO need to become an Event for use in Drools? Are you trying to
internalise too much at the risk of making the event mechanism inflexible?
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto: <mailto:rules-dev-bounces@lists.jboss.org>
rules-dev-bounces(a)lists.jboss.org] On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] Determining if a class is an event or not
Edson Tirelli <tirelli <at> post.com> writes:
All, I reached a point where I need to make a design decision and
would
like your opinion about it. Imagine the following scenario: A user has a
domain model like this:package a.b.c
;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
event
a.b.c.* ; rule Xwhen
Event( ... )then ...end So, it is clear that a.b.c.Event
should
be
handled as an event by the engine. At runtime, the user asserts an object
of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and
probably
to the user) that MyEvent should be handled as an event, since by DRL
semantics,
a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how the engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
class as input? The only answer I have is that when the first
MyEvent
instance is asserted into the working memory, we must get the class name
and
iterate over all event import declarations checking for a match. In case no
one
is found, we need to repeat the process for each interface and each class up
in
the MyEvent hierarchy. Once this process is complete, we cache the results
in
the ObjectTypeConf.
This may be a quite heavy process to be executed each time a fact
of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
The alternatives would be intrusive, IMO, breaking the drools
premise
to
work with user-defined POJOs as facts: use anotations to annotate classes
that
are events, or mandate users implement a specific interface for events.
Any better idea? []s Edson -- Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org <http://lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson,
I got your striving not to mandate users implement a specific interface for
events. However, why not at least introducing an empty event interface (i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event
interface
(by means of 'instanceof'). Moreover, while parsing the import statements of
a
rule file, it enables you to double-check whether all the "event imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
restrictions
on the structure for a user defined event class, how do you make sure it has
all
the required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for temporal relationships)?
Having said this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a method
returning
the event's occurrence date (i.e. the timestamp) at least... Or how would
you
handle this issue?
Matthias
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
12:49 a.m.
Michael,
The engine *must* know, at rulebase compile time, what classes represent
events. When I say it is for optimization purposes, is because events are
"light-weight" facts with special characteristics, but that occur in huge
volumes, and so, the engine will never scale without knowing they are
events. The way we can make the engine aware that a given class is an event
may vary:
* we can use some "declaration statement" in the DRL like the ones I
described
* we can make the classes implement a markup-interface like Matthias was
suggesting
* we can use keywords, like iLog uses, writing "event" in every pattern that
represents an event
Besides what I commented in a previous e-mail regarding the markup
interfaces, having the declaration statement in the DRL has an additional
benefit of making clear to third-parties reading the rules that those are
event classes (that carry special characteristics).
The idea here is to discuss exactly the benefits and disadvantages of
each approach. :)
[]s
Edson
2007/11/8, Anstis, Michael (M.) <manstis1(a)ford.com>:
I can turn that question around...
If the user has written objects MyFact and MyEvent is it fair to expect
them to have to declare it in the DRL?
I don't know what Events are to do in Drools so don't which is the more
reasonable approach. Is it just for network optimisation as you say, or will
Drools be calling into members?
This is much more interesting than (my) work ;-)
------------------------------
*From:* rules-dev-bounces(a)lists.jboss.org [mailto:
rules-dev-bounces(a)lists.jboss.org] *On Behalf Of *Edson Tirelli
*Sent:* 08 November 2007 14:54
*To:* Rules Dev List
*Subject:* Re: [rules-dev] Determining if a class is an event or not
Michael,
Yes, the session.insertEvent() API is something other engines (like
iLog JRules) have. I initially discarded that idea, but since you mentioned,
we may need to reconsider it.
Anyway, the API would solve this part of the problem, but the whole
scenario is:
The engine must know at the compile time exactly what
classes/interfaces used in rules are events, so that it can optimize the
network. That is achievable by using any of the syntaxes bellow (I'm not
sure which one to use yet):
import event a.b.c.Foo; (or)
import event a.b.c.*;
or explicit saying:
declare event a.b.c.Foo;
Once the user declared that something is an event, do you think it is
fair/acceptable to force the user to use a different API to insert events
into the engine?
session.insert(); for regular facts
session.insertEvent(); for events
[]s
Edson
2007/11/8, Anstis, Michael (M.) <manstis1(a)ford.com >:
>
> Here's my 2 cents - as a non-contributor to Drools codebase ;-)
>
> You could add insertEventFactTypeThingie to the API? Then you need just
> check that the class has been declared as an event in the DRL similar to
> what must already happen for normal DRL imports. I personally don't have
> issue with implementing a marker interface (this is what frameworks like
>
> Hibernate, EJB3 and Spring etc have been imposing for years). What
> "wiring"
> does the POJO need to become an Event for use in Drools? Are you trying
> to
> internalise too much at the risk of making the event mechanism
> inflexible?
>
> Cheers,
>
> Mike
>
> -----Original Message-----
> From: rules-dev-bounces(a)lists.jboss.org
> [mailto: rules-dev-bounces(a)lists.jboss.org] On Behalf Of Matthias
> Sent: 08 November 2007 13:09
> To: rules-dev(a)lists.jboss.org
> Subject: Re: [rules-dev] Determining if a class is an event or not
>
> Edson Tirelli <tirelli <at> post.com> writes:
>
> >
> >
> > All, I reached a point where I need to make a design decision and
> would
> like your opinion about it. Imagine the following scenario: A user
> has a
> domain model like this:package a.b.c
> > ;public interface Event { ... }package x.y.z;public class MyEvent
> implements
> a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
> event
> a.b.c.* ; rule Xwhen
> > Event( ... )then ...end So, it is clear that a.b.c.Eventshould
> be
> handled as an event by the engine. At runtime, the user asserts an
> object
> of
> the class x.y.z.MyEvent into the working memory. Seems clear to me (and
> probably
> to the user) that MyEvent should be handled as an event, since by DRL
> semantics,
> > a.b.c.* are all events, and by OO class hierarchy concept, since
> a.b.c.Event
> is an event, x.y.z.MyEvent is an event too. My question is: how the
> engine
> knows that MyEvent is an event, since it only has the x.y.z.MyEvent
> > class as input? The only answer I have is that when the first
> MyEvent
> instance is asserted into the working memory, we must get the class name
> and
> iterate over all event import declarations checking for a match. In case
> no
> one
> is found, we need to repeat the process for each interface and each
> class up
> in
> the MyEvent hierarchy. Once this process is complete, we cache the
> results
> in
> the ObjectTypeConf.
> > This may be a quite heavy process to be executed each time a fact
> of a
> different class is asserted in the working memory for the first time,
> but I
> can't think a different user-friendly way to solve the question.
> > The alternatives would be intrusive, IMO, breaking the drools
> premise
> to
> work with user-defined POJOs as facts: use anotations to annotate
> classes
> that
> are events, or mandate users implement a specific interface for events.
> > Any better idea? []s Edson -- Edson Tirelli Software
> Engineer
> - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
> 9287-5646
> > JBoss, a division of Red Hat <at> www.jboss.com
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev <at> lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
>
>
> Edson,
>
> I got your striving not to mandate users implement a specific interface
> for
> events. However, why not at least introducing an empty event interface (
> i.e.
> a
> marker interface, similar to the Serializable interface in Java) the
> user-defined event class(es) have to implement? This way, when inserting
> a
> MyEvent instance, you can simply check whether it implements the event
> interface
> (by means of 'instanceof'). Moreover, while parsing the import
> statements of
> a
> rule file, it enables you to double-check whether all the "event
> imports"
> really
> refer to classes implementing the (empty) event interface.
> In this regard, for me another question raises: Without making any
> restrictions
> on the structure for a user defined event class, how do you make sure it
> has
> all
> the required attributes of an event (which in my opinion must be a
> timestamp,
> at least) and how do you access them (necessary for temporal
> relationships)?
> Having said this, in my opinion defining an empty event interface may
> not be
> sufficient; in addition, it must force the user to implement a method
> returning
> the event's occurrence date (i.e. the timestamp) at least... Or how
> would
> you
> handle this issue?
>
> Matthias
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
6:49 p.m.
Hi Edson,
Sorry if I'm causing more pain and grief than you ever intended your
original posting to cause.
Now I understand (more) the use case for Events I can better appreciate your
original dilemma. If you need the information to optimise the RETE network
at compile-time why do you need to perform the check when a Fact is
inserted; couldn't you have a new ObjectTypeNode that is specific to Event
classes? If my lack of knowledge is more of a hindrance let me know and I'll
revert to being a passive observer.
Cheers,
Mike
_____
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Edson Tirelli
Sent: 08 November 2007 15:50
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Michael,
The engine *must* know, at rulebase compile time, what classes represent
events. When I say it is for optimization purposes, is because events are
"light-weight" facts with special characteristics, but that occur in huge
volumes, and so, the engine will never scale without knowing they are
events. The way we can make the engine aware that a given class is an event
may vary:
* we can use some "declaration statement" in the DRL like the ones I
described
* we can make the classes implement a markup-interface like Matthias was
suggesting
* we can use keywords, like iLog uses, writing "event" in every pattern that
represents an event
Besides what I commented in a previous e-mail regarding the markup
interfaces, having the declaration statement in the DRL has an additional
benefit of making clear to third-parties reading the rules that those are
event classes (that carry special characteristics).
The idea here is to discuss exactly the benefits and disadvantages of
each approach. :)
[]s
Edson
2007/11/8, Anstis, Michael (M.) < manstis1(a)ford.com
<mailto:manstis1@ford.com> >:
I can turn that question around...
If the user has written objects MyFact and MyEvent is it fair to expect them
to have to declare it in the DRL?
I don't know what Events are to do in Drools so don't which is the more
reasonable approach. Is it just for network optimisation as you say, or will
Drools be calling into members?
This is much more interesting than (my) work ;-)
_____
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Edson Tirelli
Sent: 08 November 2007 14:54
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Michael,
Yes, the session.insertEvent() API is something other engines (like iLog
JRules) have. I initially discarded that idea, but since you mentioned, we
may need to reconsider it.
Anyway, the API would solve this part of the problem, but the whole
scenario is:
The engine must know at the compile time exactly what classes/interfaces
used in rules are events, so that it can optimize the network. That is
achievable by using any of the syntaxes bellow (I'm not sure which one to
use yet):
import event a.b.c.Foo; (or)
import event a.b.c.*;
or explicit saying:
declare event a.b.c.Foo;
Once the user declared that something is an event, do you think it is
fair/acceptable to force the user to use a different API to insert events
into the engine?
session.insert(); for regular facts
session.insertEvent(); for events
[]s
Edson
2007/11/8, Anstis, Michael (M.) <manstis1(a)ford.com
<mailto:manstis1@ford.com> >:
Here's my 2 cents - as a non-contributor to Drools codebase ;-)
You could add insertEventFactTypeThingie to the API? Then you need just
check that the class has been declared as an event in the DRL similar to
what must already happen for normal DRL imports. I personally don't have
issue with implementing a marker interface (this is what frameworks like
Hibernate, EJB3 and Spring etc have been imposing for years). What "wiring"
does the POJO need to become an Event for use in Drools? Are you trying to
internalise too much at the risk of making the event mechanism inflexible?
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto: <mailto:rules-dev-bounces@lists.jboss.org>
rules-dev-bounces(a)lists.jboss.org] On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] Determining if a class is an event or not
Edson Tirelli <tirelli <at> post.com> writes:
All, I reached a point where I need to make a design decision and
would
like your opinion about it. Imagine the following scenario: A user has a
domain model like this:package a.b.c
;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
event
a.b.c.* ; rule Xwhen
Event( ... )then ...end So, it is clear that a.b.c.Event
should
be
handled as an event by the engine. At runtime, the user asserts an object
of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and
probably
to the user) that MyEvent should be handled as an event, since by DRL
semantics,
a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how the engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
class as input? The only answer I have is that when the first
MyEvent
instance is asserted into the working memory, we must get the class name
and
iterate over all event import declarations checking for a match. In case no
one
is found, we need to repeat the process for each interface and each class up
in
the MyEvent hierarchy. Once this process is complete, we cache the results
in
the ObjectTypeConf.
This may be a quite heavy process to be executed each time a fact
of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
The alternatives would be intrusive, IMO, breaking the drools
premise
to
work with user-defined POJOs as facts: use anotations to annotate classes
that
are events, or mandate users implement a specific interface for events.
Any better idea? []s Edson -- Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org <http://lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson,
I got your striving not to mandate users implement a specific interface for
events. However, why not at least introducing an empty event interface (i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event
interface
(by means of 'instanceof'). Moreover, while parsing the import statements of
a
rule file, it enables you to double-check whether all the "event imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
restrictions
on the structure for a user defined event class, how do you make sure it has
all
the required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for temporal relationships)?
Having said this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a method
returning
the event's occurrence date (i.e. the timestamp) at least... Or how would
you
handle this issue?
Matthias
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
8:49 p.m.
Michael,
No, it is good to "speak loud" about the problem so I can think more
about it while doing it. :)
The problem is related to class inheritance. At compile time we know that
a.b.c.Foo is an event and we create an ClassObjectTypeConf for it, that says
it is an event. At runtime, though, the user can insert instances (facts) of
absolutely any class in the working memory... even classes for which there
are no rules for. So, at runtime, when a fact of a class that was never seen
before is inserted into working memory, we need to create a
ClassObjectTypeConf for it, where we do a series of analysis (for instance,
at this time we decide if a shadow proxy is needed for it or not), and at
this time, we need to determine if this fact of a new "unknown" class (lets
say x.y.z.Bar) is an event or not (i.e, is it a subclass of a.b.c.Foo?).
So, back to my original e-mail, I can do that hierarchy analysis to
transparently determine that, but it is a costly operation. The other
alternative is assume that the user is explicit naming all event classes,
but that will not work for automatically generated classes (like when using
some XML binding frameworks). The last alternative is what your suggested of
having a specific API for that, but wouldn't we need to create a checking
algorithm anyway to prevent users mistakes?
So, that is the dillemma... :)
[]s
Edson
2007/11/9, Anstis, Michael (M.) <manstis1(a)ford.com>:
Hi Edson,
Sorry if I'm causing more pain and grief than you ever intended your
original posting to cause.
Now I understand (more) the use case for Events I can better appreciate
your original dilemma. If you need the information to optimise the RETE
network at compile-time why do you need to perform the check when a Fact is
inserted; couldn't you have a new ObjectTypeNode that is specific to Event
classes? If my lack of knowledge is more of a hindrance let me know and I'll
revert to being a passive observer.
Cheers,
Mike
------------------------------
*From:* rules-dev-bounces(a)lists.jboss.org [mailto:
rules-dev-bounces(a)lists.jboss.org] *On Behalf Of *Edson Tirelli
*Sent:* 08 November 2007 15:50
*To:* Rules Dev List
*Subject:* Re: [rules-dev] Determining if a class is an event or not
Michael,
The engine *must* know, at rulebase compile time, what classes
represent events. When I say it is for optimization purposes, is because
events are "light-weight" facts with special characteristics, but that occur
in huge volumes, and so, the engine will never scale without knowing they
are events. The way we can make the engine aware that a given class is an
event may vary:
* we can use some "declaration statement" in the DRL like the ones I
described
* we can make the classes implement a markup-interface like Matthias was
suggesting
* we can use keywords, like iLog uses, writing "event" in every pattern
that represents an event
Besides what I commented in a previous e-mail regarding the markup
interfaces, having the declaration statement in the DRL has an additional
benefit of making clear to third-parties reading the rules that those are
event classes (that carry special characteristics).
The idea here is to discuss exactly the benefits and disadvantages of
each approach. :)
[]s
Edson
2007/11/8, Anstis, Michael (M.) < manstis1(a)ford.com>:
>
> I can turn that question around...
>
> If the user has written objects MyFact and MyEvent is it fair to expect
> them to have to declare it in the DRL?
>
> I don't know what Events are to do in Drools so don't which is the more
> reasonable approach. Is it just for network optimisation as you say, or will
> Drools be calling into members?
>
> This is much more interesting than (my) work ;-)
>
> ------------------------------
> *From:* rules-dev-bounces(a)lists.jboss.org [mailto:
> rules-dev-bounces(a)lists.jboss.org] *On Behalf Of *Edson Tirelli
> *Sent:* 08 November 2007 14:54
> *To:* Rules Dev List
> *Subject:* Re: [rules-dev] Determining if a class is an event or not
>
>
> Michael,
>
> Yes, the session.insertEvent() API is something other engines (like
> iLog JRules) have. I initially discarded that idea, but since you mentioned,
> we may need to reconsider it.
> Anyway, the API would solve this part of the problem, but the whole
> scenario is:
> The engine must know at the compile time exactly what
> classes/interfaces used in rules are events, so that it can optimize the
> network. That is achievable by using any of the syntaxes bellow (I'm not
> sure which one to use yet):
>
> import event a.b.c.Foo; (or)
> import event a.b.c.*;
>
> or explicit saying:
>
> declare event a.b.c.Foo;
>
> Once the user declared that something is an event, do you think it
> is fair/acceptable to force the user to use a different API to insert events
> into the engine?
>
> session.insert(); for regular facts
> session.insertEvent(); for events
>
> []s
> Edson
>
> 2007/11/8, Anstis, Michael (M.) <manstis1(a)ford.com >:
> >
> > Here's my 2 cents - as a non-contributor to Drools codebase ;-)
> >
> > You could add insertEventFactTypeThingie to the API? Then you need
> > just
> > check that the class has been declared as an event in the DRL similar
> > to
> > what must already happen for normal DRL imports. I personally don't
> > have
> > issue with implementing a marker interface (this is what frameworks
> > like
> > Hibernate, EJB3 and Spring etc have been imposing for years). What
> > "wiring"
> > does the POJO need to become an Event for use in Drools? Are you
> > trying to
> > internalise too much at the risk of making the event mechanism
> > inflexible?
> >
> > Cheers,
> >
> > Mike
> >
> > -----Original Message-----
> > From: rules-dev-bounces(a)lists.jboss.org
> > [mailto: rules-dev-bounces(a)lists.jboss.org] On Behalf Of Matthias
> > Sent: 08 November 2007 13:09
> > To: rules-dev(a)lists.jboss.org
> > Subject: Re: [rules-dev] Determining if a class is an event or not
> >
> > Edson Tirelli <tirelli <at> post.com> writes:
> >
> > >
> > >
> > > All, I reached a point where I need to make a design decision
> > and
> > would
> > like your opinion about it. Imagine the following scenario: A user
> > has a
> > domain model like this:package a.b.c
> > > ;public interface Event { ... }package x.y.z;public class MyEvent
> > implements
> > a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r
> > ;import
> > event
> > a.b.c.* ; rule Xwhen
> > > Event( ... )then ...end So, it is clear that a.b.c.Eventshould
> > be
> > handled as an event by the engine. At runtime, the user asserts an
> > object
> > of
> > the class x.y.z.MyEvent into the working memory. Seems clear to me
> > (and
> > probably
> > to the user) that MyEvent should be handled as an event, since by DRL
> > semantics,
> > > a.b.c.* are all events, and by OO class hierarchy concept, since
> > a.b.c.Event
> > is an event, x.y.z.MyEvent is an event too. My question is: how the
> > engine
> > knows that MyEvent is an event, since it only has the x.y.z.MyEvent
> > > class as input? The only answer I have is that when the first
> > MyEvent
> > instance is asserted into the working memory, we must get the class
> > name and
> > iterate over all event import declarations checking for a match. In
> > case no
> > one
> > is found, we need to repeat the process for each interface and each
> > class up
> > in
> > the MyEvent hierarchy. Once this process is complete, we cache the
> > results
> > in
> > the ObjectTypeConf.
> > > This may be a quite heavy process to be executed each time a fact
> > of a
> > different class is asserted in the working memory for the first time,
> > but I
> > can't think a different user-friendly way to solve the question.
> > > The alternatives would be intrusive, IMO, breaking the drools
> > premise
> > to
> > work with user-defined POJOs as facts: use anotations to annotate
> > classes
> > that
> > are events, or mandate users implement a specific interface for
> > events.
> > > Any better idea? []s Edson -- Edson Tirelli Software
> > Engineer
> > - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
> > 9287-5646
> > > JBoss, a division of Red Hat <at> www.jboss.com
> > >
> > >
> > > _______________________________________________
> > > rules-dev mailing list
> > > rules-dev <at> lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-dev
> > >
> >
> >
> > Edson,
> >
> > I got your striving not to mandate users implement a specific
> > interface for
> > events. However, why not at least introducing an empty event interface
> > (i.e.
> > a
> > marker interface, similar to the Serializable interface in Java) the
> > user-defined event class(es) have to implement? This way, when
> > inserting a
> > MyEvent instance, you can simply check whether it implements the event
> > interface
> > (by means of 'instanceof'). Moreover, while parsing the import
> > statements of
> > a
> > rule file, it enables you to double-check whether all the "event
> > imports"
> > really
> > refer to classes implementing the (empty) event interface.
> > In this regard, for me another question raises: Without making any
> > restrictions
> > on the structure for a user defined event class, how do you make sure
> > it has
> > all
> > the required attributes of an event (which in my opinion must be a
> > timestamp,
> > at least) and how do you access them (necessary for temporal
> > relationships)?
> > Having said this, in my opinion defining an empty event interface may
> > not be
> > sufficient; in addition, it must force the user to implement a method
> > returning
> > the event's occurrence date (i.e. the timestamp) at least... Or how
> > would
> > you
> > handle this issue?
> >
> > Matthias
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
9:39 p.m.
OK, I understand.
How does this differ to a regular import and Fact insertion? At compile time
you know the imports and create ObjectTypeNodes, and when a sub-class is
inserted.... then what?
PS - are you in London or working late? ;-)
_____
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Edson Tirelli
Sent: 09 November 2007 11:49
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Michael,
No, it is good to "speak loud" about the problem so I can think more
about it while doing it. :)
The problem is related to class inheritance. At compile time we know that
a.b.c.Foo is an event and we create an ClassObjectTypeConf for it, that says
it is an event. At runtime, though, the user can insert instances (facts) of
absolutely any class in the working memory... even classes for which there
are no rules for. So, at runtime, when a fact of a class that was never seen
before is inserted into working memory, we need to create a
ClassObjectTypeConf for it, where we do a series of analysis (for instance,
at this time we decide if a shadow proxy is needed for it or not), and at
this time, we need to determine if this fact of a new "unknown" class (lets
say x.y.z.Bar) is an event or not (i.e, is it a subclass of a.b.c.Foo?).
So, back to my original e-mail, I can do that hierarchy analysis to
transparently determine that, but it is a costly operation. The other
alternative is assume that the user is explicit naming all event classes,
but that will not work for automatically generated classes (like when using
some XML binding frameworks). The last alternative is what your suggested of
having a specific API for that, but wouldn't we need to create a checking
algorithm anyway to prevent users mistakes?
So, that is the dillemma... :)
[]s
Edson
2007/11/9, Anstis, Michael (M.) <manstis1(a)ford.com>:
Hi Edson,
Sorry if I'm causing more pain and grief than you ever intended your
original posting to cause.
Now I understand (more) the use case for Events I can better appreciate your
original dilemma. If you need the information to optimise the RETE network
at compile-time why do you need to perform the check when a Fact is
inserted; couldn't you have a new ObjectTypeNode that is specific to Event
classes? If my lack of knowledge is more of a hindrance let me know and I'll
revert to being a passive observer.
Cheers,
Mike
_____
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Edson Tirelli
Sent: 08 November 2007 15:50
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Michael,
The engine *must* know, at rulebase compile time, what classes represent
events. When I say it is for optimization purposes, is because events are
"light-weight" facts with special characteristics, but that occur in huge
volumes, and so, the engine will never scale without knowing they are
events. The way we can make the engine aware that a given class is an event
may vary:
* we can use some "declaration statement" in the DRL like the ones I
described
* we can make the classes implement a markup-interface like Matthias was
suggesting
* we can use keywords, like iLog uses, writing "event" in every pattern that
represents an event
Besides what I commented in a previous e-mail regarding the markup
interfaces, having the declaration statement in the DRL has an additional
benefit of making clear to third-parties reading the rules that those are
event classes (that carry special characteristics).
The idea here is to discuss exactly the benefits and disadvantages of
each approach. :)
[]s
Edson
2007/11/8, Anstis, Michael (M.) < <mailto:manstis1@ford.com>
manstis1(a)ford.com>:
I can turn that question around...
If the user has written objects MyFact and MyEvent is it fair to expect them
to have to declare it in the DRL?
I don't know what Events are to do in Drools so don't which is the more
reasonable approach. Is it just for network optimisation as you say, or will
Drools be calling into members?
This is much more interesting than (my) work ;-)
_____
From: rules-dev-bounces(a)lists.jboss.org [mailto:
<mailto:rules-dev-bounces@lists.jboss.org>
rules-dev-bounces(a)lists.jboss.org] On Behalf Of Edson Tirelli
Sent: 08 November 2007 14:54
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Michael,
Yes, the session.insertEvent() API is something other engines (like iLog
JRules) have. I initially discarded that idea, but since you mentioned, we
may need to reconsider it.
Anyway, the API would solve this part of the problem, but the whole
scenario is:
The engine must know at the compile time exactly what classes/interfaces
used in rules are events, so that it can optimize the network. That is
achievable by using any of the syntaxes bellow (I'm not sure which one to
use yet):
import event a.b.c.Foo; (or)
import event a.b.c.*;
or explicit saying:
declare event a.b.c.Foo;
Once the user declared that something is an event, do you think it is
fair/acceptable to force the user to use a different API to insert events
into the engine?
session.insert(); for regular facts
session.insertEvent(); for events
[]s
Edson
2007/11/8, Anstis, Michael (M.) <manstis1(a)ford.com
<mailto:manstis1@ford.com> >:
Here's my 2 cents - as a non-contributor to Drools codebase ;-)
You could add insertEventFactTypeThingie to the API? Then you need just
check that the class has been declared as an event in the DRL similar to
what must already happen for normal DRL imports. I personally don't have
issue with implementing a marker interface (this is what frameworks like
Hibernate, EJB3 and Spring etc have been imposing for years). What "wiring"
does the POJO need to become an Event for use in Drools? Are you trying to
internalise too much at the risk of making the event mechanism inflexible?
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto: <mailto:rules-dev-bounces@lists.jboss.org>
rules-dev-bounces(a)lists.jboss.org] On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] Determining if a class is an event or not
Edson Tirelli <tirelli <at> post.com> writes:
All, I reached a point where I need to make a design decision and
would
like your opinion about it. Imagine the following scenario: A user has a
domain model like this:package a.b.c
;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
event
a.b.c.* ; rule Xwhen
Event( ... )then ...end So, it is clear that a.b.c.Event
should
be
handled as an event by the engine. At runtime, the user asserts an object
of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and
probably
to the user) that MyEvent should be handled as an event, since by DRL
semantics,
a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how the engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
class as input? The only answer I have is that when the first
MyEvent
instance is asserted into the working memory, we must get the class name
and
iterate over all event import declarations checking for a match. In case no
one
is found, we need to repeat the process for each interface and each class up
in
the MyEvent hierarchy. Once this process is complete, we cache the results
in
the ObjectTypeConf.
This may be a quite heavy process to be executed each time a fact
of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
The alternatives would be intrusive, IMO, breaking the drools
premise
to
work with user-defined POJOs as facts: use anotations to annotate classes
that
are events, or mandate users implement a specific interface for events.
Any better idea? []s Edson -- Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org <http://lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson,
I got your striving not to mandate users implement a specific interface for
events. However, why not at least introducing an empty event interface (i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event
interface
(by means of 'instanceof'). Moreover, while parsing the import statements of
a
rule file, it enables you to double-check whether all the "event imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
restrictions
on the structure for a user defined event class, how do you make sure it has
all
the required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for temporal relationships)?
Having said this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a method
returning
the event's occurrence date (i.e. the timestamp) at least... Or how would
you
handle this issue?
Matthias
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
11:26 p.m.
Edson,
We always tried to avoid mandating the user to change its domain
model to use
Drools and "contaminating" it with Drools specific
classes/interfaces. This way,
different from other engines, we work with simple POJOs as facts. There are also
other reasons for that, like we want to implement support for other fact types,
like ontologies, etc, but the main one I still thing is the one above.
So, we can have an Event interface or an annotation that the user
may use
to explicit mark a Java class as an event, but IMO, we should use the Event
interface as an alternative way of doing it, and not as the only way.
The event interface was the first thing that came to my mind since it's pretty
straight-forward. However, I see your point. So if there is a way to maintain
the POJO philosophy without making too many awkward allowances, I'm up for it :).
A simpler solution we could go for is to mandate that the user
declares
all its event classes/interfaces with a declare like statement in the DRL
instead of using the "import event" syntax. Something like that:
declare event a.b.c.Foo; So the engine can load the
class/interface
a.b.c.Foo and check each asserted fact to see if it is an a.b.c.Foo
instance.
That would be easier from an engine perspective, but would be verbose from a
users perspective, since we would not be able to allow wildcards in such
declaration. Would that be better?
Actually, that sounds like a good compromise to me. The question is how many
different event class definitions a user would define. As long as there are not
too many, manually declaring them in a way you suggested shouldn't be a big
deal. I don't know what's the most common approach, but IMO it makes sense to
have a generic event (class) definition, and different events just differ in a
different name and attributes they carry with them. To give an example: In the
use case I'm working on, having lots of different kinds of events though, there
will be exactly one primitive event class/interface. A primitive event will have
a name, a parent id (i.e. some device it refers to) and a list or map,
respectively, of parameters (which have changed). I might have to add another
interface for composite events (i.e. events composed of primitive or other
composite events by means of temporal relationships), but that should be it.
However, other people might prefer to have a different event class for every
different event (like an alarm, a status change, a confirmation, etc.); not
being able to use wildcards and having to declare all the event class manually
may becomee awkward; then I can't think of another way to do it than the one you
initially suggested, although it may be costly...
The other question you asked is really interesting and I also
don't have a
definitive answer, but have some ideas:> In this regard, for me
another question
raises: Without making any restrictions on the structure for a user defined
event class, how do you make sure it has all the required attributes of an
event (which in my opinion must be a timestamp, at least) and how do you access
them (necessary for temporal relationships)?
In the paper "Discarding unused temporal information in a
Production
System", by Dan Teodosiu and Günter Pollak, they state that
"Events carry an
additional *implicit* attribute that represents the timestamp. The value of this
attribute is automatically set upon creation of an event to the current value of
the system-clock."
I agree with them, except for the "system-clock" part.
Replace
"system-clock" by "engine-clock" and I think we get the
best compromise. We
know that most real-world events are generated with an explicit timestamp
attribute, but since we may be handling events coming from different sources
without any guarantee that the sources have synchronized clocks, we can not rely
on the eventual explicit timestamp attribute for reasoning in the engine. Not
relying on that also give us the ability to handle events that do not contain
the explicit timestamp attribute.
I completely agree. Relying only on the explicit timestamp attribute could raise
problems; not only due to unsynchronized clocks, but also network delay might be
reason for events arriving in an order distinct to their original time and order
of occurrence.
What I am thinking is:1. In current Drools implementation, each
fact
asserted into the rules engine is wrapped in a FactHandle implementation. This
FactHandle implementation contains metadata attributes that are used by the
engine during fact manipulation and reasoning. What I'm suggesting is we derive
a new EventFactHandle implementation that would contain all event's implicit
attributes and metada we need, including the timestamp. This would allow us to
also support different semantic-models for the timestamp, and that is why I
asked you about the point-interval semantics. The easiest one would be the
point-in-time semantic, obviously.
As you may have noticed, I shirked from answering the question which timesramp
represntation to use. I didn't find a paper making the decision for me; most of
the times it's just a comparison between these two approaches without clear
arguments for or against it. IMO, interval-based representation seems to be more
general, i.e. more expressive; at the same time, its operators are more complex
and harder to use. The maybe most comprehensive analysis can be found in the
paper "Point- Versus Interval-based Temporal Data Models" from Bohlen, Busatto
and Jensen; another short summary is given in chapter 3, paragraph "Timestamps"
in "Unified Semantics for Event Correlation Over Time and Space in Hybrid
Network Environments" from Yoneki and Bacon. Let me add that the set of temporal
relationships (between two timestamps) in interval-based semantics is much more
extensive than in point-based semantics (13 vs. 2).
As you mentioned, the more intuitive and straight-forward approach to represent
timestamps would be point-interval semantics. However, since we (or at least me
:)) wanna process composite events (which consists of several primitive events),
I'm not quite sure whether this will be enough. Primitive events in general are
instantaneous, however they could be modelled as interval with identical start
and end point. Composite events definitely will last longer than an instant,
i.e. from the occurrence time of the first until the last constituent event. Of
course, detecting them may only require to detect the single constituent events,
however you might wanna store them as a composite event and insert them into
working memory to use them later on. What time(point) do you assign them? The
time of the first constituent, or of the last, or some time in between? Not to
mention that the constituent events could be composite events again.
2. We also will need to create the engine clock abstraction, and, as
we
discussed previously, we will probably need 4 implementations:
- "System Clock": a clock that periodically synchronizes
with the machine clock
- "Event based clock": a clock that is updated every time a given event
arrives
- "Pseudo Clock": a generic implementation that is arbitrarily updated by
application code
- "Event Attribute Clock": a clock that is updated by a
configured event
attribute
3. Every time a new event is inserted into the engine, we would then
populate
the "implicit" attributes by using a configurable strategy. For
instance, if a
user wants to use the explicit value of the object timestamp as the event
timestamp, the configurable strategy would simply copy the value of the
attribute to the implicit event attribute. If the user wants to use the engine
clock timestamp at assertion time as the event timestamp, the configurable
strategy would simply request the current value to the engine clock and populate
the event timestamp with this attribute.
Makes perfect sense. I don't know why this "different strategy" thing
didn't
come to my mind, but that's the way we should do it. Preferably the implicit
timestamp should be used, but in case there's none or the user simply wants to
use the engine's timestamp, the excplicit timestamp will be taken.
Maybe one could even think of a mixed strategy, i.e. maintaining the order of
the events (from possibly different sources) by means of their "local"
timestamp, but adapting them to one global clock (that could be the engine
clock) by balancing different delays from different sources, for instance. Just
an idea :)...
Cheers,
Matthias
10:25 p.m.
Well,
IMHO for the experience I have I suggest to implement both solutions:
-an API insertEvet() so the user can implement the mechanism to manage
their rules knowing when a fact is an event or not.
-an Interface Event so when the user cant manage the flow asserting
facts, when
he cant know when a fact is or not an event, then maybe he can wrap
some facts on this
interface and the API insert() internaly can check if the fact is an
event or not and call insertEvent if
necesary.
:)
On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:
Here's my 2 cents - as a non-contributor to Drools codebase ;-)
You could add insertEventFactTypeThingie to the API? Then you need
just
check that the class has been declared as an event in the DRL
similar to
what must already happen for normal DRL imports. I personally don't
have
issue with implementing a marker interface (this is what frameworks
like
Hibernate, EJB3 and Spring etc have been imposing for years). What
"wiring"
does the POJO need to become an Event for use in Drools? Are you
trying to
internalise too much at the risk of making the event mechanism
inflexible?
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] Determining if a class is an event or not
Edson Tirelli <tirelli <at> post.com> writes:
>
>
> All, I reached a point where I need to make a design decision
> and
would
like your opinion about it. Imagine the following scenario: A
user has a
domain model like this:package a.b.c
> ;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he writes:package
p.q.r;import
event
a.b.c.*; rule Xwhen
> Event( ... )then ...end So, it is clear that a.b.c.Event
> should
be
handled as an event by the engine. At runtime, the user asserts
an object
of
the class x.y.z.MyEvent into the working memory. Seems clear to me
(and
probably
to the user) that MyEvent should be handled as an event, since by DRL
semantics,
> a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how
the engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
> class as input? The only answer I have is that when the first
> MyEvent
instance is asserted into the working memory, we must get the class
name and
iterate over all event import declarations checking for a match. In
case no
one
is found, we need to repeat the process for each interface and each
class up
in
the MyEvent hierarchy. Once this process is complete, we cache the
results
in
the ObjectTypeConf.
> This may be a quite heavy process to be executed each time a
> fact of a
different class is asserted in the working memory for the first
time, but I
can't think a different user-friendly way to solve the question.
> The alternatives would be intrusive, IMO, breaking the drools
> premise
to
work with user-defined POJOs as facts: use anotations to annotate
classes
that
are events, or mandate users implement a specific interface for
events.
> Any better idea? []s Edson -- Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
> JBoss, a division of Red Hat <at> www.jboss.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
Edson,
I got your striving not to mandate users implement a specific
interface for
events. However, why not at least introducing an empty event
interface (i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when
inserting a
MyEvent instance, you can simply check whether it implements the event
interface
(by means of 'instanceof'). Moreover, while parsing the import
statements of
a
rule file, it enables you to double-check whether all the "event
imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
restrictions
on the structure for a user defined event class, how do you make
sure it has
all
the required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for temporal
relationships)?
Having said this, in my opinion defining an empty event interface
may not be
sufficient; in addition, it must force the user to implement a method
returning
the event's occurrence date (i.e. the timestamp) at least... Or how
would
you
handle this issue?
Matthias
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
11:49 p.m.
Hi Felipe,
I recall Edson saying that "Event" classes need to be ascertained at (RETE)
compilation time - which, I think, rules out the API addition. I was hoping
Edson, time permitting, would explain how declarative (fact-centric class)
imports currently work to generate an ObjectTypeNode and therefore to
understand how his proposal to create cached ObjectTypeConf instances for
Event-centric classes compares. My reasoning being that if the process is
similar the new event stuff should be no different; simply having two
ObjectTypeNodes - one for Events and another for Facts. See attached.
It's quite possible our exchanges have given Edson time to come to his own
conclusion and the solution is now being coded!
With kind regards,
Mike
_____
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Felipe Piccolini
Sent: 12 November 2007 13:25
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Well,
IMHO for the experience I have I suggest to implement both solutions:
-an API insertEvet() so the user can implement the mechanism to manage
their rules knowing when a fact is an event or not.
-an Interface Event so when the user cant manage the flow asserting facts,
when
he cant know when a fact is or not an event, then maybe he can wrap some
facts on this
interface and the API insert() internaly can check if the fact is an event
or not and call insertEvent if
necesary.
:)
On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:
Here's my 2 cents - as a non-contributor to Drools codebase ;-)
You could add insertEventFactTypeThingie to the API? Then you need just
check that the class has been declared as an event in the DRL similar to
what must already happen for normal DRL imports. I personally don't have
issue with implementing a marker interface (this is what frameworks like
Hibernate, EJB3 and Spring etc have been imposing for years). What "wiring"
does the POJO need to become an Event for use in Drools? Are you trying to
internalise too much at the risk of making the event mechanism inflexible?
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] Determining if a class is an event or not
Edson Tirelli <tirelli <at> post.com> writes:
All, I reached a point where I need to make a design decision and
would
like your opinion about it. Imagine the following scenario: A user has a
domain model like this:package a.b.c
;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
event
a.b.c.*; rule Xwhen
Event( ... )then ...end So, it is clear that a.b.c.Event should
be
handled as an event by the engine. At runtime, the user asserts an object
of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and
probably
to the user) that MyEvent should be handled as an event, since by DRL
semantics,
a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how the engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
class as input? The only answer I have is that when the first MyEvent
instance is asserted into the working memory, we must get the class name and
iterate over all event import declarations checking for a match. In case no
one
is found, we need to repeat the process for each interface and each class up
in
the MyEvent hierarchy. Once this process is complete, we cache the results
in
the ObjectTypeConf.
This may be a quite heavy process to be executed each time a fact of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
The alternatives would be intrusive, IMO, breaking the drools premise
to
work with user-defined POJOs as facts: use anotations to annotate classes
that
are events, or mandate users implement a specific interface for events.
Any better idea? []s Edson -- Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson,
I got your striving not to mandate users implement a specific interface for
events. However, why not at least introducing an empty event interface (i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event
interface
(by means of 'instanceof'). Moreover, while parsing the import statements of
a
rule file, it enables you to double-check whether all the "event imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
restrictions
on the structure for a user defined event class, how do you make sure it has
all
the required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for temporal relationships)?
Having said this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a method
returning
the event's occurrence date (i.e. the timestamp) at least... Or how would
you
handle this issue?
Matthias
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Felipe Piccolini M.
<mailto:felipe.piccolini@bluesoft.cl> felipe.piccolini(a)bluesoft.cl
1:54 a.m.
Mike, Felipe and Matthias,
Thank you for all your feedback. It really helps to understand the
different point of views.
I will try to summarize my understanding of the issue based on your
comments so far and on the technical requirements of the system. First we
need to understand the 2 different times where the information about an
instance of a class (fact) being an event or not is needed:
* At compile time: this is required to actually create the optimized network
(including the ObjectTypeNodes that Mike mentions). It is a must have and we
can't avoid it. The best way to do that IMO is using a specific declarative
statement in the rules files. I'm thinking about either an "import event
x.y.z.Event" statement, or a specific "declare event x.y.z.Event". This is
pure syntax to let the engine know what is an event and what is not, at
rulebase compilation time. If most users think a syntax like "I want to
declare that the x.y.z.Event instances are events" is more appropriate, :)
we could do it, but as it is today, I like the idea of using a simple
"event" keyword in import statements, the same way we import static
functions:
import a.b.c.Fact; // a simple fact import
import function java.lang.Math.max; // a static function import
import event x.y.z.Event; // an event import
If we were an engine working with templates or any other type of fact
that did not allows inheritance, that would completely solve the problem.
But we work with POJOs as facts, and POJOs (being plain java) support
inheritance. So:
* At runtime: even knowing, at compile time, that x.y.z.Event is an event,
at runtime a user may assert p.q.r.AnotherClass into working memory. Now, is
p.q.r.AnotherClass an event or not? We need to determine that at the time
the first instance of p.q.r.AnotherClass is asserted into the working
memory. At this time, in runtime, we create an ObjectTypeNode for this fact
class that previously was not known by the engine. A few options on how to
determine that were discussed here:
1. Mandate all classes that are events implement an "Event" interface. I
don't like this solution, as mentioned in a previous e-mail, because it
breaks the Drools paradigm of working with user defined domain models,
without contaminating them with drools specific code. Although, by your
comments, seems that this would be an acceptable solution.
2. Create a separate API (something like "session.insertEvent()") to insert
events into the working memory. This would also "solve" the problem, but:
* "What happens if a user uses this API to insert a class that was not
declared as event at compile time?". From a technical perspective, this will
lead to unpredictable behavior and possibly to inconsistencies in the
reasoning algorithm, specially because events do not need shadow facts (they
are supposed to be immutable).
* "What happens if a user uses the regular 'session.insert()' API for a
class that was declared as an event at compile time?". Same as above with
the additional problem that the user may try to call update() or retract()
for that given fact, what is not allowed for events. Again, unpredictable
behavior.
My worry is that the only solution for the above 2 issues would be to
implement a verification routine that would validate if a fact asserted as
event is indeed an event according to what was declared at compile time, and
vice-versa. Note though, that this validation procedure would be basically
the same required for solution number 3 bellow, but would have to be
executed at every insert()/insertEvent() call, making it more costly than
the completely automated decision.
3. Implementing an automated decision procedure, analyzing the class
hierarchy of the inserted fact, every time a fact of a previously unknown
class is inserted into working memory. Due to the problems presented in the
previous solutions, this is still my preferred approach. Its main drawback
is the class hierarchy analysis that is not simple to do and at the same
time is a bit heavy, but would happen only when the first fact of a
previously unknown class is inserted into working memory.
So, we can probably implement solution (1) and (2) as options, but at
this time, I can't see how to avoid implementing support for (3). But having
(3), is it worth to have (1) and/or (2) too, or would it only confuse users?
Thanks all for all the feedback so far.
[]s
Edson
2007/11/12, Anstis, Michael (M.) <manstis1(a)ford.com>:
Hi Felipe,
I recall Edson saying that "Event" classes need to be ascertained at
(RETE) compilation time - which, I think, rules out the API addition. I
was hoping Edson, time permitting, would explain how
declarative (fact-centric class) imports currently work to generate an
ObjectTypeNode and therefore to understand how his proposal to create cached
ObjectTypeConf instances for Event-centric classes compares. My reasoning
being that if the process is similar the new event stuff should be no
different; simply having two ObjectTypeNodes - one for Events and another
for Facts. See attached.
It's quite possible our exchanges have given Edson time to come to his own
conclusion and the solution is now being coded!
With kind regards,
Mike
------------------------------
*From:* rules-dev-bounces(a)lists.jboss.org [mailto:
rules-dev-bounces(a)lists.jboss.org] *On Behalf Of *Felipe Piccolini
*Sent:* 12 November 2007 13:25
*To:* Rules Dev List
*Subject:* Re: [rules-dev] Determining if a class is an event or not
Well,
IMHO for the experience I have I suggest to implement both solutions:
-an API insertEvet() so the user can implement the mechanism to manage
their rules knowing when a fact is an event or not.
-an Interface Event so when the user cant manage the flow asserting facts,
when
he cant know when a fact is or not an event, then maybe he can wrap some
facts on this
interface and the API insert() internaly can check if the fact is an event
or not and call insertEvent if
necesary.
:)
On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:
Here's my 2 cents - as a non-contributor to Drools codebase ;-)
You could add insertEventFactTypeThingie to the API? Then you need just
check that the class has been declared as an event in the DRL similar to
what must already happen for normal DRL imports. I personally don't have
issue with implementing a marker interface (this is what frameworks like
Hibernate, EJB3 and Spring etc have been imposing for years). What
"wiring"
does the POJO need to become an Event for use in Drools? Are you trying to
internalise too much at the risk of making the event mechanism inflexible?
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org<rules-dev-bounces@lists.jboss.org>]
On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] Determining if a class is an event or not
Edson Tirelli <tirelli <at> post.com> writes:
All, I reached a point where I need to make a design decision and
would
like your opinion about it. Imagine the following scenario: A user has
a
domain model like this:package a.b.c
;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
event
a.b.c.*; rule Xwhen
Event( ... )then ...end So, it is clear that a.b.c.Event should
be
handled as an event by the engine. At runtime, the user asserts an
object
of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and
probably
to the user) that MyEvent should be handled as an event, since by DRL
semantics,
a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how the
engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
class as input? The only answer I have is that when the first MyEvent
instance is asserted into the working memory, we must get the class name
and
iterate over all event import declarations checking for a match. In case
no
one
is found, we need to repeat the process for each interface and each class
up
in
the MyEvent hierarchy. Once this process is complete, we cache the results
in
the ObjectTypeConf.
This may be a quite heavy process to be executed each time a fact of a
different class is asserted in the working memory for the first time, but
I
can't think a different user-friendly way to solve the question.
The alternatives would be intrusive, IMO, breaking the drools premise
to
work with user-defined POJOs as facts: use anotations to annotate classes
that
are events, or mandate users implement a specific interface for events.
Any better idea? []s Edson -- Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson,
I got your striving not to mandate users implement a specific interface
for
events. However, why not at least introducing an empty event interface (
i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event
interface
(by means of 'instanceof'). Moreover, while parsing the import statements
of
a
rule file, it enables you to double-check whether all the "event imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
restrictions
on the structure for a user defined event class, how do you make sure it
has
all
the required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for temporal
relationships)?
Having said this, in my opinion defining an empty event interface may not
be
sufficient; in addition, it must force the user to implement a method
returning
the event's occurrence date (i.e. the timestamp) at least... Or how would
you
handle this issue?
Matthias
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
*Felipe Piccolini M.*
felipe.piccolini(a)bluesoft.cl
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
4:04 a.m.
Edson,
As I see it,
Solutions (1) and (2) lend the responsabilitie of knowing what
they are doing on developers, and can be tricky...but at the end
could be
an optimal solution...so they should exists.. solution (3) makes all
the work clean and easy, but can introduce over load work, so for first
instance I'll set up solution (3) so an advanced developer coul
deactivated by developer with some config API, so they could make their
application work faster if they know what they are doing...
OF course i dont like to break the POJO paradigm on drools, is one of
the things make drools THE choice... but introduce extra check to
add a feature that maybe not all devs will use is something that an
advanced dev should decide...
my 2 cents..
:)
btw: Im a little lost on this event feature (last moths Iv been
working on other things) so, where can I read about this event
handle?..is a new
feature from 4.0.2?...is on the docs? Thx.
On 12-11-2007, at 13:54, Edson Tirelli wrote:
Mike, Felipe and Matthias,
Thank you for all your feedback. It really helps to understand
the different point of views.
I will try to summarize my understanding of the issue based on
your comments so far and on the technical requirements of the
system. First we need to understand the 2 different times where the
information about an instance of a class (fact) being an event or
not is needed:
* At compile time: this is required to actually create the
optimized network (including the ObjectTypeNodes that Mike
mentions). It is a must have and we can't avoid it. The best way to
do that IMO is using a specific declarative statement in the rules
files. I'm thinking about either an "import event x.y.z.Event"
statement, or a specific "declare event x.y.z.Event". This is pure
syntax to let the engine know what is an event and what is not, at
rulebase compilation time. If most users think a syntax like "I
want to declare that the x.y.z.Event instances are events" is more
appropriate, :) we could do it, but as it is today, I like the idea
of using a simple "event" keyword in import statements, the same
way we import static functions:
import a.b.c.Fact; // a simple fact import
import function java.lang.Math.max; // a static function import
import event x.y.z.Event; // an event import
If we were an engine working with templates or any other type
of fact that did not allows inheritance, that would completely
solve the problem. But we work with POJOs as facts, and POJOs
(being plain java) support inheritance. So:
* At runtime: even knowing, at compile time, that x.y.z.Event is an
event, at runtime a user may assert p.q.r.AnotherClass into working
memory. Now, is p.q.r.AnotherClass an event or not? We need to
determine that at the time the first instance of p.q.r.AnotherClass
is asserted into the working memory. At this time, in runtime, we
create an ObjectTypeNode for this fact class that previously was
not known by the engine. A few options on how to determine that
were discussed here:
1. Mandate all classes that are events implement an "Event"
interface. I don't like this solution, as mentioned in a previous e-
mail, because it breaks the Drools paradigm of working with user
defined domain models, without contaminating them with drools
specific code. Although, by your comments, seems that this would be
an acceptable solution.
2. Create a separate API (something like "session.insertEvent()")
to insert events into the working memory. This would also "solve"
the problem, but:
* "What happens if a user uses this API to insert a class that was
not declared as event at compile time?". From a technical
perspective, this will lead to unpredictable behavior and possibly
to inconsistencies in the reasoning algorithm, specially because
events do not need shadow facts (they are supposed to be immutable).
* "What happens if a user uses the regular 'session.insert()' API
for a class that was declared as an event at compile time?". Same
as above with the additional problem that the user may try to call
update() or retract() for that given fact, what is not allowed for
events. Again, unpredictable behavior.
My worry is that the only solution for the above 2 issues would
be to implement a verification routine that would validate if a
fact asserted as event is indeed an event according to what was
declared at compile time, and vice-versa. Note though, that this
validation procedure would be basically the same required for
solution number 3 bellow, but would have to be executed at every
insert()/insertEvent() call, making it more costly than the
completely automated decision.
3. Implementing an automated decision procedure, analyzing the
class hierarchy of the inserted fact, every time a fact of a
previously unknown class is inserted into working memory. Due to
the problems presented in the previous solutions, this is still my
preferred approach. Its main drawback is the class hierarchy
analysis that is not simple to do and at the same time is a bit
heavy, but would happen only when the first fact of a previously
unknown class is inserted into working memory.
So, we can probably implement solution (1) and (2) as options,
but at this time, I can't see how to avoid implementing support for
(3). But having (3), is it worth to have (1) and/or (2) too, or
would it only confuse users?
Thanks all for all the feedback so far.
[]s
Edson
2007/11/12, Anstis, Michael (M.) <manstis1(a)ford.com>:
Hi Felipe,
I recall Edson saying that "Event" classes need to be ascertained
at (RETE) compilation time - which, I think, rules out the API
addition. I was hoping Edson, time permitting, would explain how
declarative (fact-centric class) imports currently work to generate
an ObjectTypeNode and therefore to understand how his proposal to
create cached ObjectTypeConf instances for Event-centric classes
compares. My reasoning being that if the process is similar the new
event stuff should be no different; simply having two
ObjectTypeNodes - one for Events and another for Facts. See attached.
It's quite possible our exchanges have given Edson time to come to
his own conclusion and the solution is now being coded!
With kind regards,
Mike
From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-
bounces(a)lists.jboss.org] On Behalf Of Felipe Piccolini
Sent: 12 November 2007 13:25
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Well,
IMHO for the experience I have I suggest to implement both
solutions:
-an API insertEvet() so the user can implement the mechanism to manage
their rules knowing when a fact is an event or not.
-an Interface Event so when the user cant manage the flow asserting
facts, when
he cant know when a fact is or not an event, then maybe he can wrap
some facts on this
interface and the API insert() internaly can check if the fact is
an event or not and call insertEvent if
necesary.
:)
On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:
> Here's my 2 cents - as a non-contributor to Drools codebase ;-)
>
> You could add insertEventFactTypeThingie to the API? Then you need
> just
> check that the class has been declared as an event in the DRL
> similar to
> what must already happen for normal DRL imports. I personally
> don't have
> issue with implementing a marker interface (this is what
> frameworks like
> Hibernate, EJB3 and Spring etc have been imposing for years). What
> "wiring"
> does the POJO need to become an Event for use in Drools? Are you
> trying to
> internalise too much at the risk of making the event mechanism
> inflexible?
>
> Cheers,
>
> Mike
>
> -----Original Message-----
> From: rules-dev-bounces(a)lists.jboss.org
> [mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Matthias
> Sent: 08 November 2007 13:09
> To: rules-dev(a)lists.jboss.org
> Subject: Re: [rules-dev] Determining if a class is an event or not
>
> Edson Tirelli <tirelli <at> post.com> writes:
>
>>
>>
>> All, I reached a point where I need to make a design
>> decision and
> would
> like your opinion about it. Imagine the following scenario: A
> user has a
> domain model like this:package a.b.c
>> ;public interface Event { ... }package x.y.z;public class MyEvent
> implements
> a.b.c.Event {...} Then, in his DRL file he writes:package
> p.q.r;import
> event
> a.b.c.*; rule Xwhen
>> Event( ... )then ...end So, it is clear that a.b.c.Event
>> should
> be
> handled as an event by the engine. At runtime, the user asserts
> an object
> of
> the class x.y.z.MyEvent into the working memory. Seems clear to me
> (and
> probably
> to the user) that MyEvent should be handled as an event, since by DRL
> semantics,
>> a.b.c.* are all events, and by OO class hierarchy concept, since
> a.b.c.Event
> is an event, x.y.z.MyEvent is an event too. My question is: how
> the engine
> knows that MyEvent is an event, since it only has the x.y.z.MyEvent
>> class as input? The only answer I have is that when the first
>> MyEvent
> instance is asserted into the working memory, we must get the
> class name and
> iterate over all event import declarations checking for a match.
> In case no
> one
> is found, we need to repeat the process for each interface and
> each class up
> in
> the MyEvent hierarchy. Once this process is complete, we cache the
> results
> in
> the ObjectTypeConf.
>> This may be a quite heavy process to be executed each time a
>> fact of a
> different class is asserted in the working memory for the first
> time, but I
> can't think a different user-friendly way to solve the question.
>> The alternatives would be intrusive, IMO, breaking the drools
>> premise
> to
> work with user-defined POJOs as facts: use anotations to annotate
> classes
> that
> are events, or mandate users implement a specific interface for
> events.
>> Any better idea? []s Edson -- Edson Tirelli Software
> Engineer
> - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile:
> +55 11
> 9287-5646
>> JBoss, a division of Red Hat <at> www.jboss.com
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
> Edson,
>
> I got your striving not to mandate users implement a specific
> interface for
> events. However, why not at least introducing an empty event
> interface (i.e.
> a
> marker interface, similar to the Serializable interface in Java) the
> user-defined event class(es) have to implement? This way, when
> inserting a
> MyEvent instance, you can simply check whether it implements the
> event
> interface
> (by means of 'instanceof'). Moreover, while parsing the import
> statements of
> a
> rule file, it enables you to double-check whether all the "event
> imports"
> really
> refer to classes implementing the (empty) event interface.
> In this regard, for me another question raises: Without making any
> restrictions
> on the structure for a user defined event class, how do you make
> sure it has
> all
> the required attributes of an event (which in my opinion must be a
> timestamp,
> at least) and how do you access them (necessary for temporal
> relationships)?
> Having said this, in my opinion defining an empty event interface
> may not be
> sufficient; in addition, it must force the user to implement a method
> returning
> the event's occurrence date (i.e. the timestamp) at least... Or
> how would
> you
> handle this issue?
>
> Matthias
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
4:25 a.m.
Felipe,
I see your point and maybe you are right. I will do some more research
till tomorrow and then start implementing that. Let's see how much overhead
solution 3 adds and if it is worth to have options 1 and/or 2.
Just to make it clear, we are talking about use cases where the rules
USE events, i.e., CEP/ESP use cases. All these must have NO impact on
rulebases that do not use events, as it is today.
CEP/ESP support and Temporal Reasoning are a set of features we are
working on for the next major release. It is in early design/implementation
phases now and we have no docs yet.
Anyone interested in that is more than welcome to join discussions like
the one in this thread, contribute ideas, code and docs. We are an open
source product after all... :)
Regards,
Edson
2007/11/12, Felipe Piccolini <felipe.piccolini(a)bluesoft.cl>:
Edson,
As I see it,
Solutions (1) and (2) lend the responsabilitie of knowing what they are
doing on developers, and can be tricky...but at the end could be
an optimal solution...so they should exists.. solution (3) makes all the
work clean and easy, but can introduce over load work, so for first
instance I'll set up solution (3) so an advanced developer coul
deactivated by developer with some config API, so they could make their
application work faster if they know what they are doing...
OF course i dont like to break the POJO paradigm on drools, is one of the
things make drools THE choice... but introduce extra check to
add a feature that maybe not all devs will use is something that an
advanced dev should decide...
my 2 cents..
:)
btw: Im a little lost on this event feature (last moths Iv been working on
other things) so, where can I read about this event handle?..is a new
feature from 4.0.2?...is on the docs? Thx.
On 12-11-2007, at 13:54, Edson Tirelli wrote:
Mike, Felipe and Matthias,
Thank you for all your feedback. It really helps to understand the
different point of views.
I will try to summarize my understanding of the issue based on your
comments so far and on the technical requirements of the system. First we
need to understand the 2 different times where the information about an
instance of a class (fact) being an event or not is needed:
* At compile time: this is required to actually create the optimized
network (including the ObjectTypeNodes that Mike mentions). It is a must
have and we can't avoid it. The best way to do that IMO is using a specific
declarative statement in the rules files. I'm thinking about either an
"import event x.y.z.Event" statement, or a specific "declare event
x.y.z.Event". This is pure syntax to let the engine know what is an event
and what is not, at rulebase compilation time. If most users think a syntax
like "I want to declare that the x.y.z.Event instances are events" is more
appropriate, :) we could do it, but as it is today, I like the idea of using
a simple "event" keyword in import statements, the same way we import static
functions:
import a.b.c.Fact; // a simple fact import
import function java.lang.Math.max; // a static function import
import event x.y.z.Event; // an event import
If we were an engine working with templates or any other type of fact
that did not allows inheritance, that would completely solve the problem.
But we work with POJOs as facts, and POJOs (being plain java) support
inheritance. So:
* At runtime: even knowing, at compile time, that x.y.z.Event is an event,
at runtime a user may assert p.q.r.AnotherClass into working memory. Now,
is p.q.r.AnotherClass an event or not? We need to determine that at the
time the first instance of p.q.r.AnotherClass is asserted into the working
memory. At this time, in runtime, we create an ObjectTypeNode for this fact
class that previously was not known by the engine. A few options on how to
determine that were discussed here:
1. Mandate all classes that are events implement an "Event" interface. I
don't like this solution, as mentioned in a previous e-mail, because it
breaks the Drools paradigm of working with user defined domain models,
without contaminating them with drools specific code. Although, by your
comments, seems that this would be an acceptable solution.
2. Create a separate API (something like "session.insertEvent()") to
insert events into the working memory. This would also "solve" the problem,
but:
* "What happens if a user uses this API to insert a class that was not
declared as event at compile time?". From a technical perspective, this will
lead to unpredictable behavior and possibly to inconsistencies in the
reasoning algorithm, specially because events do not need shadow facts (they
are supposed to be immutable).
* "What happens if a user uses the regular 'session.insert()' API for a
class that was declared as an event at compile time?". Same as above with
the additional problem that the user may try to call update() or retract()
for that given fact, what is not allowed for events. Again, unpredictable
behavior.
My worry is that the only solution for the above 2 issues would be to
implement a verification routine that would validate if a fact asserted as
event is indeed an event according to what was declared at compile time, and
vice-versa. Note though, that this validation procedure would be basically
the same required for solution number 3 bellow, but would have to be
executed at every insert()/insertEvent() call, making it more costly than
the completely automated decision.
3. Implementing an automated decision procedure, analyzing the class
hierarchy of the inserted fact, every time a fact of a previously unknown
class is inserted into working memory. Due to the problems presented in the
previous solutions, this is still my preferred approach. Its main drawback
is the class hierarchy analysis that is not simple to do and at the same
time is a bit heavy, but would happen only when the first fact of a
previously unknown class is inserted into working memory.
So, we can probably implement solution (1) and (2) as options, but at
this time, I can't see how to avoid implementing support for (3). But having
(3), is it worth to have (1) and/or (2) too, or would it only confuse users?
Thanks all for all the feedback so far.
[]s
Edson
2007/11/12, Anstis, Michael (M.) <manstis1(a)ford.com>:
>
> Hi Felipe,
>
> I recall Edson saying that "Event" classes need to be ascertained at
> (RETE) compilation time - which, I think, rules out the API addition. I
> was hoping Edson, time permitting, would explain how
> declarative (fact-centric class) imports currently work to generate an
> ObjectTypeNode and therefore to understand how his proposal to create cached
> ObjectTypeConf instances for Event-centric classes compares. My reasoning
> being that if the process is similar the new event stuff should be no
> different; simply having two ObjectTypeNodes - one for Events and another
> for Facts. See attached.
>
> It's quite possible our exchanges have given Edson time to come to his
> own conclusion and the solution is now being coded!
>
> With kind regards,
>
> Mike
>
> ------------------------------
> *From:* rules-dev-bounces(a)lists.jboss.org [mailto:
> rules-dev-bounces(a)lists.jboss.org] *On Behalf Of *Felipe Piccolini
> *Sent:* 12 November 2007 13:25
> *To:* Rules Dev List
> *Subject:* Re: [rules-dev] Determining if a class is an event or not
>
> Well,
> IMHO for the experience I have I suggest to implement both solutions:
> -an API insertEvet() so the user can implement the mechanism to manage
> their rules knowing when a fact is an event or not.
> -an Interface Event so when the user cant manage the flow asserting
> facts, when
> he cant know when a fact is or not an event, then maybe he can wrap some
> facts on this
> interface and the API insert() internaly can check if the fact is an
> event or not and call insertEvent if
> necesary.
>
> :)
>
> On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:
>
> Here's my 2 cents - as a non-contributor to Drools codebase ;-)
>
> You could add insertEventFactTypeThingie to the API? Then you need just
> check that the class has been declared as an event in the DRL similar to
> what must already happen for normal DRL imports. I personally don't have
> issue with implementing a marker interface (this is what frameworks like
> Hibernate, EJB3 and Spring etc have been imposing for years). What
> "wiring"
> does the POJO need to become an Event for use in Drools? Are you trying
> to
> internalise too much at the risk of making the event mechanism
> inflexible?
>
> Cheers,
>
> Mike
>
> -----Original Message-----
> From: rules-dev-bounces(a)lists.jboss.org
> [mailto:rules-dev-bounces@lists.jboss.org<rules-dev-bounces@lists.jboss.org>]
> On Behalf Of Matthias
> Sent: 08 November 2007 13:09
> To: rules-dev(a)lists.jboss.org
> Subject: Re: [rules-dev] Determining if a class is an event or not
>
> Edson Tirelli <tirelli <at> post.com> writes:
>
>
>
> All, I reached a point where I need to make a design decision and
>
> would
> like your opinion about it. Imagine the following scenario: A user
> has a
> domain model like this:package a.b.c
>
> ;public interface Event { ... }package x.y.z;public class MyEvent
>
> implements
> a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
> event
> a.b.c.*; rule Xwhen
>
> Event( ... )then ...end So, it is clear that a.b.c.Event should
>
> be
> handled as an event by the engine. At runtime, the user asserts an
> object
> of
> the class x.y.z.MyEvent into the working memory. Seems clear to me (and
> probably
> to the user) that MyEvent should be handled as an event, since by DRL
> semantics,
>
> a.b.c.* are all events, and by OO class hierarchy concept, since
>
> a.b.c.Event
> is an event, x.y.z.MyEvent is an event too. My question is: how the
> engine
> knows that MyEvent is an event, since it only has the x.y.z.MyEvent
>
> class as input? The only answer I have is that when the first MyEvent
>
> instance is asserted into the working memory, we must get the class name
> and
> iterate over all event import declarations checking for a match. In case
> no
> one
> is found, we need to repeat the process for each interface and each
> class up
> in
> the MyEvent hierarchy. Once this process is complete, we cache the
> results
> in
> the ObjectTypeConf.
>
> This may be a quite heavy process to be executed each time a fact of
> a
>
> different class is asserted in the working memory for the first time,
> but I
> can't think a different user-friendly way to solve the question.
>
> The alternatives would be intrusive, IMO, breaking the drools premise
>
> to
> work with user-defined POJOs as facts: use anotations to annotate
> classes
> that
> are events, or mandate users implement a specific interface for events.
>
> Any better idea? []s Edson -- Edson Tirelli Software
>
> Engineer
> - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
> 9287-5646
>
> JBoss, a division of Red Hat <at> www.jboss.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> Edson,
>
> I got your striving not to mandate users implement a specific interface
> for
> events. However, why not at least introducing an empty event interface (
> i.e.
> a
> marker interface, similar to the Serializable interface in Java) the
> user-defined event class(es) have to implement? This way, when inserting
> a
> MyEvent instance, you can simply check whether it implements the event
> interface
> (by means of 'instanceof'). Moreover, while parsing the import
> statements of
> a
> rule file, it enables you to double-check whether all the "event
> imports"
> really
> refer to classes implementing the (empty) event interface.
> In this regard, for me another question raises: Without making any
> restrictions
> on the structure for a user defined event class, how do you make sure it
> has
> all
> the required attributes of an event (which in my opinion must be a
> timestamp,
> at least) and how do you access them (necessary for temporal
> relationships)?
> Having said this, in my opinion defining an empty event interface may
> not be
> sufficient; in addition, it must force the user to implement a method
> returning
> the event's occurrence date (i.e. the timestamp) at least... Or how
> would
> you
> handle this issue?
>
> Matthias
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> *Felipe Piccolini M.*
> felipe.piccolini(a)bluesoft.cl
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
*Felipe
Piccolini M.*
felipe.piccolini(a)bluesoft.cl
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
6:19 p.m.
Option (3) fits in best with the current way Drools exposes itself to users
(we don't need to implement an interface for regular facts, or shadow facts)
but would like to understand how it differs to the insertion of regular
facts: a user imports a class but can insert a sub-class, so it appears this
would need to perform the same type of inheritance check as Edson is
proposing for (3) to ensure the correct ObjectTypeNode is selected... it
could well be that (3) is no different to how regular facts are propagated
through the network.
_____
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Edson Tirelli
Sent: 12 November 2007 19:25
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Felipe,
I see your point and maybe you are right. I will do some more research
till tomorrow and then start implementing that. Let's see how much overhead
solution 3 adds and if it is worth to have options 1 and/or 2.
Just to make it clear, we are talking about use cases where the rules
USE events, i.e., CEP/ESP use cases. All these must have NO impact on
rulebases that do not use events, as it is today.
CEP/ESP support and Temporal Reasoning are a set of features we are
working on for the next major release. It is in early design/implementation
phases now and we have no docs yet.
Anyone interested in that is more than welcome to join discussions like
the one in this thread, contribute ideas, code and docs. We are an open
source product after all... :)
Regards,
Edson
2007/11/12, Felipe Piccolini <felipe.piccolini(a)bluesoft.cl>:
Edson,
As I see it,
Solutions (1) and (2) lend the responsabilitie of knowing what they are
doing on developers, and can be tricky...but at the end could be
an optimal solution...so they should exists.. solution (3) makes all the
work clean and easy, but can introduce over load work, so for first
instance I'll set up solution (3) so an advanced developer coul deactivated
by developer with some config API, so they could make their
application work faster if they know what they are doing...
OF course i dont like to break the POJO paradigm on drools, is one of the
things make drools THE choice... but introduce extra check to
add a feature that maybe not all devs will use is something that an advanced
dev should decide...
my 2 cents..
:)
btw: Im a little lost on this event feature (last moths Iv been working on
other things) so, where can I read about this event handle?..is a new
feature from 4.0.2?...is on the docs? Thx.
On 12-11-2007, at 13:54, Edson Tirelli wrote:
Mike, Felipe and Matthias,
Thank you for all your feedback. It really helps to understand the
different point of views.
I will try to summarize my understanding of the issue based on your
comments so far and on the technical requirements of the system. First we
need to understand the 2 different times where the information about an
instance of a class (fact) being an event or not is needed:
* At compile time: this is required to actually create the optimized network
(including the ObjectTypeNodes that Mike mentions). It is a must have and we
can't avoid it. The best way to do that IMO is using a specific declarative
statement in the rules files. I'm thinking about either an "import event
x.y.z.Event" statement, or a specific "declare event x.y.z.Event". This is
pure syntax to let the engine know what is an event and what is not, at
rulebase compilation time. If most users think a syntax like "I want to
declare that the x.y.z.Event instances are events" is more appropriate, :)
we could do it, but as it is today, I like the idea of using a simple
"event" keyword in import statements, the same way we import static
functions:
import a.b.c.Fact; // a simple fact import
import function java.lang.Math.max; // a static function import
import event x.y.z.Event; // an event import
If we were an engine working with templates or any other type of fact
that did not allows inheritance, that would completely solve the problem.
But we work with POJOs as facts, and POJOs (being plain java) support
inheritance. So:
* At runtime: even knowing, at compile time, that x.y.z.Event is an event,
at runtime a user may assert p.q.r.AnotherClass into working memory. Now, is
p.q.r.AnotherClass an event or not? We need to determine that at the time
the first instance of p.q.r.AnotherClass is asserted into the working
memory. At this time, in runtime, we create an ObjectTypeNode for this fact
class that previously was not known by the engine. A few options on how to
determine that were discussed here:
1. Mandate all classes that are events implement an "Event" interface. I
don't like this solution, as mentioned in a previous e-mail, because it
breaks the Drools paradigm of working with user defined domain models,
without contaminating them with drools specific code. Although, by your
comments, seems that this would be an acceptable solution.
2. Create a separate API (something like "session.insertEvent()") to insert
events into the working memory. This would also "solve" the problem, but:
* "What happens if a user uses this API to insert a class that was not
declared as event at compile time?". From a technical perspective, this will
lead to unpredictable behavior and possibly to inconsistencies in the
reasoning algorithm, specially because events do not need shadow facts (they
are supposed to be immutable).
* "What happens if a user uses the regular 'session.insert()' API for a
class that was declared as an event at compile time?". Same as above with
the additional problem that the user may try to call update() or retract()
for that given fact, what is not allowed for events. Again, unpredictable
behavior.
My worry is that the only solution for the above 2 issues would be to
implement a verification routine that would validate if a fact asserted as
event is indeed an event according to what was declared at compile time, and
vice-versa. Note though, that this validation procedure would be basically
the same required for solution number 3 bellow, but would have to be
executed at every insert()/insertEvent() call, making it more costly than
the completely automated decision.
3. Implementing an automated decision procedure, analyzing the class
hierarchy of the inserted fact, every time a fact of a previously unknown
class is inserted into working memory. Due to the problems presented in the
previous solutions, this is still my preferred approach. Its main drawback
is the class hierarchy analysis that is not simple to do and at the same
time is a bit heavy, but would happen only when the first fact of a
previously unknown class is inserted into working memory.
So, we can probably implement solution (1) and (2) as options, but at
this time, I can't see how to avoid implementing support for (3). But having
(3), is it worth to have (1) and/or (2) too, or would it only confuse users?
Thanks all for all the feedback so far.
[]s
Edson
2007/11/12, Anstis, Michael (M.) < <mailto:manstis1@ford.com>
manstis1(a)ford.com>:
Hi Felipe,
I recall Edson saying that "Event" classes need to be ascertained at (RETE)
compilation time - which, I think, rules out the API addition. I was hoping
Edson, time permitting, would explain how declarative (fact-centric class)
imports currently work to generate an ObjectTypeNode and therefore to
understand how his proposal to create cached ObjectTypeConf instances for
Event-centric classes compares. My reasoning being that if the process is
similar the new event stuff should be no different; simply having two
ObjectTypeNodes - one for Events and another for Facts. See attached.
It's quite possible our exchanges have given Edson time to come to his own
conclusion and the solution is now being coded!
With kind regards,
Mike
_____
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Felipe Piccolini
Sent: 12 November 2007 13:25
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Well,
IMHO for the experience I have I suggest to implement both solutions:
-an API insertEvet() so the user can implement the mechanism to manage
their rules knowing when a fact is an event or not.
-an Interface Event so when the user cant manage the flow asserting facts,
when
he cant know when a fact is or not an event, then maybe he can wrap some
facts on this
interface and the API insert() internaly can check if the fact is an event
or not and call insertEvent if
necesary.
:)
On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:
Here's my 2 cents - as a non-contributor to Drools codebase ;-)
You could add insertEventFactTypeThingie to the API? Then you need just
check that the class has been declared as an event in the DRL similar to
what must already happen for normal DRL imports. I personally don't have
issue with implementing a marker interface (this is what frameworks like
Hibernate, EJB3 and Spring etc have been imposing for years). What "wiring"
does the POJO need to become an Event for use in Drools? Are you trying to
internalise too much at the risk of making the event mechanism inflexible?
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org
<mailto:rules-dev-bounces@lists.jboss.org> ] On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] Determining if a class is an event or not
Edson Tirelli <tirelli <at> post.com> writes:
All, I reached a point where I need to make a design decision and
would
like your opinion about it. Imagine the following scenario: A user has a
domain model like this:package a.b.c
;public interface Event { ... }package x.y.z;public class MyEvent
implements
a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import
event
a.b.c.*; rule Xwhen
Event( ... )then ...end So, it is clear that a.b.c.Event should
be
handled as an event by the engine. At runtime, the user asserts an object
of
the class x.y.z.MyEvent into the working memory. Seems clear to me (and
probably
to the user) that MyEvent should be handled as an event, since by DRL
semantics,
a.b.c.* are all events, and by OO class hierarchy concept, since
a.b.c.Event
is an event, x.y.z.MyEvent is an event too. My question is: how the engine
knows that MyEvent is an event, since it only has the x.y.z.MyEvent
class as input? The only answer I have is that when the first MyEvent
instance is asserted into the working memory, we must get the class name and
iterate over all event import declarations checking for a match. In case no
one
is found, we need to repeat the process for each interface and each class up
in
the MyEvent hierarchy. Once this process is complete, we cache the results
in
the ObjectTypeConf.
This may be a quite heavy process to be executed each time a fact of a
different class is asserted in the working memory for the first time, but I
can't think a different user-friendly way to solve the question.
The alternatives would be intrusive, IMO, breaking the drools premise
to
work with user-defined POJOs as facts: use anotations to annotate classes
that
are events, or mandate users implement a specific interface for events.
Any better idea? []s Edson -- Edson Tirelli Software
Engineer
- JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
9287-5646
JBoss, a division of Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Edson,
I got your striving not to mandate users implement a specific interface for
events. However, why not at least introducing an empty event interface (i.e.
a
marker interface, similar to the Serializable interface in Java) the
user-defined event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the event
interface
(by means of 'instanceof'). Moreover, while parsing the import statements of
a
rule file, it enables you to double-check whether all the "event imports"
really
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
restrictions
on the structure for a user defined event class, how do you make sure it has
all
the required attributes of an event (which in my opinion must be a
timestamp,
at least) and how do you access them (necessary for temporal relationships)?
Having said this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a method
returning
the event's occurrence date (i.e. the timestamp) at least... Or how would
you
handle this issue?
Matthias
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
<https://lists.jboss.org/mailman/listinfo/rules-dev>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
<https://lists.jboss.org/mailman/listinfo/rules-dev>
Felipe Piccolini M.
<mailto:felipe.piccolini@bluesoft.cl> felipe.piccolini(a)bluesoft.cl
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
Felipe Piccolini M.
<mailto:felipe.piccolini@bluesoft.cl> felipe.piccolini(a)bluesoft.cl
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
12:29 a.m.
Edson,
Im glad to hear this kind of stuffs being designed/implemented on
drools, it has grown so much... I like the way this project has take
the lead,
good job to all of u guys!! :) Im more than happy of get involved on
this kind of discusion... and congratz to u Edson as u represent
southamerica
on this team :)
On 12-11-2007, at 16:25, Edson Tirelli wrote:
Felipe,
I see your point and maybe you are right. I will do some more
research till tomorrow and then start implementing that. Let's see
how much overhead solution 3 adds and if it is worth to have
options 1 and/or 2.
Just to make it clear, we are talking about use cases where the
rules USE events, i.e., CEP/ESP use cases. All these must have NO
impact on rulebases that do not use events, as it is today.
CEP/ESP support and Temporal Reasoning are a set of features we
are working on for the next major release. It is in early design/
implementation phases now and we have no docs yet.
Anyone interested in that is more than welcome to join
discussions like the one in this thread, contribute ideas, code and
docs. We are an open source product after all... :)
Regards,
Edson
2007/11/12, Felipe Piccolini <felipe.piccolini(a)bluesoft.cl>:
Edson,
As I see it,
Solutions (1) and (2) lend the responsabilitie of knowing what
they are doing on developers, and can be tricky...but at the end
could be
an optimal solution...so they should exists.. solution (3) makes
all the work clean and easy, but can introduce over load work, so
for first
instance I'll set up solution (3) so an advanced developer coul
deactivated by developer with some config API, so they could make
their
application work faster if they know what they are doing...
OF course i dont like to break the POJO paradigm on drools, is one
of the things make drools THE choice... but introduce extra check to
add a feature that maybe not all devs will use is something that an
advanced dev should decide...
my 2 cents..
:)
btw: Im a little lost on this event feature (last moths Iv been
working on other things) so, where can I read about this event
handle?..is a new
feature from 4.0.2?...is on the docs? Thx.
On 12-11-2007, at 13:54, Edson Tirelli wrote:
>
> Mike, Felipe and Matthias,
>
> Thank you for all your feedback. It really helps to understand
> the different point of views.
> I will try to summarize my understanding of the issue based on
> your comments so far and on the technical requirements of the
> system. First we need to understand the 2 different times where
> the information about an instance of a class (fact) being an event
> or not is needed:
>
> * At compile time: this is required to actually create the
> optimized network (including the ObjectTypeNodes that Mike
> mentions). It is a must have and we can't avoid it. The best way
> to do that IMO is using a specific declarative statement in the
> rules files. I'm thinking about either an "import event
> x.y.z.Event" statement, or a specific "declare event x.y.z.Event".
> This is pure syntax to let the engine know what is an event and
> what is not, at rulebase compilation time. If most users think a
> syntax like "I want to declare that the x.y.z.Event instances are
> events" is more appropriate, :) we could do it, but as it is
> today, I like the idea of using a simple "event" keyword in import
> statements, the same way we import static functions:
>
> import a.b.c.Fact; // a simple fact import
> import function java.lang.Math.max; // a static function import
>
> import event x.y.z.Event; // an event import
>
> If we were an engine working with templates or any other type
> of fact that did not allows inheritance, that would completely
> solve the problem. But we work with POJOs as facts, and POJOs
> (being plain java) support inheritance. So:
>
> * At runtime: even knowing, at compile time, that x.y.z.Event is
> an event, at runtime a user may assert p.q.r.AnotherClass into
> working memory. Now, is p.q.r.AnotherClass an event or not? We
> need to determine that at the time the first instance of
> p.q.r.AnotherClass is asserted into the working memory. At this
> time, in runtime, we create an ObjectTypeNode for this fact class
> that previously was not known by the engine. A few options on how
> to determine that were discussed here:
>
> 1. Mandate all classes that are events implement an "Event"
> interface. I don't like this solution, as mentioned in a previous
> e-mail, because it breaks the Drools paradigm of working with user
> defined domain models, without contaminating them with drools
> specific code. Although, by your comments, seems that this would
> be an acceptable solution.
>
> 2. Create a separate API (something like "session.insertEvent()")
> to insert events into the working memory. This would also "solve"
> the problem, but:
> * "What happens if a user uses this API to insert a class that was
> not declared as event at compile time?". From a technical
> perspective, this will lead to unpredictable behavior and possibly
> to inconsistencies in the reasoning algorithm, specially because
> events do not need shadow facts (they are supposed to be immutable).
> * "What happens if a user uses the regular 'session.insert()' API
> for a class that was declared as an event at compile time?". Same
> as above with the additional problem that the user may try to call
> update() or retract() for that given fact, what is not allowed for
> events. Again, unpredictable behavior.
> My worry is that the only solution for the above 2 issues would
> be to implement a verification routine that would validate if a
> fact asserted as event is indeed an event according to what was
> declared at compile time, and vice-versa. Note though, that this
> validation procedure would be basically the same required for
> solution number 3 bellow, but would have to be executed at every
> insert()/insertEvent() call, making it more costly than the
> completely automated decision.
>
> 3. Implementing an automated decision procedure, analyzing the
> class hierarchy of the inserted fact, every time a fact of a
> previously unknown class is inserted into working memory. Due to
> the problems presented in the previous solutions, this is still my
> preferred approach. Its main drawback is the class hierarchy
> analysis that is not simple to do and at the same time is a bit
> heavy, but would happen only when the first fact of a previously
> unknown class is inserted into working memory.
>
> So, we can probably implement solution (1) and (2) as options,
> but at this time, I can't see how to avoid implementing support
> for (3). But having (3), is it worth to have (1) and/or (2) too,
> or would it only confuse users?
>
> Thanks all for all the feedback so far.
>
> []s
> Edson
>
> 2007/11/12, Anstis, Michael (M.) < manstis1(a)ford.com>:
> Hi Felipe,
>
> I recall Edson saying that "Event" classes need to be ascertained
> at (RETE) compilation time - which, I think, rules out the API
> addition. I was hoping Edson, time permitting, would explain how
> declarative (fact-centric class) imports currently work to
> generate an ObjectTypeNode and therefore to understand how his
> proposal to create cached ObjectTypeConf instances for Event-
> centric classes compares. My reasoning being that if the process
> is similar the new event stuff should be no different; simply
> having two ObjectTypeNodes - one for Events and another for Facts.
> See attached.
>
> It's quite possible our exchanges have given Edson time to come to
> his own conclusion and the solution is now being coded!
>
> With kind regards,
>
> Mike
>
> From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-
> bounces(a)lists.jboss.org] On Behalf Of Felipe Piccolini
> Sent: 12 November 2007 13:25
> To: Rules Dev List
>
> Subject: Re: [rules-dev] Determining if a class is an event or not
>
> Well,
>
> IMHO for the experience I have I suggest to implement both
> solutions:
> -an API insertEvet() so the user can implement the mechanism to
> manage
> their rules knowing when a fact is an event or not.
> -an Interface Event so when the user cant manage the flow
> asserting facts, when
> he cant know when a fact is or not an event, then maybe he can
> wrap some facts on this
> interface and the API insert() internaly can check if the fact is
> an event or not and call insertEvent if
> necesary.
>
> :)
>
> On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:
>
>> Here's my 2 cents - as a non-contributor to Drools codebase ;-)
>>
>> You could add insertEventFactTypeThingie to the API? Then you
>> need just
>> check that the class has been declared as an event in the DRL
>> similar to
>> what must already happen for normal DRL imports. I personally
>> don't have
>> issue with implementing a marker interface (this is what
>> frameworks like
>> Hibernate, EJB3 and Spring etc have been imposing for years).
>> What "wiring"
>> does the POJO need to become an Event for use in Drools? Are you
>> trying to
>> internalise too much at the risk of making the event mechanism
>> inflexible?
>>
>> Cheers,
>>
>> Mike
>>
>> -----Original Message-----
>> From: rules-dev-bounces(a)lists.jboss.org
>> [mailto:rules-dev-bounces@lists.jboss.org ] On Behalf Of Matthias
>> Sent: 08 November 2007 13:09
>> To: rules-dev(a)lists.jboss.org
>> Subject: Re: [rules-dev] Determining if a class is an event or not
>>
>> Edson Tirelli <tirelli <at> post.com> writes:
>>
>>>
>>>
>>> All, I reached a point where I need to make a design
>>> decision and
>> would
>> like your opinion about it. Imagine the following scenario: A
>> user has a
>> domain model like this:package a.b.c
>>> ;public interface Event { ... }package x.y.z;public class MyEvent
>> implements
>> a.b.c.Event {...} Then, in his DRL file he writes:package
>> p.q.r;import
>> event
>> a.b.c.*; rule Xwhen
>>> Event( ... )then ...end So, it is clear that
>>> a.b.c.Event should
>> be
>> handled as an event by the engine. At runtime, the user asserts
>> an object
>> of
>> the class x.y.z.MyEvent into the working memory. Seems clear to
>> me (and
>> probably
>> to the user) that MyEvent should be handled as an event, since by
>> DRL
>> semantics,
>>> a.b.c.* are all events, and by OO class hierarchy concept, since
>> a.b.c.Event
>> is an event, x.y.z.MyEvent is an event too. My question is: how
>> the engine
>> knows that MyEvent is an event, since it only has the x.y.z.MyEvent
>>> class as input? The only answer I have is that when the first
>>> MyEvent
>> instance is asserted into the working memory, we must get the
>> class name and
>> iterate over all event import declarations checking for a match.
>> In case no
>> one
>> is found, we need to repeat the process for each interface and
>> each class up
>> in
>> the MyEvent hierarchy. Once this process is complete, we cache
>> the results
>> in
>> the ObjectTypeConf.
>>> This may be a quite heavy process to be executed each time a
>>> fact of a
>> different class is asserted in the working memory for the first
>> time, but I
>> can't think a different user-friendly way to solve the question.
>>> The alternatives would be intrusive, IMO, breaking the drools
>>> premise
>> to
>> work with user-defined POJOs as facts: use anotations to annotate
>> classes
>> that
>> are events, or mandate users implement a specific interface for
>> events.
>>> Any better idea? []s Edson -- Edson Tirelli
>>> Software
>> Engineer
>> - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile:
>> +55 11
>> 9287-5646
>>> JBoss, a division of Red Hat <at> www.jboss.com
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev <at> lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>> Edson,
>>
>> I got your striving not to mandate users implement a specific
>> interface for
>> events. However, why not at least introducing an empty event
>> interface (i.e.
>> a
>> marker interface, similar to the Serializable interface in Java) the
>> user-defined event class(es) have to implement? This way, when
>> inserting a
>> MyEvent instance, you can simply check whether it implements the
>> event
>> interface
>> (by means of 'instanceof'). Moreover, while parsing the import
>> statements of
>> a
>> rule file, it enables you to double-check whether all the "event
>> imports"
>> really
>> refer to classes implementing the (empty) event interface.
>> In this regard, for me another question raises: Without making any
>> restrictions
>> on the structure for a user defined event class, how do you make
>> sure it has
>> all
>> the required attributes of an event (which in my opinion must be a
>> timestamp,
>> at least) and how do you access them (necessary for temporal
>> relationships)?
>> Having said this, in my opinion defining an empty event interface
>> may not be
>> sufficient; in addition, it must force the user to implement a
>> method
>> returning
>> the event's occurrence date (i.e. the timestamp) at least... Or
>> how would
>> you
>> handle this issue?
>>
>> Matthias
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> Felipe Piccolini M.
> felipe.piccolini(a)bluesoft.cl
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
6:18 a.m.
Mike,
Good question.
Since I'm playing "devil's advocate" here, imagine the scenario:
* There is an event stream that the user wants to process with our engine.
The stream has events of types (classes) A, B and C, all of them from
package x.y.z. So, the user writes in the DRL:
import events x.y.z.*;
Although, at this time, the user is only interested in events of type A, and
so only writes rules for event type A. So, the engine will only create (at
rulebase compile time) ObjectTypeNodes for class A. Since one of the jobs of
an ESP engine is to select only the events the user is interested in, the
engine must discard events B and C. But a rules engine, only automatically
discards events, not facts, and as so, the engine must know that B and C are
events and the user is not interested in them, but using existing
ObjectTypes to determine if B and C are events, will not help in this case.
So, with regular facts, Drools does exactly what you said, but with
events, an additional verification must be made to determine at runtime if a
given class is an event class or not. That is the difference we are looking
a solution for.
Edson
2007/11/13, Anstis, Michael (M.) <manstis1(a)ford.com>:
Option (3) fits in best with the current way Drools exposes itself to
users (we don't need to implement an interface for regular facts, or shadow
facts) but would like to understand how it differs to the insertion of
regular facts: a user imports a class but can insert a sub-class, so it
appears this would need to perform the same type of inheritance check as
Edson is proposing for (3) to ensure the correct ObjectTypeNode is
selected... it could well be that (3) is no different to how regular facts
are propagated through the network.
------------------------------
*From:* rules-dev-bounces(a)lists.jboss.org [mailto:
rules-dev-bounces(a)lists.jboss.org] *On Behalf Of *Edson Tirelli
*Sent:* 12 November 2007 19:25
*To:* Rules Dev List
*Subject:* Re: [rules-dev] Determining if a class is an event or not
Felipe,
I see your point and maybe you are right. I will do some more research
till tomorrow and then start implementing that. Let's see how much overhead
solution 3 adds and if it is worth to have options 1 and/or 2.
Just to make it clear, we are talking about use cases where the rules
USE events, i.e., CEP/ESP use cases. All these must have NO impact on
rulebases that do not use events, as it is today.
CEP/ESP support and Temporal Reasoning are a set of features we are
working on for the next major release. It is in early design/implementation
phases now and we have no docs yet.
Anyone interested in that is more than welcome to join discussions
like the one in this thread, contribute ideas, code and docs. We are an open
source product after all... :)
Regards,
Edson
2007/11/12, Felipe Piccolini <felipe.piccolini(a)bluesoft.cl>:
>
> Edson,
> As I see it,
>
> Solutions (1) and (2) lend the responsabilitie of knowing what they
> are doing on developers, and can be tricky...but at the end could be
> an optimal solution...so they should exists.. solution (3) makes all the
> work clean and easy, but can introduce over load work, so for first
> instance I'll set up solution (3) so an advanced developer coul
> deactivated by developer with some config API, so they could make their
> application work faster if they know what they are doing...
>
> OF course i dont like to break the POJO paradigm on drools, is one of
> the things make drools THE choice... but introduce extra check to
> add a feature that maybe not all devs will use is something that an
> advanced dev should decide...
>
> my 2 cents..
>
> :)
>
> btw: Im a little lost on this event feature (last moths Iv been working
> on other things) so, where can I read about this event handle?..is a new
> feature from 4.0.2?...is on the docs? Thx.
>
>
> On 12-11-2007, at 13:54, Edson Tirelli wrote:
>
>
> Mike, Felipe and Matthias,
>
> Thank you for all your feedback. It really helps to understand the
> different point of views.
> I will try to summarize my understanding of the issue based on your
> comments so far and on the technical requirements of the system. First we
> need to understand the 2 different times where the information about an
> instance of a class (fact) being an event or not is needed:
>
> * At compile time: this is required to actually create the optimized
> network (including the ObjectTypeNodes that Mike mentions). It is a must
> have and we can't avoid it. The best way to do that IMO is using a specific
> declarative statement in the rules files. I'm thinking about either an
> "import event x.y.z.Event" statement, or a specific "declare event
> x.y.z.Event". This is pure syntax to let the engine know what is an
> event and what is not, at rulebase compilation time. If most users think a
> syntax like "I want to declare that the x.y.z.Event instances are
> events" is more appropriate, :) we could do it, but as it is today, I like
> the idea of using a simple "event" keyword in import statements, the same
> way we import static functions:
>
> import a.b.c.Fact; // a simple fact import
> import function java.lang.Math.max; // a static function import
>
> import event x.y.z.Event; // an event import
>
> If we were an engine working with templates or any other type of
> fact that did not allows inheritance, that would completely solve the
> problem. But we work with POJOs as facts, and POJOs (being plain java)
> support inheritance. So:
>
> * At runtime: even knowing, at compile time, that x.y.z.Event is an
> event, at runtime a user may assert p.q.r.AnotherClass into working
> memory. Now, is p.q.r.AnotherClass an event or not? We need to determine
> that at the time the first instance of p.q.r.AnotherClass is asserted
> into the working memory. At this time, in runtime, we create an
> ObjectTypeNode for this fact class that previously was not known by the
> engine. A few options on how to determine that were discussed here:
>
> 1. Mandate all classes that are events implement an "Event" interface. I
> don't like this solution, as mentioned in a previous e-mail, because it
> breaks the Drools paradigm of working with user defined domain models,
> without contaminating them with drools specific code. Although, by your
> comments, seems that this would be an acceptable solution.
>
> 2. Create a separate API (something like "session.insertEvent()") to
> insert events into the working memory. This would also "solve" the
problem,
> but:
> * "What happens if a user uses this API to insert a class that was not
> declared as event at compile time?". From a technical perspective, this will
> lead to unpredictable behavior and possibly to inconsistencies in the
> reasoning algorithm, specially because events do not need shadow facts (they
> are supposed to be immutable).
> * "What happens if a user uses the regular 'session.insert()' API for
a
> class that was declared as an event at compile time?". Same as above with
> the additional problem that the user may try to call update() or retract()
> for that given fact, what is not allowed for events. Again, unpredictable
> behavior.
> My worry is that the only solution for the above 2 issues would be to
> implement a verification routine that would validate if a fact asserted as
> event is indeed an event according to what was declared at compile time, and
> vice-versa. Note though, that this validation procedure would be basically
> the same required for solution number 3 bellow, but would have to be
> executed at every insert()/insertEvent() call, making it more costly than
> the completely automated decision.
>
> 3. Implementing an automated decision procedure, analyzing the class
> hierarchy of the inserted fact, every time a fact of a previously unknown
> class is inserted into working memory. Due to the problems presented in the
> previous solutions, this is still my preferred approach. Its main drawback
> is the class hierarchy analysis that is not simple to do and at the same
> time is a bit heavy, but would happen only when the first fact of a
> previously unknown class is inserted into working memory.
>
> So, we can probably implement solution (1) and (2) as options, but
> at this time, I can't see how to avoid implementing support for (3). But
> having (3), is it worth to have (1) and/or (2) too, or would it only confuse
> users?
>
> Thanks all for all the feedback so far.
>
> []s
> Edson
>
> 2007/11/12, Anstis, Michael (M.) < manstis1(a)ford.com>:
> >
> > Hi Felipe,
> >
> > I recall Edson saying that "Event" classes need to be ascertained at
> > (RETE) compilation time - which, I think, rules out the API addition. I
> > was hoping Edson, time permitting, would explain how
> > declarative (fact-centric class) imports currently work to generate an
> > ObjectTypeNode and therefore to understand how his proposal to create cached
> > ObjectTypeConf instances for Event-centric classes compares. My reasoning
> > being that if the process is similar the new event stuff should be no
> > different; simply having two ObjectTypeNodes - one for Events and another
> > for Facts. See attached.
> >
> > It's quite possible our exchanges have given Edson time to come to his
> > own conclusion and the solution is now being coded!
> >
> > With kind regards,
> >
> > Mike
> >
> > ------------------------------
> > *From:* rules-dev-bounces(a)lists.jboss.org [mailto:
> > rules-dev-bounces(a)lists.jboss.org] *On Behalf Of *Felipe Piccolini
> > *Sent:* 12 November 2007 13:25
> > *To:* Rules Dev List
> > *Subject:* Re: [rules-dev] Determining if a class is an event or not
> >
> > Well,
> > IMHO for the experience I have I suggest to implement both
> > solutions:
> > -an API insertEvet() so the user can implement the mechanism to manage
> >
> > their rules knowing when a fact is an event or not.
> > -an Interface Event so when the user cant manage the flow asserting
> > facts, when
> > he cant know when a fact is or not an event, then maybe he can wrap
> > some facts on this
> > interface and the API insert() internaly can check if the fact is an
> > event or not and call insertEvent if
> > necesary.
> >
> > :)
> >
> > On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:
> >
> > Here's my 2 cents - as a non-contributor to Drools codebase ;-)
> >
> > You could add insertEventFactTypeThingie to the API? Then you need
> > just
> > check that the class has been declared as an event in the DRL similar
> > to
> > what must already happen for normal DRL imports. I personally don't
> > have
> > issue with implementing a marker interface (this is what frameworks
> > like
> > Hibernate, EJB3 and Spring etc have been imposing for years). What
> > "wiring"
> > does the POJO need to become an Event for use in Drools? Are you
> > trying to
> > internalise too much at the risk of making the event mechanism
> > inflexible?
> >
> > Cheers,
> >
> > Mike
> >
> > -----Original Message-----
> > From: rules-dev-bounces(a)lists.jboss.org
> > [mailto:rules-dev-bounces@lists.jboss.org
> > <rules-dev-bounces(a)lists.jboss.org>] On Behalf Of Matthias
> > Sent: 08 November 2007 13:09
> > To: rules-dev(a)lists.jboss.org
> > Subject: Re: [rules-dev] Determining if a class is an event or not
> >
> > Edson Tirelli <tirelli <at> post.com> writes:
> >
> >
> >
> > All, I reached a point where I need to make a design decision and
> >
> > would
> > like your opinion about it. Imagine the following scenario: A user
> > has a
> > domain model like this:package a.b.c
> >
> > ;public interface Event { ... }package x.y.z;public class MyEvent
> >
> > implements
> > a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r
> > ;import
> > event
> > a.b.c.*; rule Xwhen
> >
> > Event( ... )then ...end So, it is clear that a.b.c.Eventshould
> >
> > be
> > handled as an event by the engine. At runtime, the user asserts an
> > object
> > of
> > the class x.y.z.MyEvent into the working memory. Seems clear to me
> > (and
> > probably
> > to the user) that MyEvent should be handled as an event, since by DRL
> > semantics,
> >
> > a.b.c.* are all events, and by OO class hierarchy concept, since
> >
> > a.b.c.Event
> > is an event, x.y.z.MyEvent is an event too. My question is: how the
> > engine
> > knows that MyEvent is an event, since it only has the x.y.z.MyEvent
> >
> > class as input? The only answer I have is that when the first
> > MyEvent
> >
> > instance is asserted into the working memory, we must get the class
> > name and
> > iterate over all event import declarations checking for a match. In
> > case no
> > one
> > is found, we need to repeat the process for each interface and each
> > class up
> > in
> > the MyEvent hierarchy. Once this process is complete, we cache the
> > results
> > in
> > the ObjectTypeConf.
> >
> > This may be a quite heavy process to be executed each time a fact
> > of a
> >
> > different class is asserted in the working memory for the first time,
> > but I
> > can't think a different user-friendly way to solve the question.
> >
> > The alternatives would be intrusive, IMO, breaking the drools
> > premise
> >
> > to
> > work with user-defined POJOs as facts: use anotations to annotate
> > classes
> > that
> > are events, or mandate users implement a specific interface for
> > events.
> >
> > Any better idea? []s Edson -- Edson Tirelli Software
> >
> > Engineer
> > - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
> > 9287-5646
> >
> > JBoss, a division of Red Hat <at> www.jboss.com
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev <at> lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
> > Edson,
> >
> > I got your striving not to mandate users implement a specific
> > interface for
> > events. However, why not at least introducing an empty event interface
> > (i.e.
> > a
> > marker interface, similar to the Serializable interface in Java) the
> > user-defined event class(es) have to implement? This way, when
> > inserting a
> > MyEvent instance, you can simply check whether it implements the event
> >
> > interface
> > (by means of 'instanceof'). Moreover, while parsing the import
> > statements of
> > a
> > rule file, it enables you to double-check whether all the "event
> > imports"
> > really
> > refer to classes implementing the (empty) event interface.
> > In this regard, for me another question raises: Without making any
> > restrictions
> > on the structure for a user defined event class, how do you make sure
> > it has
> > all
> > the required attributes of an event (which in my opinion must be a
> > timestamp,
> > at least) and how do you access them (necessary for temporal
> > relationships)?
> > Having said this, in my opinion defining an empty event interface may
> > not be
> > sufficient; in addition, it must force the user to implement a method
> > returning
> > the event's occurrence date (i.e. the timestamp) at least... Or how
> > would
> > you
> > handle this issue?
> >
> > Matthias
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
> > *Felipe Piccolini M.*
> > felipe.piccolini(a)bluesoft.cl
> >
> >
> >
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
>
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> *Felipe Piccolini M.*
> felipe.piccolini(a)bluesoft.cl
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
6020
days inactive
6026
days old
18 comments
4 participants
participants (4)
-
Anstis, Michael (M.) -
Edson Tirelli -
Felipe Piccolini -
Matthias