TIBCO Rendezvous Reviews

We are dealing with both TIBCO and Tomcat. Tomcat is the backend server which is used at the back end of TIBCO 5.x. TIBCO is a product-based company that creates products for businesses such as pharma, retail, and finance. They develop their own products and provide sales and support for them. We are currently working with a big pharma multinational company from Switzerland that uses TIBCO.

There are many TIBCO integration tools available. We are using DevOps, Grafana, Docker, and Kubernetes to deploy instances and applications. We have internally developed automated scripts that detect when any application experiences downtime. After a one-hour interval, these scripts execute automatically and bring up applications that are experiencing downtime.

Kubernetes is the platform where we deploy pods containing YAML files. We deploy Python or Java JAR files and run them. It does not require the operating system and we run it flawlessly.

TIBCO Rendezvous is a great tool but has some advantages and disadvantages. It runs on TCP and has a specific port on each server. However, the messages are not guaranteed messages. Messages that float on TIBCO Rendezvous are not persistent, which means we can lose the message. That is the disadvantage of TIBCO Rendezvous. If there is a disadvantage with TIBCO Rendezvous, people prefer to use TIBCO EMS because businesses do not want to lose their messages.

The best features in Rendezvous require that when we need to install the TIBCO environment, the dependency of Rendezvous itself is required after the Java installation. There is too much dependency of TIBCO Rendezvous for the TIBCO environment to run. On each server, we need TIBCO Rendezvous messaging to communicate with different servers, both within the servers and outside the server.

TIBCO Rendezvous is a good messaging service, but there is a feature of losing messages. We cannot guarantee that a message will reach the client because there is no client send receipt and acknowledgment receipt protocol that works in TIBCO Rendezvous. With TIBCO EMS, we have client send and acknowledgment responses. TIBCO Rendezvous is very good to use within the TIBCO servers. If businesses need to use it, they always prefer to use TIBCO EMS outside the servers, as TIBCO EMS is the best.

The response time of Rendezvous is good, but I have one disadvantage only for Rendezvous. We can lose the messages over TIBCO Rendezvous. That is not good for businesses. They are not ready to lose messages.

Eight.

We do not have scalability issues everywhere. We have a limited scope for Kubernetes, but we have a vast scope for TIBCO, which is an integration tool to send and receive messages for end-to-end transmission from different systems.

Customer service is satisfactory.

We have not used previous solutions of that kind.

TIBCO has quite high prices as compared to other messaging services. However, the business still relies on TIBCO.

TIBCO Rendezvous is an alternate solution. TIBCO EMS is one of the messaging servers. TIBCO Runtime Agent is the runtime entity which executes or runs the applications on the servers.

I am a consultant. We were using IBM MQ for messaging middleware. I have not used IBM Cloud. My overall review rating for this product is eight out of ten.

We have many use cases for TIBCO Rendezvous. For example, since 2008 we are using it as the middleware of integration between distributed applications, and the core banking channels and mainframe applications. Additionally, in 2018 we implemented an event bus to leverage the digital service and digital marketing platform.

TIBCO Rendezvous has a strategy to communicate in the network between the Daemons in a very fast fashion. They provide strategy through secure communication. They use the UDP protocol, but It's with reliable communication using another protocol to create a type of guarantee. It has a high level of communication throughput between the daemons. This is the best capability the solution has.

TIBCO Rendezvous is currently restricted in a cloud environment and it would be more useful in a hybrid cloud setup. It does not work correctly in a cloud environment alone. This is something they can improve in the future.

I have been using TIBCO Rendezvous for approximately 13 years.

TIBCO Rendezvous is very scalable. We are running a digital service platform and TIBCO Rendezvous has about 600 days of time without any problems in the system.

The infrastructure we have. It's very stable to support infrastructure.

We have approximately 4,000 developers using this solution.

We don't have any plans to increase usage

TIBCO Rendezvous' support is very good. We have a resident here in Brazil and he always responds fast to problems or issues we have.

Positive

We did use other solutions previously, but we have found TIBCO Rendezvous was the best for our use case.

TIBCO Rendezvous has some difficulties to be deployed in a cloud environment. We use it typically in a bare-metal infrastructure. We can use a cluster of the nodes of the other companies. For example, we cannot deploy in the cloud infrastructure, but the companies cannot deploy TIBCO Rendezvous in a cloud environment without issues.

It is very easy to start the TIBCO Rendezvous in the DMO infrastructure.

The first time we deployed TIBCO Rendezvous, we used it to support individual transaction integration between the distributed and mainframe applications. We spent approximately five days deploying TIBCO Rendezvous in the companies in their application. It's very fast to implement and to use.

We did not use an integrator, we did everything in-house.

We have approximately four system engineers and junior engineers that support TIBCO Rendezvous.

There is a license needed to use this solution.

We did evaluate Oracle and IBM messaging solutions, we made some prototypes and proof of concept. TIBCO Rendezvous was our best choice.

If you implement this application in a microservice or distributed fashion. For example, you can use TIBCO Rendezvous as a reliable message burst to guarantee the delivery of the message. With other solutions, you need another product that will guarantee the delivery of the message from the provider and the consumer inside. TIBCO Rendezvous does not have this, it's a very important feature. You need to evaluate and select what solutions suit the use case best.

I rate TIBCO Rendezvous a nine out of ten.

Connectionless is the most valuable feature. The whole idea behind that is I don't have to be physically connected to a server in order to receive a message. What it does is that it broadcasts messages on the multicast and UDP ports.

Its speed is also an important feature.

There have been improvements; in the original version, there was basically a broadcast 255 address. Now, you can use specific multicast addresses. So, it became more specific.

The point-to-point connection issue with the mailbox needs to improve. In the case where you can send a message from the mailbox with the Daemons, so the point-to-point connection needs to improve a little bit. Point-to-point means that there's a way of being able to communicate from one daemon to the other, and being able to restart daemons on the fly. That is one of the things that has to be improved.

We have used this solution since 1997, i.e., roughly for about 20 years.

There were no issues with the stability, it is very good.

It's more of a transport mechanism. For example, if I have subscribers for IBM in the market, so it's a one-to-many software, it's not a point-to-point solution. It allows people to subscribe for events anonymously. The scalability depends more on the OS and the network, this is where the scalability issue lies; it's outside of the realm of the machine specifically.

They're pretty good with the technical support. TIBCO has been a good vendor for technical support.

We wrote our own deamons. It is called OTS (our own version software).

The setup is very straightforward.

They're very good with their licensing, although a little expensive. But, I recommend others to run a trial before they do it.

We did an extensive choice, i.e., when we originally made the choice. At that time, there were not that many vendors doing what TIBCO was doing. That's the truth, they had the monopoly in the market at that time.

You should read the documentation really well. They have made some improvements over the years(during the past 20 years). It's a hundred times better than what it was back in 1996/1997. It's much better now.