I agree on the EDA not just being messaging, what I'd say is that from a business SOA perspective there isn't really any difference between an event based interaction and a non-event based interaction. Sometimes you are right that an event based implementation is the right thing. The core in a good SOA organisation is to have the blend of different technology approaches that works for that org and to pick the solutions that deliver the most value.
My 3rd big SOA solution was an EDA implementation, we used services as the abstract definition of both emitters and receivers of events to understand the business context, these were even implemented as services down in the code, but all of the interaction was done via events. So in the model below we'd have put the Car as being a service with a potential to emit certain events and the claim service as being a receptor for those events. This would give both of them capabilities and no direct coupling (i.e. you could have multiple cars and claim services for a given event) but it would still be "SOA" even if implemented as EDA. Steve On 01/04/2008, Rob Eamon <[EMAIL PROTECTED]> wrote: > > +/- 1 > > + on the numbering POV. And on the notion that EDA is something new. > > - on the characterization of EDA. Just as SOA is not simply web > services neither is EDA simply a messaging style. It is architecture > centered around the notion that business-related events are of enough > importance as to be addressed at the architectural level rather than > dealt with as a lower-level technical detail. > > I offer this example. > > A car crashes into a tree. After a time, the driver files a claim > with the insurance company. The company processes the claim and makes > payment. > > Insurance companies have found that the faster that claims are > settled, the lower the payout [editor note: no comment on causality > vs. correlation here]. So the insurance company strives to settle > claims as quickly as possible. > > What is the significant business event here? Is it when the adjuster > is notified by the claims system? Is it when the claim hits the > processing system? Is it when the claim is entered into the claim > system? > > It was when the car hit the tree. Which can, depending upon the > circumstances, be far in advance of any of the other candidate event > points. > > Clearly the technology now exists to do capture that early event > (plug into OnStar and you're set!), but if one thinks of events as > something that is simply on the ESB or handled by MOM, then we miss > things. Event orientation at the higher levels of architecture-- > asking what are the significant business level events--can make just > has much impact as service orientation. > > At least that's the theory! :-) > > -Rob > > >
