More on actions as part of event processing

The recent Blog posting by Matt Rothera from Apama has argued that actions are fundemental parts of CEP, and added two reasons: avoiding latecny and providing seamless view by the user. Both of these claims are valid, the question is that makes the "action" part - an integral part of event ptoceding or not. What I stated in a past posting is that there are two types of actions - those which are done internally inside the "event processing network", and those that are done in the outside universe, and those, architectually are part of consumers and not of the event processing network. This is still valid, if the action is a "buy" or "sell" it is executed inside some trading system, and not in the event processing system, the event processing system can, at most, make a decision (or recommendation, depending on the type of application). This leads to an observation on packaging - if the event processing product is a "stand-alone" then it probably needs additional capabilities that are not pure event processing in nature, however, then the integration effort of these products may be high in some cases. I also stated in a a past posting that event processing is part of a bigger picture, thus, it needs to be nicely integrated inside a bigger whole - e.g. an application integration middleware from the run-time aspects, and then the latency issues are solved, since everything is using the same infrastructure, and QoS properties can apply to the entire application. It should also be nicely integrated from modeling, tooling, and interface aspects, thus a customer will be able to express E2E application.

My main claim is that in many cases - event processing capture part but not whole of an applicaton, and thus we need to look anyway on the bigger picture anyway, however, it is not realistic to develop event processing products into an entire middleware...