--- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > Again this sort of depends whether viewing SOA as an RPC interaction > style or if you view SOA as being about business services and the > interactions that drive them. If its the later then clearly event > based elements are within the scope as an event is just something > that drives a services or is sent from a service with the intention > of completing a goal.
I agree that the interactions between services, be they event based or otherwise, would be within the scope of a service-orientated design. > For me when I look at primarily event based infrastructures I still > look to see what the different services are, their boundaries, their > interactions and their drivers. This gives the structure needed to > really create effective event infrastructures and not just get the > mythical "send it and they will come" idea. My primary rationale for separating service-oriented and event-driven notions is because one doesn't require the other. An event-driven design may or may not have business-level services at the end points-- it might just be a plain ol' application. A service-oriented design might not use event-driven interactions. (I suppose this will now get into what event-driven means, and that's okay I guess.) > This is the challenge at the moment with EDA v T-SOA v REST its > arguing about which wheel is better, rather than rising above it and > working out which wheel works on which car. Vendors increase this > problem as do technologists as we focus on the implementation > details and then turn around surprised when the business still > complains that IT isn't doing what it wants and keeps talking about > technology. I'm not arguing about which wheel is better. I'm saying you can put on an EDA wheel, an SOA wheel, or both or neither on your architecture vehicle. :) EDA can be as business-ish as SOA. > Events are just one type of interaction model and for some cases > they are the best implementation model. Some business events are > best implemented by straight invocations (e.g. Stock arrived in > Warehouse is an event from one perspective but the source and > destination are physically linked so you might as well do it as an > invocation) and some business invocations actually end up being > best implemented via events (e.g. send me the sales data is > implemented as a event that ships information when sales switch to > closed). I've no problem with your examples of events. Some events are distributed synchronously, some are async, some are point-to-point, some are broadcast (these characteristics are implementation details I suppose). My only contention is that event-driven is a separate, distinct and independent principle from service-orientation and that an architecture (be it a business or enterprise or other architecture) can (and should) incorporate both of those notions as well as others. And the resulting architecture shouldn't be called "the SOA" because that label is unnecessarily narrow and incomplete. An architecture might also be "the EDA" but we don't call architectures that, do we? > I know I've said this before on this thread but I'm feeling like > crap today so am even more grumpy than normal. You've made good points. No excess grump detected! :-) -Rob
