現有方案：兩個應用程序正在使用隊列進行通信。 其中一個永遠是生產者，而其他永遠是消費者。可以通過輪詢Web服務調用來替換JMS消息嗎？
'生產者'生成和保存數據在自己的存儲。然後使用隊列將其發送給消費者。
我讀到的關於JMS消費者（和偵聽器）實現（使用Spring）的內容越多，我們就可以輕鬆地用Polling Webservice調用來替代消息傳遞。
這是因爲JMS Listeners所做的一切就是保持線程處於打開狀態，監聽隊列。所以如果你的JMS監聽器ConnectionFactory被設置爲有10個連接，你將有10個阻塞線程。
因此，而不是保持10個線程打開，而不是使用1個線程每隔30秒輪詢一次。該輪詢可以指示WebService在響應中發送100個數據項（或更多）。
這些都只是抽象。如果你想到它，它只是一個插槽，你正在推動數據。真正不同的是每個抽象所提供的保證。足夠瘋狂的你可以擁有通過使用HTTP作爲傳輸的JMS和JMS服務的SOAP Web服務。
簡而言之，JMS指定了一組與消息傳遞（確認，重新傳送，故障轉移等）相關的保證。 Web服務（大多數人認爲它們的方式）主要由一組描述消息格式（SOAP，JSON）的規範組成，這些規範分層描述傳輸（HTTP）規範。
關於投票。大多數JMS實現都是推式模型。訂閱者向代理註冊，隨着消息到達，他們被推送給訂閱者。推模式比拉模式具有更高的吞吐量。
那麼這完全取決於您的要求。具有基於JMS通信有自己的優勢，如：
當然這一切都是有代價的，所以這一切都取決於你的需要。如果您的系統吞吐量較低，每分鐘只有幾條消息，並且可能由於通信錯誤而丟失一些消息，那麼您可以切換到基於輪詢的Web服務。
如果你想實現自己的排隊服務，那麼隨意。關於唯一的主要好處就是不必依賴第三個組件（JMS服務器）。
如果您的資源涉及10個額外的線程和10個額外的套接字，那麼在使用JMS服務器之前，您確實還有其他問題需要考慮。廣告足夠的增量成本無關緊要。
如果您根本不需要排隊，那麼只需簡單地調用web服務並完成它。
如果你自己實現它，那麼你必須執行隊列，持久性和恢復（當系統出現故障在第29秒，並失去100個未發送的郵件），事務恢復，重新連接邏輯等
如果我必須這樣做一個單一的隊列到一個單一的生產者的單一目的地，並且JMS服務器每年在許可費等方面花費了一千美元，那麼是的，我肯定會考慮重做那些自己的邏輯。或者如果我不想承擔JMS服務器的內存壓力。
但是JMS服務器是免費的，它們與我的應用服務器一起提供，它們配置了六次鼠標點擊，並且對於大多數需求它們「足夠快」。他們今天無處不在的基礎設施。
只是機率真的很高，它根本不值得努力重塑這個輪子，恕我直言。
答案是延遲。通過JMS，消息可以在發送消息的同一秒內使用。使用任何投票解決方案，您平均會在投票週期的大約一半時間內遇到延遲。
這也消耗更多的CPU和網絡，因爲輪詢消費者必須每隔一秒醒來並執行實際的呼叫。
最後你必須考慮重複和交易。使用正確設置的JMS，您可以確保收到完全一致的消息。
偉大的觀點。我希望我能接受兩個答案！ – rk2010
好的，我明白你的意思，如果HTTP調用因爲某種原因失敗，數據就會丟失。與JMS相反，除非消費者承認它，否則數據不會丟失。有趣的是，在這種情況下，製片人始終存在數據。因此，HTTP呼叫失敗，消費者可能會在30秒內重試。 – rk2010
這是一個相當深的兔子洞。你應該看看你的要求，並決定你的解決方案是否滿足需求。雖然具有重試的簡單WS輪詢解決方案可能適用於您，但對於進行調用另一個WS的WS調用並更新兩個數據源的人可能無效。後者可能會更容易與JMS和JTA協同工作 – nsfyn55