我正在研究使用SOA风格实现的实时应用程序(通过一些消息传递协议读取松散耦合的组件--JMS,MQ或HTTP)。
设计此系统的架构师选择使用JMS连接组件。该系统是实时的,因此如果一个组件发生故障(事务将只是超时),则不需要排队消息。此外,无需保证交付或回滚。
在这种情况下,使用JMS对HTTP Web服务(速度,资源足迹等)有什么好处?
我正在考虑的一件事是,因为JMS方法要求我们设置线程池大小(监听JMS主题/队列的组件数),所以HTTP服务不会更合适不需要配置(为每个HTTP请求创建一个新线程,使应用程序可扩展到“无限”数量的请求,直到服务器资源耗尽为止。)
我错过了什么吗?
答案 0 :(得分:2)
我完全不同意S.Lott提出的观点,但有关HTTP网络服务的几点要考虑:
您的客户只需要知道如何通过HTTP进行通信 - 这种协议很好地支持几种形式的现代语言。 JMS虽然很受欢迎,但它比HTTP更专业,因此限制了互连系统可以使用的语言。目前您的系统可能不是问题,但是您是否需要在以后插入其他可能难以支持JMS连接的系统?
您可以为您的服务提供服务的WSDL和SOAP等标准得到很多语言的支持,并且有很多工具可以生成代码来实现管道的两端(客户端和服务器)一个WSDL文件,减少了你必须要做的开发量。这些标准还使得定义和发布您将在系统之间传递的数据规范变得相对简单,您可能必须使用JMS等排队技术手动完成这些操作。
正如S.Lott所指出的,缺点是,JMS为您提供了使用(无状态)HTTP协议丢弃的功能:保证排序&可靠性;监测;可扩展性;你确定你不需要这些,并且不需要这些吗?
很好的问题,顺便说一下。
答案 1 :(得分:2)
我认为这完全取决于具体情况。在我工作的地方,我们支持Remoting,JMS,MQ,HTTP和sFTP。我们正在实现一个讲中间件,JMS,MQ和HTTP的中间件设备,以及一个讲JMS,MQ和HTTP的软件中间件组件。
正如上面提到的,标准有助于我们变得灵活,但专有格式允许更多功能。
简而言之,我会说使用HTTP进行无状态调用(最终可能满足您的所有需求),以及有状态调用所需的专有格式。如果您在大型企业中工作,硬件设备通常非常适合作为中间件:Lightning快速压缩,加密,转换和翻译,总拥有成本非常低。
答案 2 :(得分:1)
我对您的要求知之甚少,但您可能会忽视可管理性,灵活性和性能。
JMS允许您监视和管理队列。这些是HTTP缺乏的功能,您必须构建而不是从供应商处购买。
此外,JMS中有队列和主题,允许单个发布者拥有多个订阅者。在HTTP中不可能。
虽然您可能不需要1.0版本中的那些内容,但您将来可能会想要它们。
此外,JMS可能能够使用其他传输机制,如命名套接字,如果没有(几乎)每个请求都进行所有套接字协商,这可以减少开销。
答案 3 :(得分:1)
如果您沿着HTTP路线走下去并且想要支持多台计算机或某种可靠性 - 您将需要一个能够发现可用Web服务器并在其中加载请求的负载均衡器 - 然后故障转移到另一个Web服务器,如果特定的盒子/进程死亡。发出HTTP请求的客户端也必须处理服务器失败并在某个循环中重试操作。
这是消息队列的主要功能之一 - 具有故障转移的可靠负载平衡以及生产者和消费者之间的松散耦合,而无需包含重试逻辑 - 因此您的客户端或服务器代码不必担心这一点有点儿的事。这与您是否想要消息持久性或想要使用ACID事务来生成/使用消息完全分开(这可能非常方便BTW)。
如果你只关注使用Java的服务器端 - 无论是Servlet还是MessageListener / MDB,它们都是真的有点类似。不同之处在于负载均衡器。
所以也许问题应该是 - JMS经纪人更容易设置&使用而不是设置DNS / NAT / IP / HTTP负载均衡器基础设施?
答案 4 :(得分:1)
我认为这取决于你的实时意思......在我看来,JMS和HTTP都不能很好地支持“实时”应用程序,这意味着它们不能提供可预测/确定性的性能,也不能在存在的情况下对流量进行适当的优先级排序。争。
部分原因是这些技术建立在TCP之上,它将所有流量序列化为单个FIFO,这意味着不能轻易地优先处理不同的流量。此外,TCP定时器不易控制,导致无法预测的阻塞和超时......因此,许多流应用程序使用UDP而不是TCP作为底层协议。
JMS的另一个问题是典型的实现使用集中消息调度的代理。这不是获得确定性性能的最佳架构。
如果您正在寻找可以为您提供JMS的可靠性保证和发布 - 订阅语义的中间件,但是我开发的中间件适合实时应用程序域,我建议您查看OMG数据 - 分发服务(DDS)。请参阅dds.omg.org和我撰写的这篇文章,争论为什么DDS是实现实时SOA的最佳中间件。 http://soa.sys-con.com/node/467488