+1 on the EDA != SOA 2.0.
-1 on the 100 times deeper and wider. SO principles are not that
complex. The focus of SO is primarily on the interfaces. A service is
represented by its interface(s). For all intents and purposes, the
interfaces are the service. Since SO does not care how a service is
implemented ("a service implementation has an architecture of its
own"), from an SO perspective, there is not much more to a service
than its interface (add in some metadata to get the rest).
-1 on the EDA subsumed by SOA. A BA, EA or AA might apply both SO and
ED principles. EDA is not an implementation detail.
-Rob
--- In [email protected], Michael
Poulin <[EMAIL PROTECTED]> wrote:
>
> 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
