vincent
10-08-2008 08:13 PM
One of the more obvious up-and-coming IT “best practices” is the area of “decision management” - as evangelised by James Taylor at Smart Enough Systems - which postulates that separating and managing decisions is as important as managing business processes. In a “conventional event processing” or synchronous SOA world, this means separate “decision services” invoked to make important decisions during automated processes, or prior to BPMN flow branches - with said decision services defined through entities like declarative business rules, decision tables, or outputs from predictive analytic models. But in an asynchronous EDA or complex event processing world, are “decision services” still valid?
Well, if you already have SOA services defined of any kind, including decision services, then a CEP system can of course invoke / utilize / exploit said services, for example based on the detection of complex events. But in the context of continuous event monitoring, where decisions are embedded along with data and trending statistics, it may not make sense to rely on external (and sometimes relatively high-latency) distributed decision services - especially when the decisions are closely related to the event processing. This means that instead of “decision services” we are talking about event processing elements that embed decisions - and ideally, managed decisions. So instead of “decision services” we can use the term event processing “decision elements”, or in a distributed CEP system, “decision agents”.
From a technology perspective, decision services and decision agents can share many components and ideas - business rules management and business user interface (for business control of the decisions), production rules engine (for efficient execution of declarative rule statements), etc etc. The difference is basicly between synchronous parameterised decision services versus asynchronous event-driven decision agents.
On the topic of the “analytical models” being used to define rules or rule parameters, these can be used to input production rules into a CEP-based “decision agent” just as well as a (say, web services) “decision service”. The main interesting delta here is the middle ground of “operational intelligence” as afforded by CEP systems with their event stores in-situ, continuously running “process refinement” rules as events occur (with such “process refinement” rules being “metarules”, predictive analytics expert systems, advanced statistical trend functions, etc). An obvious example here would be the use of sophisticated analytical functions such as TIBCO S+ functions within a “decision monitoring agent” that updates the decision agent rules (and rule parameters) in real-time.
Notes:
Although obviously one can consider
TIBCO BusinessEvents as a source for decision agents and decision monitoring agents, you can also consider the “synchronous service invocation” pattern as a subset of “asynchronous agent invocation”. Which means that TIBCO BusinessEvents is equally adept running as a conventional decision service, for example to do business rule execution in a
TIBCO BusinessWorks application (a relatively common use case).
Source...
10-09-2008
