消息队列还是Web服务?
在什么情况下,人们会倾向于通过消息队列而不是通过Web服务来交流应用程序(我只是指XML或JSON或YAML或HTTP上的任何内容,而不是任何特定类型)?
我必须在本地网络上的两个应用程序之间进行通话。 一个将是一个Web应用程序,并且需要在另一个应用程序上运行命令(运行在不同的硬件上)。 这些请求就像创建用户,移动文件和创建目录一样。 在什么情况下,我更喜欢XML Web服务(或直接TCP或其他)来使用消息队列?
Web应用程序是Ruby on Rails,但我认为这个问题比这更广泛。
当您使用Web服务时,您有一个客户端和一个服务器:
当您使用像RabbitMQ,Beanstalkd,ActiveMQ,IBM MQ Series,Tuxedo这样的消息队列时,您会期望得到不同且更容错的结果:
消息队列有更多的功能,但这是一些经验法则来决定您是要自己处理错误条件还是将它们留给消息队列。
在考虑REST HTTP调用如何取代消息队列概念方面,近来有相当多的研究。
如果将流程和任务的概念作为资源引入,中间消息传递层的需求开始消失。
例如:
POST /task/name
- Returns a 202 accepted status immediately
- Returns a resource url for the created task: /task/name/X
- Returns a resource url for the started process: /process/Y
GET /process/Y
- Returns status of ongoing process
任务可以有多个步骤进行初始化,并且一个进程可以在轮询时返回状态,或者在完成时返回到回调URL。
这很简单,当你意识到现在可以订阅所有正在运行的进程和任务的rss / atom feed而没有任何中间层时,它变得非常强大。 无论如何,任何排队系统都需要某种类型的Web前端,而这个概念已经内置了另一层自定义代码。
您的资源一直存在,直到您删除它们,这意味着您可以在完成流程和任务后很长时间查看历史信息。
您已经构建了服务发现,即使对于具有多个步骤的任务,也没有任何额外的复杂协议。
GET /task/name
- returns form with required fields
POST (URL provided form's "action" attribute)
您的服务发现是一种HTML表单 - 一种通用且可读的格式。
整个流程可以使用普遍接受的工具以编程方式或由人类使用。 这是一个客户端驱动的,因此是RESTful。 为网络创建的每个工具都可以推动您的业务流程。 通过异步发布到单独的日志服务器阵列,您仍然拥有备用的消息通道。
在您考虑了一段时间后,您可以坐下来认识到REST可能完全不需要消息队列和ESB。
http://www.infoq.com/presentations/BPM-with-REST
消息队列非常适合需要很长时间处理的请求。 请求已排队,可以在不阻止客户端的情况下脱机处理。 如果客户需要收到完成通知,您可以提供一种方式让客户定期检查请求的状态。
消息队列还允许您随着时间的推移缩放更好。 它提高了您处理繁重活动爆发的能力,因为实际处理可以随时间分布。
请注意,消息队列和Web服务是正交的概念,即它们不是相互排斥的。 例如,您可以拥有一个基于XML的Web服务,它充当消息队列的接口。 我认为你寻找的区别是消息队列与请求/响应,后者是当请求被同步处理时。
链接地址: http://www.djcxy.com/p/71287.html上一篇: Message Queue vs. Web Services?
下一篇: How much effort is required to convert an ASMX to WCF web service?