TIBCORVVSIBMMQ和JMS消息中间件的对比分析

1、TIBCORendezvous一技术介绍1.1.1. TIBCORendezvous一技术介绍TIBCORendezvous( 或 称 为TIBCORV产 品 是 一 种 中 间 件 ， 它 具 有 发 布 / 订 阅(Publish/Subscribe)、基于主题寻址(Subject-BasedAddressing)和自定义数据信息(Self-DescribingDataMessages)等专利技术功能，使不同应用平台上的信息在一个共享白虚拟总线InformationBus(TIB)上进行传输交换。这些技术能有效地帮助企业从传统的请求/应答(Request/Reply)模式转到自动数据接受的

2、事件驱动模式(Event-Driven,或称之为Push)。TIBCORV有助于在各种应用系统中获取信息和数据，能将异构平台有机地联结起来，通过以即插即用(Plug&Play)、位置无关(Location-Independent)和分布式服务(DistributedServices)的方式在WANff口LAN间配置系统。并且TIBCORV具有认证消息传递(CertifiedMessageDelivery)、容错(FaultTolerance)和分布式队列(DistributedQueue)功能。因为使用TIBCORV不用考虑网络的技术细节，而只需专注于企业应用的开发，所以能快速建立和配

3、置一个可伸缩的分布式应用系统。TIBCORendezvous的优点：加快应用的开发，减少维护费用；唯一独立于硬件、操作系统、网络和协议平台供应商；动态组件替换：进程可以随时加载、退出、替换，而不影响系统运行；屏蔽网络细节；应用伸缩性高；地址无关，简化增加/改变组件；提高分布系统的生命期;一般特性：分布式队列实现一对多信息传送；安全信息传送；冗余机制实现容错；所有平台间对等传输；与其他通讯协议并存于统一系统；支持多种数据内部交换格式；系统开销低，容易嵌入；线程安全，多线程安全保护；支持多点传送；通讯和数据特性：异步通讯；发布/订阅，可靠的广播(broadcast)/多播(multicast)机制

4、;,点对点请求/应答；基于主题消息传送；自定义数据信息与硬件/操作系统无关；透明的信息打包或重组；认证信息传递：明确的信息认证，确保信息传送到目的地；在进程中断和重新启动状态下确保要传递的信息不丢失；分布式队列，自动实现负载均衡功能；传递信息给队列种的某一成员；队列成员进程保持异步运行；容错：通过冗余进程实现系统容错；监控活动的冗余进程；开发特点：提供Java、C、C+ActiveX、.NET、Perl的API库；源码兼容所有的平台；支持同步/异步事件管理结构；TIBCORendezvous 包含的组件TIBCORendezvousDaemon(rvd)为应用进程传递信息，过滤主题信息，分配信

5、息；TIBCORendezvousRoutingDaemon(rvrd)在WA解口LAN间跨网段有效地传递信息， 对TIBCORendezvous应用编码不做任何修改；TIBCORendezvous 部署方法TIBCORV在当前的操作环境中加入两个组件：API库。每个应用程序连接到RVAPI库的某一版本；RV通讯Daemon进程。在大多数环境，每台主机上面运行一个Daemon进程。下图演示了一个简单环境中两个系统进行交互的过程。主机1上运行应用程序A和一个daemon进程，主机2上运行两个应用程序B和C,它们通过单个daemon进程连接到网络上。所有这三个应用程序可以进行相互通讯。Netwcr

6、k任何主机上可以运行任意数量的RV应用程序。 通常一个主机上的所有RV应用程序共享同一个RVDaemon程。RendezvousDaemon进程应用程序依赖RVDaemon后台进程进行可靠和高效的网络通讯。 （通常RVDaemon进程和RV应用程序运行在同一主机上；但是RV应用程序也可以连接到远程daemon）RV应用程序试图连接到RVdaemon进程。如果daemon没有运行，应用程序将自动启动它并连接到daemon进程。RVdaemon负责通讯的所有细节：如数据的传输，包的排序，接收确认包，重发请求，将信息派发到适当的应用程序进程等。它为RV应用程序隐藏了所有这些细节。XML 功能的实现T

7、旧CORV只是一个消息中间件产品，XML数据可以通过RV消息进行传递，但它不提供对XML数据的处理能力。可以通过几种方式来实现XML数据的处理：PrcsgramTIB-1RndozggAPITlaRendlezvousDaemoneHERerdez-AusCjemoriCoinpurer2使用TIBCOBusinessWorks产品对包含XML数据的RV消息进行各种处理，如映射、变换、合并、分解等；使用第三方XML工具或API,以编程方式对RV消息中的XML数据进行处理。如何使用 TIBCORendezvousTIBCORV本身只提供一些后台Daemon程序以及API接口供用户使用。 用户使用

8、这些API,选才?RV支持的开发语言（如C/C+,Java等）开发相应的RV应用程序，并通过后台Daemon进程进行消息的发送或接收。用户也可以选择TIBCO基于RV开发的一些其他产品（如BusinessWorks,各种Adapter等）来简化应用程序的开发。1.1.2.TIBCOAdapterforActiveDatabase一技术介绍概述TIBCOAdapterforActiveDatabase可以把某个数据库中数据的变化可以发送给其他的数据库或应用。它把发布/订阅与请求/回复机制扩充到数据库层面，使数据库应用可以使用多种不同层次的消息传递服务。它支持所有的ODBCS容数据库，包括DB2,

9、Oracle,Sybase,Informix,MicrosoftSQLServer,TimesTenin-memorydatabase等。TIBCOAdapterforActiveDatabase|PublishISubscribe特色事先定义的数据库表中的行发生插入、修改或删除操作时，可以把数据按照TIBCORendezvous消息格式发布创建数据的拷贝，按照数据值来发布数据直接引用新的数据来发布信息。可以使用参数定义发布消息的主题，即可以根据发布数据的内容动态床架主题。可以使用可靠传输和保证传输两种方式进行数据的发布。保证传输的接收者可以事先在保证传输信息的发布者上注册。事 先 定 义 的

10、 数 据 库 表 中 的 行 发 生 插 入 、 修 改 或 删 除 操 作 时 ， 可 以 订 阅 按 照TIBCORendezvous消息格式发布的数据变化可以使用含有通配符的主题名称订阅消息可以使用可靠传输和保证传输两种方式进行数据的订阅。可以根据消息数量或超时时间进行批处理提交。可以使用基于TIBCORendezvous客户端应用定义特定的主题使用RV消息格式向数据库发送SQL语句或存储过程。使用内建的函数来配置发布代理和订阅代理，修改信息内容EnterpriseMessagingServirviceTIBCOBusinessWorksTIBCOAdapterforR/3TIBCOAd

11、apterforSiebel配置TIBCOAdapterforActiveDatabase来满足需求：定义数据库表间关系，发布所有的相关表内容。使用定期检查或通知机制监测数据库的改变。基于的标准：通过ODBC1接多种数据库与其他TIBCOActiveEnterprise组件实现互操作。使用TIBCOHawk!行系统监控。支持的系统平台WindowsHP-UXSolarisAIXLinux支持的数据库系统OracleSybaseMSSQLDB2forOS/390DB2forAS/400DB2UDBforWindowsandUnixTIBCORV,IBMMQ 和 JMS 消息中间件的对比分析对于消

12、息中间件，绝大多数熟悉的是旧MMQ,这是目前使用最广泛的中间件产品。国内还有一款中间件TongLinkQ,结构和MQ相似。 其实在国外还有一款叫Rendzvous的消息中间件应用也非常广泛，只是在国内应用不多，所以在国内并没有MQ那么大的名气。这款消息中间件的设计和MQ是完全不同的，有很多不同的特性特点，使得它在某些应用场景具备更多的优势。总结一下Rendzvous的架构特点，和MQ的架构以及JMS消息中间件的架构做比较。深入了解和比较这些中问件产品，才能用的准用的好它们。先总结一下消息中间件的功能，以上的三类中间件都实现了这些功能。实现消息的异步发送接收，发布订阅，使得两端的应用解耦。实现消

13、息持久化机制，保证消息可靠性传输。优化网络传输，支持断点续传。.分布式结构VS星型结构，推送VS接收，服务端缓存VS客户端缓存。RV和MQ都是分布式结构的，和JMS消息中间件的星型结构不同。分布式消息中间件的Server在应用环境里都会部署多个，彼此互联，没有主备之分。JMS消息中间件的应用部署一般都是主备两个Server,消息的发送和接收应用平时和主Server相连，有问题时切换到备Server,主备Server共用公共的存储设备来保存消息。MQ和JMS消息中间件都采用消息接收端主动接收消息的方式。消息从发送端发出后，首先会缓存到Server上， 接收端应用发起一个接收消息的请求，Serve

14、r把消息作为应答返回给接收端。接收端不执行接收动作，消息就会一直在Server上保存。RV和这两种消息中间件都不同，使用的是消息推送的模式。消息从发送端发出后，并不在Server上缓存，Server只做路由把消息推送给消息接收端。消息接收端只要连接上Server,订阅要接收的消息，这些消息就会源源不断地从Server那里推送过来，消息先缓存到接收客户端的队列里，接收端应用再从队列里取消息。总之RV是一个分布式结构，推送消息模式，客户端缓存的消息中间件。分布式结构适用于分布是应用系统，方便做扩展，推送加客户端缓存适用于高实时性消息的处理，消息需要在第一时间到达目的地，过时的消息的没有必要保存下来

15、的,消息接收端应用需要做的事情就是不断地处理已经推送到的消息。2,使用广播和组播来实现一对多的发布订阅MQ和JMS消息中间件在IP层都使用点对点的传输方式，而RV在IP层使用的是广播或者组播的方式。使用广播或者组播可以直接实现一对多的发布订阅形式，发布应用发布消息到RV网络上，这些消息会广播到网络的每一个节点上，每一个订阅应用都会收到这些消息。而MQ和JMS实现发布订阅就要麻烦的多了，都是在Server按消息的Topic来缓存消息，为每一个订阅者拷贝每一条消息的引用。当所有订阅者都从Server上取走某条消息，这条消息才在Server上删除。3.UDPVSTCP。MQ和JMS消息中间件不论是S

16、erver和Server的通信，还是Server和Client的通信，在传输层都使用TCP协议，保证消息传输连接的可靠性。而RV在Server和Server之间的通信使用了UDP协议，牺牲可靠性来达到高实时性的需求。RV有两种可靠性级别，RVReliable和RVCM。RVReliable模式使用基于UDP增加了一定可靠机制的TRDP协议，在一定范围内具有消息包的检查和重传机制，保证了一定程度的消息可靠性，但不保证消息不丢失。RVCM在RVReliable基础上更进一步，在消息级别具有消息确认和重传机制，可以保证消息绝对不丢失。对于长度在1500个字节以下的消息，RVReliable发布消息能

17、达到150万笔消息每秒， 接收也能达到50万笔消息每秒。传输消息的性能是非常好的。4,使用消息Subject做收发两端的匹配。MQ和JMS消息中间件在Server端按Queue和Topic来缓存消息，消息的发送端和接收端按Queue和Topic的名字来匹配。每个Server能创建的Queue和Topic是有限的，这也就限制了使用MQ和JMS消息中间件构建的应用， 这些应用在做消息收发处理的时候只能使用粗粒度的消息分类。RV不在Server端缓存消息， 也没有Server端的Queue和Topic。 它是使用消息的Subject来做消息发送端和接收端的匹配的。每个消息都有Subject,Subject格式是多个字符串的用接，没有数目或者长度的限制。比如在市场数据系统里，行情数据消息的Subject里包含金融品种的名字，这样的Subject可以有上百万个。消息订阅端可以细到只接收某个市场的某个品种的行情数据。RV使用优化的算法实现Subject的筛选。如果RV网络