[rules-dev] Determining if a class is an event or not
Felipe Piccolini
felipe.piccolini at bluesoft.cl
Tue Nov 13 10:29:49 EST 2007
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 at 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 at 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 at lists.jboss.org [mailto:rules-dev-
>> bounces at 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 at lists.jboss.org
>>> [mailto:rules-dev-bounces at lists.jboss.org ] On Behalf Of Matthias
>>> Sent: 08 November 2007 13:09
>>> To: rules-dev at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> Felipe Piccolini M.
>> felipe.piccolini at bluesoft.cl
>>
>>
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> Felipe Piccolini M.
> felipe.piccolini at bluesoft.cl
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
Felipe Piccolini M.
felipe.piccolini at bluesoft.cl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20071113/3abc9863/attachment.html
More information about the rules-dev
mailing list