Tight Budgets? Try Open Source SOA!

Implementing SOA can be an extremely expensive undertaking. You might need to purchase several products within the SOA stack like an enterprise service bus (ESB), a business process modeling (BPM) tool, a portal, a rules engine and a data services tool. But it doesn’t stop there. There are additional tools for testing, SOA governance, security… and the list goes on and on. In addition to all the software, you need to budget for training, hardware, consulting and salaries.

That’s a boat load of capital you need to ask senior management for. Leveraging open source products and services can help ease the pain.

There are many advantages of leveraging open source to meet your SOA needs.

1. Try before you buy. With commercial software, once you invest in the software, the cost of the software and the first year of maintenance (typically 20% of the purchase price) is committed. With open source, you can create prototypes and try out the software before you commit large sums of money. Even if you plan on buying commercial software you can leverage open source software to validate your architecture before making any purchases.

2. Lower cost of entry. The cost of the various tools within the stack can be quite staggering. Open source eliminates or greatly reduces the initial sticker shock. You get the software for free and you have the option to subscribe for support services. Of course, not paying for support for your SOA stack is suicide. In some cases, there is a community version and an enterprise version. For certain products within the stack, a company may only need the community version which is totally free. Other companies may need the robust feature set of the enterprise version, but it is still substantially cheaper then commercial software.

3. Cost effective support. With commercial software, support costs a percentage of the initial purchase. This leads to incredibly high maintenance costs in the hundreds of thousands or even millions of dollars. Support for open source software is substantially less. So not only do you not have the huge initial investment, but your ongoing fixed costs are substantially less as well.

4. Core competency. Many of the mega vendors in the SOA space have tentacles in various areas of technology with SOA being one of them. They often take existing products and tweak them in the name of SOA. They also buy several companies and then call themselves an integrated stack. The reality is, their stacks are a hodgepodge of many different companies and the promise of integration is not a reality. With many of the open-source vendors, SOA is all that they do. These products are built for SOA from the ground up, not from mergers, acquisitions, and rushed integration releases.

5. For the people by the people. Commercial software is closed and not accessible by developers. In my past life, we had some integration challenges with a vendor’s portal and BPM products. We spent two months providing the vendor with logs and various information so that they could troubleshoot the issues. Once they finally found the bugs, they patched some of them but deferred others to a future release to be determined. If we had access to the code, we would have found the issues sooner and fixed the ones that they were not willing to fix in order to save the precious time that we lost while waiting for the vendor to resolve its issues. Instead, the project slipped several weeks and we wrote a ton of workarounds that will probably exist in the system for years to come.

There are a few paths that you can take for your open-source SOA initiative. You can go with a complete open-source SOA stack, you can mix and match various open-source SOA products from different vendors, or you can mix and match both commercial and open-source products.

There are two major open source stack providers that stand out: MuleSource and WSO2.

Mulesource

MuleSource launched the Mule ESB back in 2003. In 2006, they formed an actual company and continued enhancing their product offerings. In addition to the ESB, they have an application and services monitoring tool called MuleHQ, and a design-time governance tool (just released) called MuleGalaxy.

To complete their stack offering, MuleSource works with open-source partners Liferay for portal functionality and Intalio for BPM functionality. Do you need proof that Mulesource is ready for prime time? Just ask H&R Block, which has a 130,000 server Mule ESB implementation [PDF] or read about Walmart.com [PDF].

WSO2

WSO2 is a true open-source alternative. Unlike many open-source vendors in this space, they do not have a separate commercial and enterprise offering. All of their features are free, with the hope that their customers will acknowledge the need to purchase subscription services. This is a great strategy because it allows the customers to see the full value of the products without having to deal with the limitations of a community version. WSO2 is three years old and started with a Web Services Framework, which is a communication run time that they offer for Perl, PHP, Ruby, Spring, C and C++.

Web Services Framework is a set of libraries and jar files for rapid development and deployment of Web services. On top of this framework, WSO2 is building its SOA offerings which include an ESB, Web Services Application Server, a runtime governance tool, a security solution, and a newly released mashup server. The Web Services Application Server makes it simple and effective to create, consume and manage Web services’ it provides data services capabilities and will soon include a rules engine. The new Mashup Server makes it easy to compose Web services, feeds and Web pages to create mashups through the use of a simple scripting language.

Do you need WSO2 case studies? Some of their customers include a large HMO with a legacy mainframe system that is using WSO2’s Data Services and ESB, Concur (a Web 2.0 Expense Management company that is using their Data Services and ESB to implement an internal SOA) and one of the largest banks in the AsiaPac area, getting support for their ESB.

Other Support Options

You can subscribe to support services from your stack provider or leverage the services of an open-source service provider like Source Labs or Spike Source. If you have doubts about open source support, you need to read this article that debunks the myth that you can’t get good support for open source software.

Other Solutions

If the stack vendors are not for you or if you only need a certain product to supplement your existing stack, there are many proven open-source alternatives to choose from. Here are a few, in addition to the ones I mentioned above:

• Portals: Liferay Portal, Apache Jetspeed

• BPM: Intalio, jBPM

• Business rules: jBoss Rules

• SOA governance: Centrasite, freebXML

• Testing tools: SoapUI, PushToTest

• Integration: Snaplogic

This short list only scratches the surface of what is available. Eric Roch, CTO at Perficient, has worked on numerous SOA initiatives as a consultant over the years. He has seen many companies mix and match open source with commercial products. He says that by doing so, a company can pick the best products across the stack for their specific requirements. Buying an entire stack from one vendor does not always give you the best products.

Roch has also seen clients leverage open source to fill a specific need within the stack. For example, a company may decide down the road to add a rules engine or a repository several months after they implement their first few projects. Instead of going back to the well to ask for more funds, some choose to fill the gap with open-source products.

On the project that I worked on, we had a fixed amount of capital to work with. We used several open-source tools to complement our commercial ESB, BPM and data services tools. Roch does caution that not all of these tools are mature, and some are lacking features that developers may need from a productivity standpoint.

When evaluating open-source software, make sure that the product or service has a large community following, has a good track record of support and that the product has a good roadmap coupled with several successful implementations. You can leverage open source across the entire stack and across all of the tools, or you can supplement your commercial purchases of software with a few open-source alternatives. The choice is yours. I highly recommend that all vendor evaluations consider at least one open-source alternative.