[rules-users] Inferencing

Mon Mar 8 16:30:07 EST 2010

Wolfgang, you've basically described the system I've been working on for two years, the Early Alerts System at Southwest Airlines.  So yes, Tim, there are real world examples. :)  In my case EAS monitors the state of our aircraft fleet (and soon the state of customer bookings) and alerts dispatchers to problems.  The actions of the dispatchers and ground operations personnel feeds back into the system and changes the aircraft state.  

The app was actually designed in a semi stateless manner at first, but it quickly became apparent that the state of all aircraft had to be tracked to reduce rule complexity and increase performance.  Otherwise, every time a significant operation had to be performed, the current state of the aircraft had to be retrieved from external system, which did not scale well at all.  Also the state being stored locally means you can continually update it and write rules that fire off the state of groups of aircraft, which would be even more untenable if handled in a stateless manner. (i.e. when monitoring all aircraft at an airport we'd have to periodically load the state of the entire airport and run rules, when in statefull mode all we have to do is subscribe to the aircraft events, a simpler and less resource intensive process.)

--- On Mon, 3/8/10, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:

> From: Wolfgang Laun <wolfgang.laun at gmail.com>
> Subject: Re: [rules-users] Inferencing
> To: "Rules Users List" <rules-users at lists.jboss.org>
> Date: Monday, March 8, 2010, 1:13 PM
> Delayed modifications of the facts
> database are bound to have an
> impact on the semantics of your rule set (unless, perhaps,
> you are
> writing them anticipating this execution cycle). A stateful
> session
> effects changes immediately, which, in turn, affects the
> facts and the
> agenda immediately. Delaying these changes for the next
> stateless run
> will make rules fire in the current run, which would not do
> so in the
> stateful execution scenario.
> 
> As for the initial question, whether there are real
> applications that
> need stateful session, I'd like to say that there is a set
> of
> applications that need stateful reasoning to be built
> according to the
> (as I call it) Plant Design Pattern. Such an application is
> meant to
> monitor a set of real world objects, with their dynamically
> changing
> states as facts, and while observing incoming state changes
> and
> operator commands. And, the important point is, that firing
> rule will
> cause interaction with the real word.
> 
> -W
> 
> 
> On Mon, Mar 8, 2010 at 6:21 PM, Pavel Tavoda <pavel.tavoda at gmail.com>
> wrote:
> > 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
> >>
> >>
> >
> > _______________________________________________
> > 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
> 