Detection Oriented Event Processing applications want to locate interesting information in a flow of data. Operations Oriented Event Processing applications want to take an action (which involves making decisions) based on incoming events.
This classification does not seem to be mutually exclusive, there are actually systems that locate interesting information in a flow of data, and after finding this interesting information are taking actions, which involves making decisions, based on that detection. Hans is right that these are two different things, one deals with the detection, the other deals with the action, and decision around the action.
Getting this classification further, let's look at two different issues: first -- what does the event processing system do (the "detection oriented") , and what are the results of the event processing system are used for (the "operation oriented").
Looking at the first aspect -- an event processing system can just filter and route event, it can also transform events (translate, enrich, aggregate etc...), and create derived events, it can detect predefined patterns, and it can detect patterns on the fly based on some reasoning, it can do part of these things, or all of them together, so an event processing platform is actually a tool box of all the above.
The event is then consumed by some consumer -- person, dashboard, system, and is (hopefully) used for something -- and this is the second aspect -- it may be used just for notification to a person, and what the person does or does not do is beyond the scope of the system, it can observe something and update a dashboard, it can diagnose something, it can do some real-time action based on decision, either in reactive mode or proactive mode (to mitigate some predicted state). This classification is based on a work we have done in IBM a few years ago by looking at applications in many industries, I have described this work in the past.
These two parts are typically decoupled. The event processing system gets events from some event producers, do some processing with it, and produce some events to the event consumers. There are certain set of techniques to do all these types of processing. The second type is done on what is called in the event processing architecture the event consumer. It gets event from an event processing system (or directly from an event producer if no processing is needed) and decides what do with it, the decision itself may apply business rules, and/or some quantitative analytic tools -- optimizers, simulators etc..., the decision can be totally automated ("autonomic"), semi-automated ("decision support system") or completely manual.
In essence, there are more and more systems that have complexity in both parts, thus the tool box to build this entire system is more extended, and while the execution is decoupled, the logic may be viewed in integrative way to build "decision processing network" in which "event processing network" is a subset, but it also includes business rules and quantitative analytics (and maybe some decision visualization tools).
I'll write more in the future abut the notion of "decision agents", introduced by James Taylor. This term reflect the atom of processing in both of the types that Hans is mentioning, however, in each of these type the agents are doing different things. I have mainly concentrated so far on the "event processing agents" type of processing in this Blog, but needs also to pay some attention to the other types of decision agents as well...
More - Later.