2008/6/25 Rob Eamon <[EMAIL PROTECTED]>: > --- In service-orientated-architecture@yahoogroups.com, "Steve Jones" > <[EMAIL PROTECTED]> wrote: >> >> In the OASIS SOA RM there is a thing called the "execution context" >> this is the bit that makes the interaction happen, its not that the >> interaction isn't defined but that its specific approach that is >> left for later. > > Good clarification. Much better wording for what I intended to say. > >> This to me means that EDA is effectively an execution context under >> the OASIS SOA RM. > > For SO approaches, that makes perfect sense. A great example of why > SOA and EDA fit naturally together. > >> Being clear here it normally takes around a day to create a specific >> level service model (at least at the outline level) so its not a >> long process ;) > > Getting to that day of discussion takes a bit longer, I imagine. ;-) > >> The reason why I do the "what" bits first is that >> this gives the clearest structure and context, "Who" are really just >> external "What" and then its all about the "Why". Events fit in the >> "Why" but can identify new elements in "What" and "Who" > > I'll have to mull over events being a "why" fully to grasp the > approach. > >> the reason I >> wouldn't analyse them independently as service elements is that they >> are interactional elements so it makes more sense to consider them >> as part of a broad view on interactions where EDA is one of the >> approaches, but at the BA level probably the most important >> interaction style. > > Interesting observation. I wouldn't have thought that event-based > interactions (which are generally of the form "something of interest > just happened") would be the *most* important. Can you elaborate?
The "easy" bits are the "Sales sends data to Finance" but the importance is to understand _why_ that happens, the reason is that there has been a "close" event on a sale and this causes sales to invoke the "send invoice" bit on Finance. This explains what actions within Sales cause the interaction. If however its done as a month end batch process for reporting then its just a case of a standard call rather than an event. The other reason I think events are more important at this level is that when dealing between business domains its not right to think of a standard process model as quite often multiple things can happen as a result of a single service event. So a sale closes and it causes goods to be shipped and the invoice to go out. I'd model this as a line from Sales to Finance and one from Sales to Logistics but note on the line that "why" it is invoked is because of the sales close event. Events indicate something has happened so a service should do something, like informing others or taking the required actions. That is why, for me, events are a great "why". Steve > > -Rob > >
