T he enterprise service bus (ESB) is a hot topic today. Many vendors are
either building new products in this category or dressing up their
existing products to pitch as ESBs. However, there is no clearly
accepted definition of what an ESB is, what its architecture should be,
or what its programming paradigm should be. Definitions range from
saying that it is nothing and wholly unneeded to saying it is everything
and has all the capabi- ties of a full integration suite with built-in
orchestration, data aggregation, and web services management
capabilities. Architectures range from being embedded in the clients and
endpoints to being a central intermediary to being a decentralized
intermediary. Progr- ming paradigms for the ESB range from writing Java
to being completely configurati- driven and pliable with graphical
interfaces. BEA Systems, the original creator of what is now the Oracle
Service Bus, did not dress up one of its existing products and pitch it
as an ESB. It built an ESB from scratch (first introduced in the summer
of 2005), with a razor-sharp focus on where it is positioned as a
component in an end-to-end service-oriented architecture (SOA). It
complements a business process management or orchestration service, but
serves a different and distinct role. Much of SOA is about
componentization, interconnectivity, and reuse.