Don't have six or seven figures to sink into commercial service-oriented architecture? Price is one of the most appealing selling points for open source SOA products. However, the price for these low- or no-cost, feature-rich platforms is often an enterprise service bus that's not designed for business users, requiring technical expertise that can drag the SOA platform down.
There are some notable exceptions, and open source leaders are increasingly aware of the problem, prompting a rush to develop "orchestration" elements in open source ESBs. Still, most aren't there yet.
Most notable among the open source ESBs are Apache ServiceMix, Iona's Fuse ESB, JBoss ESB, Mule ESB, and WSO2 ESB. But before you jump, take a close look at specific features to see if a particular open source product will be an asset or an obstacle to your company's SOA effort.
The ESB is a standards-based SOA backbone, capable of connecting applications through service interfaces. By combining messaging, Web services, XML, and data transformation/management, an ESB can reliably connect, mediate, and control communications and interactions among services.
When it comes to technological integration, open source ESBs deliver results that are similar to those of their commercial counterparts. Even more impressive, they always adhere to standards such as JBI, which isn't something all commercial vendors can claim. The open source ESBs are not only thoroughly tested and decently documented online, but they come with a number of adapters for JDBC, SOAP, FTP, HTTP, POP3, TCP, UDP, and even legacy systems such as the AS/400.
However, aligning business needs and IT infrastructure is critical during the implementation phase of SOA, and this is where open source ESBs fail to deliver, at least for now. IT professionals will be fine working with XML/Java, but business pros may have a difficult time working in the open source environment. Business analysts generally need to visually orchestrate their process flows, make real-time changes to running processes, adjust service-level agreements, and replace underperforming services. Commercial products have the edge in offering increased business flexibility through plug-and-play architecture and reuse of existing services.
Open source ESBs offer straightforward results, but only if users have enough expertise in XML and Java to use them. For instance, consider a company that needs a system to accept, validate, and place Web orders. In the Mule ESB, end- points, connectors, and routers are defined in XML. In Spring and Mule, a JavaBean and two configuration files are created to accept the order information, but the conversion of the file contents to XML and the validation that corrects quantities require additional Java coding. A Web service adapter is then configured in XML to place orders.
In another case, a client of ours needed to merge a product catalog with the complementary suite of products of the acquired entity. On a short deadline with a staff of developers already assigned to ongoing projects, a commercial ESB was the best option--business analysts were able to visually orchestrate the process flow without any coding. In less than a week, adapters using the ODBC standard were doing lookups in the two databases at different locations based on some visually defined logic. In addition, a Web service entry point was exposed for third-party vendors to have access to the entire suite of products from both databases. Here, a product that required extra coding and technical expertise would have presented a significant obstacle.
Testing is a good place to gain experience with open source products. As soon as a Web service is created, developers tend to immediately create a small test client using their language of choice, especially true during early initiatives such as a SOA pilot phase. When it comes to standalone testing, JMeter and SoapUI offer the same features as many commercial products, with enough features to thoroughly test a SOA pilot project. You may already be using JMeter for testing Web applications, but SoapUI should definitely be in everyone's arsenal of tools as well. If additional features and support are needed, check out SoapUI Pro, which offers more features for $350 per year; or PushToTest, which integrates SoapUI and offers free downloads and paid subscriptions.
Compare this with commercial product prices, which are usually licensed per CPU with support plans that come in at 15% to 20% of the CPU license at a minimum. This translates into a $75,000 to $100,000 cost just to get started with a commercial product.
SHORT ON GOVERNANCE
- Time to market is reduced and integration costs are lower
- Feature-rich governance platforms and mature testing and Web service products can be customized as needed
- Open source ESBs aren't business-user-friendly
- Implementation can be slow and costly for sites that haven't mastered the framework, component model, and XML scripting
- Apache, Eviware, Iona, JBoss, Mule, PushToTest, SoapUI, WSO2
Unlike the ESB, where multiple open source products are available, when it comes to SOA governance, there's only one open source solution on the market: Mule Galaxy. This isn't necessarily a bad thing, because the entire community's effort is focused on developing and refining one platform that definitely delivers and matches the abilities of its commercial counterparts.
Mule Galaxy offers Web administration console artifacts such as XML, XSD, and WSDL files that can be entered into the registry. IT teams can apply and enforce policies, and users can manage life cycles and dependencies, as well as run reports. The platform supports auto-discovery of services and exposes an Atom publishing interface that's easy to use. These are the same features in commercial products, so Mule Galaxy should get a look when you're shopping for governance options.
The Mule ESB in particular offers additional tools for monitoring, management, availability, and performance (Mule HQ and Mule Saturn) in its paid subscription, which companies that need high availability, high performance, and technical support should consider. As with all open source projects, community support always is available via online message boards, though that's probably not sufficient for businesses.
The cost of most SOA-related open source products comes down to time, effort, and, probably most important, technological expertise. To effectively implement an open source ESB, IT teams must be ready to learn the framework, component model, and XML scripting model, as well as have a good working knowledge of Spring and Java. For companies with the talent and time, the excellent governance and testing features, as well as scalability, expendability, reliability, and availability out of the box, make open source products viable alternatives to costly commercial products.
Cristian Sturek is founder and principal SOA architect of XWebServices, with more than 12 years of experience in enterprise architecture.
Photo illustrations by Sek Leung