9:26 a.m.
On 27/07/2011 14:13, Edson Tirelli wrote:
Hi Wolfgang,
Thanks for the feedback. My comments.
2011/7/27 Wolfgang Laun <wolfgang.laun(a)gmail.com
<mailto:wolfgang.laun@gmail.com>>
On 26 July 2011 21:42, Edson Tirelli <ed.tirelli(a)gmail.com
<mailto:ed.tirelli@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.
TMS itself is now
disabled by default and only enabled per object type,
per entry point. However there is still some cost involved, but it's
minimal.
ObjectTypeConf typeConf = this.typeConfReg.getObjectTypeConf(
this.entryPoint, object );
if ( logical && !typeConf.isTMSEnabled()) {
enableTMS(object, typeConf);
}
// check if the object already exists in the WM
handle = (InternalFactHandle) this.objectStore.getHandleForObject( object );
So this really is quite minimal. We need to get the typeConf anyway I
think as it contains things like the cache of OTNs. If it's not a
logical insertion and TMS is not enabled we do nothing. I suspecct in
that situation even the FactHandle itself can be delayed until it
reaches the beta network.
In short TMS overhead should not be a consideration in design choices
for streams.
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 <http://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?
This is already done and automatic,
done by leo. You don't pay for TMS
unless you logically insert something.
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).
My personally opinion is much of what you are
suggesting would be good
design for entrypoints. Lazy TMS (already done), delayed FactHandle
creation util beta node (great idea). I suspect we can do a little
refactoring of EntryPoints to push more towards delayed execution at the
Beta level if we look into it. As the FactHandle has a reference to the
EntryPoint that it belongs to, having a FactHandleFactory per EntryPoint
shouldn't be a problem. This is actually realted to Wolfgang's previous
email about facthandle behaviour when used on the correct/incorrect
entry point.
On a separate issue it might be we prefer "streams" as a conceptual
level to allow users to understand different use cases. i.e. a stream
might be specific to a given re-usable named window. Using the term
"entry point" there might field a bit wierd. But I'd rather sort out the
technical implementation first, figure out the use cases and see whether
then users need the additional representation.
Mark
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 <http://www.jboss.com>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev