WSO2: A lightweight, fast, and free ESB

Open source WSO2 ESB 1.0 makes XML messaging easy to deploy and easy to manage, but lacks high-availability options

With the increased adoption of SOA, companies are finding the ESB (enterprise service bus) the "must have" application to connect disparate systems. Although a number of open source ESBs, such as Mule, OpenESB, Apache ServiceMix, and JBoss ESB have been around for a while, these products take a relatively heavyweight approach to integration by implementing the JBI (Java Business Integration) specification. A more recent open source arrival, WSO2 ESB, takes a lightweight approach, focusing on integration based on Web service standards.

WSO2 ESB is based on the open source Web service mediation and routing engine, Apache Synapse, released in June 2007 after two years of development effort. Synapse was written with the goal of providing fast XML message processing.

Click for larger view.
WSO2 provides several enhancements to the Synapse framework, and a few of the Synapse committers work for WSO2. Among the enhancements are a browser-based GUI for configuring the ESB; an integrated registry for browsing, loading, and configuring services; and graphical management and monitoring tools. All of these enhancements are released under the same open source software license, the Apache License, as Synapse itself. WSO2 also provides several intangible enhancements to Synapse, such as sponsoring an active user community, providing commercial support, and offering a Web site with tools and forums.

Of the WSO2 enhancements, the Web management console is one of the most useful. Although the underlying XML-based configuration files are not terribly difficult to understand, and clear examples are provided for most common EAI patterns, the console makes mistakes less likely. This is especially true in environments where the operators and administrators of the ESB are not developers, commonly the case in larger enterprises. Proxies, end points, and sequences can all be created and managed via the DHTML-based management console. Although configuring the ESB does require some knowledge of the underlying ESB principals, the task is significantly easier in this environment.

The WSO2 management console also provides useful monitoring functions, allowing administrators to see graphical depictions of message traffic to proxies, end points and sequences, as well as details such as min/max/average response times, faults, and total message counts.

Click for larger view.
A simple registry
The WSO2 ESB includes a simple file-based registry that can be used to dynamically update the ESB by deploying new configuration files. The "integrated registry," as they call it, can be referred to by any particular instance of the ESB, so any number of ESB servers may be deployed with the same configuration. Local registry entries can override remotely derived values.

The simple registry works well enough, but making a remote file system available to all running instances of the ESB isn’t feasible in most production environments, where the ESB is likely to run in a clustered, high-availability configuration.

That said, one advantage to a file-based registry is ease of integration into an organization's existing change management practices. Most commercial vendors have their own form of version control for registries, and shoehorning these schemes into the IT organization's way of doing things is a constant source of frustration for the customer. WSO2 has a separate registry project that will ultimately provide a full feature set; hopefully it will also make it easy to adopt different change management practices.

Apache Synapse provides the core message mediation and transformation framework for the ESB. As such, it doesn’t include a JMS (Java Message Service) provider of its own, but works with third-party providers such as ActiveMQ. Synapse was designed with speed, low overhead, and scalability in mind. By optimizing its design at a network level, and focusing on XML messages, it claims some impressive performance figures, exceeding the performance and scalability of an unspecified proprietary ESB by a significant margin. WSO2 also touts better performance than some of the open source ESBs. I was unable to verify these performance claims, but hope to do so in a future article.

Standard Web services
On the messaging side of things, WSO2 ESB (that is, Synapse) supports a number of advanced Web services standards, among them standards for reliable messaging, security, and message policies. Transmission of binary payloads is also supported by MTOM (Message Transmission Optimization Mechanism) and SwA (SOAP with Attachments). The transport side of things seems heavily slanted toward HTTP/S, but JMS is also available, including SOAP over JMS, although with a proprietary binding.

Messages may be manipulated by any of the Apache BSF languages, such as JavaScript, Groovy, and Ruby, and there’s native support for E4X (ECMAScript for XML) and REXML (Ruby Electric XML). The Synapse framework itself may be extended by custom Java classes, or via the Spring Framework.

Setup was very easy: Unzip the files, start the ESB, and then log in to the management console. I took the hard route, just to see if I could throw a spanner in the works, by compiling from source code and using Tibco Enterprise Message Service as my JMS provider. After a bit of reconfiguring the examples to use the Tibco JAR (Java Archive) files, everything worked without a hitch.

For a product that is a dot-zero release and less than six months old, WSO2 ESB works remarkably well. A few things are missing that might make some enterprise customers wait for future releases -- primarily deployment options. The biggest limitation is a lack of good high-availability options, which is a bit odd considering the application server offered by WSO2, WSAS, supports clustering and high availability. There are ways of achieving high availability with Version 1.0, but clearly this release is focused on messaging functionality, not on meeting mission-critical deployment requirements.

Version 1.5 of the WSO2 ESB is only a couple of weeks away at the time of this writing, and it promises the capability of deploying into J2EE containers via existing container transports, as well as clustered deployment into the WSAS (Web Services Application Server). In addition to expanded deployment options, Version 1.5 promises file-based transports via Apache VFS (Virtual File System), message splitting and aggregation, XQuery transformations, database lookups, and more.

A work in progress
An ESB is often the entry point along the road toward SOA adoption. A service bus makes it easy to begin sharing services among applications with little development effort and minimal impact on existing infrastructure.

The WSO2 ESB is limited to organizations basing their messaging on XML. It's also worth noting that, unlike commercial SOA suites from the likes of BEA, Cape Clear, Oracle, Progress Sonic, and Tibco, which typically package a full-fledged development environment, a BPEL orchestration engine, plug-ins and adapters to enterprise applications, and other bells and whistles with their ESBs, WSO2 strictly provides the software backbone to route and transform XML messages.

But with its focus on fast, scalable, and reliable message mediation, and its support for Web service standards, this ESB would be well suited to organizations with high transaction volumes, such as banks and financial institutions. If your organization has adopted a CIM (Common Information Model), then the WSO2 ESB would fit in perfectly.

The biggest factor hindering its acceptance now is the lack of deployment options for organizations requiring highly available solutions. If your organization is ready to take a "roll your own" approach to HA, or is doing so now, then WSO2 is ready to be considered as a content-based router (CBR) or XML appliance. A number of XML appliances on the market tout their hardware acceleration for speedy XML processing, but if the numbers are to be believed, WSO2 ESB can provide nearly equal performance at a fraction of the cost.

Organizations with broader requirements for an ESB should consider WSO2 for non-critical applications until a HA strategy is rolled out by the vendor. Development of the product is active and proceeding quickly; if progress continues at the current pace, a few more releases would make WSO2 worthy of consideration in most enterprise-level ESB deployments.

InfoWorld Scorecard
Features (20.0%)
Security (10.0%)
Value (10.0%)
Interoperability (30.0%)
Scalability (15.0%)
Management (15.0%)
Overall Score (100%)
WSO2 Enterprise Service Bus 1.0 6.0 7.0 9.0 6.0 9.0 7.0 7.0

Copyright © 2007 IDG Communications, Inc.