我正在使用SOA風格實現的實時應用程序（通過一些消息傳遞協議（JMS，MQ或HTTP）連接讀取鬆散耦合的組件）。實時SOA應用程序的最佳消息傳遞媒介？
設計此係統的架構師選擇使用JMS來連接組件。這個系統是實時的，因此如果一個組件發生故障，交易將不再需要排隊。此外，沒有必要保證交付或回滾。
在這種情況下，使用JMS而不是HTTP Web服務（速度，資源佔用等）有什麼好處？
我在想的一件事是，由於JMS方法要求我們設置線程池大小（偵聽JMS主題/隊列的組件數量），因此不會更好地適應HTTP服務不需要額外的配置（爲每個HTTP請求創建一個新線程，使應用程序可以擴展到「無限」數量的請求，直到服務器資源耗盡）。
我錯過了什麼嗎？
我不與美國洛特提出在所有的點不同意，但這裏有幾點需要考慮關於HTTP web服務：
你的客戶端只需要知道如何溝通通過HTTP協議 - 幾乎每種現代語言都支持這種協議。 JMS雖然很流行，但比HTTP更專業，因此限制了互聯繫統可以使用的語言。目前對於您的系統來說可能不是問題，但是您以後需要插入其他可能難以支持JMS連接的系統嗎？
您可以爲您的服務提供的WSDL和SOAP等標準很好的支持許多語言，並且有很多工具可以生成代碼以實現管道的兩端（客戶端和服務器） WSDL文件，減少你必須做的dev的數量。這些標準還使得定義和發佈您將在系統之間傳遞的數據規範變得相對簡單，您可能必須親自使用像JMS這樣的排隊技術來完成這些規定。正如S.Lott指出的那樣，JMS爲您提供了使用（無狀態）HTTP協議丟棄的功能：保證排序&可靠性;監測;可擴展性;等等。你確定你不需要這些，並且不需要這些前進嗎？
偉大的問題，順便說一句。
我對您的要求不夠了解，但您可能忽略了可管理性，靈活性和性能。
JMS允許您監視和管理隊列。這些是HTTP缺乏的功能，你必須建立而不是從供應商處購買。
另外，JMS中有一些隊列和主題，允許多個訂戶到單個發佈者。在HTTP中不可能。
雖然在版本1.0中可能不需要這些東西，但您可能會在將來想要它們。另外，JMS可以使用其他傳輸機制，如命名套接字，這樣可以減少開銷（如果沒有所有套接字協商正在進行（幾乎）每個請求。
如果你停下HTTP路由，並且你想支持多臺機器或某種可靠性 - 你將需要一個能夠發現可用Web服務器並在它們之間加載請求的負載平衡器 - 然後故障轉移到另一個網絡服務器，如果一個特定的盒/過程死亡。進行HTTP請求的客戶也將不得不處理服務器失敗並在某個循環中重試操作。
這是消息隊列的主要特性之一 - 可靠的負載均衡，故障轉移和生產者與消費者之間的鬆散耦合，而不必包含重試邏輯 - 因此您的客戶端或服務器代碼不必擔心這種事情。這與你是否想要消息持久化或想使用ACID事務來產生/使用消息（這可能非常方便）是完全分離的。
如果您只關注使用Java的服務器端 - 無論是Servlets還是MessageListener/MDB，它們實際上都有點類似。區別在於負載平衡器。
所以也許這個問題應該是真的 - 與設置您的DNS/NAT/IP/HTTP負載平衡器基礎設施相比，JMS代理更容易設置&嗎？
我認爲這確實取決於情況。在我工作的地方，我們支持Remoting，JMS，MQ，HTTP和sFTP。我們正在實施一種可以說Remoting，JMS，MQ和HTTP的中間件設備，以及一種說JMS，MQ和HTTP的軟件中間件組件。
正如上面提到的，標準幫助我們變得靈活，但專有格式允許更多功能。
簡而言之，我會說使用HTTP進行無狀態調用（最終可以滿足幾乎所有的需求），以及您需要進行有狀態調用的任何專有格式。如果您在大型企業工作，硬件設備通常非常適合作爲中間件：閃電般的快速壓縮，加密，轉換和轉換，總體擁有成本非常低。
我想這取決於你的意思是實時的......我認爲JMS和HTTP都不能很好地支持「實時」應用程序，這意味着它們不能提供可預測的/確定性的性能，也不能正確地確定流中的流的優先級的爭奪。
部分原因是這些技術是建立在TCP之上的，它將所有流量串行化爲單個FIFO，這意味着不能輕易優先考慮不同的流量。此外，TCP定時器不易控制，從而導致不可預知的阻塞和超時...因此，許多流式應用程序使用UDP而不是TCP作爲底層協議。
JMS的另一個問題是典型的實現使用集中化消息分發的代理。這不是獲得確定性性能的最佳體系結構。
如果您正在尋找一種中間件，它可以爲您提供可靠的保證以及您使用JMS獲得的發佈 - 訂閱語義，但是爲了適應實時應用程序領域而開發，我建議您查看一下OMG數據分發服務（DDS）。請參閱dds.omg.org和我寫的這篇文章，論證爲什麼DDS是實現實時SOA的最佳中間件。 http://soa.sys-con.com/node/467488