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@gmail.com>
On Fri, Mar 27, 2009 at 7:23 PM, Greg Barton <greg_barton@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@gmail.com> wrote:

> From: Wolfgang Laun <wolfgang.laun@gmail.com>
> Subject: [rules-users] org.drools.runtime.rule.WorkingMemoryEntryPoint
> To: "Rules Users List" <rules-users@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users



_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
rules-users@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