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.
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.
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.
Though the ESB replacement concept is the same for most SOA Gateways, vendor implementations can be very different. Each vendor can provide a laundry list of their supported protocols and message formats. Each will take a unique approach to policy configuration and extensibility. Each will support slightly different encryption algorithms and access control mechanisms. Each will have various potential deployment methods and clustering strategies.
When considering an SOA Gateway in an ESB scenario, the goal is to match up each of these capabilities with your particular requirements. Consider which of your current applications could be made more valuable by providing a robust, standards-based interface. Consider what data you’d like to expose, to whom and in what format. Then go through the various options and choose wisely. If you want to provide an OAuth-protected REST interface to a mainframe application accessed using MQ, then make sure the necessary formats and protocols are supported by your SOA Gateway vendor.
Support for these common ESB functions is what will likely make your decision much easier. In terms of protocols, what do you need beyond basic HTTP(S)? Are messaging protocols (MQ, JMS, EMS) a requirement; if so, do you use a particular flavor (vendor-specific JMS), and is it supported? Do you need file-based protocols such as FTP and NFS; if so, which secure versions and/or security options (FTPS, SFTP, NFSv4)?
Do you need support for incoming (POP3, IMAP) or outgoing (SMTP) email? In terms of message formats, are XML-based options (XML, SOAP) sufficient? Do you need flat-file support? B2B formats such as EDI? Mainframe formats like Cobol Copybooks? Modern Web-based formats such as JSON?
What tools will you use to map between these formats? How is policy created on the gateway, using what interfaces? Is there a logical GUI that makes it clear what actions are taking place? Is there a Command Line Interface? How about a services-based interface for programmatic access to gateway functions?
On the security side, what incoming and outgoing credential types need to be supported, and is there an easy, standards-based way of mapping between them? What authentication and authorization servers are supported? Does the gateway both support modern cryptographic algorithms and protect against modern threats? Do you require any security certifications or specialized hardware?
Considerations around placement of an ESB and integration into existing architectures carry over to SOA Gateways acting in the same capacity. Some enterprises require a hardware gateway form factor when dealing with deployments that touch the DMZ, some deploy all internal applications on virtualization software and others need their internal architecture to be replicable in a public cloud environment. These form factor choices will be of primary importance to your network and operations teams, along with clustering methodologies and integration with existing logging, monitoring and reporting.
Understanding the limitations of SOA Gateways is equally important. They’re powerful and flexible, but are by no means a panacea. For example, though they generally provide workflow and logical message processing capabilities, they are not BPEL-enabled business orchestration engines that can manage all of your human interaction and long-running processes.
Though they can process batches of messages, they are neither a Managed File Transfer platform nor an ETL data warehousing tool. And though there is definitely some feature overlap with Web Application Firewalls, SOA Gateways don’t generally fulfill all of those requirements; neither do WAFs come anywhere close to parity on non-HTML traffic.
The exact deployment model for an SOA Gateway in an ESB role depends on the feature comparison exercise we just went through, and generally falls into one of three categories.
If these “Lightweight ESBs” meet all of your corporate requirements for application integration and SOA deployment, they can easily stand alone and fulfill the ESB pattern. If, on the other hand, an existing ESB is meeting most of your application integration needs, then an SOA Gateway can be deployed as a complement to provide value as an on- and off-ramp to that ESB. This “ESB Gateway” use case focuses on the gateway’s strengths around security, high-performance transformation and edge-based protocol mediation.
The third option is most common in large enterprises that have grown through mergers and acquisitions and have a heterogeneous corporate IT landscape. In these cases, the SOA Gateway can perform all of the ESB functions for those divisions without an existing infrastructure and can act as a bridge between other more entrenched technologies in the rest of the enterprise. It even enables extension of this secure architecture to applications deployed in public or private cloud environments. This “Federated ESB” use case takes advantage of the true agility and flexibility of SOA gateways without requiring a rip-and-replace implementation.
SOA Gateways combine the capabilities of a traditional ESB with security, agility and simplicity. They transform the archaic code-based challenge of application integration into a modern configuration and networking problem. They can be implemented as hardware, as VMs or in the cloud. They are Internet ready, giving enterprises the immediate ability to support the extended enterprise which increasingly encompasses partners, cloud and mobile.
In a modern corporate culture that demands we do more with less, they give you the capacity to respond to customer demands and provide new, secure interfaces to the data and applications that drive your business. SOA Gateways truly are the cure for the common ESB.
(From Network World U.S.)
