編排與消息驅動體系結構

Question

編排引擎與消息驅動系統的職責是什麼。

如果我必須構建一個系統，它必須將不同的獨立組件（不需要公開Web服務端點的交叉技術/平臺組件）串聯在一起，這是要選擇的工具集？

有更好的選擇嗎？

Answer 1

雖然這個問題被標記爲Java，但我不敢說我​​看過的最好的工具，如果你真的必須走這條路線是Microsoft's BizTalk Server。

當我不得不做這種類型的產品的評價（這是一個幾年前），這是頭肩與主要特徵的存在在競爭中：

• 的Visual Studio的開發環境
• 不錯的可視化工具來描述工作流程和變換
用於以極大的實時報告連接到參與者
• 強大的工作流引擎
• 擴展連接器架構

最後我們選擇保持簡單去了消息路由，儘管這確實需要你控制了所有的參與者，但情況可能並非如此。

Answer 2

使用openESB與netbeans編輯器或任何其他提供標準方式或編排流程的開源BPEL引擎。如果您認爲性能比標準化非常重要，您可以嘗試使用一些專有的ESB或BPM工具，如Jboss jBPM或mule ESB等。

請注意如果您的組件不是Web服務，那麼只能使用BPEL服務你可能不得不使用一些像Mule這樣的ESB，它可以支持200多個擴展協議。

Answer 3

當您決定是否應該使用Orchestration或Message Directed工作流程時，您面臨的一個大問題是，您是否認爲有必要定期更改您的編排工作流程。如果您認爲業務流程需要靈活，因爲它可能會發生變化，那麼採用規範消息格式並使用業務流程，這將最大限度地減少服務之間變化關係的影響。如果您認爲工作流程穩定，您可以採用消息驅動的工作流程。就個人而言，我認爲編排是一般的優秀方法，然而它確實需要更多的軟件基礎設施，其中使用諸如Apache Camel之類的工具，投資是時間與增加長期靈活性的獎勵。

Answer 4

我建議你首先將你的單獨獨立組件作爲服務透露給網絡（我不明白你是否已經擁有web服務）。 之後..最好的選擇取決於您的系統工作量/複雜度。

基本上你可以選擇服務編排和編排。使用BPM/BPEL/ESB制定的服務協調是一種體系結構選擇，其中單個組件（服務協調器/服務組合器）知道哪些步驟需要執行，並且負責以正確的順序調用服務（在協調器本身上配置） 。它還處理事務管理（如果需要）。

恰恰相反的是編排，其中構成整個系統的每個單一服務都知道如何在接收到特定消息時採取行動。事實上，這是各個組成部分之間的問題。服務編排它是服務組合問題的分散方法。

如果你有很多的服務，複雜的規則等...可能會更容易使用服務協調器，如jBPM或類似的東西。