出于集成的目的，我们使用Apache Camel，Karaf和OSGi，所以我们创建了OSGi包。
集成非常简单，传入文档类型（通过HTTPS、SFTP、JMS等协议），转换为另一种文档类型，再通过某种协议传输。基本设置始终相同，并遵循VETO模式：验证、丰富、转换、操作。上述协议/docType的每个唯一组合定义一个集成。
我们通过JMS将连接性（包括验证）与其他步骤分离。当我们查看ETO步骤时，我们将其分为各自的Java类和对应的XSLT。然而，OSGi框架的附加值是什么？我们应该如何划分OSGi包之间的集成？
是否考虑执行更改、维护和部署？考虑2打集成点（唯一端点）之间运行50个不同的集成，换句话说，两个不同docType之间有50个唯一的转换。我们可以将所有50个集成的所有代码和XSLT放在一个包中（另一个捆绑包处理连接），或者50个捆绑包，每个捆绑包1个集成。在部署策略方面，最佳实践是什么（如果有）？需要考虑哪些因素？
1条答案
按热度按时间s5a0g9ez1#
您可以从Apache Karaf github仓库中查看examples，了解OSGi应用程序包是如何在那里构建的。Christian Schneider也做过关于OSGi最佳实践的talk，并且在他的repository中也有一些例子。
一般来说，你希望你的软件包尽可能的小，依赖性尽可能的少。因此，我建议每个软件包只有一个集成。这使得安装集成和它们的依赖性更容易，如果你决定在多个Karaf示例之间分割集成，也提供了一些灵活性。
对于连接性的东西，你最好的选择通常是使用/create/publish OSGi服务。例如，通过pax-jdbc-config，你可以使用配置文件来创建新的DataSource类型的服务，然后你可以使用这些服务从你的集成包中连接到不同的数据库。
发布自己的自定义服务is pretty easy with declarative services，并可轻松用于共享到内部系统、blob存储、数据访问对象等的连接，同时通过使用接口隐藏实际实现来保持松散耦合。对于服务，建议的方法是使用单独的API和实现捆绑包，以便使用服务的捆绑包可以仅向API捆绑包添加依赖项。
对于部署，您可以创建自己的自定义Karaf分发包，并预先安装捆绑包，使用Karaf功能部署捆绑包或使用热部署文件夹。对于后两种情况，您可能希望配置Karaf使用外部文件夹进行捆绑包配置和热部署，因为更新Karaf的过程基本上是用新安装替换它。
[编辑]
如果我们有50多个转换，并将每个转换放在自己的包中，那么我将有50多个包需要管理。这只是一个示例。其他客户将有自己的示例，同样运行50多个、100多个包
我会说，这里的关键是尝试简化和识别捆绑中的重复。通常这些可以转换成更通用和可重用的东西。
有了OSGi，你可以使用声明性服务和OSGiDefaultCamelContext来示例化每个配置文件的Camel集成示例，如果你有多个集成，它们的工作方式几乎相同，但只有微小的变化，这会很有用。不知道camel是否支持蓝图。
由于有许多包，有效地使用Karaf features或OSGi features (R8)对于处理增加的复杂性是至关重要的。特性使得安装和更新由多个包、配置文件和其他特性组成的OSGi应用程序变得相当容易。
对于单个OSGi包来说，到底有多大才算太大，还真的没有什么规则。将密切相关的东西组合到单个包中会很有意义，并有助于避免将东西过多地分裂。