Event processing and transactions - real, real time and real time enterprise

One of the common believes about "event driven architectures" are that they are loosely coupled in the sense that the producer, processing and consumer are all distinct, and there are no dependency among them. This is true in some type of applications, but in this short article I would like to discuss another type of event processing applications that turns to become significant, I am using the TLA RTE (Real-Time Enterprise) to classify these type of applications. Since sensitivity to "correct terminology" is one of my known eccentricities, I would say a few words about the "real time" issue, before continuing. The term "real-time" in the "correct" sense denotes - action that has to be completed by a time constraint, types of real-time systems (hard or soft) are determined according to the damage inflicted if the time constraint is not satisfied. However, in the marketing slang, real-time is interpreted as "as fast as possible", which of course is different, and does not necessarily have time constraints, but best effort to act fast. The term "Real Time Enterprise" belongs to the latter interpretation, the use of the term "Real Time" here is loose, and typically says that an enterprise acts to changing conditions fast and not necessarily deterministic, sometimes "real time" is being used to denote "online" to contrast with "batch". One of the properties of RTE is that event processing is done within transactions, as noted before, this may be contrary to some beliefs, however it is very common misconception to look at one type of event processing applications and think that it represents the whole spectrum. Why do we need event processing as part of transactions ? -- take a simple example --- there is a transaction that processes some order, and there is an event that cancels the order, this can be a direct cancellation event, or a derived event, derived from some other event that relates to the customer making the order. The order itself is an atomic transaction (may be a long duration transaction), the event effects the transaction (e.g. cause "rollback" or "compensate") and the transaction effect the event (e.g. if the transaction is in the phase that the order cannot be cancelled, it may cause the event processing part to compensate). Since the event processing part typically does not manage transactions, and the transaction is typically larger than the event processing part, RTE also requires some level of integration between the EP part and the transaction management middleware.
RTE applications, in the event processing context, are thus defined as those applications that impact running transaction directly. Other types of applications that use event processing in observation mode (e.g. BAM) are typically looking at running transaction from the outside, while RTE applications are indeed part of the transaction processing. More on BAM applications and other types - later.