I cannot understand what is so special about Tibco.
Their marketing material stresses that TCP is a pessimistic transport protocol which does not require client acknowledgement of receipt. How can this be true?
To me Tibco is basically a TCP protocol backed by a queue.
Can someone please help me understand the main selling points of Tibco? I am about to have a rant to my manager telling him we are being completely ripped off here.
Answer
I'm assuming that you're going to be using RV (Rendezvous) as that is their main messaging protocol.
This is a UDP-based broadcast-like protocol which is faster than TCP, but still doesn't necessarily have client acknowledgment.
There are configurations of it that do support it (certified messaging,) so whether it's TCP vs. UDP, it's really up to what you're trying to do with it.
The value that Tibco (BusinessWorks) adds is that it provides a simple, straightforward middleware application designer and makes it simple to deploy apps in a load balanced and fault tolerant environment. It gives you all sorts of connectors (soap, http, jdbc, jms etc.) to hook up to what you need and spit it out an many different formats.
It would help if we had more info about what sorts of things you'll be using it for.
ps. instead of RV, go with EMS (a JMS implementation.)
RV vs. EMS:
- RV is UDP, EMS is TCP
- RV is decentralized: there is an rv client on every host. Great for broadcast messaging where you have multiple recipients. Unless you use a 'remote daemon' your messages are contained within your class-c subnet, there are no single points of failure or bottlenecks,
- EMS is centralized (hub and spoke) on a specific server(s) and can traverse subnets no problem.
- EMS is subject to a SPOF, but you can cluster servers in pairs to eliminate this.
- EMS is better for 1-1 or 1-2, but RV is way better for 1-many