Open source middleware: is Mule ESB the Next Big Thing?

15 Responses

  1. Matt Corr says:

    Thanks for this! As a BizTalk developer I had been wondering what Mulesoft were working on and if it could be a serious competitor for BizTalk. It does sounds like from your experience they still have a fair way to go!

    • Robbie says:

      Exactly. They’ve done some good stuff, but it’s almost as if they only focused on the development part. Maybe they are working to improve runtime. Only future will tell.

  2. Phil Chalk says:

    Hi. I’m also a BizTalk developer who has, for the past 8 months, been working with Mule ESB. I have worked with BizTalk since 2004 (with beta version of BTS2004) on some large projects. My last BizTalk engagement (using BTS2010) ended in March 2013, so I feel I can also comment on the differences between Mule and BizTalk. My experience with Mule has been, it would seem, more positive than yours, though not entirely without frustration (but then again I had a few sleepless nights with BizTalk). I’ve made some notes below – apologies for the length, but it is difficult to respond in a few lines.

    AnyPoint Studio (local development environment) is free – you can download the AnyPoint Studio and start developing for free (includes the DataMapper). The AnyPoint Studio contains its own runtime and is fully featured.
    Mule Community Runtime, which is free, will give you a workable runtime environment, but does not support any DataMapper transformations.
    For production environments, the BizTalk prices look correct, but SQL Server 2012 enterprise edition is approx. $6500 per core (or thereabouts), so even $20k for SQL is a little low for four cores.

    Documentation & Community
    Admittedly, there is a shortage of good books and blogs about Mule ESB at present. The MuleSoft online docs are good, and generally Stack Overflow will point frustrated developers in the right direction. But yes, it could be better! That said, I remember BizTalk back in the early days of BizTalk 2004, and that was in a similar state to Mule then, i.e. lack of documentation. Since then, BizTalk has developed into a very mature product with lots of superb bloggers and resources – hopefully Mule will develop similarly as it grows.

    Visual Mapper (DataMapper)
    A few months ago I may have agreed with your comments, but I stuck with it and am now finding it very usable as an enterprise tool. With regards to not being able to map nodes on different levels, that is incorrect; you can, within the DataMapper, define mapping levels which allow you to do this. I have mapped from a flat csv structure to a complex xml structure with nested repeating nodes – it is possible. Not sure what you mean by having to recreate the map when replacing the source or target object; you can update (say) schemas and refresh the associated meta-data without losing the mapping, but if you totally change either schema then yes, you’ll clearly lose the mapping.

    Agree that not everything is supported in the designer (though most is), and that there are a few annoying ‘quirks’ with its drag and drop. With regards to managing variables though, that is the same if you’ve defined lots of them in a BizTalk orchestration, though I would concede that the BizTalk Orchestration designer is clearer to use due to its maturity.

    I think when it comes to supporting integration engines, they all have their challenges which is why we have products like BizTalk360. All I can recommend with Mule (until we get a ‘Mule360’!) is to ensure you have an effective logging strategy and use Business-Events.

    Mule Management Console (MMC): it has a little more than the BizTalk2004 Admin Console, but not much more of any use – other than Business Events (see below)!

    You can, relatively simply, add Business-Events into Mule flows into which you can extract data from messages etc. – this data is then reported and searchable within the MMC along with any errors that may have occurred with the messages…so it is sort of a BAM ‘lite’.

    Flow Control
    I agree – to a degree – with your comments about queuing messages. However, it is possible to implement something similar to BizTalk queuing via, say, ActiveMQ and designing the functionality into the flow. Similarly, Pub-Sub is entirely possible by using ActiveMQ which is free and integrates fully with Mule (no custom code necessary).

    Agree that up to version 3.4.2 its difficult to change config on-the-fly in a runtime environment. I’m in the process of upgrading to v3.6 and will be looking at this aspect closely (I’m sure it is possible but up to now I have missed something up to now).

    Its horses for courses. If you want an out of the box, mature integration engine that persists all messages to database, is able to queue effectively, and comes with a rich, mature development environment, then you may want to look closely at BizTalk. The downside of BizTalk comes with its inherent complexity, and the level of expertise required to develop almost any level of integration solution (and associated development costs). If you want a lighter, but capable, integration engine where you can quickly develop enterprise-ready solutions, with significantly lower development costs, then Mule is well worth considering.

    • Robbie says:

      Thanks for the extensive comment! Very helpful and indeed some valid points 🙂 I will surely look into ActiveMQ.
      Indeed Mule needs to mature and hopefully it will in the future. I don’t hate it, I just have some worries. Competition is (mostly) good for everyone and leads to better products.

  3. Reggie Pillay says:

    Thank you to Robbie and Phil Chalk for a detailed article and response. I am new to Mule ESB and this article helps me position the product correctly.

  4. Mike Stowe says:

    Hi Robbie,
    I’m sorry to hear about your experience with Mule ESB and Anypoint Studio – I would love to talk to you more to better understand what you liked and didn’t like. And I’d like to thank you for sharing such a well-written and carefully crafted review – it’s feedback like yours that has helped us significantly improve Mule ESB, and has helped us jump significantly in Gartner’s Magic Quadrant for On-Premises Application Integration Suites 2014 report. It’s also why MuleSoft has been able to become the only company recognized as a leader for both on-premise and cloud enterprise integration – and the choice for 35% of the Global 500.

    I’d also like to invite you to try out version 3.6, as it sounds like you’ve been working with a much older version (3.4) and we’ve made a ton of improvements and bug fixes (especially to the DataMapper)!!!

    But again, thank you for your candid feedback, it is something I will definitely pass on to the appropriate teams so that we can make MuleSoft’s products and services even better!

    I hope to hear back from you soon!

    – Mike, Developer Relations Manager @ MuleSoft

    • Robbie says:

      Hi Mike.
      I appreciate your comment! I’ve been trying out 3.6.1. just the other day for a demonstration and especially development wise there are a lot of little, though very good, improvements. Something like keeping track of your variables (properties) makes development just so much easier.
      I didn’t notice all the improvements in the mapper, but I haven’t been fiddling around with it a lot. I have seen some changes, but still was unable to do complex mappings. I just have to look more into this and maybe I am just missing something there.

      Development wise Mule is pretty good (allthough I am not an Eclipse fan 🙂 ). I think runtime, especially on-premise, needs some work. There are a lot of quirks in the MMC and getting servers registered – in Windows that is – is always a problem. If it’s not SSL, it’s something else. Mind you, Mule is way better to setup than Fuse for instance.
      With Mule I just don’t have the feeling I am in control of my runtime environment out-of-the-box. I would like to see stuff like a decoupled tracking feature. So I can have some sort of tracking enabled all the time, instead of reactive. I can’t imagine someone coming up to me asking to search between a million messages in logfiles to see whether or not I received it yesterday.
      And of course being able to do a configuration change without redeployment or being able to queue-up messages out of the box. E.g. when a service provider has predicted outage because of an upgrade. Of course you can develop stuff for this, but it will cost extra development time, and that’s a USP for Mule. And if this stuff isn’t available out-of-the-box, it’s hard to justify the price.

      Just my 2 cents and I hope you guys will be able to improve runtime for a next big release (4.0) and give adminstrators and operators the ability to be more in control.

      – Rob

      • Mike Stowe says:

        Your 2 cents are pretty important to us 🙂 I’ll pass this along too.

        Thank you again for being so willing to share what you like, and what you don’t.

        And please, feel free to email me anytime with any suggestions, questions, or concerns.

        Keep up the great work,

  5. Brad Grant says:

    It sounds like you are pretty biased to me. Mule is not perfect, but it much better than Biztalk (or anything that runs exclusively on an inferior OS like Windows). Many of your complaints sound like you don’t know how to utilize JMX for monitoring and the custom calls from the Mule API. It is open source so you can build what you need. It also sounds like you are really reliant on the UI. Mule is built with Java and if you understand the principles of Java you can do all of your development in IntelliJ or Eclipse. You may not like Eclipse but it is much better than Visual Studio (considering Eclipse is the most used IDE). Funny that your blog title describes you as MSFT DVLPR. Could easily be confused as Mulesoft dev not Microsoft but it is clear after reading a few entries that you are convinced Microsoft is better.

    • Nathan Reitz says:

      It’s quite humorous to me that you attempt to lambaste the author for being biased, then spring into one of the most biased monologues possible. Pot calling the kettle black, much?

      My team has been working with Mulesoft EE for a year now, and have many, many complaints. Server registrations in the management console can drop, forcing you to manually edit config files on the servers to trick them into being unregistered, thereby allowing them to show up in the MMC as a new server to register. The slightest configuration difference between Mule developer workstations can render import of another developers flow impossible. They claim that they charge for development licenses because support is most often utilized in development, but then de-escalate tickets and don’t to get back with adequate answers in a timely fashion. Several tickets we have submitted were answered by referencing the community forums. Also, with each and every update we have received on the platform, numerous issues were introduced where the features previously worked. The best analogy is that their EE customers are doing their Alpha and Beta testing for them in our environments.

      This isn’t to say that it’s a bad platform, and that people should look elsewhere. It is a great platform. But, it is very disappointing, nay unacceptable, that a tool as expensive as EE should have these issues.

    • Hung Nguyen says:

      Eclipse works like shit, very slow and unstable. Most popular doesn’t really mean the best. Eclipse is the most popular, maybe you’re right, but it’s because on the Java world it seems to be the most mature IDE. Just like JavaScript is the most popular language it’s not because it’s the best language, but because it’s the only choice on the front-end side. We haven’t had chance used Mule AnyPoint Studio but WSO2 Dev Studio which is also an Eclipse-based product, after six months trying with it we decided to change to use a pure text editor like Sublime.

  6. IsThereAnyPoint says:

    We have been working with Mule on a very large project. The ANNUAL license fees are well in excess of 200k USD and that is with a substantial introductory discount. This software has been a nightmare to maintain in production. The company are only interested in conversations about taking more money from you. Try to use the community edition and you will find basic features are unavailable so this is a useless edition.

  7. Danielle says:

    Great article. Your readers might also find real user reviews for Mule ESB on IT Central Station to be helpful:

    While your client ruled out Oracle because s/he was looking into open source, it is interesting to note that some IT Central Station users still went with Oracle despite the open source option. As an example, this Oracle SOA Suite user writes, “We also looked at Mule ESB/CloudHub, TIBCO, and IBM. There were many reasons that we chose Oracle, including that it’s a more robust and scalable product, more features, better future roadmap and product vision.” You can read the rest of his review here:

  8. Arpit sharma says:

    Awesome write-up. I’m a regular visitor of your web site and appreciate you taking the time to maintain the excellent site.

Leave a Reply

Your email address will not be published.