Open source SOA
Many enterprises have adopted Service Oriented Architecture (SOA) over the past decade, but open source SOA solutions have emerged only recently. This article provides a definition of open source SOA, presents different open source SOA options, compares the pros and cons of proprietary and open source SOA solutions, and concludes with a few points on why an open source SOA makes sense for today’s enterprise.
What is open source SOA?
Open source SOA is an approach to implementing SOA that makes use of open source middleware and other software to handle crucial functions such as transport, messaging, service description and discovery. These tools include the Enterprise Service Bus (ESB), Business Process Modeling (BPM) tools, Business Rules Management Systems (BRMS), data services tools, portals, testing tools and security tools. MuleSoft, Apache, WSO2, Intalio, and JBoss are just a few examples of open source communities that develop and provide open source SOA middleware and related products.
Traditionally, open source software is free (or very low in cost) and the source code is made available to users and developers. Moreover, contrary to popular misconceptions, open source products are neither lower in quality nor unreliable just because they have been traditionally developed in a collaborative fashion by a community at large rather than an established commercial developer like IBM or Oracle. In fact, open source middleware has matured in recent years and is especially suited for realizing SOA initiatives.
Open source SOA options
For system administrators looking to implement SOA using open source products, there are a number of options. The first is a mix-and-match approach, which involves piecing together components from different open source providers and integration providers to build a customized SOA stack. For instance, you might use MuleSoft’s Mule ESB to handle integration functions and turn to WSO2 for data services, Intalio for your BPM tool and JBoss Drools for your BRMS.
In another mix-and-match approach, you can combine different tools from a single open source provider. In other words, you create an SOA stack by choosing your ESB, data services tool, BPM tool and rules engine all from one provider’s suite of open source products. Red Hat’s JBoss, for example, offers a range of open source SOA tools.
For system administrators considering open source SOA options but want to avoid the task of picking and choosing individual tools to build their SOA stack, some open source providers are beginning to offer complete packages of SOA middleware connectivity that combine features from both proprietary and open source models of development. Open source companies typically offer such packages as enterprise editions of the community versions of their SOA products and make them available to customers through a subscription model. While this goes against the idea that open source software should be free, paid subscriptions to enterprise-class open source SOA products usually include full support services and regular software updates, features that are often missing from open source options that are free.
Pros and cons: Proprietary SOA vs. Open source SOA
Although open source SOA middleware is becoming more prevalent, some enterprises may not be ready to abandon proprietary SOA in favor of open source SOA. To be sure, both proprietary and open source approaches have pros and cons and SOA projects vary in their requirements. Proprietary SOA offerings, for instance, are managed and maintained by the developer, easing the burden of system administrators, and include regular upgrades and professional support services. At the same time, proprietary SOA products come at a high cost and result in vendor lock-in, making customers dependent on a single vendor for its SOA stack. Moreover, because the source code of proprietary SOA middleware is not disclosed to users and developers, bugs can take longer to fix and users have limited influence on future product development.
Open source SOA middleware, on the other hand, costs much less than proprietary offerings and are vendor agnostic, resulting in greater flexibility in working across different platforms. Since users and developers have access to the source code, product improvements and bug fixes are rapid and constant. Nonetheless, open source SOA does have its downsides. In mix-and-match scenarios involving several providers, more skill and time is required to test, manage, and maintain the SOA stack. Open source SOA offerings also tend to lack the full support services that come with proprietary SOA products.
Why open source SOA makes sense
Despite some limitations, the benefits of open source SOA middleware make it a logical choice for system administrators. The increasing availability of complete SOA stacks with reliable and robust capabilities from open source providers, including enterprise-level support services, means that many of the shortcomings of open source SOA have been addressed. In addition, open source products don’t lead to vendor lock-in, enabling enterprises to customize their service orchestration and SOA stack to suit their particular needs. If SOA aims to lower costs, enhance flexibility, and improve scalability, then open source SOA just makes plain sense.
For more on open source SOA, take a look at this article on Open Source ESB.
Want to know more about the future of Mule ESB?
The Mule development team has released new Development features to the platform, including: