tag:blogger.com,1999:blog-7831813422886730737.post8450892243755431322..comments2023-10-08T10:44:28.524+03:00Comments on Event Processing Thinking: on event processing language and modelingOpher Etzionhttp://www.blogger.com/profile/10791357917675270335noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-7831813422886730737.post-3996734119336824282007-10-18T03:21:00.000+02:002007-10-18T03:21:00.000+02:00Event processing has a few interesting characteris...Event processing has a few interesting characteristics:<BR/>1. You have to discover that an event happened (perhaps by observing several proto-events in some sort of pattern)<BR/>2. You have to tell something about it.<BR/>3. You may want to do something about it.<BR/><BR/>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.<BR/><BR/>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.)<BR/><BR/>Telling someone about an event or proto-event will likely leverage queues, SOAP, REST, etc.<BR/><BR/>Doing something about an event requires processing, and there is a lot of convergence on BPEL and rules.<BR/><BR/>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.<BR/><BR/>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.Anonymoushttps://www.blogger.com/profile/16159576367477007568noreply@blogger.com