Looks like we are getting into discussion of what is SOA again... Here are my -----1:
1) The focus of SO is primarily on ... services! Interfaces is only communication mechanisms serving the purposes of services IF programmers do not see further than interfaces, it does not mean there is nothing. Other IT roles can and have to see behind the interfaces 2) For all intents and purposes of PROGRAMMERS, the interfaces are the services. All CONSUMERS are interested in business functionality and Real World Effects provided by the service body 3) SOA and, especially, SO is not about HOW but about WHAT, WHY and WHO. Consumers do not care how a service, i.e. service body, is implemented, they only care about WHAT the service does and have to decide WHY they need this service. 4) from an SO perspective, there is not much more to a service INVOCATION than its interface. When you bring your favorite <SPAN id="misspell-2" class="mark" >AWM</SPAN> 3-3.<SPAN id="misspell-3" class="mark" >indd</SPAN>Hawaiianshirtto the laundry, you do not care if there is a regular or revolving door in the shop, you only care whether the laundry uses bleach or color-saving stuff, how they do washing - it does not matter. The business function in this case is cleaning colorful cloth (not just cleaning). >From an SO perspective, interface is the servant of the business >functionality. We can twist interfaces in any way w/o changing business >functions and RWE. In particular, a service may have as many interfaces as >needed; the interfaces may be communication channel dependent, consumer >audience dependent, automated or manual - this does not matter, they lead to >the same business functions and RWE 5) though the principles are different, a service orientation can effectively use EDA principles for its purposes, opposite is not 100% true - Michael ----- Original Message ---- From: Rob Eamon <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, October 16, 2008 4:49:44 PM Subject: [service-orientated-architecture] Re: van Hoof on EDA & SOA +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 service-orientated- architecture@ yahoogroups. com, 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 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
