On Event Flow and Decoupling
This is a simulation of an anesthesia workstation, it can simulates various cases that creates a flow of events that are flowing inside this configuration, e.g. what happens when there is power failure.
I was recently asked if there is no contradiction between two concepts:
- The decoupling concept, each event processing agent is independent, it subscribes to some event, publishes derived events, and is independent in any other agent, furthermore, it is decoupled and does not know anything about the other agents.
- The Event Flow concept, in which there is explicit modeling of event flows
My answer is that there is not really a contradiction, since these two principles are in two different levels. The decoupling is in the execution level, event processing agents indeed do not need to communicate with one another, since there is no RPC or any other synchronous communication among them. The event flow concept exists in the modeling and management layers. In the modeling layer, there should be a view of the entire "event processing network" to enable that that the orchestra is playing together; in the management level, there should be a possibility to trace back the provenance of a certain decision or action, or trace forward the consequences of any event, however this still does not require to violate the decoupling in the execution layer, that's the beauty of model driven architecture... more - later.
2 comments:
This is illustrated by the example of capital markets. In a big trading environment, there are many services available: routing to various trading exchanges, "crossing", order management, position keeping, trading limit or risk checking, external client connectivity, electronic trade reporting. Each of these is written to be as generic as possible.
Each business unit (trading desk) then wires together the components that they need, maybe combined with their own custom trading engine, creating an event flow. Usually there is no modeling tool here - they simply determine the components that are needed (maybe using Visio) and order them configured to talk to each other.
How to model this invisible event flow when decoupled components publish and subscribe events is really interesting. I been trying to find a good way to do this for long.
As the flows change as components change their pubs and subs, I suppose it need to be based on run-time pub/sub information somehow...
Post a Comment