Enterprise Integration Zone is brought to you in partnership with:

As VP of Technology Evangelism at WSO2, Chris Haddad raises awareness of Platform as a Service, Cloud Architecture, Service Oriented Architecture, API Management, and Enterprise Integration. Prior to joining WSO2, Haddad’s experience includes building software development teams, contributing to open source, crafting technology roadmaps, leading Gartner research teams, and delivering Software as a Service and Web applications. Chris is a DZone MVB and is not an employee of DZone and has posted 108 posts at DZone. You can read more from them at their website. View Full User Profile

How to pick an ESB - Comparison Criteria

05.16.2012
| 16325 views |
  • submit to reddit

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:

ESB Evaluation Framework

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/

Published at DZone with permission of Chris Haddad, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Robert Morschel replied on Mon, 2012/10/08 - 8:16am

This is a good high-level starting point. but I'm not sure this helps a lot in terms of establishing concrete, scoreable evalutation criteria.

 

Robert

http://soaprobe.blogspot.co.uk/2012/10/preparing-for-enterprise-service-bus.html 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.