TIBCO Rendezvous 和 MSMQ
我想知道 TIBCO Rendezvous 和 MSMQ 之间的区别。
I would like to know the differences between TIBCO Rendezvous and MSMQ.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我想知道 TIBCO Rendezvous 和 MSMQ 之间的区别。
I would like to know the differences between TIBCO Rendezvous and MSMQ.
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（2）
这不是很结构化，但有一些差异，还有更多。 我的 Tibco 知识比 MSMQ 丰富得多，因此请以更大的怀疑态度对待我关于 MSMQ 的陈述。
您为 Tibco 支付的费用要高得多，具体金额因站点许可和协商而异，但对于具有 DR 备份的 bog 标准 rv 守护程序，您需要的费用在 10-20 千美元范围内）
Tibco RV 有多种不同的客户端实现语言（C、C++、.Net、Java）并支持多个平台（Windows、各种 Unix 风格）。 客户端 API 完全与平台无关（除非需要此类知识才能实现最大效率，否则大多数用户不需要处理此问题）。
RV 具有云、多播共享网络的概念，发送到云上守护程序的消息将透明地可供注册到云上其他任何地方的守护程序的任何客户端使用。
MSMQ 为基础产品中的后续交付提供了消息持久性，而 TibRV 则不然（需要经过认证的消息传递 api，但随后提供了对用于此目的的日志的完全控制）
RV 可以使用路由守护进程通过 WAN 链接来链接云（这些比普通守护进程昂贵得多）
RV 使用底层面向消息的平台以对客户端基本透明的方式在其自身之上分层附加服务。 容错组、认证消息传递和路由守护程序使用在保留主题上传递的底层消息来执行此操作。
MSMQ可以参与分布式事务，RV不能。
Tibco 提供了一个 MSMQ 适配器（尽管我没有使用它的经验）
Tibco 消息可以具有复杂的内部结构（其中嵌套消息），MSMQ 消息要简单得多，结构通常由用户定义。
Tibco api 公开了底层套接字等待方面，允许您以有效的方式将调度循环与其他基于套接字的 api 集成。
Tibco 在金融领域拥有巨大的市场渗透率，从与他们的讨论来看，他们的许多客户都是拥有站点许可证和专门的管理团队的大型公司。
This is not terribly structured but here are some differences, there are many more than this. My Tibco knowledge is much greater than MSMQ so treat my statements on MSMQ with greater sceptism.
You pay a lot more for Tibco, the precise amount varies due to site licensing and negotiation but for a bog standard rv daemon with DR backup you would be looking in the range of 10-20 thousand USD)
Tibco RV has multiple client implementations in differing languages (C,C++,.Net,Java) and supporting multiple platforms (windows, various unix flavours). The client api is entirely platform agnostic (except where such knowledge is required for maximum efficiency, most users won't need to deal with this).
RV has the concept of clouds, multicast shared networks whereby a message sent to a daemon on the cloud will be transparently available to any client registered to a daemon anywhere else on the cloud.
MSMQ provides persistence of messages for later deliverability in the base product, TibRV does not (Certified Messaging api is required but then full control of the journal used for this is provided)
RV can use routing daemons to link a cloud across a WAN link (these are much more expensive than normal daemons)
RV uses the underlying message oriented platform to layer additional services on top of itself in a manner largely transparent to the client. Fault tolerant groups, Certified messaging and the routing daemons use the underlying message passing on reserved subjects to do this.
MSMQ can take part in distributed transactions, RV cannot.
Tibco supplies an MSMQ adapter (though I have no experience with it)
Tibco messages can have complex internal structure (with nesting of messages inside them), the MSMQ message is considerably simpler, structure is normally defined by the users.
Tibco api's expose the underlying socket waiting aspect allowing you to integrate the dispatch loop with other socket based api's in an efficient way.
Tibco has massive market penetration within the finance area, from discussions with them it appears a great many of their customers are sizeable companies with site licences and dedicated teams of administrators.
MSMQ 还允许支持通过 PGM 协议（这是一种可靠的多播协议，由 Microsoft 和 Tibco 的代表部分设计）发送消息。 原则上，这与将其发送到 ShuggyCoUk 提到的“云”几乎相同，因为侦听 PGM 队列的多个客户端都应该接收从另一个客户端分派的消息，而服务器的多播效率只需发送一次。
Tibco Rendezvous（如果它仍然这么叫的话）是：
我从未使用过 MSMQ，而且我不知道那些使用 MSMQ 的子集是通过 PGM 实现的。 我的猜测可能不多。 它倾向于吸引可靠性胜过延迟的人群（对于 Rendezvous 通常情况相反）和点对点而不是多播。
MSMQ also allows supports sending messages over the PGM protocol (which is a reliable multicast protocol designed in-part by representatives from Microsoft and Tibco). In principle, this is pretty much the same as sending it into the 'cloud' ShuggyCoUk alludes to, in that multiple clients listening to a PGM queue should all receive a message dispatched from another client, with the multicast efficiency of the server only having to send it once.
Tibco Rendezvous (if that's what it's still called) is:
I've never used MSMQ, and I have no idea what subset of those that do, do so over PGM. Probably not many is my guess. It tends to draw the reliability-trumps-latency crowd (the reverse is generally true for Rendezvous) and point-to-point rather than multicast.