The bit I struggle with Rob of EDA at the BA level is that I've not seen it achieve much, you map out events and say they are important but it always comes down to "who sends" and "who cares" which are the services parts. I think using Event thinking can help in modelling at the BA level as it helps highlight services/domains that have been missed but I'm not sure that in itself it would be sufficient to create a BA.
Steve 2008/6/23 Rob Eamon <[EMAIL PROTECTED]>: > --- In service-orientated-architecture@yahoogroups.com, Michael > Poulin <[EMAIL PROTECTED]> wrote: >> >> Steve Jones wrote: >> >Now I'm not sure about EDA in its own world without an SO world >> >that encapsulates it. >> >> I need more input to discuss this. EDA existed and can exist on its >> own, w/o SOA, right? >> >> Encapsulation in this context means that principles of one are >> included into or among principles of another. In SOA we are talking >> about loosely-coupled service consumer and provider. In EDA they >> may be totally decoupled. > > Event producers and consumers are still coupled. There is no such > thing as components that interact in some way being "totally > decoupled." EDA coupling is not inherently "looser" than SOA coupling. > >> In SOA we are talking about Service Contract, i.e. direct agreement >> between consumer and provider. Implementation of EDA via MOM allows >> for an intermediary which estranges consumers and providers to each >> other. > > An intermediated implementation is not required in EDA, nor is MOM > used only in EDA. Components connected via an intermediary are still > coupled. > >> ESB tries to do the same but I argue that this contradicts SOA >> principles of loose-coupling and reach-ability if the ESB does not >> take a 'service representative role' on itself. > > The ESB is an interface to the service, so yes, it "represents" the > service as all interfaces do. But that doesn't change the nature of > the contract. And it doesn't change the separation of interface and > implementation--as you point out, the call to the intermediary is a > call to the service from the consumer's POV, for all intents and > purposes. > > The argument that the intermediary isn't the one with the contract > and thus may violate the contract is an interesting scenario, and > ultimately needs to be addressed. If a provider exposes an interface > via an intermediary, then that provider (the developers, etc.) should > make sure that the intermediary enforces the provisions of the > contract of that interface. The intermediary is the provider's agent, > or representative, or proxy, etc. and as such must abide by the > provider's (and by extension, the consumer's) needs. > >> >so I'd say that EDA makes >> >sense as an implementation approach for a business service >> >architecture. >> >> Agree but with the condition (mentioned above) > > I disagree. EDA as a style is as applicable as SOA to a BA. I agree > that it typcially will not be *the* style used in a BA, but I argue > that about SOA too. ED approaches can be used at a BA level. They > won't necessarily translate to the technical implementation use of > MOM. > > -Rob > >
