2011-07-05 50 views
0

我們正在設計一個應用程序,其中MDB將拾取傳入消息並執行一系列任務。MDB的Java EE設計模式

一些是像XML驗證功能和一些像例如日誌記錄,MIS條目等方面

編輯:

消息類型可基於功能,如訂貨或不同提高故障或信息服務,如郵政編碼查詢。這些對於調用者也不同,因此調用者A的命令與B不同,但大多數XML結構應該是相同的。

每個人都會經歷功能單元的工作,例如驗證發件人,驗證產品代碼(如果下訂單),安全檢查(基於IP),註冊到我們的數據庫(如果有效),錯誤隊列如果沒有,等等。

我的問題是,因爲我們想要使功能位模塊化,以便我們可以根據消息的類型構建一個執行功能A,B,C和另一個MDB的MDB以執行B,C,D等操作它是 - 並基於哪些任務在所有消息類型中是通用的。

我應該使用什麼樣的設計模式?

其次,是對我有辦法在一個XML文件來配置這些功能,使MDB讀取XML,看看哪些功能是必須執行和按什麼順序?這是將Helper POJO或Session Beans中的模塊與主MDB鏈接的模塊的替代方法,這是我們目前認爲的。

回答

2

@shinynewbike:對於你的問題,最好用MDB來讀取消息並確定消息的類型,然後MDB可以諮詢一個工廠類來返回實現相同接口的處理程序列表,以及哪個MDB可以迭代調用...所以基本上就是一個命令設計模式。一個示例XML配置: -

<configuration> 
<handler name="A" class="A"/> 
<handler name="B" class="B"/> 
... 


<handlers-stack name="stack1"> 
<handler ref="A"> 
<handler ref="c"> 
</handlers> 

<message type="X" handlers-ref="stack1"/> 
<message type="Y" handlers-ref="stack2"/> 
</configuration> 
1

Strategy,很可能與每個MDB可以有幾個戰略的怪癖。如果你想配置一個bean在一個文件(或env-entry或類似的)中使用的策略集,那麼你必須通過JNDI獲得對策略的引用,而不是讓它們被注入,這是一個次要的疼痛。在一個非EJB世界中,我會建議Observer,但對於EJB,我認爲讓一個組件給另一個組件提供一個長壽命的引用是相當困難的。除非他們是@Singleton,而MDB則不是。

1

模式方面不談,我們在我們公司一直努力保持業務邏輯出MDB類本身。這對於您在此嘗試構建的內容非常有用,這幾乎聽起來更像是企業服務總線(ESB)服務網關模式。查看MSDN(即使它不是Java的良好頁面)和Martin Fowler的以下鏈接。

我會建議讓MDB採取的消息。然後你可以使用其他模式(命令,策略,工廠等)來完成實際的工作。或者,主MDB可以確定消息應該轉發到哪裏,然後將消息轉發到專用於特定類型功能的隊列。

這並從多個隊列和MDB的角度增加一些行政和資源開銷。但是它也爲不同信息的不同邏輯之間增加了一點分離(即關注點分離)。它還使您能夠根據性能需求對不同的「實現」隊列進行不同的調整,而不是讓一個隊列成爲所有瓶頸的瓶頸。

有性能方面的考慮,以增加新的隊列。我希望我可以給你一個關於「多少」的具體答案,但是我不能真正的依賴於你選擇用於你的應用服務器和你的JMS和/或消息提供者的東西。不幸的是,對於什麼是正確的,沒有神奇的「數字」。你真的必須坐下來和其他建築師討論你需要多少隊列。最好在設計之前先做這件事。這將排除任何數量的隊列。接下來嘗試找出系統上的負載。你的信息有多大? 100KB? 1MB? 5MB?更大?小嗎?然後一次將有多少消息通過系統傳播?有了這樣的數字,您可以重新審視您的排隊數量決定,看看它是否仍然有意義。您還可以讓應用程序服務器/消息傳遞管理員(或者如果您恰好是您的話)管理使用不同配置設置的隊列,以便通過系統實現更平滑的消息傳遞。 (您可能還需要調整應用程序/消息傳遞服務器的JVM堆設置,具體取決於您遇到的情況)。

不幸的是,通過限制應用程序服務器來獲得性能的最佳方式是閱讀,閱讀,閱讀任何文檔和論壇對此的評論。還有你自己的經驗。

但即使如此。最重要的是良好而簡單的設計。如果你太過分並且排隊等待所有可能影響性能的東西。但是,你可能不會。但是,您可能會使應用程序過度複雜化,並使其更難以排除故障。

我會盡力爲你找到更多的鏈接,但要誠實地採取我們在這裏所說的話,並與你的開發者討論。

如果你可以改變你的問題,何況你可能多少消息類型處理或他們的目的,我們都可以給你一起設計一個更好的推薦,隊列數量等

+0

這聽起來對我們想要做的事非常有吸引力,是否會對多個內部轉發隊列產生任何性能影響?是否有任何參考文件可以讓我指點? 「 – shinynewbike

+0

」會建議允許MDB接收消息,然後可以使用其他模式(命令,策略,工廠等)來完成實際工作。「 - 我把這個問題看作是預設的;我認爲問題是* MDB如何獲得其他對象來完成這項工作,而不必將調度邏輯構建到MDB中。 –

+0

@Tom Anderson:這個問題真的有點兒。今天,我們堅持使用重MDB來完成所有業務任務 - 這些設計爲兩個MDB來處理MessageTypeA和MessageTypeB,當添加新功能時,這顯然是不可擴展的,因爲兩者都必須處理。 問題是A)我應該在運行時使用哪種設計模式來選擇合適的處理方法(策略/命令是我的更好工作方式)和B)如何使用MDB中的最小邏輯進行配置和更多的配置文件。 – shinynewbike