JMS和Web服务之间的区别

本文介绍了JMS和Web服务之间的区别的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我需要开发一个接受订单并返回确认的系统.订单可能来自Java或非Java客户端.

不确定是否要进行Web服务实现或JMS.

任何建议...

解决方案

JMS是用于抽象化消息传递中间件(如ActiveMQ或IBM MQSeries)的API.

消息中间件具有存储转发范式和异步消息传递，而Web服务则倾向于促进调用范式的同步过程.在很多可能出错的分布式系统中，当系统的某些部分不可用或性能不佳并且处理所需的代码往往是一个错误的代码时，异步处理这些内容会使头脑更专注于需要执行的操作.简单得多.

如果您有多个服务器在同一队列上侦听，则群集部分变得不那么重要，在这种情况下，并行和负载平衡是免费的.

我个人觉得JMS比Web服务更易于使用，并且更健壮和可靠，但是消息传递中间件必须支持您要使用的所有平台.如果所有需要彼此交谈的组件都在您的控制之下，那么我将认真考虑具有JMS接口的消息传递中间件.

如果另一方是外部的，则可能是Web服务规则，在那种情况下，您可以考虑使用薄层将外部Web服务转换为内部消息传递基础结构，以便您仍然具有最大的优势. /p>

如果它只是在Web应用程序上拍一个远程API"，那么它当然也不用设置异步消息.

I need to develop a system which accepts orders and returns confirmation. Orders could come from java or non java clients.

Not sure whether to go for web service implementation or JMS.

Any suggestions ...

解决方案

JMS is an API which abstracts messaging middleware, like ActiveMQ or IBM MQSeries.

Messaging middleware has a store-and-forward paradigm and asynchronous message passing, while web services tend to promote a synchronous procedure calling paradigm. In distributed systems where a lot can go wrong, dealing with things asynchronously tend to focus the mind better to the things you need to do when part of the system is not available or poorly performing and the code needed to deal with that tends to be a lot less complicated.

Clustering parts become trivial if you have multiple servers listening on the same queue, parallelism and load balancing is for free in this case.

Personally I find JMS much easier to work with and more robust and reliable than web services, but the messaging middleware must support all platforms you want to use. If all the components who need to talk to each other are under your control, I would give a messaging middleware with a JMS interface serious consideration.

If the other party is external then probably Web Services rule, and in that case you could think of a using thin layer to convert the external web service to an internal message passing infrastructure so you still have the most of the advantages.

If it is "just slapping an remote API on a webapp" then of course it does not pay either to setup asynch messaging.