2014-03-04 39 views
0

在JEE應用程序中,需要擺脫支持工作流執行的大量JMS隊列。工作流通常由多個順序任務組成。任務可能包含外部系統調用和其他業務邏輯。任務處理器被實現爲MDB。當任務處理器接收到來自輸入隊列的消息時,它將執行業務邏輯,從而豐富輸入消息並將其放入工作流鏈中下一個任務處理器的輸入隊列。如果任務處理器根據設置失敗執行任務,則輸入消息會在隊列中回滾以延遲執行或放入錯誤隊列中。 現在,應該使用數據庫而不是JMS隊列。任務應該作爲包含任務狀態(延遲,正在進行,失敗等),目標(應該執行任務的處理器的名稱/別名)以及當然業務數據的數據庫表中的行保存。java ee作業調度和執行

我已經開始使用JCA實現此要求。我的入站連接器掃描數據庫表中的任務,然後調用適當的端點(實現業務接口的MDB)。

是否有其他方法可以滿足要求?也許有人知道這種場景的輕量級開源框架?請不要提及BPM框架。

回答

1

我認爲你想擺脫JMS,因爲管理很多隊列中的很多消息並不像你想要的那麼「輕量級」......而且你的代碼庫正在增長!

  • 您經常監視許多隊列以查看問題或瓶頸。
  • 如果其中一個外部系統關閉了一段時間,則會發出很多調用並失敗,並且所有消息都會進入錯誤隊列。
  • 如果您想了解單個「工作流程」實例發生的情況,請查看日誌文件。
  • 如果你想看到工作流程從頭到尾,你將不得不求助於手寫文檔(這並不總是準確的)。
  • 如果您添加或刪除一個步驟,則必須查找並更新所有導致該步驟的步驟,儘管它們沒有更改。
  • 在部署新版本之前,您需要等待舊版本的作業運行到最終狀態。

雖然你的JMS解決方案滿足他們,都需要考慮新的解決方案更多的非功能性需求:可擴展性,可靠性等所有的一切,這些都是滿足......與嚴格要求任何技術。

也許你可以考慮不同的區域,其中「輕量」是最重要的是你:

  • 可以測試普通的業務邏輯部分,而無需啓動整個框架?即與框架耦合的業務邏輯有多強烈?
  • 學習編程和操作系統有多困難?找到已經知道的人有多難?
  • 你可以從舊系統遷移到新的一步或只是在一個大爆炸?

在這個領域有很多解決方案,但他們都不是一個一站式的解決所有問題的解決方案。一些是面向批處理的(比如Spring Batch或Java Batch),其他則是面向消息的(比如Akka或Hystrix)。比較它們本身就是一門科學。有這麼多的力量或agains它們,你就不會在這裏得到一個完美的答案,即使你提供了很多細節,比如高峯的任務數,步數,外部系統調用號,等我」我一次又一次地看到它:如果您完全瞭解業務工作流程,可以更輕鬆地替換技術......所以這是一個先決條件。

然後,我建議你玩不同的解決方案(如果你有時間),還是留你在哪裏......這可能還不是最壞的所有可能的解決方案。不...我真的意味着:不要實現另一個「輕量級」的東西,你可以打賭,會不會很「輕量級」更快超乎你的想象。

最後一兩件事:我分享傳統BPM框架,即BPEL和朋友你的感受。但是還有像Camunda BPM這樣的輕量級和開源框架值得一看。