实时SOA应用程序的最佳消息传递介质?

我完全不同意S.Lott所提出的观点,但是这里有几个关于HTTP Web服务的观点需要考虑:

• 您的客户机只需要知道如何通过HTTP通信——一种几乎所有现代语言都以某种形式支持的协议。虽然JMS很流行,但它比HTTP更专业,因此限制了互连系统可以使用的语言。目前您的系统可能不存在问题,但稍后是否需要插入其他可能难以支持JMS连接的系统?

• 许多语言都很好地支持像WSDL和SOAP这样的标准,并且周围有许多工具可以生成代码来从WSDL文件为您实现管道两端(客户机和服务器),从而减少您必须执行的开发工作。这些标准也使得定义和发布将在系统之间传递的数据的规范变得相对简单,这可能需要使用诸如JMS之类的排队技术手工完成。

• 另一方面,正如S.Lott指出的那样,JMS为您提供了使用(无状态)HTTP协议所放弃的功能:保证订购和可靠性;监控;可伸缩性等。您确定不需要这些功能,并且将来也不需要这些功能吗?

好问题,顺便说一句。

我认为这真的取决于形势。在我工作的地方,我们支持远程处理、JMS、MQ、HTTP和SFTP。我们正在实现一个说远程处理、JMS、MQ和HTTP的中间件设备,以及一个说JMS、MQ和HTTP的软件中间件组件。

正如sgreeve上面提到的,标准帮助我们变得灵活,但是专有格式允许更多的功能。

简言之,我想说的是,使用HTTP进行无状态调用(最终可能会满足几乎所有的需求),以及状态调用所需的任何专有格式。如果您在大型企业中工作,硬件设备通常非常适合作为中间件:闪电般快速的压缩、加密、转换和转换,总体拥有成本非常低。

我对您的需求知之甚少,但您可能忽略了可管理性、灵活性和性能。

JMS允许您监视和管理队列。这些是HTTP所缺少的功能,您必须构建这些功能,而不是从供应商那里购买。

此外,JMS中还有队列和主题,允许单个发布服务器的多个订阅服务器。在HTTP中不可能。

虽然在1.0版中您可能不需要这些东西,但将来您可能需要它们。

此外,JMS还可以使用其他传输机制,如命名套接字,如果不是所有的套接字协商都与(几乎)每个请求一起进行,则可以减少开销。

如果您沿着HTTP路径走下去,并且希望支持多台机器或某种可靠性—您需要一个负载均衡器,能够发现可用的Web服务器并在它们之间加载请求—然后在特定的框/进程死亡时故障转移到另一个Web服务器。发出HTTP请求的客户机还必须在某些循环中处理服务器故障和重试操作。

这是消息队列的主要功能之一——可靠的负载平衡、故障转移和生产者和消费者之间的松耦合,而不必包括重试逻辑——因此您的客户机或服务器代码不必担心这类问题。这完全独立于您是否希望消息持久化或使用ACID事务来生成/使用消息(这对于btw非常方便)。

如果你只关注服务器端的Java——无论是servlet还是MasaGelister-/MDBS,它们都是类似的。区别在于负载均衡器。

因此,问题可能真的应该是-与设置DNS/NAT/IP/HTTP负载均衡器基础结构相比,JMS代理更容易设置和使用吗?

我想这取决于你所说的实时…在我看来,JMS和HTTP都不支持“实时”应用程序,这意味着它们不能提供可预测的/确定性的性能,也不能在存在争用的情况下对流进行适当的优先级排序。

部分原因是这些技术是建立在TCP之上的,TCP将所有流量序列化为一个FIFO,这意味着不同的流量流不容易被优先化。此外,TCP定时器不容易控制,导致不可预测的阻塞和超时…因此,许多流应用程序使用UDP而不是TCP作为底层协议。

JMS的另一个问题是,典型的实现使用集中消息调度的代理。这不是获得确定性性能的最佳体系结构。

如果您正在寻找一种中间件,它可以为您提供JMS所提供的可靠性保证和发布订阅语义,但它是为适应实时应用程序领域而开发的,我建议您查看OMG数据分发服务(DDS)。参见dds.omg.org,我写的这篇文章讨论了为什么dds是实现实时SOA的最佳中间件。 http://soa.sys-con.com/node/467488