TIBCO Business Works vs. Apache Camel — A short Comparison

ESB stands for Enterprise Service Bus. It is an architecture pattern that enables disparate applications to connect seamlessly with each other. Under the hood, ESB uses an integration tool, more commonly known as middleware. Integration or Middleware tools have capabilities such as data transformation (such as XML to JSON), protocol transformation (like FTP to HTTP), content-based message routing and service orchestration. Many vendors converted this concept into an ESB product with standard connectors

In this blog, I will compare two such integration tools, one which I have worked extensively i.e TIBCO BW and the de facto open source integration framework Apache Camel. I choose open source as it has a bright future and becoming very popular among many enterprises. I did not choose Mule ESB because it is not completely open-source as its most vital components come under a licensed enterprise version.

What is TIBCO Business Works (BW)?

TIBCO BW is a Java-based middleware product with which one can easily implement integration logic. An integration project of TIBCO BW looks like a workflow. Business logic is usually implemented in the form of a workflow. That is the reason why it is known as TIBCO Business Works.

It has a graphical user interface to define business processes and also contains an engine to execute those processes. It includes great performance, stability, and compatibility features.

What is Apache Camel

Apache Camel is a message-based middleware with a rule-based routing- and mediation engine, which simplifies the integration of Enterprise applications. Based on domain-specific language, Camel can be used to configure routing- and mediation rules. Apache Camel uses Java as its programming language and is platform-independent, thus making it compatible with all operating systems. Camel supports most of the Enterprise Integration Patterns (EIP)

How they fare when compared

TIBCO BW and Apache Camel are characteristically very different. Let’s see how

Aside from the basic differences above, there are several other key aspects where they differ

Points to Consider

Apache Camel is an awesome lightweight framework to integrate applications with different technologies. But Camel doesn’t come with deep service-oriented concepts which have been a pillar of TIBCO BW for many years now. Though one can use Camel to build SOA components

Another point to note with Camel is there are No standard runtime nor management interface and hence needs clear design and architecture guidelines or things can get messy.

Camel also does not have a visual development environment and without additional tools is only efficient for a limited audience. As integration points grow, the Camel framework becomes less manageable most enterprises will choose to add a visual development environment to Camel.

TIBCO BW comes with a powerful and visual IDE. Because of its low code approach, TIBCO integration teams in many enterprises work more or less in an earliest avatar of DevOps.

TIBCO BW also addresses non-functional requirements such as reliability, high availability, scalability, and enterprise security in addition to expected functional requirements

All software can have vulnerabilities and with Open Source like Camel, you can identify them yourself and fix them. With proprietary software like TIBCO, you rely entirely on the vendor’s turnaround time.

It is difficult to compare both on the total cost of ownership since TIBCO BW comes with heavy licensing costs and training. On the other hand, most enterprises would choose more commercially supported implementation of Camel with its own cost in addition to the cost of experienced developers.

I personally like Apache Camel. It is quite powerful with very strong community support. If an enterprise is already moving towards the containerization of its applications, microservices and open standards it definitely makes sense to consider Camel. But keeping multiple middleware centers of excellence without a strategic thought can quickly become an architectural disaster.

Thank you for taking the time to read this post and hope you find it helpful! Do you have any comments or questions? Do you wish to share your experience with either or both middleware mentioned above? Please feel free to comment on this story!

I work at Sytac.io; We are a consulting company in the Netherlands, we employ around ~100 developers across the country at A-grade companies like KLM, ING, ABN-AMRO, TMG, Ahold Delhaize, and KPMG. Together with the community, we run DevJam, check it out and subscribe if you want to read more stories like this one. Alternatively, look at our job offers if you are seeking a great job!