Apache Camel is an open source integration platform.
N/A
TIBCO Messaging
Score 7.7 out of 10
N/A
TIBCO offers high-performance messaging technology, and gives customers flexibility and unique choice between Commercial and Open-source messaging solutions. TIBCO Messaging is a comprehensive messaging portfolio available to meet a wide variety of use cases and deployment models.
N/A
Pricing
Apache Camel
TIBCO Messaging
Editions & Modules
No answers on this topic
No answers on this topic
Offerings
Pricing Offerings
Apache Camel
TIBCO Messaging
Free Trial
No
No
Free/Freemium Version
No
No
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
Apache Camel
TIBCO Messaging
Considered Both Products
Apache Camel
Verified User
Anonymous
Chose Apache Camel
Easier to use, better routing system, but perhaps too basic dependant on business needs?
If you are looking for a Java-based open source low cost equivalent to webMethods or Azure Logic Apps, Apache Camel is an excellent choice as it is mature and widely deployed, and included in many vendored Java application servers too such as Redhat JBoss EAP. Apache Camel is …
working with Apache's TomCat server, our developer found it most easy given the UI of Camel to perform integration and data processing tasks. when compared to the other two softwares they felt the need to learn new tools outside of Apache family can be avoided and with kafka, …
We did a comparison of the two products with an example application that tested about 10 distinct EIP pattern. We wrote Camel in XML and Java DSL and SI in XML. This was about 3 years ago. At the time, I found the threading model in SI to be more intuitive and Camel's seda. …
Akka or Spring Integration/ XD are alternatives to Apache Camel and very good frameworks on their own (especially Akka which provides a single threaded illusion).
We chose Apache Camel because it was lightweight, easy to get started with and because it had a groovy DSL since we were a grails shop when we started using it.
Apache Camel has been the integration framework of choice, but I was not the person to make the decision to use it. Compared to other competing products like Tibco Business Works, etc., it is free and open source and its licensing policy is acceptable to the management of Cox.
Esper is only similar in that they both are involved in complex even processing, however Esper's aim is a little more complex and specialized. In general however I found Apache Camel to be much easier to understand, implement and debug, whereas Esper's DSL can get very …
We chose TIBCO Messaging not just for its performance but because it looked like the natural way to pave our existing TIBCO Integration architecture. Setting up TIBCO EMS servers and objects seems more straightforward than with most of competitors. It is easy to configure and …
We also use other messaging products: IBM MQ, especially for integration with other systems (server2server), which has been an industry standard for a long time, and Apache Kafka for cloud-native applications. EMS is a worse option compared to them, but it is still acceptable.
No real hesitation has this product was natively compatible to make a proper communication between the two TIBCO products we USE (TIBCO Business Works and TIBCO Active Matrix BPM).
MQ was way more expensive and it is limited in many ways against TIBCO Enterprise Message Service. MQ does not allow easy topic to queue bridging and also requires much more configuration for basic types of activities. Does not support all of the same JMS headers that TIBCO …
We have both products installed. We prefer on product over the other based on applications requirements. We have no preferences on these products, we are using both with good results!
TIBCO is not the industry leader in general but for our unique case and also because we also deployed TIBCO MFT Platform Server, it was the go to choice. The recent improvements like container support also gave us confidence that this is a product for the future. Moving from an …
TIBCO Enterprise Message Service serves as a "barebone" service in our environment. Some applications use TIBCO Rendezvous, others EMS. This allowed us to evaluate the differences and I saw that EMS is more robust and open to different programming languages. In particular, the …
IBM MQ was the old product we used, and we migrated from it to TIBCO EMS. We use also RabbitMQ for our light-weight IPC scenarios and Kafka for our data stream use cases. They 3 compose our complete messaging and streaming solution.
Rabbit is much easier to use and get started with thanks to its online, free, public tutorials and availability of the software on public repositories like Dockerhub, Maven Central, NuGet, etc.
At the time we made the selection and purchase, we found it to be a performant technology. Also, TIBCO was a young company at that time. In order to have us as ther first major client, they accepted to give us a huge discount on their products, including EMS (that's the main …
IBM MQ series is a messaging product . You will need to use IBM product suit heavily and it works better but personaly I have not used it. Apache MQ is also a messaging bus and I have come across it with SAP . EMS is light weigh as its written in C language and easy to implement.
Integration with Tibco BusinessWorks is out of the box. JMS and JNDI configuration is very easy using the available wizard. Client configuration is very simple. Capability to validate the connection at design time.
TIBCO Enterprise Message Service was selected because of the contract with TIBCO. We generally see company buying other TIBCO products such as TIBCO BusinessWorks and then TIBCO offers some discount on their "minor" products. If I would compare technical capabilities of EMS …
It is easy to configure, develop, upgrade and maintain using TIBCO Emterprise Message Service compared to other products on the market. Deployment or setup of new environments can be automated. Support from theTIBCO engineering team is very responsive and effective.
We selected TIBCO EMS because we selected TIBCO BW as an ESB. TIBCO EMS must be installed in the TIBCO BW stack. I prefer TIBCO EMS because it implements very powerful functionality like bridges and routing.
TIBCO Enterprise Message Service has been chosen by the customer because it had many contracts with TIBCO products and it has been full integrated with a TIBCO BusinessWorks platform. Moreover, TIBCO Enterprise Message Service has all required functionalities searched for the …
Message brokering across different systems, with transactionality and the ability to have fine tuned control over what happens using Java (or other languages), instead of a heavy, proprietary languages. One situation that it doesn't fit very well (as far as I have experienced) is when your workflow requires significant data mapping. While possible when using Java tooling, some other visual data mapping tools in other integration frameworks are easier to work with.
Organization which uses TIBCO Business Works or TIBCO Business Process Management or TIBCO BPM Enterprise can make use of TIBCO Messaging as it works well with other TIBCO tools. Many TIBCO tools have TIBCO Messaging products bundled as a package along with other TIBCO tools. Use of dynamic topics and queues makes run time processing easier.
Tibco EMS performs very well, and it meets our stringent performance requirements for corporate messaging backbone.
Tibco EMS scales well, and this is another of our stringent requirements.
Tibco provides good support for the EMS product, and continues to improve it. This is important as we don't want to use something that does not keep up with the changes in the technology landscape.
Some of the documentation is a little sparse. In particular, its TCP-based routes use an underlying Netty server, and the interactions between Netty's decoder capabilities and Apache Camel's routing/handler capabilities can be a little muddy at times. In general it is clear which routes and endpoints are the more frequently used and which haven't been given as much attention.
EMS is a solid system and I see no reason to abandon it, in fact I am eager to see what the next versions will offer and future road maps. Knowing we have support to help us in case of problems is invaluable, both in case of critical issues and to improve overall performance.
Apache Camel has been the integration framework of choice, but I was not the person to make the decision to use it. Compared to other competing products like Tibco Business Works, etc., it is free and open source and its licensing policy is acceptable to the management of Cox.
We chose TIBCO Messaging not just for its performance but because it looked like the natural way to pave our existing TIBCO Integration architecture. Setting up TIBCO EMS servers and objects seems more straightforward than with most of competitors. It is easy to configure and easy to use and understand.
Very fast time to market in that so many components are available to use immediately.
Error handling mechanisms and patterns of practice are robust and easy to use which in turn has made our application more robust from the start, so fewer bugs.
However, testing and debugging routes is more challenging than working is standard Java so that takes more time (less time than writing the components from scratch).
Most people don't know Camel coming in and many junior developers find it overwhelming and are not enthusiastic to learn it. So finding people that want to develop/maintain it is a challenge.