Good post by Radovan
Janecek, CTO of Systinet, re Enterprise Service Bus and Web Services
Management. We both think "bus" should be changed to
"network". So Radovan uses the term ESN: Enterprise Service Network.
If I were king, would also change "enterprise" to "web",
because Web services are used just as much inter-enterprise (or more the point,
"a web of enterprises") as intra-enterprise. Thus, we should be
talking about a WSN ("Web Services Network") not an ESB. (BTW, I could
live with "Business Service Network", since business is inter- and
intra- neutral, and fits the small-to-medium business market better.) However,
the ESB term has traction and META Group has decided to adopt it, despite its
flaws.
What I disagree with in many debates about Web
services and SOA is the implicit assumption that the choice between "dumb
endpoints and smart network" vs. "smart endpoints and dumb bus
network" is a binary one. This "end to
end" argument has been debated since the dawn of the Internet, and the
reality (as opposed to the theory) is that BOTH the endpoints and the network
need to have some smarts.
I THINK Radovan leans towards this point of view
given the distinction he makes between an ESB and an ESN:
Indeed, the problems of monitoring, state
management, or debugging would be simpler to address with a shared
infrastructure like ESB. ESB can monitor, route, enforce, transform, report,
secure, and orchestrate everything because every single message exchanged
among web services goes via ESB! Unfortunately, you cannot fulfill this
requirement in the real world – so you loose these advantages anyway.
So, yes, in the "ESN", every service (or its hosting environment
like WASP, .NET, etc.) is responsible for many things: it should report
several metrics, it is secured, it does transformations it needs, it routes,
it enforces policies, and so on. Of course, as I mentioned previously, these
services can use other services for specific tasks – registry for
finding other services or policies or other metadata, single sing-on, or even
content router service. Important factor is that services decide to use
other ones on their own. There is nothing like – use the bus otherwise
you cannot play the SOA game.
The first two sections I highlighted suggest that
he agrees that "BOTH the endpoints and the network need to have some
smarts." What concerns me however is the
third highlighted section. I don't believe that the service providers
"decide", I think it is a negotiated decision by the service consumer,
the service provider, and the ESN. For example, the service consumer may
want to use Kerberos tokens for service interactions, but the provider only
supports X.509 certificates. The ESN (or more precisely a Token Security Service
intermediary) could enable a federated interaction without the service provider
ever knowing that the intermediary was there. On the other hand, if both the
consumer and provider can use Kerberos, then there is no intermediary for the
service interactions. So it's not a consumer-makes-right model, or a
provider-makes-right model, its a network-makes-right model. Radovan is
correct to criticize a model that conceptually requires an intermediary
in all cases; but I would criticize his alternative model the conceptually
requires that "services [providers] decide to use other ones on their
own." (I'm assuming that Radovan is referring to service providers in the
section I've quoted.) The right model is one that allows optional
intermediaries, which may be transparent to the consumer, the provider, or both.
This is why I like the SOAP processing model so
much. Its concept of roles and nodes enables one to transcend this ancient (and
false) dichotomy between end-to-end and in-the-network intelligence. SOAP
enables one to define absolute (e.g., ultimateReceiver), relative (e.g., next), or even functional
roles. A functional role is completely independent of node location. That is,
either endpoint (initial sender or ultimate receiver in SOAP terminology) or any
intermediary can "play" a particular functional role. Gudge uses the example
of a "logger" role, soap:role='http://example.org/loggers', for a log header. Any node assigned that role may
process the header. The sender could play the role, or an intermediary, or the
receiver. In fact, the role could be dynamically reassigned to different nodes
by the ESB transparently. Even better, depending on how the log header is
defined, multiple nodes can play a single role, each processing the header and
passing it along.
In fact, this is exactly how WS-Security
(I'm citing a slightly out of date version) works:
As stated, a message MAY have
multiple <wsse:Security> header blocks if they are targeted for separate
recipients. However, only one <wsse:Security> header block MAY omit the S:role
attribute and no two <wsse:Security> header blocks may have the same value for S:role.
Message security information targeted for different recipients MUST appear in
different <wsse:Security> header blocks. The <wsse:Security>
header block without a specified S:role MAY be consumed by anyone, but MUST NOT be
removed prior to the final destination or endpoint.
"Consumed" in this context means
processed. Thus multiple nodes (including intermediaries) could change the
security header as it is routed through the network. For example, as discussed
above, a Token Security Service between enterprises may change from Kerberos to
PKI encryption of the message WITHOUT either endpoint ever knowing such
transformation was done on the fly "in the network".
The concept of functional role completely
demolishes the useless debates about where network processing should be done.
Message SOAP headers can now specify WHO should do the processing regardless of
WHERE they are located. In fact, with SOAP roles and the SOAP processing model,
one can begin thinking in terms of Aspect-Oriented
Networking (a term I just coined), where each aspect of a message
exchange is defined by a role. One might also call this Concern-Based
Protocols, which Radovan has even mentioned in his
blog. So in a properly designed ESB, just as in a properly designed IP network,
some messages will go point-to-point between endpoints without going through any
intermediaries (e.g., in an IP network, two PCs on the same physical Ethernet
LAN) and some will go through multiple intermediaries (e.g., in an IP network, a
PC in a Microsoft campus building in China communicating with a PC in a Sun
campus building in Massachusetts). And the programs on both PCs should never
know the difference.
This is what makes ESB potentially so radically
different from most EAI architectures as implemented: the endpoints should never
know whether or not a ESB product is being used, and should certainly never know
WHICH ESB product is being used, anymore than two network endpoints know whether
routers are being used or which vendor's router is being used.
4:53:19 PM 
