分散收集實現

我是一個在信息系統集成（SOA，ESB，消息代理等）領域工作的程序員。分散收集實現

目前我正在致力於一個專有的ESB，但不幸的是它沒有實現Scatter-Gather pattern。

其實，我會感興趣的解決方案來異步實現這種模式。在this example中，的最佳報價不在與報價請求（例如，不是同步請求/回覆服務）相同的同步交易中管理。

因爲我們正在討論異步處理，我正在尋找一個可靠的解決方案。例如，如果供應商B出現故障（由於技術問題），我不想發回錯誤報價請求。我必須將整個交易視爲保證交易，並且能夠在一個時間點重新處理對賣方B的呼叫。然後交易會神奇地繼續，我將能夠發回成功的報價請求。

我已經能夠在過去使用專有的複雜事件處理（CEP）工具實現這種模式。事實上，CEP工具能夠堅持全局事務的狀態，並從供應商A，B和C

所以我在想，如果有一個現有輕量級的解決方案來實現可靠這種格局回來關聯事件辦法。

最後但並非最不重要我不搜索另一個ESB工具。我知道Apache Camel，Spring Integration，Mule或WSO2正在實現這種模式，但我對一種專用解決方案很感興趣。

感謝

來源

2015-10-29 RickyMartin92

「但我對一個專門的解決方案很感興趣」 - 這是什麼意思？ –

來自Udi Dahan本人的評論？多麼偉大的時刻:) 我想說，我不尋找另一個ESB（我已經有一個），我想要一個專門的解決方案來管理事件關聯，事件過濾等......到目前爲止，我最好的搭配是Apache Storm但分散 - 收集實施並非真正開箱即用。 – RickyMartin92

風暴並不是一個真正輕量級的解決方案。但是你可以使用駱駝作爲庫，即在進程中。 –

你的需求下降兩大空間。事件關聯/過濾通常使用CEP引擎完成，而像Scatter-Gather這樣的集成模式要使用ESB完成。確實，CEP引擎將促進某種級別的消息轉換和集成功能，而ESB還將支持事件的基本過濾/關聯（主要是事件處理而不是複雜事件處理），但這些並不是它們最初設計的目的。

因此，如果無法使用ESB或CEP服務器實現它，那麼您的解決方案可以同時包含CEP和ESB服務器，每個服務器都執行一些特定的任務，這些任務是他們最適合的。（這是不可能的，一個供應商構建一個組合的服務器來執行所有這些東西）

話雖如此，如果你打算用WSO2產品來實現這一點，並且如果你真的需要一個服務器實例，你可以考慮安裝CEP如解釋in this doc所述，位於ESB頂部的功能。否則，您可以使用像Thrift這樣的高性能協議來連接兩臺服務器。

來源

2015-11-05 15:54:39

其實我只有一個要求是實現分散 - 聚集模式。即使我不完全同意你的理解，我理解你的觀點，因爲所有的ESB都沒有實現它。當然，基於EIP模式的所有「現代」ESB（因爲分散 - 聚集是一個EIP）會將其考慮在內，但對於「經典」類型（如TIBCO或webMethods）則不是這種情況。儘管感謝您的評論。 – RickyMartin92

分散收集實現

回答

相關問題