我们正在开发基于OSGi的基础架构，用于处理基于流的数据流。具体的处理任务由各个OSGi组件执行。我们现在需要在不同的机器上分发这些组件的可能性，这意味着我们需要OSGi组件/容器之间的某种通信机制。
在我的研究期间，我遇到了不同的潜在解决方案：R-OSGi，用于分布式OSGi的Apache CXF，Eclipse通信框架。
ECF似乎特别有趣，因为它支持不同的传输格式，并为服务发现等内容提供支持。
我的核心问题：
答案 0 :(得分：2)
第一个问题 - 是否有与Felix建立ECF的详细演练 - 我不知道答案，尽管可能会使用搜索引擎来找出这些术语的组合。
问题是ECF使用Equinox基础架构，并且有时无意中依赖于通过传递依赖性而非公开的包（特别是使用Equinox进行非公共调试的Runtime API）。反过来，这意味着ECF依赖于许多其他组件可用，而这个集合通常在Felix运行时没有很好地定义。
您错过了Paremus的Service Fabric，这是一个商业OSGi云解决方案。我不确定你是否专注于开源或不关注;但如果您要包含商业许可证，那么他们就拥有了非常强大的远程服务架构。
最后，Apache CXF超过ECF问题 - 如果您使用的是Felix，我认为使用Apache CXF可能比使用ECF更容易。这主要是由于依赖集和使其工作，结合ECF可能未在Felix上进行测试的事实，因此可能假设Equinox运行时的特定方面（例如，包括运行时的父类加载器委托）引导类路径上的东西）。这不是ECF本身的错误，而是Eclipse生态系统如何运作的人工制品。
如果您想与非OSGi运行时进行通信，那么Apache CXF的优势在于它们可以生成WDSL以与其他语言进行交互。我相信你可以在ECF做同样的工作。 CXF解决方案可能比相应的ECF解决方案（WSDL始终如此）更冗长，但如果您没有使用大量请求，则不太可能产生显着差异。