OSGi服務的消息總線

Question

我正在一個項目中，我們將基於一套更大的定製技術基於OSGi服務遷移一個主要軟件系統。爲此，我們可能需要一些類似OSGi服務的消息總線。

• 同步和異步傳送
• 點至點僅
• 保證交付 - 優選經由文件持久
來自同一客戶端（異步模式）有序
• 嚴格消息，但不一定來自不同客戶端
• 支持流程到流程和節點到節點的不錯，但沒有嚴格要求

開源解決方案w ^生病是首選，但不是必需的。

我已經看過eventbus（按照https://stackoverflow.com/a/1953453/796559的建議），但這似乎不起作用。

所以問題是，哪些技術符合上述？

Answer 1

的Tonny，

剛走來自一個非常相似，並且成功的項目，請讓我分享我的經驗與您節省時間和你的公司一些錢。首先，ESB在8年前提出時是一個非常好的主意。而且，他們解決了一個重要問題：您如何定義一個業務問題，以便那些討厭的編碼員能夠理解？我們的目標是開發一個系統，讓商業人士創建一個軟件解決方案，不需要很少討厭的開發人員交互，從而消耗更多花在管理獎金上的資金。

爲了回答這個問題，許多組織的好人提出了JBI，BPMN和其他一系列解決方案，讓業務人員對他們想要「數字化」的業務流程進行建模。但實際上，它們在非常關鍵的層面上都存在缺陷：它們解決的是業務問題，而不是整合問題。因此，除非由一些高價位的顧問完成，否則這些實施中的許多實施都是不成功的，即使這樣，您的前景也很粗糙。

與此同時，在非常90年代末一些很聰明的人出版了一本書，叫其確定用於解決常見的集成問題，超過60的設計模式「企業集成模式」。許多執行ESB的人意識到他們的問題不是商業模型。問題在於如何整合現有的應用程序。爲了幫助解決這個問題，Michael Strachan和一些非常聰明的人開始了Apache Software Foundation Project「Camel」。駱駝是企業集成模式的嚴格實施，除了大量的組件設計，允許像你和我這樣的人把東西鉤在一起。

所以，如果你認爲你的業務流程簡單地需要從一個應用程序發送到另一個數據到另一個，之間適當的數據轉換，那麼駱駝是你的答案。現在，如果您想將「路由」（您想發送數據的特定系列應用程序端點）從一組數據庫中的一組可配置規則中取出來？那麼，駱駝也可以做到這一點！有一個終點！總之，不要做傳統的ESB，它的老舊和破壞。絕對做駱駝的事情。

請讓我知道這是否有幫助。

Answer 2

你不是在找一個ESB嗎？ ServiceMix是：

靈活的，開放源碼的集成容器統一的功能和Apache ActiveMQ，Camel，CXF，ODE，Karaf的功能整合到一個強大的運行平臺，你可以用它來構建自己的集成解決方案。它提供了一個完全的企業級ESB，它完全由OSGi提供支持。

Answer 3

貌似你在說ESB在這裏。如果是這樣的話，那麼你可以看看wso2 ESB。它由apache synapse供電。它使用OSGi作爲模塊化框架，以便您可以根據需要添加/刪除功能。基於相同的OSGi核心平臺，來自wso2的整個product stack，如消息代理，業務流程服務器（ODE）等。

免責聲明：我爲wso2工作。

Answer 4

OSGi規範定義組件「事件管理」，這是一個輕量級發佈 - 訂閱事件子系統。 從RFC0157：

事件聯繫指定裝置的事件源事件發送到 事件偵聽器。事件源可以創建一個主題， 屬性和請求事件管理活動提供的事件事件已宣佈在特定事件主題和/或 屬性值的興趣 聽衆。事件源可以請求同步（以及無序）或異步（和有序）傳送。

比起你的要求，將比分如下：

• 同步和異步交付：檢查
• 點至點只：號發佈 - 訂閱
• 保證交付 - 優選經由文件的持久性：NO
• 嚴格messag E從同一客戶端排序（異步模式）：YES
• 支持進程到進程：如果（過程== OSGi服務） - >是
• 支持節點到節點：尚未。 分佈式OSGi的傢伙一直在努力，但我還沒有看到任何具體的東西 。

我喜歡駱駝的概念，但最近決定去（輕）事件管理員，因爲我的要求是有限的。麥克駱駝動機+1。我會研究它，然後在決定之前比較選項。

Answer 5

iPOJO Event Admin Handlers是訪問由@maasg提到的事件管理服務一個更好的使用的方式。