At present, these schemes are exclusively focused on system events and digital-to-digital transformations.
What I'm really interested in is some way of capturing events in the “real world” and transforming them into system events. For example: customer buys product, customer phones helpdesk, customer returns product, customer complains. Passenger passes security check, passenger fails initial security check, passenger falls ill (before take-off), passenger falls ill (midflight).
One way of capturing such real-world events might involve various forms of analog-to-digital event transformation. For example, automatic extraction of events from video (think CCTV in an airport or other transport system) or voice.
Perhaps there is an assumption that these "real-world events" are all captured by some “application” or other. But I want to be able to characterize the event itself, independently of its source or capture. In some cases, there may be some uncertainty associated with a particular source, and I may want more than one system event/message to give me a reasonable level of certainty about the original real-world event.
The Wikipedia article on Complex Event Processing provides a useful example:
'The combination of "blowOutTire", "zeroSpeed" and "driverUnseated" come in a very short period of time (a few seconds) and the car infers that the driver was thrown from the car and announced the "occupantThrown" event.'Presumably the "occupantThrown" event calls for a complex and urgent response. But we don't want to hard-wire the event source/inference to the response. If we separate them (at least in the logical design) then we can innovate both areas independently - we can introduce better and faster and more reliable ways of detecting the "occupantThrown" event, and we can work on better ways of responding to this event. In other words, the "occupantThrown" event has the same meaning/significance, and should trigger the same actions, regardless of how it is detected or inferred.
No comments:
Post a Comment