Tibco versus TCP (Rendezvous/RV)

Question

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 1

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

Answer 2

The added value is supposed to be the "reliable multicast" and platform-independence. The whole architecture with rvd in the middle of everything is sort of stupid, so in my opinion you are being ripped off, just like us here, and everybody else paying them :)

Answer 3

Good question - but have you ever tried to connect 500 consumers over TCP sockets ?

If you also have a high message rate (>10k msgs/sec), you will end up using UDP (one message to ALL consumers, not copies!). But then you don't have TCP's reliability, which is where PGM or TRDP comes in. with such a requirement, I found TIBCO RV very useful/the best I know. The C API is very quick (forget about Java if you are above 10k msgs/sec).

Of course you could roll your own reliable multicast, but the RV API is very simple to use and ported to MANY different platforms. I guess simplicity of use is the main argument against TCP. It takes a day to teach a junior programmer how to write an stable and working RV pub/sub application, it takes a month to do the same with TCP.

The rvd itself just sits there and is invisible, so why would you worry about that ?

If fanout is not an issue (1-1 or even 1-5 scenario), look into TIBCO EMS (or another JMS provider) instead or maybe AMQP.

And another real advantage over TCP are subjects (or JMS topics). If you are integrating 20 different applications, that helps a lot.

Answer 4

It really depends on who you are and what your goals are. My familiarity with TIBCO is that it was a messaging system used by many of our competitors in financial services industries to send messages securely from web-based front ends back to mainframe for processing, and to deliver things such as stock quotes to our front end.

We had our own messaging product which bore a strange resemblance to a messaging product that one of the higher-ups in our company previously worked at :)

We had a 300 million technology budget, but keep in mind we also had 2 large datacenters and several production centers, as well as 3 offices for development.

Now, a company in our situation might find it a good deal to use something like TIBCO out of the box (we could probably have saved a substantial chunk of that 300 million).

If you don't have that kind of budget and your demands are much less, then for you it might indeed be a "ripoff". But, to develop that kind of system yourself, for an organization such as the one I worked at ... I'm sure it would use a substantial chunk of that 300 million.