Event Driven Architecture and Business Rules Management
Published by Rajgo March 1st, 2007 in Business Rules, Rule Engine, BRE, Business Rule Engine, Business Rules Management System, SOA, Complex Event ProcessingJoe Mckendrick asks Is EDA the ‘new’ SOA ?.I was thinking about what SOA is and what is EDA. Now this is what I think.
SOA >> A architectural model where systems are modeled as Service Providers and Service Consumers. Decoupling is provided for because the Service Providers and Service Consumers use the Service Definition as a communication and interaction contract
EDA >> An architectural model where the System broadcasts State changes using Events. Other Systems that are interested in these Events can subscribe to these Events and choose to respond to it. Event Processing becomes complex when you also become interested in identifying new event patterns.
Now , I just do not see what it means to ask, Is EDA the new SOA? As far as I understand, these are 2 different architectural principles, and each has its own application area, sometimes in the same Enterprise system.
I tend to agree with Brenda Michelson, when she says,
EDA is not the next evolution for SOA, but an architecture that can effectively work in conjunction with SOA.
But I am not sure I completely agree with Bates when he says,
Data is static, and queries are dynamic. In event-driven SOA, however, data is constantly on the move.
“The rules that you’re using to monitor the data and take action are fairly static, and it’s the data that’s dynamic. The data is continuously changing. So you have to structure your software to take into account that paradigm shift.
I am not sure that is necessarily correct. You would be interested in not only what these events are telling you today, but also about what they could mean for the business tomorrow.
Now, detecting patterns of events will be based on the rules that you wil apply on those events, and these rules can be pretty dynamic.
Take the example of a Fraud Surveillance application in a Stock Exchange. Here the rules which determine which trade to be flagged with an Alert and which trade to ignore are all pretty dynamic. In one implementation that I was a part of, these rules changed almost everyday.
James Taylor has written when not to confuse routing rules with business rules in a CEP architecture, and I completely agree with him.
I believe that EDA and SOA are complementary, but this whole discussion on Decoupling, Service enablement is not really complete without talking about the Business Decision Architecture and Business Rules Management.



















I think the quote of Brenda Michelson is right.
I recognize a huge business potential of asynchronous, event oriented design. And I believe that EDA by its nature will be the paradigm to realize the ultimate alignment of business processes and the supporting IT-systems. I think that the ultimate layer between our real world events and artificial application constructs will be an EDA. And I recognize the possibilities offered by the current IT-technology evolutions to support this paradigm.
http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html
http://soa-eda.blogspot.com/2006/06/soa-doesnt-add-business-value-but-eda.html