I am thankful to Jack van Hoof for not calling EDA an SOA 2.0 !... Also, I either misunderstood or disagree with Paul Fremantle on "simple" SOA description. SOA is 100 times deeper and wider than "about devolving interfaces management and definition to endpoints". Those you insist on mentioned simplification take SOA_service = Interface, which is totally wrong in 2008. It was OK before the end of 2006 when a service was taken as just a Web Service.
What uniform form is mentioned? In SOA, as in the market, the service provider wants to sell the service to as many consumers a possible. However, the service provider is NOT responsible for the consumer's decision to buy it: do not like the service, do not take it, VERY simple. One more consideration on the service provider side - the service interface has to be enough complex to handle service changes in the least intrusive manner for the consumer (even if the consumer does not guess about it). So, a simple interface may be just single-time used one... I do not see that EDA goes a bit further than SOA; SOA can easily include EDA as one of the trigger mechanisms for the service invocation. I do agree with Jack - EDA is not about data access, it is about Event description. Messages in the EDA represent one of possible implementation mechanisms, nothing more. AS of understanding service or event information, it is ALWAYS the consumer effort and responsibility to share/understand the semantics of the events and business functionality offered by the provider. Even in the English speaking countries some words have different meanings... This relates to all Service Description, Service Contract, and service interfaces (and message namespaces) - Michael ----- Original Message ---- From: Paul Fremantle <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, October 16, 2008 1:15:34 PM Subject: Re: [service-orientated-architecture] Re: van Hoof on EDA & SOA 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.fremantl e.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.fremantl e.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
