OSGi 如何管理在不同 JVM 中运行的组件的交互？答案

【问题标题】：How does OSGi manage interaction of components running in separate JVMs?OSGi 如何管理在不同 JVM 中运行的组件的交互？
【发布时间】：2010-09-27 09:43:25
【问题描述】：

我一直试图在不阅读整个规范的情况下更多地了解 OSGi 的更广泛的图景。与许多事情一样，OSGi 的实际含义可能是 introduction 可能是由从事它工作了十年的人编写的，并且可能不适合将自己置于对它一无所知的人的心态中： -)

看Felix的例子DictionaryService，我真的不明白发生了什么。 OSGi 是 JVM 的一个独特实例，您可以在其中加载捆绑包，然后可以找到彼此？

显然不是只是因为 StackOverflow 上的其他答案明确表明 OSGi 可以解决包含部署在不同 JVM 中的模块的分布式系统的依赖性问题（加上常见问题解答一直在谈论网络）。

在后一种情况下，在一个 JVM 中运行的组件如何与单独 JVM 中的另一个组件交互？这两个组件能否像在同一个 JVM 中运行一样“使用”彼此（即通过本地方法调用），以及 OSGi 如何管理跨网络的数据编组（例如，您是否必须使用 Serializable） ?

或者组件作者是否必须使用其他不同的机制（由 OSGi 提供或自己编写）在远程组件之间进行通信？

非常感谢任何帮助！

【问题讨论】：

标签： osgi

【解决方案1】：

AFAIK，bundle 在同一个 JVM 中运行，但不是使用同一个类加载器加载的（这就是为什么你可以同时使用同一个 bundle 的两个不同版本的原因）。

要与另一个 JVM 中的组件交互，您必须使用网络协议，例如 rmi。

【讨论】：

【解决方案2】：

@Patriarch24

this question 接受的答案似乎另有说明（除非我误读了它）。另外，摘自常见问题解答：

OSGi 服务平台提供了在各种网络的设备上动态更改组合的功能，无需重新启动

（强调我自己的）。尽管在同一个常见问题解答中将 OSGi 描述为 in-VM。

为什么我对此感到如此困惑？为什么一个关于十年前技术的基本问题不清楚？

【讨论】：

我会说这是一个非常令人困惑甚至具有误导性的答案。 OSGi 的核心不处理分布式系统，只是在单个 VM 中保持模块分离和可重新加载。

【解决方案3】：

据我所知，OSGi 并没有开箱即用地解决这个问题。有 OSGi 捆绑包，例如 Remote OSGi，允许程序员通过网络分发服务。

【讨论】：

【解决方案4】：

还没有，我认为它正在为下一个版本开发。

但是一些公司已经实现了分布式osgi。我知道的一个是 Paremus 的 Infiniflow (http://www.paremus.com/products/products.html)。在linkedin，他们也在努力解决这个问题。更多信息在这里：Building Linkedin next gen architecture with osgi 和这里：Matt raible: building linkedin next gen architecture

以下是 OSGI 4.2 更改的摘要：Some thoughts on the OSGi R4.2 draft，RFC-119 中有一节处理分布式 OSGi。

【讨论】：

【解决方案5】：

是的，OSGi 仅处理在同一 VM 上运行的捆绑包和服务。然而，应该注意的是，OSGi 的一个显着特点是它促进了在同一个 JVM 上运行多个应用程序（以受控方式并共享公共模块）。

当涉及到访问客户端 JVM 之外的服务时，目前还没有标准化的解决方案。 Paremus Infiniflow 和衍生的开源项目 Newton 使用 SCA 方法。即将发布的 4.2 版 OSGi 规范将解决问题的一方面，即如何使用通用分发软件，以便将远程服务带入客户端的 JVM。

正如有人提到 R-OSGi，这种方法还处理了问题的另一面，即如何管理分布式 OSGi 框架之间的依赖关系。由于 R-OSGi 不是通用分发软件，而是明确处理 OSGi 包的生命周期问题和依赖管理。

【讨论】：

>> OSGi 只处理在同一个 VM 上运行的捆绑包和服务
如果OSGi only deals with bundles and services running on the same VM，可扩展性怎么样？顺便说一句，分布式 OSGi 目前进展如何？

【解决方案6】：

OSGI 最初的问题更多是与代码的分配（然后是 bundle 的配置）有关，而不是与执行的分配有关。

关注分布式组件的人更倾向于关注 SCA

【讨论】：

【解决方案7】：

OSGi 联盟正在制定分布式 OSGi 标准：

http://www.osgi.org/download/osgi-4.2-early-draft2.pdf

这个新标准甚至有一个早期的 Apache 实现：

http://cxf.apache.org/distributed-osgi.html

【讨论】：

【解决方案8】：

“介绍”链接并不是真正的介绍，它是一个常见问题解答条目。欲了解更多信息，请参阅http://www.osgi.org/About/WhatIsOSGi 我认为不难找到。

无论如何，OSGi 是一个虚拟机内 SOA。也就是说，OSGi 框架是关于虚拟机内部发生的事情，它提供了一个框架来构建虚拟机内部的应用程序，因此您可以在很大程度上从组件构建它。所以核心与分发无关，它完全不知道谁实现了服务，它只是为模块提供了一种机制以松散耦合的方式相互满足。

也就是说，µService 模型具体化了模块之间的连接，事实证明，您可以在为其他组件提供分发的框架之上构建支持。在上一个版本中，我们指定了一些机制，使其在核心中标准化并提供可以管理分布式拓扑的特殊服务 Remote Service Admin。

【讨论】：

【解决方案9】：

如果您正在寻找以 OSGi 为中心的分布式云运行时 - 那么 Paremus Service Fabric (https://docs.paremus.com/display/SF16/Introduction) 可以提供这些功能。

一个或多个系统，每个系统都由多个 OSGi 程序集（蓝图或声明式服务）组成，可以跨 OSGi 运行时框架（Knopflerfish、Felix 或 Equinox）动态部署和维护。

提供了一个轻量级的 RSA 远程框架，默认情况下使用 DDS（一种非常好的中间件消息传递技术）提供服务发现 - （认为可以使用 ZooKeeper 和其他方法）。当前支持的远程处理协议包括 RMI 和 Avro。

问候

理查德

【讨论】：