BibSonomy ::  user :: cschie ::

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).

The success of Service-Oriented Architecture (SOA) has created the foundation for information and service sharing across application and organizational boundaries. Through the use of SOA, organizations are demanding solutions that provide vast scalability, increased reusability of business services, and greater efficiency of computing resources. More importantly, organizations need agile architectures that can adapt to rapidly changing business requirements without the long development cycles that are typically associated with these efforts. Event-Driven Architecture (EDA) has emerged to provide more sophisticated capabilities that address these dynamic environments. EDA enables business agility by empowering software engineers with complex processing techniques to develop substantial functionality in days or weeks rather than months or years. As a result, EDA is positioned to enhance the business value of SOA. The purpose of this white paper is to describe the approach employed to overcome the significant technical challenges required to design a dynamic grid computing architecture for a US government program. The program required optimization of the overall business process while maximizing scalability to support dramatic increases in throughput. To realize this goal, an architecture was developed to support the dynamic placement and removal of business services across the enterprise.

For those unfamiliar with business-driven architecture, I believe the most viable, agile architectures will be comprised of a blend of architecture strategies, including (but not limited to) service-oriented architecture, event-driven architecture, process-based architecture, federated information, enterprise integration and open source adoption.

This is EDA! Model your business events right and have their software representations travel in real-time through a global (enterprise wide) data space (call it an ESB), then you are offering your business huge opportunities. Think of connecting your global data space with those controlled by other enterprises: your fantasy is the limit.

EDA is more a manifestation of finite state machines going all the way back to Alan Turing. Old_State + Event = Some_Action + New_State. It is the simplest, yet most powerful way to design robust systems. I only wish more people would give it due consideration. A very old implementation example is I/O interrupts (hardware events) for asynchronous I/O - real time event handling which enabled multitasking operating systems. Many want to use web services for everything now and at times it is hard to convince people that other messaging schemes and standards are a better fit for some problems.

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!