This picture shows static and dynamic flows in an interesting picture I have found in one of the Web albums under "Minneapolis pictures".
In continuation to my previous posting on event flow and decoupling, I would like to discuss the issue of static vs. dynamic event flows.
I already discussed the fact that event processing applications can be of many types, and naturally various types have their own properties.
There are applications whose nature is totally dynamic, such an application is information dissemination to alerts about customer's activities in banking systems. There are many subscribers that can subscribe to multiple type of alerts and change their subscriptions from time to time. In these type of application monitoring the event flow can be done for management purposes of the system, e.g. collection statistics about patterns of use, tracing individual flows for exception handling purposes etc.. However there is no sense of a global event processing network as there are many flow islands that are not related.
On the other hand there are event processing applications in which the flows are relatively static and there are a relatively stable set of event processing agents with relatively stable collection of relationships among them, actually, many of the event processing applications I have encountered are of this type. Example: an event processing application that manages am auction. The flow here is fixed as long as the auction protocol is not changing, thus the collection of event processing agents and their relationships are fixed. Of course, the run-time instances are still dynamic. This is similar to a database schema that may be relatively stable, and the data itself is dynamic.
The flow modeling is helpful for the:
- "software engineering" aspect --- debugging, validation,analysis
- performance aspect --- enable of scale-out by semantic partition, a topic we are working on and I'll discuss in detail in one of the future postings
- management aspect --- provenance, tracing, monitoring