Service-oriented architecture has proven to be a boon in the computing world. At its core, SOA provides enterprise patterns for systems development and integration where legacy systems are viewed as discrete business capabilities and packaged as standards-based services interfaces. SOA also typically describes an IT infrastructure that allows different applications to exchange data with one another as they participate within business processes. Over the past few years, SOA has grown almost exponentially in popularity, becoming one way for companies to knit together applications and processes in a flexible, reusable and cost-effective way. SOA separates functions into distinct units, or services, which developers make accessible to users over a network, ideally allowing them to combine and reuse them in the creation of business applications. These services communicate with each other by passing data from one service to another or by coordinating an activity between two or more services.
- leave anything related to transport, communication to other layers- use this revised CEP to express and execute event-relevant logic, the purpose of which is to translate the ambient events into relevant business events- have these business events trigger business processes (however lightweight you want to make them)- have these business processes invoke decision services implemented through decision management to decide what they should be doing at every step- have the business processes invoke action services to execute the actions decided by the decision services- all the while generating business events or ambient events- etc.
The objective of this document(*)
is to provide some rational, structured access to an analysis of cognitive and agent architectures (for
more information on accessing the document, see the Reader's Guide). Twelve architectures have
been used for this preliminary analysis representing a wide range of
current architectures in artificial
intelligence (AI). The aim of the project is to facilitate both
an understanding of current architectures and provide insight to the
development of future, improved intelligent agent architectures.
This work was based on publications from 1992 and before and has not
been authorized by the researchers responsible for particular
architectures (see DISCLAIMER for additional
information).
On Event Processing Agents implies a “new” event processing reference architecture with terms like,
(1) simple event processing agents for filtering and routing,
(2) mediated event processing agents for event enrichment, transformation, validation,
(3) complex event processing agents for pattern detection, and
(4) intelligent event processing agents for prediction, decisions.
Frankly, while I generally agree with the concepts, I think the terms in On Event Processing Agents tend to add to the confusion because these concepts in On Event Processing Agents are following, almost exactly, the same reference architecture (and terms) for MSDF, illustrated again below to aid the reader.
Most BREs today are deployed as “decision services”, and are used in “stateless” transactions to make “decisions” as a part of a business process. A CEP application is instead processing multiple event streams and sources over time, which requires a “stateful” rule service optimized for long running. This is an important distinction, as a stateful BRE for long-running processes needs to have failover support - the ability to cache its working memory for application restarting or distribution. And of course long-running processes need to be very particular over issues like memory handling - no memory leaks allowed!
Multiple channels and types of events…
… executing in multiple Inference Agents (Event Processing Agents on an Event Processing Network)…
… where Events drive Production Rules with associated (shared) data…
… and event patterns (complex events) are derived from the simple events and also drive Production Rules via inferencing…
… to lead to “real-time” decisions.
Confusion about Services Based Architectures [SBA, SOA, EDA, ...] has been created by a number of industry elements. Industry critics like Forrester first used the term Services Based Architecture until 2000 when Gartner came up with their own term Services Oriented Architectures (SOA). Forrester was still using the term SBA in 2002. Gartner next created the term Event Driven Architecture and has now come full circle back to SOA 2.0 (supporting both SOA and EDA like the original SBA).
at the core, enterprise architecture is very simple: it starts with the idea that one should plan technology purchases and development ahead of time and -- here's the important part -- that the business people, not technology people, should determine what is needed (the requirements).
M. LeMay, R. Nelli, G. Gross, and C. Gunter. HICSS '08: Proceedings of the Proceedings of the 41st Annual Hawaii International Conference on System Sciences, page 174. Washington, DC, USA, IEEE Computer Society, (2008)
T. Bucher, R. Fischer, S. Kurpjuweit, and R. Winter. Enterprise Distributed Object Computing Conference Workshops, 2006. EDOCW '06. 10th IEEE International, (October 2006)
B. Schilit, N. Adams, and R. Want. In Proceedings of the Workshop on Mobile Computing Systems and Applications, page 85--90. IEEE Computer Society, (1994)
T. Nguyen, J. Schiefer, and A. Tjoa. DOLAP '05: Proceedings of the 8th ACM international workshop on Data warehousing and OLAP, page 77--86. New York, NY, USA, ACM, (2005)
A. Harter, A. Hopper, P. Steggles, A. Ward, and P. Webster. MobiCom '99: Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking, page 59--68. New York, NY, USA, ACM, (1999)