OSGi bundle部署策略最佳實踐apache Camel

Question

出於集成目的，我們使用 Apache Camel、Karaf 和 OSGi，因此我們正在創建 OSGi 包。 但是，在構建捆綁包時存在哪些最佳實踐？

集成相當簡單，具有傳入的文檔類型（通過某種協議，如 HTTPS、SFTP、JMS），轉換為另一種文檔類型，並再次通過某種協議進行傳輸。 基本設置始終相同並遵循 VETO 模式：驗證、豐富、轉換、操作。 提到的協議/文檔類型的每個唯一組合都定義了一個集成。

我們通過 JMS 將連接（包括驗證）與其他步驟分離。 當我們查看 ETO 步驟時，我們將它們分成各自的 Java 類及其對應的 XSLT。 然而，OSGi 框架的附加價值是什么？我們應該如何划分 OSGi 包之間的集成？

考慮執行更改、維護和部署？ 考慮 2 打集成點（唯一端點），其中運行 50 個不同的集成，換句話說，兩個不同的 docType 之間有 50 個唯一的轉換。 我們可以將所有 50 個集成的所有代碼和 XSLT 放在 1 個捆綁包中（另一個捆綁包處理連接性），或者 50 個捆綁包，每個捆綁包有 1 個集成。 在部署策略方面，有哪些最佳實踐（如果有）？ 要考慮什么？

Answer 1

您可以查看 Apache Karaf github 存儲庫中的示例，以了解 OSGi 應用程序的捆綁包是如何構建的。 Christian Schneider 還談到了 OSGi 最佳實踐，並且在他的存儲庫中也有一些示例。

通常，您希望盡可能少地使用最小數量的依賴關系來保持您的捆綁包小。 因此，我建議每個捆綁包只有一個集成。 如果您決定在多個 Karaf 實例之間拆分集成，這使得安裝集成及其依賴項更容易，並提供一些靈活性。

對於連接的東西，你最好的選擇通常是使用/創建/發布 OSGi 服務。 例如，使用 pax-jdbc-config，您可以使用配置文件創建新的 DataSource 類型服務，然后您可以使用這些服務從集成包連接到不同的數據庫。

使用聲明式服務發布自己的自定義服務非常容易，並且可以輕松地用於共享與內部系統、blob 存儲、數據訪問對象等的連接，同時通過將實際實現隱藏在接口中來保持松散耦合。 對於服務，推薦的方法是使用單獨的 API 和實現捆綁包，以便使用該服務的捆綁包只需將依賴項添加到 API 捆綁包。

對於部署，您可以創建自己的自定義 Karaf 發行版並預裝捆綁包，使用 Karaf 功能部署捆綁包或使用熱部署文件夾。 對於后兩個，您可能希望將 Karaf 配置為使用外部文件夾進行捆綁配置和熱部署，因為更新 Karaf 的過程基本上是將其替換為新安裝。