[rules-users] Inferencing

Pavel Tavoda pavel.tavoda at gmail.com
Mon Mar 8 12:21:44 EST 2010


Yes you are right but that should be a hidden detail like asynchronous
connect is internally synchronous because you are waiting for
confirmation packet (but not response) ;-).

No way to implement execution without changing "global" state - am I
right? BTW I implemented for one small subproject (IRC bot) mechanism
where I listen to all new memory inserts and repeat them at beginning
of next stateless session with new KnowledgeBase. Very simple and
straightforward just 20 lines of code because I don't have to
serialize it just keep in memory for next run.

Pavel

2010/3/8 Edson Tirelli <ed.tirelli at gmail.com>:
>
>     Interesting analogy, but careful here:
>
> "Statefull is just series of stateless session where you transfer state from
> one session to another."
>
>     Not sure what lead you to think that way, but it is actually the
> opposite, and trying to explain that will make things REALLY confusing for
> some. So, I would recommend anyone not interested in knowing internal
> details to **stop reading here**!
>
>     Ok, if you are still reading, then I will try to explain in the simplest
> way I can: "there is no such thing as stateless session in Drools
> internals". Deep in drools internals, there is only stateful working memory,
> that is exposed to the user in 2 different ways: a properly stateful
> session, that allows users to manage the state, and a helper object that we
> call "staless session". This helper staless session object, among other
> things, simply holds a reference to the kbase and when the execute(...)
> method is called, internally it creates a stateful session, inserts the
> facts, fire the rules and disposes the session automatically. There are a
> bunch of other helper mechanisms there, but the essence is just that:
> simplify the use of stateful sessions for stateless scenarios.
>
>     Edson
>
> 2010/3/8 Pavel Tavoda <pavel.tavoda at gmail.com>
>>
>> It's like synchronous vs. asynchronous communication. In reality it's
>> always asynchronous but from top view it appear synchronous.
>> Similar to stateless vs. statefull. Statefull is just series of
>> stateless session where you transfer state from one session to
>> another. Look for Drools statefull persistency. In reality it is
>> series of stateless sessions where you store status from one session
>> result and use it as start for another session plus some new changes.
>> This is my point of view of difference between stateless/statefull
>> session specially how Drools make it.
>>
>> Regards
>>
>> Pavel
>>
>> On Mon, Mar 8, 2010 at 4:23 PM, Tim de Jager <tim.dejager at student.hu.nl>
>> wrote:
>> >
>> > Hi everybody,
>> >
>> > I'm currently doing my bachelor thesis on Rule engines. This includes
>> > comapring different Rule engine products. I have set up a small Java
>> > program
>> > (Conway's game of life) and I'm writing the 'engine' in different Rule
>> > engines, while keeping the same GUI,CellGrid etc. I have already made a
>> > Drools based engine.
>> >
>> > I have been studying the Rule engine subject for somewhat more then a
>> > month
>> > now. And I'm currently seeing two different developments namely the use
>> > of
>> > an inference engine and the generation of embedded code instead (Take,
>> > Visual Rules etc.)  I can see some of the pro's and cons with both
>> > paradigms. But I'm wondering what opinion some of you guys have on the
>> > subject.
>> >
>> > I can see that without inferencing  it is very hard (or even impossible)
>> > to
>> > keep a statefull session inside the rule engine, haven't seen a
>> > non-inferencing rule engine which does offer this possibility. And also
>> > lose
>> > features like TMS. But what would be a concrete example where a
>> > statefull
>> > session is absolutely necessary? Instead of letting the engine reason
>> > over
>> > all the facts in stateless way. And managing conflicts with a ruleflow
>> > (see
>> > Visual Rules for a nice example).
>> >
>> > I'm looking forward to hearing your thoughts.
>> >
>> > Thanks,
>> >
>> > Tim
>> >
>> > P.S I already read two of Mark Proctors blogs on inferencing, but while
>> > enlightening, they didn't supply me with a definitive awnser
>> > --
>> > View this message in context:
>> > http://n3.nabble.com/Inferencing-tp435411p435411.html
>> > Sent from the Drools - User mailing list archive at Nabble.com.
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> --
>  Edson Tirelli
>  JBoss Drools Core Development
>  JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>




More information about the rules-users mailing list