Enterprise Integration Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2578 posts at DZone. You can read more from them at their website. View Full User Profile

Top Open Source ESB Projects

10.29.2009
| 163925 views |
  • submit to reddit
In today's software markets, open source technologies are giving commercial products some stiff competition.  Enterprise Service Busses are no exception.  Don Rippert, the chief technology officer at Accenture says, "ESBs are software products that allow you to create a business process with web services running on different platforms."  Rippert believes an ESB is essential for achieveing the full potential of service-oriented architecture.  In general, an ESB should provide flexibility built on a basis of standards.  Jos Dirksen, an author of "Open Source ESBs in Action," said in a recent interview that today's top open source ESBs were "on par with commercial alternatives."  Competition drives innovation, and this page has a list of the most competitive open source ESBs on the market.

Here are the the forerunners among open source ESBs (in no particular order):

JBoss ESB

JBoss
JBoss generally has mature components in its GA releases with no vendor-lockin characteristics.  Their ESB leverages JEMS technologies like the JBoss business rules engine for content-based routing and messaging. Content-based routing on the JBoss ESB can use Drools or XPath.  The JBoss ESB supports XSLT and the Smooks transformation engine for XML and non-XML data formats.   JBoss' ESB also runs on the JBoss application server and features a pluggable architecture for swapping out ESB subsystems.


Apache ServiceMix

Apache
Apache ServiceMix 4 is OSGi based and a great option for integrating with an XML standards focussed landscape.  Apache ServiceMix makes it very easy to hot-deploy new integration flows.  Even the pluggable integration components are hot deployable.  ServiceMix uses a JBI standard which provides a lot of components like JMS, BPEL, Web service, and Camel.  The inclusion of Camel is a strong point for ServiceMix along with the Spring Framework, which is also supported.  FUSE ESB is another great distribution of Apache ServiceMix.


OpenESB

Sun(Oracle)
OpenESB has an easy learning curve due to its solid integration with the GlassFish Application Server and Sun's popular IDE, NetBeans. The Netbeans IDE provides countless integrated functions for administration and development.  The best thing about OpenESB is its toolset.  OpenESB's tools include WSDL and schema editors, a JPI manager integrated into the service manager, and Ant running in the background.  Another tool is the Composite Application Service Assembly (CASA) editor, which gives you a graphical overview of integration applications.  Many Java developers will love OpenESB because it comes straight from the home of Java.  OpenESB is also OSGi based.


MuleESB

MuleSoft
Mule is the most used open source integration platform.  MuleESB's low cost along with easy configuration, expansion, and flexibility make it very popular.  Java developers will find MuleESB easy to work with because it is Java centric.  There’s also a powerful set of XML schemas in MuleESB.  The creation of integration flows is very straightforward.  MuleESB can have fairly complex integration flows up and running in minutes.  It has many connectivity, routing, and transformation options right out of the box. 


WSO2 ESB

WSO2
Other ESB products take a relatively heavyweight approach by using the JBI specification, but the relative newcomer, WSO2, takes a lightweight approach in its ESB.  It does this by focusing on Web service standards for integration.  The WSO2 ESB uses Apache Synapse, a nimble Web service mediation and routing engine that focuses on providing fast XML message processing.  WSO2 takes advantage of Synapse's non-blocking http://s transport implementation over the Apache HttpComponents/NIO module.  This allows the WSO2 ESB to handle thousands of parallel requests using a small amount of resources and threads.  You can always expect great XML support from the WSO2 ESB because well-known XML expert James Clark is a company director at WSO2.
AttachmentSize
apache_logo.jpg5.92 KB
jboss_logo.png13.16 KB
MuleSoft-Logo.jpg5.6 KB
sun_logo.jpg7.31 KB
WSO2_logo.gif4.7 KB

Comments

Stefan Krause replied on Fri, 2009/10/30 - 2:16am

Comparing those ESBs is very confusing which makes it extremely hard to choose one.

  • What's the purpose of an ESB?
    Do you want to deploy code for your services into an ESB (JBoss ESB, Mule and ServiceMix), which turns it into a kind of next-gen application server, or do you want to have just a bus (Synapse) that proxies services and does mediation, routing and transformation (To me this sound pretty much what an ESB should actually be).
    Who needs a registry (only WSO seems to have a useable one)?
  • How about Enterprise Integration Patterns vs. BPM?
    BPEL is supported on OpenESB (with excellent Netbeans support - if you want to stick with Netbeans 6.5), but there appears to be no production ready human-task extension (which means it just won't work for real life projects)
    JBoss ESB has support for jBPM, but they started to develop Riftsaw which makes jBPM's future in JBoss ESB uncertain.
    Apache ODE (also without human tasks) can be used with ServiceMix.
    Support for monitoring and administrating those processes is minimal in all of those tools.
  • What about logging and monitoring?
    Except for WSO2 I don't think they have useable support for that essential feature. The JMX console from ServiceMix is a start, but I don't think your admin will appreciate that.
  • Complexity of development
    Ever tried to develop with JBoss ESB? Those config files with their dependencies are actually no fun. ServiceMix 3 (better those of JBI) deployment artefacts are no better. Both are way too complicated and Mule shows how much easier configuration can be.

I'm really excited hearing about your experiences (and correcting my statements ;-) ) and your thoughts about those ESBs.

There are two more projects that I'd like to mention:

  • Apache Tuskany. The SCA model to create composite services appears way more natural to me that trying to achieve that with xml tricks.
  • Spring Integration. I don't know whether it's an ESB, but it's close to what other ESBs from your list can do. It seems like a very natural and easy way to apply the Enterprise Integration Patterns. Compared to ServiceMix Spring Integration brings fun back into EAI.

Lukas Zapletal replied on Fri, 2009/10/30 - 2:28am in response to: Stefan Krause

Well but Mule is the Apache ServiceMix. Is the configuration really nicer? I think making ESB with Spring Integration is not good way. I saw very similar approach in a really big company and they are (still) failing...

Martijn Verburg replied on Fri, 2009/10/30 - 4:57am in response to: Stefan Krause

Hi there, It's interesting that you mention Logging and Monitoring (and I'll add Management to the mix). It's something the Ikasan Open Source EIP (Alpha at this stage) is focusing heavily on. The existing users of Ikasan want to be able to see exactly what's going on with their messaging in real time in a professional looking UI, it's an interesting challenge! Cheers, Martijn

Artti Jaakkola replied on Fri, 2009/10/30 - 5:29am

I think Apache Camel should be promoted to that list as well. It doesn't have so much bells and whistles, but I think it has a very nice way of enforcing good practices, like loose coupling instead of promoting synchronous and increasingly monstrous SOAP/WS-*/BPEL solutions to its users.

Tijs Rademakers replied on Fri, 2009/10/30 - 8:33am in response to: Stefan Krause

Nice list of open source ESB products. I want to add that if you mention the open source vendor for the other products you should also use the FUSE ESB product in stead of / in addition to the Apache ServiceMix product.

I don't really get the difference Stefan mentioned between Synapse and the rest of the ESBs. To my opinion you must also deploy your services within Synapse and it also provides a container just like Mule and ServiceMix. What I do think differentiates JBoss ESB and OpenESB from the others is that they run on an application server (JBoss ESB on JBoss and OpenESB on Glassfish).

I do think that Mule Galaxy is a useable registry in addition to the WSO2 registry.

I agree that development with JBoss ESB is a bit harder at first. Mule provides a great XSD schema set that makes it really easy to develop your configurations. But I do think that the configuration of JBoss ESB is also pretty lean and mean and after you get familiar with it, it's also very easy to use. For ServiceMix it should be mentioned that ServiceMix 4 (which is OSGi based by the way) has out-of-the-box support for Camel configurations and that's just great. With Camel you can choose between a XML based configuration and a Java DSL configuration which are both really great examples of how you can keep complex stuff very simple!

In addition to these container (Mule, ServiceMix, OpenESB, Synapse, JBoss ESB) based ESBs, several other frameworks are available that provide ESB like functionality but don't run in a container. You just copy the JAR files into your project and you can use ESB functionality in each Java application you like. Therefore Apache Camel and Spring Integration should certainly be mentioned here. It's interesting to see that Camel and Spring Integration have a similar foundation in supporting EIPs.

Apache Tuscany is another addition to the open source integration / service frameworks. Apache Tuscany is SCA based and provides a standardized, clean service framework. However don't look for routing and transformation functionality in Tuscany, that's not it's purpose. I always use the following matrix to clarify the distinction between the popular open source integration frameworks:

Mule --> Custom architecture, XML based configuration, easy for Java developers
ServiceMix 3 --> JBI based, focus on XML messages
ServiceMix 4 --> OSGi based, integrated with Camel configuration, also provides support for JBI
JBoss ESB --> Custom architecture, runs on JBoss application server, fits great with JBoss products
Synapse --> Focus on WS-*, Rest, build on Axis 2, great if you need things like WS-Security etc
OpenESB --> JBI and OSGi based, runs on Glassfish, nice tool support with Netbeans
Camel --> XML and Java DSL configuration, no container, support for EIPs and lots of transports
Spring Integration --> XML and Java annotation configuration, no container, support for EIPs
PetTALS --> JBI based, nice admin console, French based
Tuscany --> SCA based, provides support for WS-*, focus on service development not integration

Best regards,

Tijs Rademakers
Author of Open Source ESBs in Action

Stefan Krause replied on Fri, 2009/10/30 - 10:46am

Hi Tijs,
first of all thanks for your book - I enjoyed reading it.

> I don't really get the difference Stefan mentioned between Synapse and the rest of the ESBs

To me it seems that Synapse focuses on its proxying capabilities. You have an existing remote service and make that service available on your ESB. The other ESBs appear to focus on deploying business logic into the esb and making that available as a service (Granted mule and service have proxy capabilities but they promote it much less and it appears to work worse). To me that appears to be a large difference, since it limits you on the programming model and environment of the ESB and changes the paradigm what the premier purpose of an ESB is. 

 

Tijs Rademakers replied on Fri, 2009/10/30 - 11:16am in response to: Stefan Krause

Hi Stefan, Thank you. I understand your remark better now. I agree that the primary focus of Synapse is to provide proxy functionality. However Synapse certainly doesn't limit you to that, because also in Synapse it's possible to implement business logic. With ESBs like Mule and ServiceMix it's first of all up to the developer to decide if they want to implement business logic inside the Mule and ServiceMix container. You can decide to just implement routing, transformation and for example security contraints. But I agree that Mule and ServiceMix can also be used as a container to host your services, and that's certainly not traditional ESB functionality. I do think that open source ESBs can however be a good choice to be used as a container to host your business logic, because you can easily expose it via al kinds of transports. But an infrastructure with Mule or ServiceMix and a JEE application server is of course still a valid option. Best regards, Tijs

Rodney Bollinger replied on Sat, 2009/10/31 - 1:05pm

Hi Tijs, Stefan, I would very much like to hear your thoughts on the Swordfish ESB entry from Eclipse. How does this product rank amongst those mentioned and what compelling value is added (or necessity omitted) compared to the others? Your time and feedback are most appreciated. -Rodney

Stefan Krause replied on Sat, 2009/10/31 - 2:15pm

Sorry Rodney, I haven't looked at Swordfish yet.

Tijs Rademakers replied on Sat, 2009/10/31 - 2:34pm

Hi Rodney,

Good question, I must say that I was a little bit suprised when I saw the description and the frameworks choice of Swordfish ESB. It seems to be ServiceMix 4 + a registry. Now you asked this question I took some time to look at the current status of the Swordfish project and I find it a bit difficult to say. There is almost no material (presentations, how to's and articles) available. Also, most (maybe all) committers seem to work for Sopera. So maybe a swordfish developer can provide a better answer, but I would say at this point, interesting proposal, but I prefer ServiceMix 4.

Best Regards, Tijs

john green green replied on Fri, 2009/11/27 - 12:06pm

WSO2 takes advantage of Synapse's non-blocking http://s transport implementation over the Apache HttpComponents/NIO module. This allows the WSO2 ESB to handle thousands of parallel requests using a small amount of resources and threads. You can always expect great XML support from the WSO2 ESB because well-known XML expert James Clark is a company director at WSO2.
nike china shoes

Laurent Guerin replied on Mon, 2009/11/30 - 11:35am

Why don't you mentioned PETALS ?

Petals is a very efficient Open Source ESB ( certified for JBI )

For more informations see  http://petals.ow2.org/

Mat LEB replied on Tue, 2009/12/01 - 4:21am

Oh, this is great ! I read your article a month ago, but didn't add comment about Petals ESB to avoid raw advertisment (I work for Petals Link). But since Petals is quoted twice by other persons, and just had a major release, let's add some precisions.
Well, it is an ESB. Main differences (from my point of view...) are :

  • It's based on SOA standards as much as possible. It's JBI-certified, and supporting SCA, BPEL, and WS-Notification (for EDA).
  • It was the only distributed ESB for few years. But it's changing, I think Jboss, Open ESB and Glassfish ESB are engaging on this path. There is still some specific things, like hot-deployment of new nodes/servers. But mostly, it's more than a brand new (and probably great) feature, it's already working on large-scale production environnement.
  • Very recently, an eclipse SOA environment was launched, for configuring the ESB, debugging, and graphically designing BPEL/SCA. A registry/governance tool, and a business flow monitoring based on EDA were launched as well, to complete the ESB.
  • As say trademark, looks like the admin console is nice :)

Hope the precisions didn't look too much like an ad and were useful. You can give it a try at http://petals.ow2.org . Completely open to feed-back :)
(And would love to hear your comments)

emil gigi replied on Wed, 2009/12/02 - 8:10am



Beyond the useful facilities of asynchronous messaging and publish/subscribe (which provide the temporal and functional decoupling needed in many interactions - but by no means in all interactions), an ESB is just yet another container of web services, like a servlet container, a J2EE server or a .Net server. The only meaningful difference I see with them is that the services hosted in a ESB are usually created by scripting other web services (often, designed graphically) - i.e. something like a Unix shell, allowing to create new services by easy recombination of other existing services.

Now this is a handy thing to have in many cases, but just as the Unix shell is not the center of the architecture of the OS or the applications running on top of it, I do not understand how an ESB is supposed to be the cornerstone of a SOA. For me, such a "service scripting engine" would be much useful to implement some new services, but just at the same level as other services, being just another way among many others of creating them: you can use it for some things, but you have not to.

I think that a typical ESB will end up being a bag of domain (business) logic, on top of other business logic. And, being a new thing, the ESB must provide new means to develop, organize, manage and govern all that new logic - different from the way other more mature containers do, and thus that can be better - or worse.

Also, giving it such a paramount importance is just the same as saying that the other containers (e.g. a J2EE server) are not a means good enough for creating web services.

Besides, the ESB collides with the concept of a service registy/directory used at runtime (i.e. UDDI), which I think is one of the foundations of the flexibility of a SOA, providing a means for services to discover each other and thus allowing for dynamic binding.

For me, one of the best things of a SOA is that it is a republic - all services are equal and can talk to each other freely, not being a need (or vendor recommendation) for them to always go through a new, higher level component other than a directory. I do not see there a place for a "bus" through which all traffic must go through.

My opinion about ESBs is that they are more a marketing term that a sound concept. However, given the frenzy that can be read about them in many places, maybe I am wrong.

Asankha Perera replied on Tue, 2010/01/19 - 8:06pm

Hi

Just wanted to share one more into this list - the UltraESB from AdroitLogic. Its introducing Zero-Copy proxying for HTTP/S, with support for AS2 in addition to other transports such as JMS, Email, File, s/FTP/s etc. Comes with loads of documents and tools and the full download with samples is less than 25MB

http://adroitlogic.org

cheers

asankha

 

Daniel Manana replied on Fri, 2010/05/21 - 12:51pm

Well but Mule is the Apache ServiceMix. Is the configuration really nicer? I think making ESB with Spring Integration is not good way. I saw very similar approach in a really big company and they are (still) failing...Daniel

Frerk Meyer replied on Fri, 2010/06/04 - 6:11am

Mule is first of all a replacement for writing another data transport glue code. It may be useful as a ESB and even in a SOA context, but first of all it's very useful in data transport, routing and transformation which is otherwise hard coded again and again. Therein lies its success and widespread use.

Everytime I came over some jobs which look periodically in file system directories, temp database tables or incoming mails of structured content for a technical user I think, mule could replace it in a standardized, bug-free, performance optimized way with just a config file. And yes this would be only a technical more elegant spaghetti architecture. But it is a dream to force a clean SOA by introducing a technical product/framwork.

Other ESBs have an entirely different history and background. They developed from XML parsing document hubs or application server  extensions or scripting facilities for WS-* services. They are good at where they came from, but not necessarily fro the donkey work of transporting data from a to b.

Frerk

 

Carla Brian replied on Sun, 2012/07/01 - 5:54pm

An enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability.  - Kummetz Cop LLC

Chris Haddad replied on Sun, 2012/10/28 - 9:07am

A few relevant resource links:

 

ESB Use Cases Driving a a Successful ESB PoC

 

Do you have clear architecture, solution, and ESB PoC guidelines describing how your organization can wisely select integration infrastructure components and products?  

ESB Comparison

Can an eight year old product category, which is hotly contested by every middleware vendor, deliver unique and differentiating product offerings?

 

 

 

James Walker replied on Thu, 2012/11/22 - 8:46am

"ESBs are warehouse software solutions products that allow you to create a business process with web services running on different platforms.

Corey Deneire replied on Wed, 2013/05/15 - 8:33am in response to: James Walker

ESBs are somewhat similar to warehouse management software solutions but a different in the way they interact with the data and the ability to jump back and forth between platform types. 

Julian Alexander replied on Mon, 2013/08/05 - 8:21pm

Choosing the warehouse management system that matches the company's needs, requirements, budget, and expectations requires attention and a high degree of professional expertise.

Commonwealth Towers replied on Mon, 2014/04/07 - 9:17pm

“Together, these two government assistance schemes, at $167 million, translated to about 36 percent of town councils’ operating expenses. This is quite substantial and helps reduce the financial burden on residents,” noted Mr Khaw. purchased late last year

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.