Tibco contre TCP (Rendezvous/RV)

Question

Je ne comprends pas ce qui est si spécial au sujet de Tibco. Leur matériel de marketing souligne que TCP est un protocole de transport pessimiste qui ne nécessite pas d'accusé de réception de la part du client. Comment cela peut-il être vrai?

Pour moi, Tibco est fondamentalement un protocole TCP soutenu par une file d'attente. Est-ce que quelqu'un peut m'aider à comprendre les principaux arguments de vente de Tibco? Je suis sur le point d'avoir une diatribe à mon manager en lui disant que nous sommes complètement arrachés ici.

Answer 1

La valeur ajoutée est supposée être la "multidiffusion fiable" et l'indépendance de la plate-forme. Toute l'architecture avec rvd au milieu de tout est un peu stupide, donc à mon avis vous êtes arnaqué, tout comme nous ici, et tout le monde les paie :)

Answer 2

Je suppose que vous êtes va utiliser RV (Rendezvous) car c'est leur protocole de messagerie principal.

Il s'agit d'un protocole de type UDP basé sur la diffusion qui est plus rapide que TCP, mais qui n'a pas toujours d'acquittement client.

Il existe des configurations qui le supportent (messagerie certifiée), donc que ce soit TCP ou UDP, c'est vraiment ce que vous essayez de faire avec. La valeur ajoutée par Tibco (BusinessWorks) est qu'il offre un concepteur d'applications middleware simple et direct et simplifie le déploiement d'applications dans un environnement à charge équilibrée et tolérant aux pannes. Il vous donne toutes sortes de connecteurs (savon, http, jdbc, jms etc.) pour vous connecter à ce dont vous avez besoin et cracher dans un grand nombre de formats différents.

Il serait utile si nous avions plus d'informations sur les types de choses pour lesquelles vous l'utiliserez.

ps. au lieu de RV, rendez-vous avec EMS

RV vs EMS (une implémentation JMS.):

• RV est UDP, EMS est TCP
• RV est décentralisée: il y a un client rv sur chaque hôte . Idéal pour la diffusion de messages lorsque vous avez plusieurs destinataires. Sauf si vous utilisez un 'démon distant' vos messages sont contenus dans votre sous-réseau de classe-c, il n'y a pas de points de défaillance ou de goulots d'étranglement,
• EMS est centralisé (hub and spoke) sur un serveur spécifique et peut traverser sous-réseaux pas de problème.
• EMS est soumis à un SPOF, mais vous pouvez regrouper les serveurs par paires pour l'éliminer.
• EMS est mieux pour 1-1 ou 1-2, mais RV est bien meilleur pour 1 beaucoup

Answer 3

Cela dépend vraiment de qui vous êtes et quels sont vos objectifs. Ma familiarité avec TIBCO est que c'était un système de messagerie utilisé par beaucoup de nos concurrents dans les services financiers pour envoyer des messages sécurisés de front-end Web à l'ordinateur central pour le traitement, et de livrer des choses comme des cotations boursières à notre front end.

Nous avions notre propre produit de messagerie qui portait une étrange ressemblance avec un produit de messagerie que l'une des plus-ups dans notre société a travaillé auparavant à :)

Nous avions un budget technologique de 300 millions, mais gardez à l'esprit nous avions également 2 grands centres de données et plusieurs centres de production, ainsi que 3 bureaux de développement. Maintenant, une entreprise dans notre situation pourrait trouver une bonne chose à utiliser quelque chose comme TIBCO hors de la boîte (nous aurions probablement pu sauver une partie substantielle de ces 300 millions).

Si vous n'avez pas ce genre de budget et vos demandes sont beaucoup moins, alors pour vous, il pourrait bien être une «arnaque». Mais, pour développer ce genre de système par vous-même, pour une organisation comme celle à laquelle je travaillais ... Je suis sûr qu'elle utiliserait une partie substantielle de ces 300 millions.

Answer 4

Bonne question - mais avez-vous déjà essayé de connecter 500 consommateurs sur des sockets TCP?

Si vous avez également un débit élevé (> 10k msgs/sec), vous finirez par utiliser UDP (un message à TOUS les consommateurs, pas des copies!). Mais alors vous n'avez pas la fiabilité de TCP, qui est où PGM ou TRDP entre en jeu. avec une telle exigence, j'ai trouvé TIBCO RV très utile/le meilleur que je connaisse. L'API C est très rapide (oubliez Java si vous avez plus de 10k msgs/sec).

Bien sûr, vous pouvez rouler votre propre multidiffusion fiable, mais l'API RV est très simple à utiliser et porté sur BEAUCOUP de plates-formes différentes. Je suppose que la simplicité d'utilisation est l'argument principal contre TCP. Il faut un jour pour enseigner à un programmeur junior comment écrire un pub/sous-application RV stable et fonctionnel, il faut un mois pour faire la même chose avec TCP.

Le rvd lui-même se trouve juste là et est invisible, alors pourquoi vous inquiéteriez à ce sujet?

Si la sortie n'est pas un problème (scénario 1-1 ou même 1 à 5), consultez plutôt TIBCO EMS (ou un autre fournisseur JMS) ou AMQP.

Et un autre réel avantage sur TCP sont les sujets (ou sujets JMS). Si vous intégrez 20 applications différentes, cela aide beaucoup.