ESB vs SOA
I also would like to add some precisions on the differences between ESB (Enterprise Service Bus)
and SOA. There
is a fundamental difference between EAI (and the web service enabled EAI, a.k.a.
ESB) and SOA. EAI relies on a "common information model", with a
central EAI manager, onto which enterprise systems are bolted via
connectors (be it web services, JCA or anything else). The bus represents both
the common information model and the EAI manager. In an ESB, connected systems are not in control, the EAI manager is.
ESB is not SOA. SOA requires a registry onto
which peers registers and find other peers. In a SOA, every peer is at the same
level, there is no center of control, nothing in the middle, therefore no need
for a common
information model. Peers are not defined by their "contract" but
rather by how they interact with each other (i.e. collaborate via a message
choreography). To answer Collaxa's question, IMHO, Indigo is not an ESB, it
is a true SOA framework, just like TME's GAIA or SUN's
JXTA project. (Please
take a look at figure 7 of the BCM introduction). ESB can be viewed as a very
particular case of SOA, a special kind of fabric if you will, but it is
certainly not the only fabric possible.
Another aspect that few people seem to be grasping at the moment is that for building SOAs
we need the
notion of "service domains" (no, this is not the same thing as
Scopes, since scopes have always a context associated to them). This notion is natural as soon as we
think of a company boundary (which will be its own service domain), but the
concept is also useful at a lower level of granularity. It greatly simplifies
problems like management, security, ... but also offer an extra level of
decoupling. WS-CAF is going a bit in this direction with the concept of
coordination, but it stops short of providing "domain level" logic, it
rather relies on well defined composition of web services packaged in a
"composite application".
