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.
2 comments:
HI Opher, blogging seems second nature to you it seems.
I'm not sure I understand what you mean when you say: "RTE applications, in the event processing context, are thus defined as those applications that impact running transaction directly." Especially given your example.
Let's say that an order is being created. An event is generated to signify this. So, in parallel, an event processing engine works consumes and processes this event. Perhaps it detects a situation whereby the order needs to be cancelled so it issues an event to cancel the order. Or if a subsequent event indicates that the order can't be cancelled, this new situation causes a different reaction.
This is pretty BAM-like behaviour to me - the event processor is "observing" the order process. It is working in parallel and not "in-line". The order will complete whether the event processor is there or not.
Did I miss something?
Brian
Real Real Time and RTE
Dear Opher, I 100% agree on your observations about the requirements that have to be satisfied by any system within the real time arena. As you say: "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.”
Based on the same observation, however, I’m not sure it is possible to completely discriminate between RTE and other “hard real time” type of applications.
If you consider a typical hard real time application, this will somehow use a set of watchdogs with the role of triggering a logic that tries to mitigate the “damage inflicted” whenever a time constraint has not been satisfied.
Well, the same paradigm can be applied to several enterprise applications that have to select a proper logic whenever a given time constraint cannot be satisfied.
Whilst this kind of application is quite popular within the finance marketplace (where a SLA that has not been satisfied might cost quite a huge amount of money), the same paradigm is spreading to other marketplaces where, for instance, there is the need to trigger an “escalation” due to a missed reaction within a given time window.
This time-constrained type of logic leads pretty much to the same behavior exposed by a hard real time system populated of watchdogs.
Based on an event driven approach, in fact, the following logic can be implemented quite easily (we have implemented this for several scenarios we have produced in the past):
1) An event is presented to a sink
2) The sink processes the event and starts a timer
3) The timer expires and –accordingly- presents an event to the sink
4) The sink reacts accordingly (the sink can check if something else that was expected has happened, represented as an event).
This is very similar, in terms of logic, to what happens in a hard real time system, the real difference here being the “infrastructure” that can be leveraged and the “repeatable latencies”. Typically, a hard real time system will be implemented on a RTOS that exposes a set of facilities such high resolution timers (usually supported by the proper hardware) whilst a RTE application will be built on top of “general purpose” middleware etc., which can hardly guarantee a “repeatable” latency.
In this respect, when you say that nowadays real time is synonym with “as fast as possible” you are quite right, but this does not necessarily means that the RTE and the hard real time are based on different paradigms. The fact is – RTE, in order to be viable, has to leverage the available infrastructure, which is not as “precise” as the kind of infrastructure that you can find in an environment populated with RTOS etc. This, in several scenarios, can however be justified considering the different type of damages that can be inflicted: to loose money is bad but to loose 200 people on an aircraft is certainly worse. Please accept my apologies for –possibly- oversimplifying the discrimination points, here.
What is Real Time and what is not, then? I would certainly draw a line in the sand, here, by asserting that whatever is not time constraint aware is not Real Time, either. The awareness towards time constraints, however, is not sufficient to identify a Real Time system – unless a reaction can be initiated whenever a time-constraint is not satisfied.
Clearly, if somebody agreed about this distinction, we might then talk about real time systems that guarantees a low latency and real time systems that might not guarantee such short latency.
To end with, I agree that RTE also means “inline” (thank you very much for this very useful distinction between inline and “observation”) and that it has to expose transactional properties.
Next: transactions – an argument we love!
Post a Comment