fredag 19 november 2010

Comparing OSS offerings, like comparing apples to oranges

Rounding up the OSS integration frameworks described earlier is not easy and by no means a task of selecting an overall "winner". I've only scratched the surface on them, and most of the experience comes from testing simple samples, reading forums and blogs and in some cases implementing small solutions. There are also a bunch of frameworks that I haven't had time to test yet, so I'll focus on Mule, WSO2 and Apache Camel. Note that these are my personal reflections and experiences, so if you disagree completely, feel free to post so and call me a moron (maybe you're right :-)

Mule ESB
Marketed as the "most popular" open source ESB this was a good alternative to start with.
Mule is quoted as a stand-alone ESB and offers a wealth of connectivity options. The Mulesoft company behind it are very commited to the product and posts regular updates to the documentation as well as blogs.
However, the configurations are all designed by editing a quite cumbersome XML files which might offput some users wishing for less "bracket coding". Editing these files is only more constrained by the amount of schemas that needs to be included, i.e. each transport has its own schema and restrictions.
It supports a stand-alone runtime, hot deployments and extra functions such as registries and management consoles if you opt for the Enterprise license.
Mule was not created with EIP in mind from the startup, but updates in the most recent version made it easier to design flows through the "flow" construct even though I've already found some bugs while using it.

Out of the three, wso2 is the only one that requires sort of an application server to run in the form of the Carbon server.
However, the management console is outstanding with its included support for statistics and registry. You also have the option to graphically design your integrations which is always good for beginners.
There are three things that bother me with WSO2 at the moment though:

- Big focus on the WS-stack, which is not surprising given the WSO2 team background. If you're after a webservice framework, this product is perhaps the most promising of the three, but as far as I see it might not be perfectly suited for other integration scenarios.

- Synapse. WSO2 is built upon Apache Synapse, a project that doesn't have as much community activity as the other two alternatives. Only the future will tell if it will grow in the same pace as the other ones, but I'm at least a bit concerned about its future.

- The need for an application server
This might be a political issue, but I'd think it will be more difficult to sell in a new application server to your management than a simple API runtime. Other might see this as a strength, but when you're already sitting on a stack of servers you'll undoubtley will get the question why you'll need another one.

Apache Camel
The most lightweight alternative of the three I've tested and probably the most flexible as well.
Since Camel is built as an implementation of the EIP patterns it fits right in to creating integration flows, which is the logical way of implementing integration.
With Camel you get alternatives wherever you go. Do you wish to develop your flows through XML? Or maybe java? Or perhaps Scala or Groovy? Would you like to execute it in a spring environemnt? Or as a routing component inside the ServiceMix OSGi runtime? Or inside a web application? Options everywhere... Which is acutally a good thing! Hopefully your team and organisation can settle with one and develop best practices using the one you prefer. Otherwise you could end up with a mess of implementations, but this holds true for all types of development environments, so its not a problem per se.

The only downside I could possibly think of when using camel is that since it's so easy to use you might start putting integration logic all over your projects instead of at a central ICC team of integrators and designers. Integration is a very complex area and should be handled by dedicated staff with end-to-end focus in mind. Camel with it flexibility and pragmatic approach might lead you to solving integration tasks as part of application projects, but as you can see I'm only nitpicking for a possible future problem here.

I especially like the fact that they've started to experiment with Scala as a a first-class citizen as I personally see a great future in Scala. Having this support from the start gives me hope that this component will have a long future even after Java has been declared as "dead" or legacy.

As noted these are just my first impressions of the frameworks and I might be proven wrong or have missunderstood some parts of them, so take these words with a grain of salt.
There are also a lot of alternatives that I haven't been able to try out extensively yet, for example JBoss ESB, ServiceMix and Spring Integration 2.0 which looks promising. So many toys, so little time...

See you soon!

2 kommentarer:

  1. Hello Billy "The Integrator" Sjöberg !

    A Google Search for "WSO2 Camel" has led me to Your Blog; I'm still searching for "my" SOA architecture at the beginning of 2011 ...

    Ever since I got aware of the new computing paradigm called "CEP (Complex Event Processing)", the good use of it became a cornerstone of my own endeavours/enterprises ...

    Furthermore, I envision to use WebORB or Kaazing as the (realtime) data exchange engine between the server-side and the client-side.

    Right now I am considering to dive deeper into Apache Camel; for it provides components for the ESPER CEP Engine and for OpenSplice DDS ...

    I am a long-term ColdFusionIst, however ... But have not been in the hardcore trenches for longer time now ...

    (Even) at the beginning of 2011 I still cannot say: Aleae iactae sunt !

    I'm also aware of WSO2, Mule and Jeff Davis' SOA Book ...

    For a scenario like mine - not in the trenches, CEP, WebORB/Kaazing, ColdFusion - do You have some advice/recommendation at the beginning of 2011 ?

    Cheers and Tschüss

    Kai "The Non-Expert" (Tischler) from Northrhine-Westfalia in Germany

  2. Hi Kai,

    I must confess that I haven't worked with ColdFusion yet, so it is difficult for me to grasp your needs and requirements. Integration is a broad area and to me it sounds like you're mostly interested in the Web tier focused type of integration. I have to say then that since I come from a messaging background any advice I could give you would probably not suit your needs.

    But if I have only one advice to give, then it would be to check out the bible on messaging integration, "Enterprise Integration Patterns" by Bobby Woolf and Gregor Hohphe. It is old for sure, but similar to how GoF design patterns still are valid for developers today, this book is the de facto bible which all integration experts swear by.

    Best luck in your endeavors!