Since my previous post on this topic has triggered some discussion, comments and questions - I am returning to the issue of "event processing and business rules". One observation I got today is that if we'll some of the "event processing typical applications", example: Paul Vincent's post about EDA and CEP in Insurance are considered by the business rule people also as typical applications for business rule engine (and the insurance area has strong presence of business rules). To answer that I'll cite another CEP blogger, whom I don't have the honor to know personally, who used the eternal-wisdom title: When all you have is a hammer everything looks like a nail, while the post talks about SQL, this is true also for business rules. In fact, if some programming tool has enough expressive power, one can, somehow, express everything using this tool, which does not say a lot, since everything can be expressed nicely by a Turing machine (this wikipedia link also points at some freeware implementation of Turing machine, so we have a single programming tool to do everything...). However, there are things that are naturally fit into a certain programming paradigm and things that look rather awkward. Of course, there are some cases in which one can equally implement it within multiple paradigms, this is typically one of two cases - it may be very simple, or there is not (yet) a specific paradigm to express it nicely, so multiple paradigms are awkward in the same way.
It is not surprising that the same phrase about hammer and nails is also going in the opposite directions- I have seen cases where people who had CEP engines, "force" them to do things that are not natural for this paradigm, by creating artificially events and patterns.
And one comment about ECA rules (Event-Condition-Action) --- the contribution of the glorious "active databases" community to the computing industry. Complex Event Processing deals with the E part - taking events, apply some function, and at the end deriving more events. Each derived event that arrive to the "edge of the event processing network", i.e. sent to a consumer, can then conditionally trigger an action. Thus, from architecture point of view, ECA rules are really part of the consumer logic, and not part of the "event processing network". More - later.
4 comments:
From my understanding, the action is anything. It could be more events or non-event related action. Back when ECA was discussed at W3C, there were a variety of examples. If I remember correctly, generating events in the action was covered.
that's doesn't mean ECA isn't on the consumer side, but I don't think ECA prohibits the create of new events. In fact it's rather common to generate events which are sent via messaging bus like IBM MQSeries.
I think I agree with woolfel here Opher...Why do you exclude "constructing a derived event out of a subset of events in an EPA's event history and then emitting the resulting derived event" as a form of action?
Moreover, in fact I would say that the event-condition part should be collapsed in one and call it, for example, coevent (from COmposite event)...Then we would have coevent-action instead of event-condition-action. Let me explain the semantics of coevent-action. An EPA continiuosly receives events (possibly composite) from the environment, let's call the events that an EPA receives from the environment input events, an EPA also continuously emits events to the environment, let's call output events the events that an EPA emits to the environment. Now, let's call the sequence of all the input events and output events received and emitted by an EPA the EPA's event history. Each time an EPA receives a new input event (or emits a new event) it updates its event history by appending the new event to it and then checks if this new event should trigger an action or not. However to decide whether an action is triggered or not the EPA does not only take into account the new event, but its whole current history of events. The EPA encodes its logic by means of a collection of rules that in their left-hand-side they express an event pattern on the EPA's event history and in their right-hand-side specify an action. When the current event history of the EPA matches a pattern of the lhs of one of these rules the action encoded in the rhs of that rule is triggered, this action can be the emission of a derived event constructed out of the events that matched the rule's pattern in the EPA's event history or it can be a transformation of the EPA's event history by acting on the events that matched the rule's pattern, or both. Now if we realize that what the EPA's rules are doing is attempting to find the occurrence of an event pattern inside the EPA's event history we can see that this procedure is in fact akin to the detection of the occurrence of a composite event, albeit restricted to the scope of the EPA's event history, this is the rationale behind the name coevent-action, because the detection of a coevent (i.e. the matching of the lhs of a rule) triggers the corresponding action associated to it (i.e. the rhs of the rule). In the end the main difference between ECA and coevent-action is that the former is fundamentally stateless while the later is stateful by virtue of acting on composite events instead of single events. Another interesting thing is that we code EPAs by using the high level concept of composite event which can be understood by non-programmers.
This is my vision of how the operational semantics of EPAs might be, now, since EPAs do not live at the edge of the network but inside the EPN the special case of ECA that is coevent-action would hapen inside the EPN and not at the edges...
In answer to Woolfel - true, in ECA - an action can do anything, and in particular may emit more events. The distinction between an EPA and an action is that an EPA is "internal" in the sense that its specification is part of the definition of the EPN and "action" is performed by a consumer and its logic is out of the bound of the EPN - why is this distinction important ? causality tracing. I'll have more on causality and lineage in the next post
To patternstorm
An EPA may be in the "middle of the network", i.e. send derived events to other agents only, or it can be at the edge of the network sending event to a consumer - which says that the "coevent" at the edge of the network that triggers the action is actually a result of a path in the network and not of a single EPA. It is cleaner model that way. I'll post more information about my EPN view in the near future.
Post a Comment