請求 - 響應模式的JMS

我們計劃用Java實現我們的新系統。由於系統的性質，需要與各種內聯網/外聯網/互聯網系統進行交互，並與各種外部系統共享相同的邏輯（只需稍作調整），我們計劃將業務邏輯從前端轉移出去，使其成爲服務並計劃使用JMS將表示層和業務邏輯層互連。表示層發送請求，業務邏輯層發送處理結果的響應。請求 - 響應模式的JMS

做了一個小的POC系統後，我們發現這種方式非常有前途。但甲骨文的人（我們計劃使用web服務器和JMS服務器）表示總會有性能問題，因爲消息隊列的性質不適用於請求響應模式。

有沒有關於Oracle傢伙的意見的建議？我們對於Java世界相當陌生（完全沒有關於java的經驗，並且必須在內部實現這個系統，沒有外包選項），儘管我們測試了POC每秒約300 req-resp（這對我們來說似乎足夠了系統），我們仍然不能確定系統在線後是否會出現性能下降...

來源

2012-04-11 dhchen

如果您僅僅是在異步服務方法調用之後，那麼新的['@ Asynchronous']（http://docs.oracle.com/javaee/6/api/javax/ejb/Asynchronous.html）EJB方法Java EE 6可以完成這項工作。如果您使用的是帶有多個接口的更一般的點對點類型請求/響應服務，那麼我建議您查看一個ESB框架或平臺來幫助您解決問題。 – 2012-04-11 03:27:35

@AlistairIsrael我們計劃使用jpa而不是ejb部分，因爲它很難實現而臭名昭着，而且我們至少需要超過10000個ejb對象。 ESB將在Extranet部分工作，但對於Intranet部分，我們需要更簡單的東西，因此jms – dhchen 2012-04-11 05:39:35

肯定不是性能問題。

由於JMS的事務性質，您會失去一點點。來自表示層的消息必須在業務層開始處理之前記錄在日誌中，類似地，在表示層可以開始處理回覆之前，必須記錄回覆。

然而，這種小小的缺點不僅僅能夠在重負載時並行處理的能力以及在極端負載下安全排隊請求的能力得到補償。（在這些情況下，RPC應用程序只是簡單地死亡，JMS只是減慢速度）。

主要問題是處理異步環境中的錯誤。如果您的表示層發送請求，應該在合理等待答覆之前多久，然後才能假定業務服務器端出現問題？如果表示層炸燬了你應該對回覆消息做什麼，特別是如果它是某種類型的更新？所有這些問題都可以解決，但是，你需要考慮如何。

來源

2012-04-11 02:46:43

感謝您的性能部分。至於你的最後一段（在異步環境中的錯誤），你能否給我一些關於你提到的錯誤句柄的暗示？兩階段提交？ – dhchen 2012-04-11 05:40:45

在您的場景中，您將有三個獨立的獨立工作單元。請求者放置，服務器獲取並放置回覆，請求者獲取。您如何處理錯誤和中斷與您的業務需求密切相關。 – 2012-04-11 05:49:31

請求 - 響應模式的JMS

回答

相關問題