Tibco与TCP(Rendezvous/RV)

我无法理解Tibco的特别之处.

他们的营销材料强调TCP是一种悲观的传输协议,不需要客户确认收据.这怎么可能是真的？

对我来说,Tibco基本上是一个由队列支持的TCP协议.

有人可以帮我理解Tibco的主要卖点吗？我即将对我的经理咆哮,告诉他我们在这里完全被扯掉了.

1> Nathan..：

---

我假设您将使用RV(Rendezvous),因为这是他们的主要消息传递协议.

这是一种基于UDP的类似广播的协议,它比TCP更快,但仍然不一定具有客户端确认.

它有支持它的配置(认证消息),所以无论是TCP还是UDP,它都取决于你想要用它做什么.

Tibco(BusinessWorks)增加的价值在于它提供了一个简单,直接的中间件应用程序设计器,使得在负载平衡和容错环境中部署应用程序变得简单.它为您提供各种连接器(soap,http,jdbc,jms等)以连接您需要的东西并吐出许多不同的格式.

如果我们有更多关于你将使用它的东西的信息会有所帮助.

PS.而不是RV,请使用EMS(JMS实现).

RV与EMS:

RV是UDP,EMS是TCP

RV是分散的:每个主机上都有一个rv客户端.非常适合有多个收件人的广播消息.除非你使用'远程守护进程',否则你的消息包含在你的class-c子网中,没有单点故障或瓶颈,

EMS在特定服务器上集中(中心和辐射),并且可以遍历子网没有问题.

EMS受SPOF限制,但您可以成对集群服务器以消除此问题.

对于1-1或1-2,EMS更好,但RV对于1-many更好

2> Nikolai Feti..：

---

增加的值应该是"可靠的多播"和平台独立性.整个架构与rvd在一切的中间是有点愚蠢,所以在我看来你被扯掉,就像我们在这里,以及其他人付钱:)

---

TIBCO是一个非常快速的开发平台/消息传递基础架构,有很多免费的开源替代品.更不用说TIBCO的文档和他们的IDE BusinessWorks一样糟糕.也没有人使用TIBCO所以只是谷歌搜索你遇到的问题是行不通的.他们的支持人员很懒惰,并且只能解决他们平台中的缺陷.这一切都来自于C/C++/C#/ Java程序员,他每天都在使用TIBCO产品并渴望纯Java.远离任何事物和一切TIBCO.

3> Axel Podehl..：

---

好问题 - 但你有没有试过通过TCP套接字连接500个消费者？

如果您的消息速率也很高(> 10k msgs/sec),您最终将使用UDP(一条消息发送给所有消费者,而不是副本!).但是你没有TCP的可靠性,这是PGM或TRDP的用武之地.有了这样的要求,我发现TIBCO RV非常有用/我所知道的最好.C API非常快(如果你的速度超过10k msgs/sec,请忘记Java).

当然,您可以使用自己可靠的多播,但RV API使用起来非常简单,并且可以移植到许多不同的平台上.我想简单的使用是反对TCP的主要论据.教一个初级程序员如何编写稳定且有效的RV pub/sub应用程序需要一天的时间,用TCP做一个月也需要一个月.

rvd本身只是坐在那里看不见,所以你为什么要担心呢？

如果扇出不是问题(1-1甚至1-5场景),请查看TIBCO EMS(或其他JMS提供商)或者AMQP.

与TCP相比的另一个真正优势是主题(或JMS主题).如果要集成20个不同的应用程序,这会有很大帮助.

---

如果您与您推荐的内容有关联,则需要在答案中披露该内容.

4> Larry Watana..：

---

这取决于你是谁以及你的目标是什么.我对TIBCO的熟悉之处在于,它是我们金融服务行业的许多竞争对手使用的消息传递系统,可以将来自基于Web的前端的消息安全地发送回大型机进行处理,并向我们的前端提供股票报价等内容.

我们有自己的消息传递产品与消息传递产品有着奇怪的相似之处,我们公司以前的一位高层人员曾在这里工作过:)

我们有3亿技术预算,但请记住,我们还有2个大型数据中心和几个生产中心,以及3个开发办公室.

现在,在我们的情况下,一家公司可能会发现开箱即用TIBCO这样的东西是很划算的(我们可能已经节省了大量的3亿美元).

如果你没有那种预算而且你的要求要少得多,那么对你来说它可能确实是一个"扯掉".但是,为了自己开发这种系统,对于像我工作过的那样的组织......我敢肯定它会占用这3亿的大部分.