10:13 p.m.
Hi Wolfgang,
Thanks for the feedback. My comments.
2011/7/27 Wolfgang Laun <wolfgang.laun(a)gmail.com>
On 26 July 2011 21:42, Edson Tirelli <ed.tirelli(a)gmail.com>
wrote:
>
> Hi all,
>
> As you all know, we use "entry-points" to represent streams in Drools,
> but in fact, entry points are a much more general abstraction than just
> streams. For instance, they create partitions in the RETE's alpha network,
> they support all Rete concepts like truth maintenance, they share a
> centralized fact handle factory (that is possibly a contention point), etc.
>
> Event Streams in general can have a much more specialized
> implementation. For instance, as events are immutable,
>
"Immutable" certainly not by a Drools definition? Something with
@role(event) is just a fact, and I can modify an event as required by my
application.
Drools (and most CEP products) do not enforce immutability because we are
dealing with "representations of events" and not the events themselves.
Representation of events are usually subject to data enrichment and so it
would not be good to enforce immutability at the engine level. OTOH, the
documentation states (not only for Drools) that event representations should
never be modified (other than data enrichment) since they represent
something that happened and the past can't be changed. In other words, a
voice call event in a telecom system could be enriched by rules by adding
customer name for a given calling number, but the calling number from the
event should never change, nor the timestamp for when the call was placed,
etc. (from now on I will continue to refer to "representations of events"
just as "events").
In such scenarios, TMS for events become just an overhead.
there is no need for truth maintenance;
>
A fact derived from events could be managed by the TMS - why not? Or do you
mean s.th. else?
A fact derived from events exclusively would be an event and again
immutable. If the justification is immutable, there would be no need for
TMS. On the other hand, if a justification contain non-events as part of it,
it could be mutable, and in this case the justified fact should not be
modeled as an event. If it is not an event, TMS should apply. The good thing
about we discussing this is that it made me realize that some users might
not be so strict when modeling their systems, and maybe instead of disabling
TMS for "streams of events", this should be a per object type configuration?
Because of things like the ones above, I was considering creating
an
> explicit concept for streams in Drools. They would be a first class concept
> in the engine and would be handled appropriately. They would be orthogonal
> to entry-points, and be used exclusively for events.
>
It's difficult (for me) to see what a "stream" should imply. Can you
provide a concise definition? A "stream" should be for role event only, and
its facts should be immutable (?) - what else?
Are there any good use cases for these "streams" that cannot be readily
dealt with using events?
Streams, from a user's perspective, are just a sequence of events that are
channeled into the system, exactly like entry-points, but specialized for
events. I am not convinced we should create this concept nor am I convinced
that we should continue using entry points. The use of streams would only
make explicit to users that they are exclusive for events (you can use any
type of facts in entry-points) and the algorithms behind the scene are
exclusive for events (entry points, if used like that, would select
algorithms based on heuristics, transparently to users).
> The other option that we have would be to continue to hide the
> implementation behind the concept of entry-points and to select algorithm
> details by compile time analysis. Although it seems like a simpler solution,
> it has the potential of confusing users
>
Most of the time, the confusion of Drools users stems from the lack of
clear documentation - not from the complexitiy of features.
Touché! :)
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com