> Service-Oriented Architecture
> (SOA) and Event-Driven Architecture (EDA) are two different paradigms
> that address complex integration challenges. How can organizations
> choose the better approach to meet their needs? Actually they don't
> have to choose: an Enterprise Service Bus (ESB) allows for the
> implementation of both the SOA and the EDA concepts.
I suddenly feel like Ron in saying this, but the architecture is
independent of the technology. An ESB can be useful in adopting an
architecture that uses services and events to describe it, but it is
by no means required. Personally, I think an orchestration engine is
far more important to the implementation than an ESB is (although
plenty of ESBs are adding this).
IMO, an event is not the same thing as a service request. Where I
draw the line is that an event is merely a point of knowledge that is
available for others to consume. The publisher of the event has no
implicit or explicit goals, nor does it care if anyone actually
receives it. Service requests, on the other hand, absolutely are an
explicit request of the publisher to have something done by a
provider. This is a fundamental difference. When viewing ESB as a
bridge from JMS to SOAP/HTTP, it does you no good if you accept my
definition. It only does you some good when you're not dealing with
events, but service requests that are sent via a queuing paradigm.
An orchestration engine, on the other hand, is a container for
business logic, specifically process logic. An event can be a
trigger for a state change in many processes, and the next step in
that process is likely to be a service request. This isn't a
bridging scenario, this is logic execution.
-tb
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
