我是 OSGi 的新手,但它很有趣。osgi bundles和java应用程序之间可以交互吗?如果可能,怎么做?谢谢!
背景是我有一个很大的 Java SE 应用程序(作者是另一个程序员),它有很多依赖项。首先,我的目标是添加新功能,其次是更改架构。我将尝试使用 OSGi,但我不想编写两次代码,因此我现在想将新代码编写为捆绑包。但是使用旧应用程序中的这个新功能。
是的!是的!是的!这是开始利用 OSGi 并向基于服务的应用程序发展的完美方式。
使用 4.2 启动器 API 创建框架是微不足道的,甚至不知道您使用的是哪个框架实现。你会得到一个 Framework 对象,它实际上是一个 OSGi Bundle,可以为你提供一个 BundleContext。您可以使用它来安装捆绑软件。这一切都在规范中进行了描述,但您可以在 Felix 中找到很多具体和出色的示例:http: //felix.apache.org/site/apache-felix-framework-launching-and-embedding.html。从第一天起,Felix 就一直在明确推广嵌入应用程序。
这种方法的难点在于习惯模块化及其限制。为了有用,您必须在 OSGi 包和您的应用程序之间共享类;这需要使用 org.osgi.framework.systempackages.extra 属性从您的应用程序中显式导出这些共享包。此属性是您的应用程序的 Export-Package 标头。
由于 Java 中的类加载模型,无法从框架中的包中导入包。这意味着您的应用程序代码只能使用框架中的服务,这些服务的包位于应用程序类路径上。
这样做的结果是,新功能往往会转移到完全可见的捆绑包:导出的应用程序包以及任何捆绑包。但是,这可能正是您想要的。
所以要注意这个潜在的陷阱。嵌入,然后随着时间的推移将所有代码迁移到包中,这样您的应用程序就只是一个 OSGi 启动器。但是,请非常注意您在两个环境之间共享的包。
祝你好运,让我们知道这是怎么回事。
我将 OSGi 视为一种结构化技术。您可以使用它来定义应用程序的组件结构。因此,您的所有应用程序实际上都是 OSGi 捆绑包的集合。因此交互不是问题,只是应用程序的不同部分以正常方式交互。
[在评论澄清后编辑。]
您有一个基本决定:您的 OSGi 代码是在与原始代码相同的进程中执行还是在单独的进程中执行?
分离意味着可以根据需要自由构建新代码,利用 OSGi,但代价是进程间通信复杂性和性能开销。您很可能最终会对现有应用程序进行重大更改,以支持某种形式的远程处理。我不认为这是一个很好的方法,除非您的 OSGi 代码恰好是其他远程客户端可能会使用的某种可重用服务。
如果在同一个过程中,那么我会说你需要硬着头皮说这将是一个 OSGi 应用程序。获取现有应用程序并使其在 OSGi 中运行的工作量不必过多。
假设您将现有应用程序视为一个巨大的 OSGi 包?在初始化方面会有一些工作,但其余的会“正常工作”吗?如果您将此作为第一步,那么现有应用程序的真正重新架构和模块化将被推迟。然后,您只需公开新模块所需的接口,并在必要时使用新模块提供的服务。通过构建依赖关系,您立即获得了 OSGi 的好处。
使用 OSGi 构建的应用程序可以以与两个普通 (Java) 应用程序相同的方式进行交互。因此,通过加载/保存文件。或者,当其中一个被创建为 OSGi http 服务器时,只需通过 http 与该 (OSGi) 服务器进行通信。就像你以前那样想它,不包括 OSGi。