<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 27/07/2011 14:13, Edson Tirelli wrote:
<blockquote
cite="mid:CAD7AJne1x4ruRMzHwV3YsAj5gKhoojZX=i76xbAHNBPy29msMw@mail.gmail.com"
type="cite">
<div><br>
</div>
Hi Wolfgang,<br>
<br>
<div> Thanks for the feedback. My comments.</div>
<div><br>
<div class="gmail_quote">2011/7/27 Wolfgang Laun <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 26 July 2011 21:42, Edson Tirelli <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:ed.tirelli@gmail.com" target="_blank">ed.tirelli@gmail.com</a>></span>
wrote:<br>
</div>
<div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="border-left:1px
solid rgb(204, 204, 204);margin:0pt 0pt 0pt
0.8ex;padding-left:1ex">
<div><br>
</div>
<div> Hi all,</div>
<div><br>
</div>
<div> 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.</div>
<div><br>
</div>
<div> Event Streams in general can have a much more
specialized implementation. For instance, as events
are immutable,</div>
</blockquote>
</div>
<div><br>
"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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div> 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").</div>
<div><br>
</div>
<div> In such scenarios, TMS for events become just an
overhead.</div>
</div>
</div>
</blockquote>
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.<br>
<br>
ObjectTypeConf typeConf = this.typeConfReg.getObjectTypeConf(
this.entryPoint, object );<br>
if ( logical && !typeConf.isTMSEnabled()) {<br>
enableTMS(object, typeConf);<br>
}<br>
// check if the object already exists in the WM<br>
handle = (InternalFactHandle) this.objectStore.getHandleForObject(
object );<br>
<br>
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.<br>
<br>
In short TMS overhead should not be a consideration in design
choices for streams.<br>
<br>
<blockquote
cite="mid:CAD7AJne1x4ruRMzHwV3YsAj5gKhoojZX=i76xbAHNBPy29msMw@mail.gmail.com"
type="cite">
<div>
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="border-left:1px
solid rgb(204, 204, 204);margin:0pt 0pt 0pt
0.8ex;padding-left:1ex">
<div>there is no need for truth maintenance;</div>
</blockquote>
</div>
<div><br>
A fact derived from events could be managed by the TMS -
why not? Or do you mean <a moz-do-not-send="true"
href="http://s.th" target="_blank">s.th</a>. else? <br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div> 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?</div>
</div>
</div>
</blockquote>
This is already done and automatic, done by leo. You don't pay for
TMS unless you logically insert something.<br>
<blockquote
cite="mid:CAD7AJne1x4ruRMzHwV3YsAj5gKhoojZX=i76xbAHNBPy29msMw@mail.gmail.com"
type="cite">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="border-left:1px
solid rgb(204, 204, 204);margin:0pt 0pt 0pt
0.8ex;padding-left:1ex">
<div> 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. </div>
</blockquote>
</div>
<div><br>
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? <br>
<br>
Are there any good use cases for these "streams" that
cannot be readily dealt with using events?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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). <br>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
Mark<br>
<blockquote
cite="mid:CAD7AJne1x4ruRMzHwV3YsAj5gKhoojZX=i76xbAHNBPy29msMw@mail.gmail.com"
type="cite">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="border-left:1px
solid rgb(204, 204, 204);margin:0pt 0pt 0pt
0.8ex;padding-left:1ex">
<div><br>
</div>
<div> 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</div>
</blockquote>
</div>
<div><br>
Most of the time, the confusion of Drools users stems
from the lack of clear documentation - not from the
complexitiy of features. <br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Touché! :)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote">
<div><br>
</div>
</div>
</blockquote>
</div>
-- <br>
Edson Tirelli<br>
JBoss Drools Core Development<br>
JBoss by Red Hat @ <a moz-do-not-send="true"
href="http://www.jboss.com">www.jboss.com</a><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>