I have a simple view of SOA and EDA: SOA is about devolving interfaces management and definition to endpoints. In an SOA, its not my responsibility to understand your interface, its your responsibility to produce an interface that anyone (including me) can handle. So an SOA offers a set of services that have uniform interfaces that can be accessed by anyone. But its still required that a service provider advertises their services and a service consumer explicitly calls those interfaces. So the wiring is not devolved.
In EDA, the model goes a stage further: not only are the interfaces defined, but their is a wider definition (the topic space) which identifies the overall structure of all the interfaces/services/event-types. And in this model, the wiring is devolved - its up to anyone who needs access to information to subscribe themselves to that topic. Of course in order to make this work, the model also needs simplification. SOA is effectively a simplification by forcing everyone to use uniform interfaces. EDA forces an even simpler model - everything must be one-way/event-based and it is up to the event-consumer to understand what to do with that event. On a related topic, I've been involved in an SOA/EDA project and we came across an interesting puzzle/problem with interfacing EDA with complete black-box systems. I wrote about it here: http://pzf.fremantle.org/2008/09/interesting-problem-in-event-driven.html Paul -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
