Ich würde gerne die Unterschiede zwischen TIBCO Rendezvous und MSMQ kennen.
Das ist nicht schrecklich strukturiert, aber hier sind einige Unterschiede, es gibt viel mehr als das. Mein Tibco-Wissen ist viel größer als MSMQ. Behandeln Sie daher meine Aussagen zu MSMQ mit größerer Skepsis.
Sie zahlen viel mehr für Tibco, der genaue Betrag variiert aufgrund von Site-Lizenzen und Verhandlungen, aber für einen Standard-Rv-Daemon mit DR-Backup würden Sie im Bereich von 10-20 Tausend USD suchen)
Tibco RV hat mehrere Client-Implementierungen in verschiedenen Sprachen (C, C ++, Net, Java) und unterstützt mehrere Plattformen (Windows, verschiedene Unix-Varianten). Die Client-API ist völlig plattformunabhängig (außer wenn solche Kenntnisse für maximale Effizienz erforderlich sind, müssen die meisten Benutzer nicht damit umgehen).
RV hat das Konzept von Clouds, Multicast-Shared-Networks, bei denen eine an einen Daemon in der Cloud gesendete Nachricht transparent für jeden Client verfügbar ist, der an einem anderen Daemon in der Cloud registriert ist.
MSMQ bietet Persistenz von Nachrichten für spätere Zustellbarkeit im Basisprodukt, TibRV nicht (Certified Messaging api ist erforderlich, aber dann wird die volle Kontrolle über das dafür verwendete Journal bereitgestellt)
RV kann Routing-Daemons verwenden, um eine Cloud über eine WAN-Verbindung zu verbinden (diese sind viel teurer als normale Daemons)
RV verwendet die zugrundeliegende nachrichtenorientierte Plattform, um zusätzliche Dienste so auf sich selbst aufzulegen, dass sie für den Kunden weitgehend transparent sind. Fehlertolerante Gruppen, Certified Messaging und die Routing-Daemons verwenden die zugrunde liegende Nachricht, die reservierte Subjekte weitergibt, um dies zu tun.
MSMQ kann an verteilten Transaktionen teilnehmen, RV nicht.
Tibco liefert einen MSMQ-Adapter (obwohl ich keine Erfahrung damit habe)
Tibco-Nachrichten können eine komplexe interne Struktur haben (mit der Verschachtelung von Nachrichten in ihnen), die MSMQ-Nachricht ist wesentlich einfacher, die Struktur wird normalerweise von den Benutzern definiert.
Tibco api's enthüllen den zugrundeliegenden Socket-Warteaspekt, der es Ihnen ermöglicht, die Dispatch-Schleife auf effiziente Weise mit anderen Socket-basierten APIs zu integrieren.
Tibco hat eine massive Marktdurchdringung im Finanzbereich. Aus Gesprächen mit diesen Unternehmen geht hervor, dass viele ihrer Kunden große Unternehmen mit Standortlizenzen und engagierten Verwaltungsteams sind.
MSMQ ermöglicht auch das Senden von Nachrichten über das PGM-Protokoll (ein zuverlässiges Multicast-Protokoll, das teilweise von Vertretern von Microsoft und Tibco entworfen wurde). Im Prinzip ist dies dasselbe wie das Senden in die "Cloud", auf die ShuggyCoUk sich bezieht, indem mehrere Clients, die eine PGM-Warteschlange hören, alle eine Nachricht von einem anderen Client empfangen sollten, wobei die Multicast-Effizienz des Servers dies nur tun muss Sende es einmal.
Tibco Rendezvous (falls es noch so heißt) ist:
Ich habe MSMQ noch nie benutzt, und ich habe keine Ahnung, welche Teilmenge von denen, die dies tun, über PGM. Wahrscheinlich sind nicht viele meine Vermutung. Es neigt dazu, die Zuverlässigkeits-Trumps-Latenz-Crowd zu zeichnen (das Gegenteil gilt im Allgemeinen für Rendezvous) und Punkt-zu-Punkt statt Multicast.