The enterprise service bus (ESB) is a tool that enterprise architects have known about for a long while now. It
is becoming a more important part of SOA as organizations build up more complex application architectures. Not all ESBs are created equal and it seems like no two organizations implement their ESB in just the same way.
As we reflect on the top news in ESBs from 2011, though, it's easy to see that the ESB is not solely associated with SOA, but is associated with EAI designs as well. You can trace the paths of ESB, EAI and SOA through the following news stories from 2011.
SOA analysts Hardy and Vollmer agree that the primary reason for implementing an ESB is for messaging between enterprise systems. Other features in ESBs can be quite helpful, but the messaging is the core function. Yet, the ESB is not strictly necessary for the implementation of an SOA, and a service-oriented architecture based strictly on point-to-point integrations is still an SOA. Still, in practice most large organizations find it necessary to implement the ESB in order to manage the complexity inherent in multiple integrations.
Here we learn that some architects are basing their service integration on the ESB as the hub to their hub-and-spoke architecture and leaving out EAI completely. Others are focusing on EAI architecture and using the ESB as a central message transporter. Either way, it's important to use an ESB built on open standards to maximize the reuse of services both internally and externally.
Site Editor Vaughan traces the history of ESBs, integration middleware, and the message queue from IBM's first MQ message server through today's innovative new ways of integrating increasingly disparate sources of data and content.
SOA governance expert Todd Biske reminds us that the acronym ESB is not synonymous with enterprise application integration (EAI). According to Biske, EAI technology is much older than the ESB and was originally based on point-to-point application integration with pre-SOA applications. Some company's EAI products grew up to find themselves rebranded as ESBs, but the ESB is a fundamentally different approach that is anchored in the modularity of SOA services.
Resident expert Todd Biske discusses the value of an ESB in today's service-oriented enterprise architecture. Biske likens the ESB to a load balancer between service consumers and service providers, similar to the load balancer between Web browsers and Web servers. Biske states that the ESB is best for policy enforcement rather than business logic.