In the past year, I have stood in a conference room at more than one client fielding a question along the lines of exactly what is an ESB? I’ve found that there is a wide variety of impressions about what exactly makes something an ESB. I’m hardly the first person to post something on the Internet claiming to answer the question. For my purposes, I’m defining what I mean by an ESB. It ties into something I’m slowly building up to on Thinkmiddleware.com-a repository of SOA material.
In the broadest sense, an ESB is a SOA Design Pattern. It’s a set of ideas and concepts. Not all of them will be relevant to every customer or every situation.
Most often, I see an ESB filling many of the following:
- Advertising internally-facing Web Service APIs.
- Entry point to an organization Web Service APIs.
- Decoupling of Service Providers and Service Consumers.
- Each of these Actors has a contract with the ESB and is ignorant of what other systems are interacting with it.
- Ability to speak numerous different types of wire protocols (HTTP, FTP, NFS, MQ, JMS, EJB, RMI, TCP, etc, etc).
- Transformations between different input and output protocols.
- Ability to understand many different types of data formats (XML, flat file, COBOL Copybook, etc,etc).
- Transformations between different input and output data formats.
- Support for security
- WS-Security
- SSL
- X509/PKI
- XML Encryption
- XML Digital Signature
- Identity Tokens
- Username Tokens
- SAML/SAML2
- X509
- BSTs
- Ability to convert between different security requirements between a Service Consumer and Service Provider.
- Ability to expose multiple versions of the same service.
- Ability to expose the same service with different security requirements.
- Service Mediation
- Service Orchestration
- Support for multiple Message Exchange Patterns (MEPs)
- Synchronous Request Respond
- Asynchronous Request and Respond
- Fire-and-Forget (Asynchronous one-way)
- Ability to convert between MEPs.
- Ability to define, enforce, and monitor SLAs.
The ESB deals with internal Service Providers and Service Consumers. If an internal Service Consumer needs to make a call to an externally hosted Web Service, I would expect that Service Consumer to make a call to the ESB, the ESB to route the request to the XML Gateway, and the XML Gateway to send the request to the External Service Provider. Likewise, for an external Service Consumer that needs to call a Service Provider inside of organization XYZ’s environment, the Service Consumer would hit the XML Gateway, be routed to the ESB, and the passed to the appropriate Service Provider.