是否存在OSGi术语,框架及其关系的概述？

Question

我正试图在广阔的企业OSGi编程生态系统中感到舒服,但我发现很难概述这个技术堆栈是如何组合在一起的,哪些技术相互依赖,哪些技术解决了什么任务,以及如何它们都符合我迄今为止所理解的有限术语.

例如:Apache Felix,Equinox,Karaf,Jira OSGi,Spring DM,Aries Blueprint,Gemini Blueprint,iPOJO,Camel等之间的关系是什么......

我知道Equinox基于Felix,而Blueprint变体和iPOJO在某种程度上与组件管理有关,但是声明服务呢？DS是Blueprint的替代品,还是Blueprint是Declarative Services的实现？

总的来说,我很困惑,我真的需要简单概述一般OSGi技术的相关性.

有谁知道OSGi生态系统存在这样的概述 - 也许是图形化的？

最好的祝福.

Answer 1

我不知道图形表示.我可以分解你在帖子中提到的一些具体事项:

1. "OSGi框架"是核心OSGi规范的实现.它必须实现捆绑包的概念,安装和解决捆绑包,生命周期,服务等.
2. Apache Felix是一个OSGi框架实现.
3. Equinox也是一个OSGi框架实现.它不是"基于"Apache Felix,但它确实从中借用了少量代码.Equinox是Eclipse等中使用的OSGi的实现.
4. Karaf本质上是一个应用服务器产品.它使用Felix作为其核心OSGi Framework实现,然后在顶部添加了许多额外功能.
5. Jira OSGi:不知道.我相信Jira是在OSGi内部实现的,但我不知道任何细节.
6. Spring DM是一个过时/死亡的项目.这是一种使用OSGi将Spring bean图分割成模块化应用程序的方法.
7. 蓝图是OSGi联盟发布的规范.它是Compendium规范之一,即Core中不需要的附加组件.Blueprint的灵感来自于Spring-DM,它标准化了在捆绑内部和捆绑之间将bean连接在一起的想法.
8. Gemini Blueprint是Blueprint规范的一个实现.Gemini从Spring-DM代码开始,并将其演化为符合(当时)新规范.
9. Aries Blueprint也是Blueprint的一个实现.它是"洁净室",即从头开始针对规范实现,而不是从较旧的Spring代码演变而来.
10. 声明性服务是Compendium的OSGi规范.它是一种替代方法,用于定义组件并使用跨服务器的服务将它们连接在一起.许多经验丰富的OSGi开发人员 - 包括我 - 认为声明式服务比FAR优于Blueprint.如果你愿意,我可以详细说明原因.
11. iPOJO是另一种定义组件并将它们连接在一起的不同方式.它不符合任何OSGi规范.
12. Camel是一个集成库,主要用于消息传递应用程序.它与OSGi没什么关系,只不过它可以在OSGi下运行.

我希望这有帮助.