ESBs Combine the Strengths of Previous Middleware Technologies
Prior to the emergence of the ESB, developers and architects used a variety of communication protocols for program to program communication, all of which had significant drawbacks:
- Raw Communication Protocols (such as TCP/IP, SOAP and FTP, among others) lack basic features (such as location transparency) that are necessary for developing real-world componentized distributed systems; the required development effort is only justified when performance is a primary concern.
- RPC (Remote Procedure Call) and ORBs (Object Request Brokers) are suitable primarily for request/reply applications and have little or no support for event-driven or asynchronous communication; in addition, besides the basic request/reply pattern, there is little standardization of programming models for RPCs and ORBs.
- MOM (Message Oriented Middleware) provides added flexibility over RPC with in-built support for event-driven as well as request/reply interaction between programs; however, MOM's require communicating modules to agree on topic or queue names, creating an underlying coupling that is not easy to remove without providing explicit support for message metadata, which MOMs lack. It is possible to deploy complex SOA and EDA applications over a MOM, but the lack of support for message metadata and a programming model for business components significantly complicates the implementation.
- Web Services provide a standardized protocol and programming model for the development of business components; however, without a communications backbone and message metadata, Web Services degenerate into a relatively inflexible request/reply point-to-point infrastructure for SOA applications with no support for event-driven (EDA) applications.
ESBs combine the strengths of all of the above middleware protocols, with support for synchronous request/reply (SOA) and asynchronous, event-driven (EDA) communication and event-notification, business-component interfaces, industry standards such as SOAP/HTTP and Web Services, together with partial support for the management of business components.
The better ESBs also provide a comprehensive business-component model, together with tools that allow business-analysts to orchestrate business components to deploy complex business processes with little or no programmer intervention.
Learn more:
The Mission of Application Integration
