Apache Camel vs. Mule ESB – What’s the Difference?

An enterprise software ecosystem is a little universe in itself, one which includes diverse  applications all of which must be integrated to share data. On-premise apps and Cloud apps mix with SaaS apps, third party plugins and APIs, as well as supporting mobile apps, and even IoT and microcontroller platforms. Software developed in-house is patched together with software packages purchased off-the-shelf, including large and complex Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) packages. 

Although newer apps today are designed with integration in mind, integration with existing legacy systems is inevitable for most enterprises. All such apps were created with various programming languages and operating systems; they invoke myriad data formats and transmission protocols. And all of the above must be interfaced to function as a whole in order for the enterprise to operate harmoniously. What is the best strategy to achieve such a promethean task? 

One very successful and popular strategy is the Enterprise Service Bus (ESB). What is ESB? In simplest terms, ESB fits within the enterprise application integration (EAI) paradigm, which enables two or more applications to interact via a central bus. In practice today the bus is often built on a message queue or message exchange platform such as Apache Pulsar. 

ESB supports interfacing applications within a service-oriented architecture (SOA), and represents a software architecture particularly for distributed computing. Numerous ESB 

integration frameworks are available today which work with large volumes of both structured and unstructured data. Choosing accurately an ESB framework is not a simple matter; our purpose here is to assist with that decision. This discussion will primarily elaborate on two open source solutions: Apache Camel and Mule ESB.

Ranking ESB Frameworks

Let’s start a checklist toward choosing accurately the best EAI solution. To begin, what are the most important factors in ranking an ESB framework? Computer science researchers often list the following when evaluating ESB platforms:

• Comprehensiveness of adapters / connectors
• Studio for developing integrations, UI tools
• Graphical modeling tool to visualize integrations
• Completeness of documentation
• Thoroughness of training courses
• Availability of technical support
• Developer and user community support
• System maintainability 

At the heart of every integration platform is a set of connectors. Adaptors and connectors demonstrate foresight of an ESB platform to anticipate specific industry needs. For example, Mule ESB’s Anypoint HL7 Connector for EDI facilitates integration specifically with healthcare systems. HL7 is an organization which develops software engineering standards for transport and communication of healthcare information. The HL7 version v2.x message protocol is supported by Mule. To illustrate the importance of education and training to your success with the platform, (equivalent resources to Apache Camel ESB tutorials), Mule lists prerequisite knowledge of:

• Anypoint Connectors
• Mule runtime engine 
• Elements in a Mule flow
• Creating a Mule app with Anypoint Studio
• HL7 EDI Connector

Likewise, Apache Camel supports a variety of connectors and adaptors. A brief look into best practices and case studies for open source middleware migration reveals that legacy systems  often use message oriented middleware for inter-app integration. Proprietary middleware is usually expensive because of licensing costs, difficult maintenance, and required engineer skill sets. Substantial community support for open source platforms like Camel can even tip the balance in favor of efficient in-house integration.

Establishing ESB Standards

Message-based integration is widely viewed as the ESB core standard and several frameworks now in development implement the pipes-and-filters (diagram 1.) workflow in integration solutions. In a pub-sub solution like Apache Pulsar, pipes are message channels and filters are tasks; combined, they model the integration pattern to share data among enterprise software applications in the form of messages. We are focused here on Camel and Mule, but two other open source solutions are noteworthy as well. Those are Spring Integration and Guaraná. Both are also message-based integration solutions.

These pub sub integration frameworks temporarily store data in channels with the benefit of de-synchronizing events and decoupling apps in order to achieve the desired flexible interface. According to the pipes-and-filters architectural style, messages must persist in a channel to guarantee zero data loss. Natural language processing and computer vision are among the unstructured data in real-time event streams which commonly pose the most challenging engineering scenarios in message pipelines today. Now that we have established the basics for ESBs, let’s look specifically at our featured solutions.

Distinguishing Mules and Camels

First the Mule…

As with many popular hybrid integration frameworks, Mule ESB is Java-based and implements –  but is not limited to – ESB concepts. Mule ESB is the flagship product of the company MuleSoft.  Conceptually, Mule ESB relies on the Anypoint Eclipse IDE Studio visual editor to represent its model-centric development approach. Command line implementation is also supported with API and XML. Mule integrations feature Spring-based configuration files and a unique coding  language for abstracting integration solutions. Mule also features an XML-based debugging  language for testing model integrations.

Although Mule ESB is Java-based, it can handle interactions with .NET via web services and  sockets, and also integrates with other platforms. Mule implements 50 standards, like the HL7 in our case study below. It supports many protocols and technologies such as JDBC, JMS, TCP, UDP, SMTP, and POP3. Functioning as an exchange platform, Mule features substantial routing capacity and high scalability. Mulesoft offers core coding classes as open source under CPAL, but also extends functionality in standard and premium paid packages.

Now for the Camel…

Apache Camel is likewise a Java-based integration platform. Camel is an Apache Software Foundation project with numerous contributors. Contrasting with Mule’s visual design and  implementation focus, Camel supports code-centric development with a Java API36 for implementing integrations. In conjunction with the core API, Camel also supports Scala or XML configuration for implementing solutions. 

Borrowing ideas from Mule, Camel provides a graphical modeling tool to visualize integrations, but it’s not an IDE and doesn’t generate code (see low code / no code). Camel  processes messages via routes with one or more inputs and outputs, and this messaging is the ESB core. Camel features an exception handling library for building redelivery policies. Developers can test routes after implementation by analyzing routes processing. Camel cannot set a message priority nor can it dynamically change routes. Developers can also monitor network consumption and disk access during execution. A SaaS commercial offering of Camel called Fuse Source provides an Eclipse-based IDE which includes a visual editor.

The concepts of integration in themselves constitute a high level of abstraction. Therefore, the real-world eureka! moments which can be achieved with an ESB integration may not be obvious. For this reason, we will share an in depth case study in the important and complex field of healthcare enterprise systems.

Mule ESB Featured Integration Case Study

NSW pathology operates 60 laboratories and processes 100,000 pathology tests every day. To fit harmoniously into the healthcare software ecosystem, NSW must integrate this unique and vast data technology with numerous enterprise software platforms. Among the objectives is to eliminate unsustainable point-to-point or ad hoc integrations and build a highly reusable SOA integration system. NSW chose MuleSoft’s Anypoint Platform because of its flexible hybrid API support.

Another critical factor in healthcare provider use cases such as with NSW, is compliance with strict regulatory requirements. MuleSoft was also challenged to extend testing beyond laboratories to enable testing at other healthcare facilities in order to accelerate testing and provide results to https://piemeds.com patients faster. In fact, improving efficiency is an important goal implicit in the development of an EAI. 

Mulesoft implemented an API based approach via Mule ESB to integrate 350 testing devices at 60 laboratories in under three months. These Point of Care (PoC) devices were swiftly connected to electronic health record (EHR) systems via ESB in order to share patient pathology results. As a result, all providers in the system can easily view all testing output.

The provider used MuleSoft’s HL7 Connector to securely route HL7 messages among state and federal health systems from its laboratories, thus illustrating another important component of   integration systems: to reliably map and transmit message data for millions of users and apps, data security is critical. 

Mule ESB’s Anypoint Platform provides exceptionally flexible deployment options, which account for the numerous successful case studies which have been published by companies using Mule ESB. As such, NSW is the largest provider of public pathology testing in Australia, with a massive clinical and non-clinical data throughput. The success of Mule in this scope amounts to the best recommendation of its capability.

Enterprise Software Apps’ Built-In Integrations

We have determined along this journey that an important consideration in the EAI scope is intelligence: most modern enterprise software applications feature one or more built-in integrations of their own! Are they fully optimized? The most popular CRM, for example, includes integrations to QuickBooks, MailChimp, Linkedin, Google Cloud, and many more. Which of those built-in features is AI-optimized? 

To put this in blunt, simple terms, if all your software apps are newer Cloud based apps and you are integrating with apps you purchased off-the-shelf, then chances are good you don’t even need an additional integration solution! Nowadays, you need an expert with the flexibility to provide this kind of intelligence as a partner – a partner who can deliver a solution for an equitable cost.

While open source ESBs intend to deliver solutions, they remain complex to implement and maintain. Pandio offers an ESB solution (built with Apache Pulsar) that gives better performance than these legacy solutions. Open source may appear economical at the onset, but the cost of the learning and development curves may be high. Pandio’s expertise arises from an intelligent combination of ESB functionality and the unique ability to engineer data abstraction (via Presto DB) and a proprietary AI automation solution via a neural network. In anticipation of the journey ahead, this is the intelligence to create a fully harmonized enterprise solution.  With Pandio, customers are not only able to virtually query their data at rest, but also to move around the enterprise at unprecedented scale in an automated fashion.