Tibco 与 TCP（Rendezvous/RV）
我不明白 Tibco 有什么特别之处。
他们的营销材料强调 TCP 是一种悲观传输协议，不需要客户端确认接收。这怎么可能是真的呢？
对我来说，Tibco 基本上是一个由队列支持的 TCP 协议。
有人可以帮我了解 Tibco 的主要卖点吗？我正要向我的经理咆哮，告诉他我们在这里完全被骗了。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我假设您将使用 RV（Rendezvous），因为这是他们的主要消息传递协议。
这是一种基于 UDP 的类似广播的协议，比 TCP 更快，但仍然不一定有客户端确认。
它的某些配置确实支持它（认证消息传递），因此无论是 TCP 还是 UDP，这实际上取决于您想要用它做什么。
Tibco (BusinessWorks) 的附加价值在于，它提供了一个简单、直接的中间件应用程序设计器，并使在负载平衡和容错环境中部署应用程序变得简单。它为您提供了各种连接器（soap、http、jdbc、jms 等）来连接您需要的内容并将其吐出多种不同的格式。
如果我们有更多关于您将使用它做什么的信息，将会有所帮助。
附：使用 EMS（JMS 实现）代替 RV。
RV 与 EMS：
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:
附加值应该是“可靠的多播”和平台独立性。
以 rvd 为中心的整个架构有点愚蠢，所以在我看来，你被敲诈了，就像我们这里一样，其他人都付钱给他们:)
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 :)
好问题 - 但您是否尝试过通过 TCP 套接字连接 500 个消费者？
如果您的消息速率也很高（>10k 消息/秒），您最终将使用 UDP（一条消息发送给所有消费者，而不是副本！）。
但是这样你就没有 TCP 的可靠性，这就是 PGM 或 TRDP 的用武之地。
有了这样的要求，我发现 TIBCO RV 非常有用/我所知道的最好的。 C API 非常快（如果您的速度超过 10k 消息/秒，请忘记 Java）。
当然，您可以推出自己的可靠多播，但 RV API 使用起来非常简单，并且可以移植到许多不同的平台。我想使用的简单性是反对 TCP 的主要论点。教初级程序员如何编写稳定且可工作的 RV 发布/订阅应用程序需要一天的时间，而使用 TCP 则需要一个月的时间。
rvd 本身就坐在那里并且是不可见的，那么您为什么要担心呢？
如果扇出不是问题（1-1 甚至 1-5 场景），请查看 TIBCO EMS（或其他 JMS 提供商），或者可能是 AMQP。
相对于 TCP 的另一个真正优势是主题（或 JMS 主题）。
如果您要集成 20 个不同的应用程序，这会很有帮助。
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.
这实际上取决于您是谁以及您的目标是什么。我对 TIBCO 的熟悉是，它是我们金融服务行业的许多竞争对手使用的消息传递系统，用于将消息从基于 Web 的前端安全地发送回大型机进行处理，并将股票报价等内容传递到我们的前端。
我们有自己的消息传递产品，与我们公司的一位高层以前工作过的消息传递产品有着奇怪的相似之处:)
我们有 3 亿美元的技术预算，但请记住，我们还有 2 个大型数据中心和几个生产中心以及 3 个开发办公室。
现在，像我们这样的公司可能会发现使用像 TIBCO 这样开箱即用的东西很划算（我们可能可以节省这 3 亿美元中的很大一部分）。
如果你没有这样的预算，而且你的要求也少得多，那么对你来说，这可能确实是一个“敲诈”。但是，要为像我工作的组织这样的组织自己开发这种系统……我确信它会使用这 3 亿美元中的很大一部分。
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.