Once known simply as XML Gateways, the name evolved as these interfaces diversified into the various protocols and message formats potentially present in modern service-oriented architecture. When companies began reusing these services internally, SOA Gateways and appliances moved and evolved with them, providing the same basic functionality for internal app-to-app communication in various form factors. And that's when IT architects began to recognize the overlap between SOA Gateways and ESB, and explore more sophisticated internal use cases.
Modern SOA Gateways include all the hallmarks of a traditional ESB: standards-based endpoint abstraction, broad data and transport mediation capabilities and dynamic, intelligent message routing. Traditional ESBs approach these requirements either through 1) adapters, or 2) code.
The first approach often results in "death by adapter," trying to deal with hundreds of obscure, incompatible, additional-cost components that then have to be wired together uniquely for each point-to-point connection. The second approach results in application logic being written in the ESB itself, introducing tightly coupled interfaces, long services engagements and serious security concerns.
SOA Gateways, on the other hand, treat security as a first-class citizen, by enforcing policies around message privacy, message integrity and access control. They utilize a consistent configuration-driven interface to prevent the need for hordes of programmers and the potential introduction of additional security vulnerabilities. And they provide the scalability and manageability one would expect from enterprise-class architecture components.
This broad set of capabilities opens the door for many diverse use cases commonly deployed on an ESB:
* Any-to-any transformation functionality allows integration of legacy mainframe applications with modern service interfaces such as SOAP, REST and JSON.
* Application-awareness and comprehensive message inspection enable dynamic routing, SLA management and protocol bridging decisions based on transaction content.
* Integration with databases and flat file formats allows message enrichment and custom data mappings.
* Connectivity to (or inclusion of) identity stores allows identity federation and credential token mapping.
* Runtime access to latency and throughput information allows business-level reporting and analytics.
The list goes on and on, but they all boil down to the same simple principle: an SOA Gateway should quickly and securely get messages to the appropriate target, in the appropriate format, using the appropriate protocol.