R-Osgi为我们提供了一种从远程OGSi容器调用服务的方法。网站：http://r-osgi.sourceforge.net。
我是 R-OSGi 的新手，现在我想将我的 OSGi 容器拆分为小容器，并通过 R-Osgi 相互交互，因为它太大了。但R-OSGi似乎只提供了一种注册服务的方式。我们知道，除了Service之外，2个bundle之间最流行的交互方式“exported-package”也被广泛使用。
那么，是否有人熟悉 R-OSGi 并知道如何从远程 OSGi 容器使用“导出的包”？
感谢您的任何回复。
R-Osgi provides us a way to call service from a remote OGSi container. WebSite: http://r-osgi.sourceforge.net.
I'm new to R-OSGi and now I want to split my OSGi container into small ones and interact each other by R-Osgi because it's too huge. But it seems R-OSGi only provides a way for Registered Service. We know that the most popular way to interaction between 2 bundles besides Service, "exported-package" is also widely used.
So, is there anyone familiar with R-OSGi and know how to use "exported-package" from remote OSGi container?
Thanks for any response.
发布评论
评论（1）
如果您考虑一下，尝试处理包的远程导入/导出是非常复杂、脆弱且容易出错的；您需要通过网络发送所有捆绑生命周期事件，并在导入系统中尊重它们（这需要缓存）。
此外，框架需要提前知道如何使用这些类定义（您无法实例化引用类加载器不可用的类的类）。远程包的类加载器可能依赖于另一个类加载器中的类，该链可能会在网络中循环，从而导致类加载需要很长时间。
换句话说；如果没有它们所依赖的类定义，您的本地捆绑包将永远无法解析，并且考虑到网络/硬件上可能有数千个潜在的远程导出器，SLA 非常差，考虑到 分布式计算的谬误。
如果我们尝试执行远程包，框架将需要从所有可用的远程节点导入所有导出的包，然后仅选择一个来导入每个包导出（这将是任意的，如果选择节点出现故障，则整个导入远程打包过程将不得不再次触发）。
您需要做的是将 api/接口与实现分离，然后将 api 包分发到需要它的所有节点，然后使用 dOSGi 导入服务。
如果这不清楚或胡言乱语，我们深表歉意，但它应该解释为什么远程导出包根本不切实际。
附注：我不确定 r-osgi 是否正在积极维护或是否与最新的 远程服务管理规范，查看对 SVN 主干的最后一次提交是 14/02/2011。 此处列出了一些替代的 dOSGi 实现（但避免使用 CXF）。
编辑：在部署方面，可以通过 OBR 来分发捆绑包（和配置）（有许多 公共的 和几个实现 Felix/Eclipse)，或者可以使用 < 重新占用 Maven 存储库a href="http://team.ops4j.org/wiki/display/paxurl/Mvn+Protocol" rel="nofollow noreferrer">pax url 处理程序。
If you think about it, attempting to handle the remote importing/exporting of packages is very complex, fragile and prone to error; you'd need to send all bundle lifecycle events over the wire, and honour them in the importing system (which would require caching).
Additionally the framework would need to know ahead of time to use these class definitions (you cannot instantiate a class that references classes that aren't available to your classloader). A remote bundle's classloader may depend on classes from another classloader, this chain could go round and round a network making classloading take ages.
Put another way; your local bundles will never resolve without the class definitions they depend on, and considering there could be thousands+ of potential remote exporters on a network/hardware with very poor SLA, this wouldn't scale well or be very robust considering the fallacies of distributed computing.
If we tried to do remote packages, the framework would need to import all exported packages from all available remote nodes and then select just one to import each bundle export from (this would be arbitrary and if the select node goes down, the whole import remote package process would have to triggered again).
What you need to do is separate you api/interfaces from your implementation, you then distribute the api bundle to all nodes that need it and then use dOSGi to import services.
Apologies if this unclear or waffly but it should explain why it's simply not practical to have remote exported packages.
On a side note; I'm not sure if r-osgi is being actively maintained or is up-to-date with the latest Remote Services Admin spec, from looking at the last commit to SVN trunk was 14/02/2011. There's some alternative dOSGi implementations listed here (but avoid CXF).
EDIT: In terms of deployment, distributing your bundles (and configuration) can be done from an OBR (there are number of public ones and several implementations Felix/Eclipse), or a maven repository can be reappropriated with pax url handler.