[rules-users] org.drools.runtime.rule.WorkingMemoryEntryPoint

Edson Tirelli tirelli at post.com
Mon Mar 30 09:50:08 EDT 2009


    Hi Wolfgang,

    The answers so far were all correct. Just to add a bit more, try this:

https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-fusion/html/ch02.html#d0e520

    Feedback most welcome.

    Also, going on into the internals, as Mark mentioned, entry points are
an abstract way of partitioning (or better saying: scoping) parts of your
alpha network. This abstract concept has a few applications in very specific
fields, but the first and more common use is to support streams of events,
as described in the above link.

> So, is there a way of knowing the WMEP thorugh wich a fact has arrived?


    The FactHandle implementation has this information, yes, but it is not
exposed through the interface. I don't think it would be good/safe to expose
it to users, but if you have a compelling use case we may discuss a way to
do that without compromising the consistency/safeness of the engine.

     []s
     Edson

2009/3/27 Wolfgang Laun <wolfgang.laun at gmail.com>

> On Fri, Mar 27, 2009 at 7:23 PM, Greg Barton <greg_barton at yahoo.com>wrote:
>
>>
>> I'm not sure about the rationale of the Drools devs, but I can give an
>> example of that design pattern from another rules package.
>>
>> At my workplace (Southwest Airlines) we use Tibco BusinesEvents, and BE
>> has the concept of Channels with Destinations that produce Events.  A
>> Channel can be mapped to various message producers (we mainly use JMS topics
>> and queues) and our internal event types are mapped to the message types
>> inside the Destination.
>>
>> This design pattern can be useful because often data with the same format
>> can come from different sources, and the application may want to react
>> differently mattering on the source.  Also, there may be reasons you can't
>> or don't want to include that source information in the data itself.
>>
>> For example, my current work deals with the airline's flight schedule, and
>> reacting to daily changes in that schedule.  We get RouteChange messages
>> from various sources. (Sometimes due to a flight cancellation, and other
>> times due to a flight addition.)  We react differently to a RouteChange
>> mattering on the reason, but the reason isn't encapsulated in the message,
>> it's in the source.  Thus it's nice to have multiple WM entry points, as
>> otherwise we'd need yet another translation layer to inject a source marker
>> into our RouteChangeEvent.
>>
>
> This makes sense, and I was thinking that the Entry Point might leave its
> tracks in some org-drools.event.rule.*Event, bu tI couldn't find any
> reference to WorkingMemoryEntryPoint in any of these. So, is there a way of
> knowing the WMEP thorugh wich a fact has arrived?
>
> -W
>
>
>>
>> GreG
>>
>> --- On Fri, 3/27/09, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>>
>> > From: Wolfgang Laun <wolfgang.laun at gmail.com>
>> > Subject: [rules-users] org.drools.runtime.rule.WorkingMemoryEntryPoint
>> > To: "Rules Users List" <rules-users at lists.jboss.org>
>> > Date: Friday, March 27, 2009, 12:26 PM
>> > Where would I find information about the rationale of having
>> > multiple named
>> > WM entry points?
>> >
>> > Thanks
>> > -W
>> > _______________________________________________
>> > 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
>
>


-- 
 Edson Tirelli
 JBoss Drools Core Development
 JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090330/6f380ccb/attachment.html 


More information about the rules-users mailing list