On 23/10/2007, Rob Eamon <[EMAIL PROTECTED]> wrote: > > > > > > > --- 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.
I'd be a bit concerned if an application, plain or otherwise, wasn't part of a business service. Part of the problem is that people don't raise themselves above the technology because "they understand its just going to the Phoenix Application". I've had occasions where when you looked at it from the business perspective and found that actually Phoenix shouldn't be the destination at all but it had become the accepted wisdom of IT that it should. > 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.) At a architecture level it isn't important whether its event or not, but at a design level its true that events aren't everywhere. > > > 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. And on the later I'd disagree. I've never seen a decent business architecture described from an event basis. If its T-SOA v EDA then I agree, but if its B-SOA then I've just never seen an equivalent B-EDA. > > > 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? Again I think this is the difference between implementation and architecture. Service Architecture as a principle lends itself, from experience, to good EDA implementations. Again I think this might be a T-SOA v EDA argument which I would agree with, but I'm talking B-SOA where T-SOA or EDA (or GDA/BP/etc) are implementation choices. > > > 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! :-) Bloody hell my ground state really is grumpy... Steve > > -Rob > >
