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.
And EDA isn't a technology approach. It's an architectural view where
events are identified first, producers and consumers second. 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.
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.
-Rob
--- 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
