On 02/04/2008, Udi Dahan <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > we used services as the abstract definition of both emitters and receivers > > of events to understand the business context > > > > I've used that model very successfully myself. > > > > However, I'm not sure that I'd say that the same sort of inter-service > communication arises when using business-events or not, in other words, I > wouldn't characterize the choice of EDA as a technological choice. That being > said, events aren't always the best way to model certain inter-service > interactions so I would say that a mixed model often arises. > > > > I would submit that event-based interactions decrease coupling between > services on the time axis and are equal in coupling to regular > request/response interactions on other axes – as such, I suggest the > following guidance: > > > > Between services PREFER event-based interactions over request/response > interactions. >
Not sure about that as there are some elements that are clearly request/response (what is the price) and others which are clearly just submissions (here is your invoice). Horses for courses I'd say would remain the mantra. > > > Interested in hearing your thoughts. > > > > Now, on the example, I would consider Car as being a poor choice for the name > of the service – maybe Traffic would be better, as event called > Accident_Occurred that might include the license plates of all vehicles > involved, only one vehicle for the car crashing into a tree. If there were > further information including if there were casualties, that would valuable > information to the Claims service, especially in terms of priority treatment. > I'd still take Car as the service as it is a self-managed entity. Now if an accident occurs there is nothing that should stop a Car "interacting" with another Car (beyond slamming into them) to obtain more information before submitting it back to the insurance company. The reason for that is that the contract for the insurance company is on the car, not on the general traffic concept, so an insurance company can look out for events sent from their cars rather than having to filter into messages. Steve > > > Thanks, > > > > > -- > > Udi Dahan - The Software Simplist > > > > > > From: service-orientated-architecture@yahoogroups.com [mailto:[EMAIL > PROTECTED] On Behalf Of Steve Jones > Sent: 01 April 2008 12:37 > To: service-orientated-architecture@yahoogroups.com > Subject: Re: [service-orientated-architecture] Re: Erl on SOA 2.0 > > > > > > > > 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 > > > > > > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.519 / Virus Database: 269.22.1/1350 - Release Date: 30/03/2008 > 12:32 > > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.519 / Virus Database: 269.22.1/1350 - Release Date: 30/03/2008 > 12:32 > > > > > > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
