On 01/04/2008, Rob Eamon <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> We agree on the point about there not being a difference between
> event and non-event service invocation. From the service perspective,
> they look the same.
>
> But EDA isn't about services. It is about events, producers and
> consumers--which may happen to be services.
True enough, but I'd argue that EDA is a technical implementation
approach (like REST or T-SOA) in which the producers and consumers are
(from a B-SOA perspective) always services.
>
> And EDA isn't a technology approach. It's an architectural view where
> events are identified first, producers and consumers second.
Which is where to me it struggles at a business modelling level as you
get disjointed entities and potentially ruinous levels of abstraction.
The easiest way (for me) to do a decent EDA was to concentrate first
on the services (which gave the bounds) then on the events they
emitted or received and then onto the logical definition of how they
would work.
Starting with events would have been a struggle on a couple of
projects I worked on because across an enterprise the number of events
is very high and they have massively varying degrees of importance and
granularity, an event model didn't help in representing those
elements, a Business Service model did.
> An SO
> view does the opposite--services first, service interactions second
> (which are typically not events) events *maybe* third if explicitly
> examined at all. For clarification, I do not subscribe to the ZT view
> that all service interactions are based on events. "Order pencils" is
> not an event. "Order placed" is. Events generally are past actions
> ("significant change in state"), not requests for action, though in
> implementation, requests may look exactly like events from a
> technical perspective.
>
> I feel that both SOA and EDA approaches are important in creating a
> robust architecture. In an SO-only analysis for the insurance
> example, who would've thought of the car as a service? By taking a
> critical look at events, additional services or other components may
> be identified.
I don't disagree that some people wouldn't have thought of the Car as
a service, but that is partially that most people focus on the server
side elements only and don't include the non-server services or
external actors, which is (IMO) wrong.
>
> An architecture (business, enterprise, etc.) can follow both SOA and
> EDA (and other) principles. That's another reason why I never call
> anything an "SOA" because that isn't all that it is.
That's a long list you have there :) I agree that a fully fledged
architecture from business through to solutions will have multiple
different architectural styles, where I think that Business based SOA
comes in is that it provides a consistent framework in which those
varying pieces can collaborate.
>
> -Rob
Steve
>
> --- In [email protected], "Steve Jones"
> <[EMAIL PROTECTED]> wrote:
> >
> > 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
>
>
