Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Open source ESBs: please collaborate!

DZone's Guide to

Open source ESBs: please collaborate!

· Integration Zone
Free Resource

The Integration Zone is brought to you in partnership with Cloud Elements.  What’s below the surface of an API integration? Download The Definitive Guide to API Integrations to start building an API strategy.

Although you may have the feeling it's a bit quiet in open source ESB space, there's still a lot of innovation and work being done in these projects. Some weeks ago Mitch from DZone posted a nice overview article of his list of top open source ESBs and this made me think again about some things that kept me busy when writing the open source ESBs in action book:

- Which open source ESBs are available out there and what are the differences?

- Almost every company I know uses a commercial company-wide ESB, so why all the fuss about their open source ESB counterparts?

- When/why should I use an open source ESB?

These are all very relevant questions and certainly the last question is always difficult to answer in general, but in this article I want to talk about two other things:

1.) Why do the big vendors make their ESB products so #@&# difficult to install and to use and how can this be so easy with their open source counterparts?

2.) I like diversity, but can there maybe be a bit more collaboration between open source ESB projects?

Please consider open source integration products

I find it really striking to see that big integration vendors still are able to succeed to sell their products for large sums of money. In the application server market, commodity is the keyword and vendors are not able to ask for large sums of license fees any more. Apache Tomcat, JBoss, Glassfish etc have become real competitors of WebSphere and the Oracle application servers. But why hasn't this happened with ESBs?

In my opinion, open source ESBs can really compete with their big vendor counterparts on core functionality like routing, transformation etc. And from what I've seen in a number of companies, typically their ESB implementations do nothing more than providing services (Web services, JMS, MQ etc) to foremost front-end applications. So this involves not a lot more than the ability to publish services and add a little bit of routing and transformation to it.

But hey, you say, are these open source ESBs reliable? Yes sure, reliability in the integration space is mostly about not losing messages. Well, open source products like Apache ActiveMQ prove that this is true.

But what about development and testing, isn't that easier and of better quality with these big vendor products? No! It' s different when you use an open source ESB but certainly not more complex or of less quality. Open source ESB products mostly have minor wizard and drag&drop support to build your integration flows, but they excel in simplicity and speed of development. Just look at the starting time of some big vendors products and compare that with starting Mule, ServiceMix, JBoss ESB etc.

So you have made a nice list of strong and weak points of a short list of ESB products and then you go to the board of directors. You have made their choice easy: pay 0.5 million EUR for vendor A or get product B for free (and pay 50.000 EUR for support, if you want to). They each have the same number of total points from the strong and weak list. From what I've experienced, the board of directors will decide to go with the 0.5 million deal because they want long-term support and a solid company behind the software products they use.

But times are changing! This economic crisis has brought a lot of bad things to the IT market, but I see possibilities for open source products. To my experience, management is now willing to look at less expensive alternatives (even, God forbid, open source products). So I think this is a great time to look at the open source ESB projects again and maybe you can look at replacing your expensive integration environment, with some open source products.

Let me stress that I don't have a commercial interest in this, but that I really think this is the way we should go forward in the integration space. We need open products, that can rely on a strong community and we do have a need for less complexity and more ease of development.

Open source ESB developers, please collaborate!

The second point I want to discuss is the difficulty to choose between open source integration projects (notice that I dumped the word ESB, because what we are really talking about is enterprise integration). There are so many initiatives out there that it's almost impossible to get a good overview, but I'll try to sum up a number of open source integration projects with some keywords:

- Mule: Java based, very lightweight, lots of connectivity options.

- Apache ServiceMix 3 (or FUSE ESB 3): JBI based, XML message focused, hot deployable.

- Apache ServiceMix 4 (or FUSE ESB 4): OSGi based with JBI support, message format agnostic, great example of OSGi strong points.

- JBoss ESB: integrated with JBoss application server and other JBoss frameworks (Drools, jBPM),  matured in the last year.

- Open ESB (or Glassfish ESB): JBI based, nice tool support with Netbeans.

- PeTALS ESB: JBI based, SCA support, tool support is added recently.

- Apache Synapse (or WSO2 ESB): strong WS-* support, easily pluggable, hot deployable.

- Apache Tuscany: SCA support, not a typical ESB but focuses on providing and consuming services.

- Apache Camel: Java, Scala, XML DSL, EIP implementation, doesn't contain a container but consists of JAR files you can add to your project.

- Spring Integration: integrated in the Spring framework, EIP implementation, als doesn't contain a container but consists of JAR files you can add to your project.

Of course this is just a list of the open source integration projects I know best and the few words can not sum up all the functionality these projects offer, but it gives some insight.

Although I do have a lot of sympathy for these projects and I do think diversity to some degree is good to have, certainly beween open source projects, I can't reach to another conclusion, we need collaboration!

Do you think it's good that there are 3 JBI based ESBs on this list, that are almost identical in the functionality they provide? Wouldn't it be nice to see that the ideas of JBI, a pluggable ESB container where you choose an implementation of each ESB component (routing, transformation, authentication) freely, would be realized in the open source space. Well, this is not the reality, just look at how hard it is to get a Open ESB JBI component working on for example Apache ServiceMix.

Good examples of collaboration are Apache ServiceMix and Apache Camel. You can use Camel out-of-the-box in ServiceMix and in version 4 it's even the core EIP component of ServiceMix. But this is really an exception in the open source integration space. It's even worse, you can find quite some flame wars between several projects when you search the mailing lists a bit.

To be able to offer great tool support, good management tools and to further expand the functionality and drive innovation in the open source integration products, more developers are needed. And of course this can be reached inside each individual project when it's successful, but wouldn't it be even better if there was a bit more collaboration between the projects?

I'm very curious about your thoughts on this and also about which open source ESB related topic you would like to see another article being written. For example, does a detailed comparison between the different projects makes sense? Please write your comments below.

For now, hope you enjoyed reading this article, and maybe you can help to make the integration space more open.

The State of API Integration Report provides data from the Cloud Elements platform and will help all developers navigate the recent explosion of APIs and the implications of API integrations to work more efficiently in 2017 and beyond.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}