Open Source ESB Search – Part 2Posted in Languages, Tools | Leave a comment
Previously on “Open Source ESB Search”
- Who we are, what we do, what has changed, what are we required to do for our customers, and how do we want to do it… (see our first post at http://ig.obsglobal.com/2013/06/open-source-esb-search-introduction/)
Today, on “Open Source ESB Search”
- Ramping up our Open Source ESB Implementation
What are the current, mature, best of breed Open Source ESB offerings?
- JBoss – the most mature, but lacks a development paradigm that allows for TDD using any IDE. Arquallian provides some support, but not ready for production. Operational support offered by Red Hat.
- Mule – lower level DSL’s that feel dated. Less testing support. Operational support offered by MuleSoft.
- JBoss Fuse ESB – nice aggregation of common tools available to Java or XML DSL. Seems to be the “simplest thing that works” while covering 40+ EIP’s. Operational support offered by Red Hat.
- Spring Integration – provides EIP and generally very good, but would still require container support. Operational support offered by VM Ware.
- WSO2 – has matured recently, but seems to require more current development than other projects that reuse other OSS components. Operational support offered by WSO2.
Which ESB scored highest? Which feels like the right fit?
- Fuse’s features combined with the ability to “upgrade” to the full JBoss stack without losing support swayed the decision in favor of Fuse. JBoss is in the process of applying other JBoss tooling to the Fuse environment. Operational support available via Red Hat may be offered to our clients on a deployment-by-deployment basis.
- Previous investigation resulted in positive feedback with Fuse ESB’s leveraging Camel’s DSL.
- Fuse ESB’s use of CXF to publish web acceptors is familiar to each project developer.
- Red Hat’s Linux offerings position us to deploy to either a free or an enterprise OS while staying within the same support proposition.
What due diligence did we perform?
- Evaluated each Open Source ESB for platform openness, community involvement, upgrade paths, development support, and many other concerns.
- Investigated possible Red Hat partnership.
- Became a Red Hat partner.
- Attended Camel One.
- Attended Red Hat Summit.
- Investigated sample and example code for quality.
- Performed gap analysis between the ESB features and our first project’s requirements and non-functional requirements with an eye towards system expandability and flexibility.
Where are we now in the process?
- We have a system architecture and design.
- We are validating our system architecture and design against the Fuse ESB.
- Help desk has built out three virtual machines – as defined by our system architecture; we require three virtual machines to validate our failover, tracing, and lost-less message non-functional requirements.
- We started a bit of an “Iteration Zero” and spike iteration. As an Agile shop, we demand customer-usable software features delivered in each and every iteration starting with the first iteration. For this project, we have a bit of time before the client is ready to consume any deliverable, so our Delivery Manager is the customer stand-in.
What are some of the next steps/posts?
- Further Discuss the Problem Domain
- Map the Solution Domain onto the Problem Domain
- Discuss Testing Tools and Techniques
- Discuss our ESB Ecosystem and Topology
- Enumerate ESB Acceptors and Message Canonicalization
- Conclusion and Postmortem