How to pick an ESB - Comparison Criteria
Join the DZone community and get the full member experience.
Join For FreeAll 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:
[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, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Five Java Books Beginners and Professionals Should Read
-
Designing a New Framework for Ephemeral Resources
-
What to Pay Attention to as Automation Upends the Developer Experience
-
Reactive Programming
Comments