I'll bite, but I won't call them DSBs. :) This all feels a lot like
Software Fortresses to me. In his book by that name, Roger Sessions
defined it as "a conglomerate of software systems serving a common
purpose and typically owned by a cohesive group of individuals.
These software systems work together in a tight trust relationship to
provide consistent and meaningful functionality to a hostile outside
world." While the term "hostile" may be a bit strong, it is
essentially about establishing ownership domains.
He goes on: "The walls of the fortress has are designed to prevent
any communications from coming into the fortress except through
approved channels. The approved channels are the drawbridges."
So, if you subscribe to this construct, you could easily have several
fortresses within an enterprise, such as along lines of business.
These fortresses thus become domains. If each domain has the
authority to do whatever they want inside their walls (which, by the
purist view of fortresses would be the case), then you could have
several ESBs that exist. An ESB clearly could be the drawbridge for
a fortress, and for a fortress that has many services inside, you
could even have internal ESB usage as well. Certainly, a common
pattern seen in enterprises is to have one (logical) gateway (whether
it's an ESB, XML appliance, whatever) for external consumers, and
another (logical) gateway for internal consumers.
While I'll admit that there are cases where multiple internal
fortresses may make sense (for example, where compliance law mandates
a separation), I tend to prefer more centralized or minimally,
federated approaches. This doesn't prevent an enterprise from having
multiple domains, however, they are not fortresses in the purist
sense. There would still only be a single, logical service bus/
fabric/network, but implemented in a federated fashion. What's
interesting, though, is that the infrastructure to do this federation
is not implemented by ESB technology, it's implemented by TCP/IP and
DNS. If you have multiple domains within your enterprise, each one
of those is going to have its own IPs, such as services.hr.foobar.com
and services.sales.foobar.com. It's the hostname that will get it to
the right "drawbridge." If you're doing registry/repository lookups
to get that endpoint hostname, you may have registry/repository
federation (just as we have with DNS), but not ESB federation.
Pointing to the telco comment, my thoughts when I saw that quote were
simply that whoever that companies was needs some governance around
their technology spending. It doesn't make sense for a company to
have 5 different ESBs, and I assume that they meant 5 ESBs from 5
different vendors. Depending on their operational structure, they
could have 5 installations of one ESB based upon operational
management domains or deployment architecture. Unless they recently
purchased 5 smaller companies, each of which brought their own ESB
with them, someone in IT should have been stepping up and saying,
"we're all looking for the same capabilities, let's buy one rather
than five."
-tb
On Apr 5, 2007, at 7:59 AM, Gervas Douglas wrote:
No, it is not necessarily the favourite acronym of a dyslexic Aston
Martin owner. Here is an extract from an e-mail Miko kindly sent me:
"I'm seeing increased sophistication around lifecycle and federation
issues in Governance and some interesting insights about whether the
Enterprise Service Bus is truly a ubiquitous pattern or whether we are
seeing the "Domain Service Bus" (DSB anyone?) winning the day. I
visited one telco that said, "we like ESBs so much that we have five
different ones!" This of course begs the question — which one is
actually the " Enterprise " Service Bus. The answer? None of them!!!
Five ESB products and no ESB. This is much more common than you would
think. I'm happy to chat about this observation if you're curious."
I guess there is a natural hierarchy of confusion with these buses.
Would someone like to take up Miko´s invitation to chat about DSBs in
this forum?
Gervas
Yahoo! Groups Links
[EMAIL PROTECTED]
