InfoQ has published a sample chapter from the book “Open Source ESBs In Action”, authored by Tijs Rademakers and Jos Dirksen, and took the opportunity to interview the authors about their experience in using open source ESBs in real-world projects.
InfoQ: Given the current state of open source ESBs, would you consider them to be on par with commercial alternatives?
Tijs Rademakers (TJ): I’ve had the privilege of working with both commercial (closed source) and open source ESBs. What I found striking when working with Mule ESB is that it makes the complex work of enterprise integration and service orientation a bit easier. Working with commercial ESBs means huge license costs upfront, heavy install procedures, having to learn a new IDE and having to learn from the documentation available and the after sales consultants. After you have dealt with this upfront costs, the well-known closed source ESBs like WebSphere, Tibco, Sonic etc do their thing well. With an open source ESB you start with downloading the ESB and after 10 min you have the ESB running with some of the available examples. Then you’ll have a look at the example configuration file and you’ll be able to implement your own integration solution quite easily. Implementing a piece of custom functionality means writing a Java class and working with Mule ESB Java API. This is very easy to understand for Java developers. And if you don’t understand anything, then there’s an active and large community available to ask questions on the mailing list.
Jos Dirksen (JD): I think that the current frontrunners in the open source space are certainly on par with the commercial alternatives when you look at the core ESB functionality. Routing, transformation and connectivity for instance are all aspects where open source ESBs are certainly on par, or even better than a lot of the commercial alternatives. Also on the subject of ease of use I think that open source ESBs score better than many commercial offerings.
TJ: And what may be a bit surprising is that the functionality of open source ESBs is quite similar to its commercial alternatives. And what’s even more striking is that the configuration and development of integration solutions is far more developer friendly due to easy configuration mechanisms and a clean API. Commercial offerings often provide an IDE where you can drag&drop and click your integration solution together, which works very well BTW, but it can be quite painful to implement something which is not provided by the drag&drop support. So in short, you really should consider open source ESBs when selecting an ESB for your organization.
InfoQ: What’s your view on the role of an ESB in an SOA? Should it be the central, focal point or live at the edges?
JD: Depends on the scenario. Often you hear that every SOA architecture should have an ESB at it’s core but I don’t really think it’s necessary. If you’ve already got a modern (e.g. web service oriented) architecture it’s not always needed to introduce an ESB. If you introduce a registry in that scenario you can create a very nice and elegant service oriented architecture. When you’ve got a more heterogeneous environment (e.g. lots of legacy, .net in combination with java, mainframes) you’ll probably require a more ‘intelligent’ integration layer to expose these application in a service oriented manner. In that scenario I think an ESB should be the central point of the SOA.
TJ: SOA is declared dead by some, so I certainly don’t want to put an ESB in that list :-) I think SOA is a far bigger topic than just integration legacy systems and providing services via an ESB. SOA has a business view and a technology view and an ESB is foremost about technology. So an ESB is a small, but important part that can be used to implement an SOA. An ESB is a vital part that can provide functionality like routing, transformation, security and protocol translation which can help to let services communicate with each other and to let (BPEL) processes communicate with services.
InfoQ: Where do you see the most room for improvement in open source SOA solutions, what do you miss most?
JD: What I miss most… Interesting question. What I personally miss most is a really good integrated solution. When we do SOA projects using open source we usually use more than just an ESB, we for instance also require a BPM engine. Currently, although it’s improving, the integration between BPM engines, rules engines and the ESBs isn’t perfect. So often we need to write our own integration code between these components. I think that this is an area where big improvements can be made.
TJ: Actually there is a lot of activity in the open source SOA projects space. There are ESB projects (Mule, ServiceMix, Synapse, Open ESB etc), BPM projects (JBoss jBPM, Apache ODE, Open ESB BPEL component etc), service registries (Mule Galaxy, WSO2 registry etc), business rule engines (Drools/JBoss Rules). So there are a lot of great SOA projects available. But I think there’s some room for improvement to get these components integrated. Commercial or closed source SOA offerings are a bit ahead, because they provide a full stack of SOA tools. But the downside there is of course vendor lockin.
JD: The area where I think the open source ESBs could improve are in the management and in graphical support. When you look at the commercial ESBs out there, their management support is usually better, also in the area of supporting tools, development environments the open source ESBs could do with a bit of improvement. The latter I think, however, is less important for power users, since they’ll probably dive deeper in the ESBs than the graphical tools restrict you to. For me personally, I’d like to see a good integrated solution, offering BPM, business rules and a good service repository.
InfoQ: Do you have some non-functional statistics you can share from case studies?
TJ: Hard question. Non-functional statistics are often difficult to retrieve, certainly in a ESB environment. But we have done projects with multiple messages per second on Mule ESB with JORAM as messaging engine.
JD: The current project I’m working on is a project which handles the interactions between residents of a city and the local authorities. This is a system based on Mule where we have 800.000 citizens communicating through a .net frontend to a set of backend services. All the interaction between the services is done over Mule. Mule also exposes a set of old backend applications as web services.
InfoQ: How would you classify the advantages and disadvantages of MuleESB vs. ServiceMix, respectively? Any recommendation on when to use which?
JD: Both have their advantages and disadvantages. I like the model of ServiceMix which makes it very easy to hotdeploy new integration flows and the fact it’s based on standards. Even though the JBI standard didn’t gain that much traction it’s a very nice specification which makes working with ServiceMix very straightforward when you understand JBI. I like the way you have pluggable components for integration, and that even those are hot deployable. The inclusion of Camel is also a very strong point for ServiceMix. I really like having a DSL to develop integration flows in.The disadvantage of ServiceMix is pretty much tied to its advantages. The JBI spec does introduce another level of difficulty and the focus on XML doesn’t always fit too well with the requirements you encounter in the integration space. Mule on the other hand makes it very easy to create integration flows and is very straightforward. It has a very extensive set of routers, is easy to extend and has a lot of connectivity, routing and transformation options right out of the box. With Mule you can have fairly complex integration flows up and running in minutes. Mule, however, does have some disadvantages. Not that much though, but the one that is the biggest disadvantage for me personally is the fact that you can’t hot deploy new integration flows. If Mule should integtate OSGi or some other way to easily update integration flows that would be a big plus.
TJ: ServiceMix is currently divided into two seperate projects, ServiceMix 3.2.x/3.3.x and ServiceMix 4. In our book we use ServiceMix 3.2.x (JBI-based), but we also have a short introduction in ServiceMix 4 (OSGi- based, with support for JBI). So the main difference between ServiceMix and Mule ESB is that ServiceMix is based on JBI and Mule ESB implements a Java based custom model. But there’s also a lot of overlap between both ESBs (Spring support, web service support with CXF, XML configuration). But let’s focus on the differences.
Mule ESB is a Java centric ESB, which makes it very easy for Java developers to start working with it. There’s a real powerful set of XML schemas which makes a really clean and readable XML configuration and provides code completion support. When you want to implement a piece of transformation logic or routing logic you can easily develop a simple Java class / Spring bean / script file and include it in the XML configuration. If I have to name one downside of Mule it has to be the lack of support for hot deployment.
ServiceMix is a JBI centric ESB which provides a lot of JBI components like JMS, Web service, Camel and BPEL components. And of course you can also use JBI components from other JBI based ESBs also, like PEtALS and Open ESB which we show in the book. ServiceMix provides an easy XML configuration language for each JBI component and provides hot deployment functionality to deploy your integration solution. A downside of ServiceMix is the learning curve to get into JBI. So it’s a question about what you like most to choose between Mule and ServiceMix. ServiceMix provides JBI support, BPEL integration, XML message focus and hot deployment functionality. Mule provides a Java centric model, jBPM support, message agnostic support without hot deployment functionality.
JD: Which one to use really depends on your requirements. When you’ve got an XML standards focussed landscape to integrate with ServiceMix is a great option. If you need more low level integration Mule might be a better choice. Both of these ESBs are great open source integration solutions that will be a good match for a lot of integration problems.
InfoQ: Why did you end up choosing ServiceMix and Mule over other alternatives? Any opinions on Apache Synapse or Spring Integration?
TJ: ServiceMix and Mule are great examples of mature open source ESB with a very active community which represent a JBI focused ESB and a Java centric ESB approach. We also considered other alternatives, with Apache Synapse as the main alternative. BTW, we have included examples for both Apache Synapse as well as Spring Integration in the book. Apache Synapse is a great example of a web service focused ESB, based on Apache Axis2. When you are foremost looking for WS-* support and Rest support Apache Synapse is certainly an ESB you may want to consider. Spring Integration is a nice framework which I find very comparable with Apache Camel. They both provide support for the Enterprise Integration Patterns described by Hohpe and Woolf which you can easily integration into your Java application without the need for a separate integration container. So these frameworks are quite useful to be able to implement integration functionality on an application level without the need to introduce a central ESB container.
JD: I personally haven’t done that much with Spring integration, we’re currently using it for a smaller project to get the feel with it. What we like so far is the fact that it’s a very lightweight solution which is very easy to combine with the rest of the spring application we were writing. When we started writing the book the open source ESB space was less mature then it is now, and there are more mature solutions at the moment.
TJ: Be sure to watch the open source ESB space, because there’s a lot of activity and a lot of projects and active communities available to choose from!
InfoQ: Thank you!