Rethinking the ESB: Building a simple, secure, scalable Service Bus with an SOA Gateway

Network World - This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.

For years the Enterprise Service Bus (ESB) has been seen as a corporate integration and messaging backbone upon which application architectures are built. However, this concept must evolve to meet the requirements of today's corporate landscape, where IT boundaries are blurring, driven by the need to integrate with partners, cloud and mobile applications.

Service Oriented Architecture (SOA) Gateways, originally designed to provide edge security between enterprises exchanging data via Web services standards like SOAP, REST and XML, have been brought inside the firewall to provide a more flexible solution to traditional integration requirements with an eye to future integration challenges over the Internet.

REPORT: Forrester: SOA is alive and well

At its core, the ESB pattern represents a basic set of functional requirements used to integrate applications across an enterprise: mediation, transformation, routing, etc. Unfortunately, this term has been conflated with vendor-specific product suites and application platforms, often leading enterprises toward insecure, overpriced, code-heavy architectures that ignore many of the pattern's non-functional requirements: security, performance and manageability.

In many cases, SOA Gateways are a simpler alternative that meet each of these ESB requirements; they allow a lightweight deployment alternative to the oversized ESB approach and enable enterprises to be more agile and responsive to customer demands at a lower total cost of ownership.

SOA Gateways were initially created to solve a different problem: How do you protect your internal applications when interfaces are being exposed to external partners and customers over HTTP and HTTPS protected only by IP firewalls?

The solution was to include a hardware-based application-aware appliance to provide protection from these new threats, specifically around XML-based attacks, message- and field-level data privacy and integrity, and interface abstraction.

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.