Ronald Schmelzer, a senior analyst at ZapThink revisits the common misconception/biases on the suitability of open source SOA solutions for the enterprise and asks “why is it then that so many IT organizations prematurely discard Open Source Software (OSS) from their SOA implementations?”
To make it absolutely clear, ZapThink is not advocating dumping all your vendor solutions in favor of an OSS stack, however, we believe that the current economic and technology environment are making OSS solutions more credible, feasible, cost-effective, and potent as the industry matures.
He starts out defining open source software according to Wikipedia; carefully pointing out the subtle difference between free software and open source software.
The term open source is frequently, although not always, used in conjunction with the idea of free software. In this terminology, free sometimes means that it costs nothing to acquire the license, but that’s not exactly how it’s defined by the Free Software Foundation (FSF). The FSF defines Free and open source software (F/OSS or FOSS) as the freedom to copy and re-use the software […] This means that FOSS licenses gives users the rights to copy, modify, share, redistribute, and otherwise contribute to the advancement of the technology, but doesn’t necessarily imply anything about total cost.
In addition, Open source software also comes in commercial flavors (COSS) where “the community has rights to certain aspects of modifying, sharing, and enhancing the software whereas others are reserved for the company”; contributing to the Fear, Uncertainty and Doubt (FUD) surrounding the adoption of open source solutions, let alone navigating the legalese of various open source licenses available.
Let’s start with uncertainty. From a SOA perspective, the big uncertainty on OSS rests on two main issues: are there a sufficient number of OSS offerings to cover the scope of things we need for our SOA implementations, and are those OSS projects of sufficient quality to meet our needs?
He goes on to answer the question
[I]ndividuals and companies have poured tens of thousands of hours of development time and maintenance into these [OSS] tools. […] Many open source tools build upon the experience of users who have previously used commercial offerings and thus aim to mimic or improve the functionality and performance of those solutions.
In addition he points out that, as many of the vendor tools are products of acquisitions, and in some cases a series of acquisitions; it is often the case that the commercial/vendor solution is “ill-defined” in terms of road map and integration with other products in the product portfolio. He goes on to categorize and list the various solutions available in the different parts of the solution space…
For […] Enterprise Service Bus (ESB) functionality, then there are a plethora of Open Source solutions. Companies have successfully implemented Mule ESB, Apache Axis2, Apache Synapse and Apache ServiceMix.
For SOA development, there are a wide variety of OSS options, […] such as the Swordfish SOA framework and the Equinox OSGi bundling framework.
[For[ open source SOA registry and management solutions Mule Galaxy, SOPERA, WSO2’s open source registry offering, and the Membrane SOA Management tool.
[For] OSS Business Process Management (BPM) and BPEL runtime engines including ActiveBPEL, Apache ODE, Orchestra, and a plethora of others.
He asserts that the fear that OSS solutions may not be supported is unfounded, saying most OSS projects have commercial companies offering paid support.
While it is true that many good OSS solutions require paid support to achieve the response time and care necessary, we would argue that money is well spent. With commercial companies providing support for OSS offerings you get the best of both worlds: community development, testing, and enhancement at low or no cost, and professional support whose time and value are known quantities. Even if you chose a commercial vendor, you’re going to be paying for support anyways.
… Additionally, he suggests that OSS mitigates the risk of sun-setting products/product lines as a result of churn in the IT industry in the form of acquisitions, cost cutting, or consolidation.
OSS presents less of a risk because the code is out there in the community, available for anyone to pick up. From a SOA perspective, you want to have as few dependencies as possible on your infrastructure or a single vendor’s solutions. As such, for many, OSS makes a whole lot of sense.
He goes on to give the example of how BlueStar Energy estimates saving of $24 million over the course of five (5) years with an SOA implementation that is based entirely on OSS solutions.
If you read the case study, you can see that the design principles had a decidedly non-vendor bias. They wanted control over their environment, and this meant creating a specification that required implementation neutrality. […] Their Business Integration Suite consists of open source distributed, scalable and reliable components such as enterprise service bus, business process management system and messaging fabric.
He urges architects to define the architecture in a implementation agnostic/vendor-neutral way and evaluate the suitability of candidate solutions; be it open source or vendor solutions. He concludes his article with an endorsement of the viability of OSS for SOA implementations in the enterprise.
Check your FUD at the door. Make sure you aren’t losing an advantage by prematurely eliminating OSS from your SOA infrastructure mix.