OSGi 如何管理在单独的 JVM 中运行的组件的交互？
我一直试图在不通读整个规范的情况下更多地了解 OSGi 的更广泛的情况。 与许多事情一样，介绍 OSGi 的实际内容可能是由以下人员编写的：我已经为此工作了十年，也许不适合将自己置于对此一无所知的人的思维方式中:-)
看看 Felix 的示例 DictionaryService，我不太明白到底是怎么回事。 OSGi 是一个独特的 JVM 实例吗？您可以将捆绑包加载到其中，然后可以互相找到对方？
显然，这不只是，因为 StackOverflow 上的其他答案明确表示 OSGi 可以解决包含部署在不同 JVM 中的模块的分布式系统的依赖问题（加上常见问题解答一直在讨论）关于网络）。
在后一种情况下，在一个 JVM 中运行的组件如何与单独 JVM 中的另一个组件交互？ 这两个组件是否可以像在同一个 JVM 中运行一样互相“使用”（即通过本地方法调用），以及 OSGi 如何管理跨网络的数据编组（是否必须使用 Serialized）代码> 例如）？
或者组件作者是否必须使用其他一些不同的机制（由 OSGi 提供或自己编写）来进行远程组件之间的通信？
非常感谢任何帮助！
I have been trying to understand a bit more about the wider picture of OSGi without reading thru the entire specification. As with so many things, the introduction to what OSGi actually is was probably written by someone who had been working on it for a decade and perhaps wasn't best placed to put themselves in the mindset of someone who knows nothing about it :-)
Looking at Felix's example DictionaryService, I don't really understand what is going on. Is OSGi a distinct instance of a JVM into which you load bundles which can then find each other?
Obviously it is not just this because other answers on StackOverflow are explicit that OSGi can solve the dependency problem of a distributed system containing modules deployed within distinct JVMs (plus the FAQ keeps talking about networks).
In this latter case, how does a component running in one JVM interact with another component in a separate JVM? Can the two components "use" each other as if they were running within the same JVM (i.e. via local method calls), and how does OSGi manage the marshalling of data across a network (do you have to use Serializable for example)?
Or does the component author have to use some other distinct mechanism (either provided by OSGi or written themselves) for communication between remote components?
Any help much appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
是的，OSGi 仅处理在同一虚拟机上运行的捆绑包和服务。 然而，应该注意的是，OSGi 的一项独特功能是它有助于在同一个 JVM 上运行多个应用程序（以受控方式并共享公共模块）。
当涉及到访问客户端 JVM 之外的服务时，目前还没有标准化的解决方案。 Paremus Infiniflow 和衍生的开源项目 Newton 使用 SCA 方法。 即将发布的 OSGi 规范 4.2 版本将解决这一问题，即如何使用通用分发软件将远程服务引入客户端的 JVM。
正如有人提到的 R-OSGi，这种方法还解决了问题的另一面，即如何管理分布式 OSGi 框架之间的依赖关系。 由于 R-OSGi 不是通用分发软件，而是明确处理 OSGi 包的生命周期问题和依赖关系管理。
Yes, OSGi only deals with bundles and services running on the same VM. However, one should note that it is a distinct feature of OSGi that it facilitates running multiple applications (in a controlled way and sharing common modules) on the same JVM at all.
When it comes to accessing services outside the clients JVM, there is currently no standardized solution. Paremus Infiniflow and the derived open-source project Newton use an SCA approach. The upcoming 4.2 release of the OSGi specs will address one side of the problem, namely how to use generic distribution software in such a way that it can bring remote services into the client's JVM.
As somebody mentioned R-OSGi, this approach also deals with the other side of the problem, being how to manage dependencies between distributed OSGi frameworks. Since R-OSGi is not generic distribution software but explicitly deals with the lifecycle issues and dependency management of OSGi bundles.
据我所知，OSGi 并没有立即解决这个问题。 有一些 OSGi 捆绑包，例如 Remote OSGi，它允许程序员通过网络分发服务。
As far as I know, OSGi does not solve this problem out of the box. There are OSGi-bundles, for example Remote OSGi, which allow the programmer to distribute services across a network.
还没有，我认为它正在为下一个版本而努力。
但有些公司已经实现了分布式osgi。 我知道的一个是 Paremus 的 Infiniflow (http://www.paremus.com/products /products.html）。 linkedin 也正在研究这个问题。 更多信息请参见：使用以下内容构建 Linkedin 下一代架构osgi 和此处：Matt raible：构建 linkedin 下一代架构
以下是OSGI 4.2 的更改： 对 OSGi R4.2 草案的一些想法，RFC-119 中有一节涉及分布式 OSGi。
Not yet, i think it's being worked on for the next release.
But some companies have already implemented distributed osgi. One i'm aware of is Paremus' Infiniflow (http://www.paremus.com/products/products.html). At linkedin they are also working on this. More info here: Building Linkedin next gen architecture with osgi and here: Matt raible: building linkedin next gen architecture
Here's a summary of the changes for OSGI 4.2: Some thoughts on the OSGi R4.2 draft, There's a section on RFC-119 dealing with distributed OSGi.
AFAIK，bundles 在同一个 JVM 中运行，但不是使用相同的类加载器加载（这就是为什么您可以同时使用同一bundle的两个不同版本）。
要与另一个 JVM 中的组件交互，必须使用网络协议，例如 rmi。
AFAIK, bundles are running in the same JVM, but are not loaded using the same class loader (that why you can use two different versions of the same bundle at the same time).
To interact with components in another JVM, you must use a network protocol such as rmi.
OSGi 联盟正在制定分布式 OSGi 标准：
http:// www.osgi.org/download/osgi-4.2-early-draft2.pdf
甚至还有这个新标准的早期 Apache 实现：
http://cxf.apache.org/distributed-osgi.html
The OSGi alliance is working on a standard for distributed OSGi:
http://www.osgi.org/download/osgi-4.2-early-draft2.pdf
There even is an early Apache implementation of this new standard:
http://cxf.apache.org/distributed-osgi.html
@Patriarch24
这个问题接受的答案似乎表明不然（除非我误读了）。 另外，摘自常见问题解答：
（重点是我自己的）。 尽管在同一个常见问题解答中，它将 OSGi 描述为in-VM。
为什么我对此如此困惑？ 为什么这样一个关于十年前技术的基本问题还不清楚？
@Patriarch24
The accepted answer to this question would seem to indicate otherwise (unless I'm misreading it). Also, taken from the FAQ:
(Emphasis my own). Although in the same FAQ it describes OSGi as in-VM.
Why am I so confused about this? Why is such a basic question about a decade-old technology not clear?
OSGI 最初的问题更多地与代码的分布（然后是捆绑包的配置）相关，而不是与执行的分布相关。
人们关注分布式组件更倾向于 SCA
The original problem of OSGI was more related to distribution of code (and then configuration of bundle) than to distribution of execution.
People looking at distributed components are rather looking towards SCA
“简介”链接并不是真正的简介，它是一个常见问题解答条目。 有关详细信息，请参阅 http://www.osgi.org/About/WhatIsOSGi 不难发现我会想。
无论如何，OSGi 是一个虚拟机内 SOA。 也就是说，OSGi 框架是关于 VM 内部发生的事情，它提供了一个用于在 VM 内部构建应用程序的框架，以便您可以在很大程度上从组件构建它。 因此，核心与分发无关，它完全不知道谁实现了服务，它只是提供了一种使模块以松散耦合的方式相互满足的机制。
也就是说，μService 模型具体化了模块之间的连接，事实证明，您可以在为其他组件提供分发的框架之上构建支持。 在最新版本中，我们指定了一些机制，使其在核心中标准化，并提供可以管理分布式拓扑的特殊服务远程服务管理。
The "introduction" link is not really an intro, it is a FAQ entry. For more information, see http://www.osgi.org/About/WhatIsOSGi Not hard to find I would think.
Anyway, OSGi is an in-VM SOA. That is, the OSGi Framework is about what happens inside the VM, it provides a framework for structuring your application inside the VM so you can built it too a large extent from components. So the core has nothing to do with distribution, it is completely oblivious of who implements the services, it just provides a mechanism for modules to meet each other in a loosely coupled way.
That said, the µService model reifies the joints between the modules and it turns out that you can build support on top of the framework that provides distribution to the other components. In the last releases we specified some mechanisms that make this standardized in the core and provide a special service Remote Service Admin that can manage a distributed topology.
如果您正在寻找以 OSGi 为中心的分布式云运行时 - 那么 Paremus Service Fabric ( https://docs .paremus.com/display/SF16/Introduction）提供了这些功能。
一个或多个系统，每个系统由多个 OSGi 程序集（蓝图或声明性服务）组成，可以在一群 OSGi 运行时框架（Knopflerfish、Felix 或 Equinox）中进行动态部署和维护。
提供了一个轻量级 RSA 远程框架，默认情况下使用 DDS（一种非常好的中间件消息传递技术）提供服务发现 - （认为可以使用 ZooKeeper 和其他方法）。 目前支持的远程协议包括 RMI 和 Avro。
问候
理查德
If you are looking for a distributed OSGi centric Cloud runtime - then the Paremus Service Fabric ( https://docs.paremus.com/display/SF16/Introduction ) provides these capabilities.
One or more Systems each consisting of a number of OSGi assemblies (Blueprint or Declarative Services) can be dynamically deployed and maintained across a population of OSGi runtime Frameworks (Knopflerfish, Felix or Equinox).
A light weight RSA remote framework is provided which provides Service discovery by default using DDS (a seriously good middleware messaging technology) - (thought ZooKeeper and other approach can be used). Currently supported re-moting protocols include RMI and Avro.
Regards
Richard