All Enterprise Service Bus (ESB) products may be used to build and deploy services, encapsulate legacy systems, route messages, transform message formats, and perform protocol mediation.  Many WSO2 prospects ask me ‘What differentiates WSO2 Enterprise Service Bus?’  This blog post shares my perspective and scales the conversation.

Integration teams use ESBs to solve service-oriented anti-patterns of isolation, uniqueness, and duplication.  Isolation refers to stand-alone system silos and point-to-point connections between systems (as opposed to shared connections).  Unique data schema models for similar entities, transactions, and processes raise integration cost.  When an organization fields multiple software applications delivering similar business functions and requires redundant data entry, opportunities exist to remove duplication and save both operational expense and maintenance cost.

To reduce service-oriented anti-patterns, teams want to share and re-use assets, consolidate functionality, and conform projects to common standards.   To achieve these best practices, teams rely on an ESB to deliver the following required architectural attributes:

• Interoperability
• Abstraction
• Resource location virtualization
• Ability to scale and manage service
• Declarative policies and platform independent models
• Separation of concern
• Loose coupling
  
  

Architectural attributes are hard to measure, and we find most evaluation teams do not develop evaluation use cases across all architectural attributes.  Teams often focus on easy identifiable product features.  ESB products may contain the following required and optional features:

Required features

• Routing
• Protocol bridging
• Message transformation
• Service agent hosting

Optional features

• Resource adapters
• Composition
• Orchestration
• Reliable message delivery
• Event processing
• Transactional integrity
• Message Exchange Pattern (MEP) mediation
• Dynamic location and binding, load balancing
• Message validation
• Capability mediation
• Security mediation (federation)
• Tooling

After creating use cases testing an ESB’s ability to deliver architectural attributes and features, an ESB evaluation process should also consider how the ESB fits into the complete platform.  An ESB is usually just a single component in a broader composite SOA Platform.   Teams often combine an ESB with Governance Registries, Identity Servers, Business Activity Monitoring, Complex Event Processing, and Business Process Management.  Teams often differentiate ESBs based on how well the ESB fits into a complete solution.  A platform built by vendor innovation instead of vendor acquisition will often provide a more holistic and cohesive experience by sharing meta-data, administration consoles, programming models, and foundational features (i.e. logging, security, management, provisioning).

Performance, scalability, and topology strongly influence solution agility and adaptability.  We see organizations evaluating how well ESB candidate products fit across hybrid Cloud environments (i.e. on-premise, outsourced, internally managed, externally managed [1]), high transaction loads, and low latency use cases.  Teams should devote ample time to build suitable performance, scalability, and topology tests.

A Proof of Concept project provides an opportunity to ‘kick the tires’ and evaluate the ESB’s ability to satisfy use cases.   Rather than simply relying on vendor demos, download the bits and directly experience the ESB’s programming model, administration interfaces, documentation, and samples.   During the Proof of Concept project, carefully evaluate the vendor’s support processes, openness [2], responsiveness, and ability to recommend suitable solutions.

By carefully considering your requirements, constraints, and technology strategy, your team can build an ESB evaluation framework demonstrating product similarities and strategic differences.  A comprehensive, weighted evaluation criteria set will ensure the ESB meets your needs today and in the future.  An evaluation framework mindmap is shown below:

Enterprise Service Bus Evaluation Framework

[1] http://blog.cobia.net/cobiacomm/2011/11/07/know-your-cloud-dimensions/

[2] http://blog.cobia.net/cobiacomm/2012/03/14/value-openness/