ATOM爲「企業」提供消息服務

我參加了Jim Webber演示，在他的演講中他表示ATOM在許多情況下可以很好地替代JMS。由於JMS是一個消息服務，我對此很好奇。你們是否使用ATOM作爲消息服務？它可靠和可擴展嗎？ATOM爲「企業」提供消息服務

JMS的最大優點是它使用push方法（服務器通知新消息）而不是拉方法（客戶端每X毫秒都要求新消息）。我認爲對於「Web 2.0」應用程序來說，這種方法很酷，但對於「企業」應用程序來說，推送方法的可擴展性要高得多。你們覺得怎麼樣？

2009-05-26 razenha

爲什麼你認爲推動是「更具可擴展性」，然後拉動首發？其次，這是一個相當廣泛的問題，如果輪詢間隔沒有意義（我需要亞秒響應時間並且不希望每100毫秒輪詢一次），則一些實時應用程序必須使用推送。但大多數情況下，我總是發現更多的可擴展性和更容易實現。我們將Atom Pub/Syndication格式用於「消息傳遞」類型的基礎架構 - 允許客戶趕上他們可能錯過的舊消息（對於JMS來說更難）。將消息發佈到Atom集合（提要），然後每當用戶啓動客戶端時，他們都可以查詢提要並查看新增內容。也許他們只關心每天每小時都會看到更新 - 在客戶端更容易做到 - 在發佈消息的服務器和使用它們的客戶端之間沒有任何交互。

來源

2009-05-26 19:19:19 Gandalf

我認爲它具有更高的可擴展性，因爲我認爲最好有一臺服務器在新消息到達時通知1000個客戶，如果新消息到達，則每1000秒向服務器請求一次。 – razenha 2009-05-28 19:48:38

我可以明白爲什麼你會這麼想，我曾經這樣做過 - 但實踐中我發現它並非如此。這兩種解決方案都有其優缺點，但WWW全都是關於投票的，它看起來好像很好。就像我上面所說的那樣，發佈消息並讓客戶在自己的閒暇時間消費它們是一種更解耦的解決方案，而且寫起來更簡單。您的服務器將非常輕量級，因此性能更強大的「推」服務器。 – Gandalf 2009-05-28 21:13:39

推送或拉取是否適合給定的問題很大程度上取決於延遲要求，正在傳輸的數據量，節點可用性以及問題的其他特定屬性。不要讓任何人告訴你，任何一方總是比另一方好。

來源

2009-05-26 19:47:18

你在比較蘋果和橘子。

JMS是Java程序使用可靠的點對點和發佈 - 訂閱消息代理的標準API。

Atom是一種用於表示新聞提要的基於XML的數據格式。

如果您願意，可以使用JMS發送包含Atom格式數據的消息。然而，沒有多少意義，因爲Atom提要的內容包含的信息可以讓客戶確定哪些提要項目是新的，以及他們上次調查時已下載的內容。發佈 - 訂閱者代理爲你做這件事，所以發佈 - 訂閱通知可以包含訂閱者感興趣的新信息。

來源

2009-06-10 20:19:02 Nat

ATOM爲「企業」提供消息服務

回答

相關問題