OpenESB community blog center

Welcome to OpenESB community blog center where OpenESB people and users exchange views about the project, the best practices, the new requirements and its future. Your comment and feedback helps us to stay in touch together


During exhibitions, lectures, and conferences and on ESB forums, architects and developers ask us regularly “What is the difference between Mule and OpenESB”. It is a recurrent question since the two products share lot of common points.

  • Both come from open sources projects supported by a community.
  • Both contain the same acronym “ESB” (enterprise service bus) and aim to make integration easier.
  • Both are running on Java and packaged with graphic tools to develop projects, …

So at the first look, the products seem similar and people are wondering what the key differences between the two products are?

In my response, I’ll try to list and explain the key differences between the two ESB products. Obviously, I propose Mule fans to reply to this post and bring their arguments to complete the discussion and the reader will mould her or his opinion. I would be happy if this paper could be the kick-off of a positive debate.

Before going on, I would like to precise that I have a great respect for Mule people and the job they do. Even if we are competitors, first we are friends.

Let’s avoid a technical comparison

In this answer, I’ll try my best to avoid the trap that pushes technical writers to an exhaustive technical comparison between two products. Starting a debate about Mule or OpenESB technical pros and cons is inefficient and debatable. Usually, each editor comes and pushes forward the best features of his ESB, with benchmark as evidence and claims that his product is the most efficient. Everyone knows the famous IT proverb that says: “There are 4 lie levels: The little lie, the average lie, the big lie and the benchmark”.  To avoid a huge lie, this paper is not focus on technical points but I underline the differences vision of integration between Mule and OpenESB teams. I explain how each team sees integration and at which level it implements the integration concepts. At that level, we shall avoid sterile technical discussions and anyone will be able to understand the key differences between the two ESBs.

Mule: View on Integration

On we can read:

“Mule is a lightweight integration platform that enables you to connect anything, anywhere. Rather than creating multiple point-to-point integrations between systems, services, APIs, and devices, you can use Mule to intelligently manage message routing, data mapping, orchestration, reliability, security, and scalability between nodes. Plug other systems and applications into Mule and let it handle all the communication between systems, enabling you to track and monitor everything that happens. Mule is so named because it “carries the heavy development load” of connecting systems.”

Mule creators gave this name because they considered their product behaving like a mule. This animal makes its jobs efficiently and without tiredness. Many countries see Mule as an essential animal for local economy and people. On the same way, Mules ESB transports and transforms messages efficiently; it takes messages from sources and bears them to the addressees. Mule ESB uses the “Enterprise Integration Patterns” (Router, Filter…) to route, filter and transform messages. Originally Hohpe and Woolf listed and explained EIPs in their famous book “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions”.  

Like a real Mule, Mule ESB accepts any load without balking. Mulesoft designed this tool to create communication between partners where messages are safely transported.

So, from Mule claims, we understand that Mule ESB’s designer vision of the integration focuses principally on message transport. Mule’s designers understand the integration as an elegant way to transport and transform messages from a provider to a message consumer.

However this basic integration does not consider the other facets of integration. As in the real life, working together in a strong partnership calls for more than sending emails to your partner, a real and efficient integration needs more than sending message between partners.

OpenESB: View on Integration

OpenESB designers understand the integration in a different way. They understand integration in a broader scope. The next points list the key concepts used to design OpenESB.

Integration is a pooling of service proposed by partners (internal or external) who take part in the same business process.

To take part in a business process, a partner must clearly define the services he or she proposes. To do it, he or she publishes a document named “contact of service”. It fixes the services features like message types, operation patterns, protocol, address….

To make up new integration processes, we pool services proposed by the partners. An orchestrator is used as a conductor to manage services and business process state.

Services and Orchestration promote Services Oriented Development (SOD), service reusing and allow complex applications development. They decrease maintenance and evolution costs

Let’s detail these sentences.

Contract of services

In the real word, integration cannot rely just on message exchange. If a project limits exchanges between partners to message exchanges, it results a poor and inefficient integration, reusing and services orientation.

At OpenESB we think the Business Process is the right level to define services and integration rules. Partners and Services must be set and designed at that level to be well-defined, accurate with business needs and reusable by analysts who write business requirements. Contrary to popular belief, reusing is not efficient at development level but at the business level. Business never cares about messages but the pay attention to services.

OpenESB development process promotes partners and services definition among Business and IT teams before starting any development. If Mule accepts nondefined messages, OpenESB deals with messages defined in the contract of services. Often developers see this constraint as a burden, but years of service oriented development prove that defining a contract of service is the only way to control efficiently message coherency and avoid vicious side effects. On its website, Mule develops its view on SOA ( and does not say any word about the contract of services. This fundamental concept is not present in Mule ESB.

Besides, using contract of services comes with an elegant way to separate service definition and implementation and distinguish between a service and the partner who proposes this service. Defining a contract of services makes easy version management as well and adds an intermediation level between the consumer and the service provider.

Flows vs. Orchestration

Mule developments rely mainly on flow diagrams and even if it proposes light tools for orchestration, message flows remain the core of Mule development process. Flows are a set of sequential operations or evaluations applied on message (Ex: route, filter, data mapping…). If message flows are easy to understand and develop, they are not accurate to manage complex business processes. Indeed, if a Business Process sends and receives messages, message flows are not powerful enough to represent real Business Process with “Compensation”, “Correlation”, and “Complex fault management”. These features are beyond message flows capabilities.

Using flow message to develop a complex process with many services and partners, increases exponentially complexity and maintenance cost. Integration application becomes a huge and inextricable plumbing.

OpenESB propose sophisticated and powerful orchestrators for critical processes management. It allows developers to create complex application where the flow messages philosophy is inefficient and costly.  Orchestration allows you to organise complex exchanges between multiple partners like a conductor does with many musicians and members of chorus. That’s one of the fundamental differences between the two products.


To keep this answer short, I propose you to talk about the others key differences between the two ESBs in another blog. However with the help of these two examples (Contract of Service and Orchestration), we understand the main difference between Mule and OpenESB is due to the way each one understands integration. On one side, Mule’s designers see integration as message exchanges between partner and business process as a set of message flows. Key SOA concepts like Contract of Services or partners are nonexistent and orchestration seems optional on the tools proposed in Mule.

At OpenESB, we think that this view limits dramatically the quality and the efficiency of integration at the enterprise level because messages are mainly a developer team concern or topic and does not impact or involve the other teams in the company (ex: Business analysts)

OpenESB promotes services oriented developments, services reusing through definition of service orchestration and composition. It pushes business analysts, developers, architects, and other teams to Services Oriented designs and developments.

So to summarize, we understand that Mule targets Integration at the development level with an efficient message management product. OpenESB invests in Service Orientation Architecture and Development and see Business processes as the right level for integration. It pushes companies to real, concrete and virtuous Services Oriented Development.

Thanks for your comments


Tags: Untagged
Hits: 15141
Paul Perez is Chief Software Architect of Pymma. He is an author, software architect, consultant and speaker. He brings more than 17 years experience helping corporations for mission-critical information systems. Prior to co-found Pymma, Paul was an independent software consultant, working for large financial services companies in France, UK, Benelux, Israel and Germany Paul's extensive experiences in high-performance architecture design helps the company's clients solve real-world business problems through technology. As chief software architect, Paul assists current and future client engagements and develops best practices based on his domain expertise. Paul holds a post master degree from Paris University and is a Sun Certified Enterprise Architect, Togaf certified and holds several other certifications. You can contact paul at: paul.perez (at)


Please login first in order for you to submit comments