消息队列 服务器需求,消息队列与Web服务？

在考虑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。 为Web创建的每个工具都可以驱动您的业务流程。 通过异步POST到单独的日志服务器阵列，您仍然可以使用备用消息通道。

在您考虑了一段时间之后，您坐下来开始意识到REST可能只是消除了对消息传递队列和ESB的需求。

[http://www.infoq.com/presentations/BPM-with-REST]