Apache Camel vs Proprietary competitors

In this inaugural post I am going to describe a bit about what made me choose to work with Camel and Karaf and what you gain and lose compared to its commercial competitors such as IBM Integration Bus. In essence, what things should you look out for when deciding on your integration platform?

Having worked with the IBM WebSphere Message Broker for more than 8 years you get used to its philosophy, concepts and tooling. Its when you step outside that you realize other tools  work differently.

Most commercial tools follow a somewhat similar conceptual model but how they implement it can very significantly.  However if you are about to start choosing an integration platform, here are some things you should look out for:

  1. If you are not familiar with the vendor landscape for integration, start with reading Gartner and Forrest reports to just get a feel. Don’t base your decision on them, rather use them to get a feel for who are the players and then use the list for an evaluation.
  2. Forget about fancy vendor demos. They are done in an idealized situation with an extremely simple scenario. No real life integration is like that. Demos are good to peak but not to base your decision on. Ideally, download their tooling and see how long or hard it is to create your own demo. Get a feel for the tooling yourself.
  3. Clearly understand your integration requirements. Talk to system owners and people who need integration to understand why and what role it will play.
  4. Understand your message formats and protocols, will it be used to connect to legacy systems or use modern REST and JSON?
  5. Cost is off course important. Try to do a total cost of ownership analysis to see how much your tooling, license, OS etc will cost in the next year, three years, and 5 years to see where it aligns with your budget.
  6. Is the vendor innovating its integration platform and attracting new customers?
  7. How does the licensing and support model of the vendor work?

The above are just a handful of questions you need to address before making a decision.

Now, now what about Camel?

Let us get one thing straight first and that is cost. Apache Camel is free. It does not cost you one dollar to use. IBM software usually costs a lot, probably more than 80 000 USD and the pricing model can be very complicated. Already you have one big difference.

However, the comparison is not fair even if there is a huge price difference. IBM’s Integration Bus is complicated piece of software that is the complete packaging, from routing, transformation to tooling and run-time. It contains all aspects of development and run-time administration. Apache Camel is first and foremost a framework and its strength lies in its simplicity and extensive routing capability. However due to its lightweight nature you are also responsible for the development tooling, finding a suitable run-time and handling monitoring and administration. Here the differences depends very highly on your needs. Camel places a far greater responsibility on the developer. It see the developer as the main person working with integrations.

I would say from personal experience that the biggest difference between the two is in the transformation part. I have never seen a better transformation tool than the Integration Bus message parsers. The concept of parsers and the ability to use them and refer to fields and messages in real time is highly helpful when you are developing mapping of data. In contrast Camel, being purely a programming language framework cannot use the concept of parsers and hence for transformation you need to either map to a java object (pojo) first or use external tools such as smooks or similar. For me, this is the single biggest difference and the one part of tooling you miss when you leave the IBM world.

I finally decide on the following components for the platform that I am working with:

  1. Apache Camel for routing and development. Why?
    1. It is free.
    2. Avoiding vendor locking.
    3. Simple to use.
    4. Based on java so easy to get started.
    5. The team innovates and fixes the framework and it is standard for integration in the open source world.
    6. Uses patterns based on Enterprise Integration Patterns book.
    7. Not tied to a specific run-time.
    8. There are many more reasons but one final one is that it is very lightweight but at the same time contains exception handling, error handling, testing, mocking and many more advanced features.
  2. Apache Karaf for OSGI run-time environment.
    1. Karaf is very light weight, just a zip file and you are good to go.
    2. It contains many advanced features missing in commercial tools.
    3. Deployment is extremely easy.
    4. It works with Camel in a relatively straightforward manner.
    5. The logging framework is great.
    6. Administrating bundles is also very easy. There are even specific camel commands so that makes life really nice when deploying camel routes.
    7. It supports installing Hawtio and Apache ActiveMQ inside its run-time.
  3. Hawtio for webconsole.
    1. Hawtio is great to debug, profile and view your camel routes. You can also view the Karaf logs, manage your camel routes and much more.

Finally, after having used Camel now for about one month, I have to see I am pleasantly surprised because it has a lot of functionality for being open source and even functionality not found in commercial software. One huge benefit I think working with Camel and its ecosystem is that you gain a more in-depth understand of software, development and get to hone your skills more. You are not just an expert at a specific vendor tool, instead you can I definitely need to read the documentation more and understand some best practice but one step at a time 😉 Thanks for tuning in.

Annonser

5 reaktioner på ”Apache Camel vs Proprietary competitors

  1. I found this blog post to be especially interesting! You have a lot of great points.

    I have worked on Camel for 6+ years and for the last year I have been using IBM Integration Bus. I would agree with your blog post, especially the comment about message parsers versus POJOs. Here are my findings on IIB/Camel.

    1) The tight-coupling of the parsers to the input/output nodes in IIB makes it difficult in cases where you don’t want to parse the full message. I recently came across a problem where I was dealing with a large HTTP payload and wanted to read the input stream and propagate the data down the flow. This was not possible as http input node read all the bytes first into BLOB parser. The guys on the mqseries team highly advised against trying to do any input stream reading because it violated IIBs fundamental architecture. Compare this to camel where they provide built in mechanisms for access input stream from an HTTP component.

    2) If you want IIB to work with existing Java APIs then you are always converting between the message parser and the POJOs that the Java API understands. This makes working with Java code really ugly. Camel is way more flexible in this as it has understands how to work with Java Beans, and you can easily integrate existing Java APIs into your camel routing logic.

    3) I really like IIB ESQL purely for data mapping, however ESQL is often abused. For example: I have seen ESQL developers implement complex logic that is often buried deep within compute nodes that makes it almost impossible to troubleshoot and debug. Of course this can occur in any language, but ESQL is not an Object Oriented language and was never designed to do complex logic, but rather data mapping. Also, many ESQL developers are not OO developers and thus, will always resort to building their complex logic in ESQL.

    4) IIB 9.0 and before does not contain any mechanisms to perform unit testing. IIB 10 does, however it cannot be integrated into a Continuous Integration environment. IIB also does not contain the ability for using Mocks within your flows. This is

    5) Setting up IIB in a Continuous Integration environment is really hard.

    6) Camel has type converters which provides a nice way to seamlessly convert between one object and another. IIB doesn’t have type converters, instead all transformations must be explicitly defined within the flow. ESQL of course is much better IMO for data mapping. If you want to find middle ground between the two I would recommend Groovy. Data mapping in Groovy is a nice option coming from an ESQL background.

    7) Talent. Finding ESQL and IIB developers is not easy. Finding experienced IIB developers is even harder. Especially if you live in a city where IIB is not prominent. Finding Java professionals is much easier task, they are a dime a dozen. Those people can be ramped up early on Camel, where as IIB like you mentioned is a domain of its own.

    8) The Java API is absolutely terrible in IIB compared to the offerings in camel, which pretty much forces you to use ESQL.

    Pound-for-pound I find Apache Camel IMO is a much more flexible and versatile integration product than IIB.

    I am still learning IIB and am finding a lot of pros/cons compared to camel. I’ve been trying to document my findings here http://beertechcode.blogspot.ca/search/label/Apache%20Camel%20%26%20IBM%20Integration%20Bus

    I am curious why you made the switch to Camel and open-source?

    Thanks for the great post! Please email me I would enjoy discussing more with you.

    Gilla

    1. Hi jamieproton

      Yeah your points are completely valid. One of the things I noticed when working with IIB was that it was easy for developer to start putting in various business logic down somewhere in the code. 6 months later nobody knew and only the integration platform had access to this logic. This meant that suddenly you had not only mapping logic but also business code which ideally should not exist in the integration platform.

      I would say there is only one thing I miss from the IIB world and and that is to easily create message models for any kind of message format and reuse that. In the java world, yeah you can find some library or your create your own classes but the new DFDL parser is nice to work with. Off course it also makes for tight coupling since you are forced to use IIB now.

      The java API in IIB is crap. I hated those lastchild firstchild thing. It was useless, either than or having to know the xpath. This is one area they need to do better.

      Off course with docker coming into play I am not sure how they plan to react. There is a docker image for IIB developer edition. But what about production? What about licensing then? In Camel world it is easy, just spin a karaf docker container and deploy. No worries 😉

      Overall I am starting to enjoy the open source options and I especially like the test part. I managed to connect Cucumber-JVM to Camel’s unit test to write scenario tests as well.

      Gilla

      1. I agree. IIB handles XSD/WSDL seemlessly out of the box and makes it very easy for the developer to getup and go. In the Java world its not so easy (e.g. JAXB). There are other frameworks which assist in doing data mapping that you can use with Camel. However it’s not integrated into the core camel. I wish camel had something like this. This is why I recommended Groovy for data mapping over Java. DFDL is also available in Java, but once again its not provided in the core. This is where IIB has some nice features, since it has everything bundled into the product.

        The ability to draw your integration flows is also really useful in IIB. JBoss Fuse has similar drawing capabilities in their IDE but I haven’t used it.

        IIB 10 runs in docker but we have yet to use it. There are some limitations from what I’ve read and it’s probably too early to run it in production.

        Liked by 1 person

      2. Yeah I have seeen IIB and MQ for docker for developer edition but I am not sure how they will enable this considering their licensing model is PVU based which doesn’t really scale well. They might do some special version for Bluemix but it remains to be seen how well these technologies work well together.

        Yeah the IIB palette is pretty cool and works very well. The JBoss tooling is I would say where IIB was in version 5 or 2. They have just started and are quit far behind. There is the graphical mapper which I tested although it is quit slow and in the end produces a dozer mapping. I might stick to java or groovy for mapping. One good aspect of the tooling is that you can do tests and run camel within the IDE without needing a runtime. That is actually really cool and something you cannot do in IIB. It would be as if running a message flow without an integration server. There is off course another part. With Camel you can create javadoc and or use swagger to document your Rest API. One of the worst parts of IIB for me is that it doesn’t offer any good way automagically produce code documentation.

        The WEB UI they created in version 9 and enhanced in IIB 10 is something you can find in Hawtio and in fact Hawtio in some aspects is more powerful even though its completely free.

        The one thing I have not tried yet is to connect directly to enterprise systems such as SAP using SAP adapters. I am not sure how good the Fuse JBoss adapter is.

        Finally, one good aspect of working with the Camel ecosystem is that it broadens your horizon and forces you to learn a little bit of everything. When I was working with IIB I felt more of a tooling expert than someone who really knew the framework and the mindset etc.

        Gilla

  2. Yeah the Fuse IDE tooling is still in its infancy. If they can make it more usable it will be a serious contender with IIB. I haven’t used Hawtio yet but I’ve heard good things.

    Gilla

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s