Hello From the IBM Hursley Lab in UK, in the picture you can see the historical building known as "Hursley House" where customers' meetings are being held, where I spent most day today...
In previous posts I have argued for the need for a specialized event processing language since the functions of event processing are specialized, and on the other hand in another posts I have argued for event processing being part of a bigger whole - which argues for more general programming language that can express the "bigger whole". This is clearly a trade-off here.
What can be done to "have one's cake and eat it too", have the specialized language but also remain within the more general framework -
How this can be achieved - some ideas:
- Have a unified meta-model that can generate multiple lower language languages
- Have an embedded EP language inside regular programming language the way that are embedded SQL work
- More ideas ?
This is not just an event processing discussion but leads to larger discussion about specialized vs. generic tools, and the trade-off involved.
1 comment:
Event processing has a few interesting characteristics:
1. You have to discover that an event happened (perhaps by observing several proto-events in some sort of pattern)
2. You have to tell something about it.
3. You may want to do something about it.
At a high level, end-to-end event processing will cover areas beyond the control of any one organization , so having one big mondo code generator is out of the question. Perhaps a unified event extension for UML that will aid in describing an overall architecture, with pointers to underlying systems and modules.
Observing proto-events will happen in data stores and streams that already exist, so we need to think about extensions to existing languages (SQL, XPath, XQuery, etc.)
Telling someone about an event or proto-event will likely leverage queues, SOAP, REST, etc.
Doing something about an event requires processing, and there is a lot of convergence on BPEL and rules.
I could see where an organization may share a community maintained unified UML picture, where each member agency (think about DHS) takes this picture and identifies their systems and messages underneath.
The point is that creating a large event processing organism requires a lot of social/org agreements, and a unified picture is required to maintain the agreement. This picture can then be extended to include subsets of systems and messages, with alignment around interfaces and message structures.
Post a Comment