-1. We've travelled this road before. EDA is not an implementation approach, IMO. A melding of SOA and EDA in an architecture definition doesn't render EDA an implementation detail. Event analysis at the BA level can be very useful. The services can definitely provide additional context/boundaries--but so too does a BA that uses some functional segmentation other than SO. Identifying services can help identify important events. Identifying important events can help identify services.
-Rob --- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > I'm not sure that it makes it easier if you think about it being about > "just subscribe" from a business perspective an Event isn't just > something that "happens" its something that _must_ be reacted to. > This puts a question of non-repudiation into the mix which doesn't > exactly make it all easier. > > For me EDA is just ONE of the potential implementation approaches for > a set of business services and is one approach for the Execution > Context implementation of the OASIS SOA RM. EDA can work at the > business level but its the organisational boundaries (the services) > that represent the producers and consumers of those events, without > those organisational bounds the events have no management base which > is a bad thing. > > Of course this could also be one of those T-SOA, B-SOA and T-EDA and > B-EDA discussion problems. > > Steve
