Enterprise Service Bus

Some ESB vendors will argue that their service bus products are the right choice as enterprise SOA Federation solutions.  ESBs provide valuable functionality for integrating existing systems and building composite applications, they are not well suited to providing enterprise SOA Federation capabilities.

ESBs fall short in the following areas:

  • Ease of use – most ESBs are driven by a application development model.  They are designed to allow developers to create applications, and manage adapter frameworks to provide broad connectivity to legacy systems.  To virtualize an existing service using most ESBs requires complex configuration steps, and in many cases programming tasks, especially if any mediation is required.  An SOA Federation solution on the other hand is explicitly designed to facilitate simple federation and virtualization with declarative policy and technology impedance mediation. 
  • Policy silos – many ESBs provide their own, internally programmed policy models.  They can quickly become policy silos creating and enforcing local policies through programming, rather than implementing and enforcing centrally defined enterprise policies.  An SOA Federation solution understands standards-based policies for services it exposes and consumes, and offers declarative mediation between the policy capabilities of consumers, the policies enforced by virtual services, and the policy requirements of physical services.
  • No service discovery – the current crop of ESBs are service runtimes with no discovery mechanism.  They don’t offer any mechanism for publishing the services they expose so that they can be discovered by 3rd parties.  An SOA Federation solution must include standards-based service discovery capabilities for development (UDDI) and runtime (WS-MetadataExchange) service, endpoint, and policy discovery.
  • Lack of a governance process – ESBs don’t provide an mechanism for automating the process of determining whether a service should be published or not.  SOA Federation solutions include a lightweight, extensible model allowing users to request the federation of a service, and administrators to approve or reject the request.
  • No contract model – ESBs don’t have any understanding of the concept of a service consumer.  They have no way to offer service consumers specific guarantees of service level, or even grant or deny access to their exposed services based on a contract approval workflow.  An SOA Federation solution includes a lightweight, extensible contract workflow allowing potential consumers to request access with specific service level guarantees, and the service provider can grant or deny this request.
  • Technology impedances – many ESBs are evolutions of EAI platforms or message-oriented middleware.  They often support only a limited subset of the messaging, transport, and policy standards expected in enterprise SOA.  It is common for different ESBs to implement services in such a way that they are not directly consumable by other vendor’s products.  Additionally, ESBs will generally not be well suited for DMZ type deployments, so cannot safely expose services outside the enterprise or regional firewall.  An SOA Federation solution offers messaging, transport and policy mediation, as well as the ability to virtualize services into secure, DMZ resident intermediaries to remove these technology impedances.
  • Semantic, not syntactic – most ESBs offer strong mediation solutions, but it is not the kind of mediation required for service federation.  ESBs offer semantic (i.e. content) mediation, while the SOA Federation solution focuses on syntactic (i.e. envelope) mediation.  An ESB can do a very good job of mapping from one business document to another, but it is not designed to map from one messaging style, standard, transport, or policy to another.  SOA Federation solutions provide declarative syntactic mediation capabilities to minimize the impact of administrative, organizational, trust and technology impedances.


SOA Federation Capabilities
SOA Federation solutions focus on taking existing services and ensuring that they meet the requirements of enterprise SOA.  To achieve this, the SOA Federation solutions offer a set of core capabilities:

  • Uniform Policy Management - Uniform Policy Management ensures consistent policy definition, implementation, enforcement, validation, and audit through all stages of the lifecycle, and across all distributed and mainframe platforms.  It ensures that services can be leveraged as first-class citizens throughout an enterprise SOA by complying with enterprise policies that are uniform across all platforms.
  • Service Virtualization - Service Virtualization provides location-transparency, service mobility, impedance tolerance and reliable service delivery without requiring a re-platforming of existing platforms or introducing yet another service platform to support the required solution architecture.
  • Trust and Management Mediation - Trust and Management Mediation ensures interoperability across disparate partners and platforms, trust enablement and trust mediation complementing threat prevention systems.  It provides provide last-mile security, metric collection and reporting, SLA monitoring and management, to ensure that services are governed, managed, and secured, and policy implementation and mediation to allow consumers to communicate with a wide range of mission critical business services exposed from any platform.
  • Change Impact Mitigation - Change Impact Mitigation provides change management and impact analysis processes integrated with the governance workflow to ensure that changes to services or other assets don’t cause major outages by breaking the consumption model.
  • Consumer Contract Provisioning - Consumer Contract Provisioning provides offer, request, negotiation, and approval workflows for service access, capacity, SLA and policy contracts.  It ensures that the service provides know which applications and users are consuming their services and allows them to treat different consumers with different priorities and service levels.

We will address the technology solutions required to address these capabilities later in this document.

SOA Federation Anti-Patterns
ESBs offer valuable capabilities that SOA Federation solutions should explicitly not address:

  • Application Composition – most ESBs include process design tools that allow developers to create composite applications tying together different services and applications.  An SOA Federation solution is explicitly not in the business of creating new applications and services.  The SOA Federation solution can create virtual services from sets of existing services, but it does not provide a mechanism for modeling business logic.
  • Enterprise Application Integration – many ESBs are the evolution of EAI solutions.  They include comprehensive adapter frameworks providing connectivity to a wide range of legacy systems.  SOA Federation solutions will not provide this connectivity – they will focus on service federation to turn existing services into governed service endpoints.
  • Complex Transformations – One of the core capabilities of an ESB is the ability to map one message schema to another, performing complex transformation operations along the way.  SOA Federation solutions will offer syntactic transformation, i.e. the ability to mediate between different message formats and syntaxes, but will not typically provide comprehensive content mediation.
  • Stateful Orchestration – ESBs typically provide process orchestration engines built on top of the message-oriented middle backbone of the ESB.  These orchestration engines are capable of orchestrating long-running business transactions through stored state.  The SOA Federation solution should be able to route and virtualize long-running transactions, but will not offer any form of process orchestration.