Back to VSLive! San Francisco Show Daily Home
Top 10 ESB Myths
The author sets the record straight on some nagging misconceptions about the enterprise service bus.
by Gordon Van Huizen
February 1, 2005
Note: Gordon Van Huizen is presenting "Top 10 ESB Myths" at Software Architecture Summit in San Francisco, Wednesday, February 9. This content is from that session.
Since Sonic Software delivered the first enterprise service bus (ESB) in March 2002, the term and the concept have become one of the most significant trends in enterprise software architecture, and synonymous with the complementary trends of service-oriented architecture (SOA) and Web services. As with any new concept—especially one with the potential and exposure of ESBs—misconceptions arise about what the technology is and what it's good for. I have gathered several of these nagging misconceptions together and offer a few words of clarity in an effort to set the record straight.
1. ESB is just a new name for EAI. ESBs provide general-purpose connectivity, coordination, mediation, and management for SOA, and can be used for many applications, including enterprise application integration (EAI). "ESB" has become synonymous with "SOA infrastructure" and helps organizations meet their enterprise requirements for this distributed, standards-based connectivity.
2. ESBs compete with J2EE application servers. ESBs complement app servers in an enterprise SOA environment, offering service mediation, intelligent routing, distributed communication, and service management. Application servers continue to host application logic and the "presentation" tier of enterprise applications.
3. I don't need an ESB if I'm using Web services. ESBs extend today's Web services through increased reliability, security, and scalability, in addition to post-deployment flexibility and service management, thereby making it practical to deploy an enterprise SOA that is durable and flexible.
4. An ESB is simply an abstract concept or design pattern. An ESB provides a specific set of capabilities, brought together in a coherent, unified, service-oriented architecture. Additionally, ESBs provide organizations with a common toolset for building and managing enterprise SOAs while leveraging and reinforcing best practices.
5. ESBs are simply message-oriented middleware with a new marketing spin. In addition to their messaging layer (which provides the robust communication backbone essential to an ESB), ESBs contain a distributed services architecture, with the ability to host, configure, mediate, orchestrate, and manage services.
6. ESBs will be obsolete once BPEL and the WS-* standards are complete. BPEL and the WS-* standards will further the interoperability between ESBs and application platforms, but they do not remove the need for service mediation, routing, and management.
7. Microsoft is building an ESB with its Indigo project. Indigo will make it easier to build message-driven applications in .NET, but it doesn't appear to include the configurable intermediaries, dynamic distributed deployment, or management capabilities found in an ESB.
8. An ESB container can be implemented using an EJB container. ESBs require service containers that are lightweight and dynamically configurable, and that support event-driven services—properties typically not found in an Enterprise JavaBeans (EJB) container.
9. ESBs offer yet another proprietary middleware stack. ESBs are fundamentally standards-based, leveraging XML and Web services standards. ESB vendors are implementing and contributing to the next generation of standards for further interoperability and openness, as well as working to standardize key architectural aspects of ESBs.
10. ESBs are useful only for departmental applications. Hundreds of ESBs have been deployed around the world for mission-critical enterprise and B2B systems. In fact, the ESB was designed with large-scale, distributed environments in mind, overcoming the limitation of previous integration brokers and distributed computing technologies, such as Common Object Request Broker Architecture (CORBA) and Remote Method Invocation (RMI).
About the Author
Gordon Van Huizen, chief technology officer for Sonic Software, pioneered the development of the ESB.
Back to top
|