Apache Camel with Apache Tomcat provides a low-cost and lightweight integration framework. Is Apache Camel with Apache Tomcat a good fit for your project requirements?
When you evaluate infrastructure vendors, do you correlate their agility and innovation with release velocity?
Many teams are actively refreshing their integration platform and evaluating open source ESB (Enterprise Service Bus) capabilities and benefits. Fewer are evaluating their SOA strategy and establishing open source SOA (Service Oriented Architecture) platform infrastructure, metrics, and measurements required to guide teams towards agility and responsiveness.
An Enterprise Service Bus (ESB) may serve as the cornerstone of your Service Oriented Architecture infrastructure, or you may feel an ESB is unnecessary and cumbersome. Many integration projects contain simple requirements and use cases that warrant including an ESB, integration framework, or alternative platform components in the integration solution. Selecting the appropriate solution mix requires integration reference architecture guidelines that include a comprehensive decision matrix. Team members strive to avoid complexity and inefficiency by specifying an optimal platform component mix, defining ‘the right tool for the job’, and developing scalable, agile integration solutions.
Do you have clear architecture, solution, and ESB PoC guidelines describing how your organization can wisely select integration infrastructure components and products? Successful enterprise architects and solution architects create an integration reference architecture decision framework, ESB use cases, and product selection guidelines containing:
- ESB use cases driving integration platform component and integration framework selection.
- Common Request for Proposal (RFP) categories and line items.
- Tools describing when to include an ESB, integration framework, or alternative integration platform components (i.e. Data Services Server, API Manager, Governance Registry).
Can an eight year old product category, which is hotly contested by every middleware vendor, deliver unique and differentiating product offerings? When performing an ESB comparison, you will notice almost all Enterprise Service Bus products support enterprise integration patterns, deliver all required ESB features (i.e. web services, message transformation, protocol mediation, content routing), and offer a graphical development workbench. When technical evaluations focus on core performance and quality of service (i.e .reliability, availability, and scalability), proof of concept workloads must closely mirror expected production profiles and the evaluation effort ideally includes vendor participation.
In John Rymer’s recent blog post, Progress Software Lowers Its Sights, he breaks the news that Progress is divesting perceived ‘non-core’ middleware products. On the selling block are Progress Sonic ESB, Savvion BPM, Actional services management, and FuseSource. Progress’ recent strategy shift places Sonic ESB, Sonic MQ, and FuseSource implementations at risk of obsolescence. The list of probable acquirers could mean product termination and forced migration.
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.