ATOM 为“企业”提供消息服务答案

【问题标题】：ATOM for messaging service for "enterprise"ATOM 为“企业”提供消息服务
【发布时间】：2010-10-29 01:06:54
【问题描述】：

我参加了Jim Webber 的演示，在他的演示中，他说在许多情况下，ATOM 是 JMS 的一个很好的替代品。由于 JMS 是一种消息传递服务，我对此很好奇。你们使用 ATOM 作为消息服务吗？它可靠且可扩展吗？

JMS 的最大优势在于它使用 push 方法（服务器通知新消息）而不是 pull 方法（客户端每 X 毫秒不断请求新消息）。我认为对于“Web 2.0”应用程序，这种方法很酷，但对于“企业”应用程序，推送方法的可扩展性要高得多。大家觉得呢？

【问题讨论】：

标签： rest jms message-queue atom-feed

【解决方案1】：

为什么您认为对于初学者来说，推送比拉取“更具可扩展性”？

其次，这是一个相当广泛的问题，如果轮询间隔没有意义，一些实时应用程序必须使用推送（我需要亚秒级响应时间，并且不想每 100 毫秒轮询一次）。但在大多数情况下，我总是发现 pull 更具可扩展性且更易于实现。我们将 Atom Pub/Syndication 格式用于“消息”类型的基础架构——它允许客户端赶上他们可能错过的旧消息（使用 JMS 更难做到）。将消息发布到 Atom 集合（提要），然后每当用户启动其客户端时，他们就可以轮询提要并查看新内容。也许他们只关心每小时、每天查看更新——在客户端更容易做到——在发布消息的服务器和使用它们的客户端之间没有任何交互。

【讨论】：

我认为它的可扩展性要高得多，因为我认为最好有一个服务器在新消息到达时通知 1000 个客户，而不是每 1 秒有 1000 个客户向服务器询问是否有新消息到达。跨度>
我明白你为什么会这么想，我曾经是这样 - 但我发现它不是真的。两种解决方案都有其优点和缺点，但 WWW 都是关于轮询的，而且它似乎可以很好地扩展。就像我上面所说的，发布您的消息并让客户在自己的空闲时间使用它们是一种更加解耦的解决方案，并且编写起来更简单。您的服务器将非常轻量级，因此比“推送”服务器具有更高的性能。

【解决方案2】：

你是在比较苹果和橙子。

JMS 是 Java 程序使用可靠的点对点和发布-订阅消息传递代理的标准 API。

Atom 是一种基于 XML 的数据格式，用于表示新闻提要。

如果您愿意，可以使用 JMS 发送包含 Atom 格式数据的消息。但是，这并没有多大意义，因为 Atom 提要的内容包括让客户确定哪些提要项是新的以及他们上次轮询时已经下载的信息。发布订阅代理会为您执行此操作，因此发布订阅通知可以只包含订阅者感兴趣的新信息。

【讨论】：

很抱歉，您显然不明白这是怎么回事。您可以使用 ATOM 进行消息传递服务。
不，您使用 HTTP + ATOM 进行消息传递。 HTTP 是传输，ATOM 只是用于表示事件的格式。

【解决方案3】：

Push 还是 Pull 是否适用于给定问题在很大程度上取决于延迟要求、正在传输的数据量、节点可用性以及问题的其他特定属性。不要让任何人告诉你任何一个总是比另一个更好。

【讨论】：