【问题标题】：Best Practice of OSGi bundle deployment strategy with apache CamelOSGi bundle部署策略与apache Camel的最佳实践
【发布时间】：2022-08-17 23:39:08
【问题描述】：
出于集成目的，我们将 Apache Camel、Karaf 与 OSGi 一起使用，因此我们正在创建 OSGi 包。但是，在构建捆绑包时存在哪些最佳实践？
集成相当简单，具有传入文档类型（通过 HTTPS、SFTP、JMS 等协议），转换为另一种文档类型，并再次通过某种协议进行传输。基本设置始终相同并遵循 VETO 模式：验证、丰富、转换、操作。提到的协议/文档类型的每个唯一组合都定义了一个集成。
我们通过 JMS 将连接（包括验证）与其他步骤分离。当我们查看 ETO 步骤时，我们将它们分成它们自己的 Java 类和它们相应的 XSLT。然而，OSGi 框架的附加价值是什么？我们应该如何划分 OSGi 包之间的集成？
考虑执行更改、维护和部署？考虑 2 打集成点（唯一端点），其中运行 50 个不同的集成，换句话说，两个不同的 docType 之间有 50 个唯一的转换。我们可以将所有 50 个集成的所有代码和 XSLT 放在 1 个捆绑包中（另一个捆绑包处理连接性），或者 50 个捆绑包，每个捆绑包有 1 个集成。在部署策略方面，有哪些最佳实践（如果有）？要考虑什么？
标签：
apache-camel
osgi
apache-karaf
osgi-bundle
【解决方案1】：
您可以从 Apache Karaf github 存储库中查看 examples，以了解 OSGi 应用程序的捆绑包是如何在那里构建的。 Christian Schneider 还完成了talk 关于 OSGi 最佳实践的工作，并且在他的repository 中也有一些示例。
通常，您希望尽可能少地使用最小数量的依赖关系来保持您的捆绑包小。因此，我建议每个捆绑包只有一个集成。如果您决定在多个 Karaf 实例之间拆分集成，这使得安装集成及其依赖项更容易，并提供一些灵活性。
对于连接的东西，你最好的选择通常是使用/创建/发布 OSGi 服务。例如，使用 pax-jdbc-config，您可以使用配置文件创建新的 DataSource 类型服务，然后您可以使用这些服务从集成包连接到不同的数据库。
发布自己的自定义服务is pretty easy with declarative services，并且可以轻松地用于共享与内部系统、blob 存储、数据访问对象等的连接，同时通过将实际实现隐藏在接口中来保持松散耦合。对于服务，推荐的方法是拥有单独的 API 和实现包，以便使用该服务的包只需将依赖项添加到 API 包。
对于部署，您可以创建自己的自定义 Karaf 发行版，其中预先安装了捆绑包，使用 Karaf 功能部署捆绑包或使用热部署文件夹。对于后两个，您可能希望将 Karaf 配置为使用外部文件夹进行捆绑配置和热部署，因为更新 Karaf 的过程基本上是将其替换为新安装。