Answers:
使用Web服务时，您有一个客户端和一个服务器：
当您使用RabbitMQ，Beanstalkd，ActiveMQ，IBM MQ系列，Tuxedo之类的消息队列时，您会期望得到不同且容错性更高的结果：
Message Queues具有更多功能，但这是决定是否要自己处理错误条件或将其留在消息队列中的一些经验法则。
在考虑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的。为网络创建的每个工具都可以推动您的业务流程。通过异步POST到单独的日志服务器阵列，您仍然具有备用消息通道。
在考虑了一会儿之后，您会坐下来开始意识到REST可能完全不需要消息队列和ESB。
消息队列非常适合可能需要很长时间处理的请求。请求被排队，并且可以在不阻止客户端的情况下脱机处理。如果需要将完成通知客户端，则可以为客户端提供一种定期检查请求状态的方法。
消息队列还使您可以跨时间更好地扩展。因为实际的处理过程可以跨时间分布，所以它可以提高您处理大量活动的能力。
请注意，消息队列和Web服务是正交的概念，即它们不是互斥的。例如，您可以有一个基于XML的Web服务，它充当消息队列的接口。我认为您要寻找的区别是消息队列与请求/响应，后者是请求被同步处理时。
消息队列是异步的，如果传递失败，则可以重试多次。如果请求者不需要等待响应，则使用消息队列。
短语“ Web服务”使我想到了通过HTTP对分布式组件的同步调用。如果请求者需要回复，请使用Web服务。
我认为通常来说，您需要一个用于阻塞任务的Web服务（此任务需要在执行更多代码之前完成），以及一个用于非阻塞任务的消息队列（可能需要一段时间，但我们不希望这样做）。无需等待）。