Java 什么'；OSGI捆绑包和组件之间的区别是什么？

从osgi开始，我想知道捆绑包和组件在概念上有什么不同。以及何时使用哪一种。欢迎任何指点

编辑：

组件和捆绑包提供不同的接口，因此它们可能不可互换

在OSGi术语中，“组件”类似于运行时服务。每个组件都有一个实现类，可以选择实现一个公共接口，有效地提供这个“服务”。OSGi的这一方面有时类似于服务注册模式
根据定义，OSGi中的组件是由捆绑包提供的。捆绑包可以包含/提供多个组件。虽然捆绑包本身可能不提供服务，但组件/声明性服务用于使OSGi更加面向服务。您没有义务使用组件/服务。
A是：
• 系统中的积极参与者
• 了解并适应其环境
  • 环境=由其他组件提供的服务
  • 环境=资源、设备
• 可以向其他组件提供服务，并使用其他组件提供的服务
• 有生命周期
简言之：
• 组件提供服务
• 捆绑包管理生命周期
一个bundle只能有一个activator（需要一个

BundleContext

），并且可以有任意数量的活动组件。
这意味着您可能最终试图将一个activator和几个松散相关的关注点整合到一个类中。
这就是为什么通过“服务组件运行时”更容易管理的原因，它是实现新的和改进的OSGi R4.2 DS-声明性服务-规范的“扩展包”。
自OSGi 4.2以来尤其如此，因为现在将DS组件编写为POJO要容易得多：不再需要使用

activate

和

deactivate

方法来获取

ComponentContext

参数。另见

---

注:
它可以帮助在OSGi的上下文中替换这些术语，并查看“我们是如何做到这一点的”（）
以下是一些相关摘录，其中“模块”最终成为OSGi捆绑包（管理声明服务的组件）：
模块分离 我们的第一个要求是清晰地分离模块，这样一个模块中的类就不会不受控制地看到和隐藏其他模块中的类
在传统Java中，所谓的“类路径”是一个庞大的类列表，如果多个类恰好具有相同的完全限定名，那么将始终找到第一个类，而忽略第二个类和所有其他类
防止类不受控制的可见性和模糊的方法是为每个模块创建一个类加载器。类加载器只能直接加载它知道的类，在我们的系统中，这些类是单个模块的内容
模块访问级别 如果我们停在这里，那么模块将完全隔离，无法相互通信。为了使系统实用，我们需要重新添加查看其他模块中的类的功能，但我们会谨慎且有限制地执行此操作。
此时，我们输入另一个需求：模块希望能够隐藏一些实现细节。
我们希望有一个“模块”访问级别，但现在的问题是javac编译器不知道模块边界在哪里
我们在模块系统中选择的解决方案是允许模块仅“导出”部分内容。如果某个模块的某个部分未导出，则其他模块无法看到它
在导入时，我们应该导入我们实际需要使用的东西，而不管它来自哪里，并且忽略所有与它一起打包的东西
进出口粒度 OSGi选择软件包。
一个Java包的内容是为了有点连贯，但是将包列为导入和导出并不太繁重，并且将一些包放在一个模块中而将其他包放在另一个模块中也不会破坏任何东西。
应该是模块内部的代码可以放在一个或多个非导出包中
封装布线 现在我们有了一个模块如何隔离自己然后重新连接的模型，我们可以想象构建一个框架来构造这些模块的具体运行时实例。它将负责安装模块和构造类加载器，以了解各自模块的内容
然后，它将查看新安装模块的导入，并试图找到匹配的导出
一个意想不到的好处是，我们可以动态安装、更新和卸载模块。安装新模块对已解决的模块没有影响，尽管它可能会使一些以前无法解决的模块得以解决。在卸载或更新时，框架确切地知道哪些模块受到影响，并在必要时更改其状态
版本 我们的模块系统看起来不错，但我们还无法处理随着时间的推移不可避免地在模块中发生的变化。我们需要支持不同的版本
我们如何做到这一点？首先，导出器可以简单地声明一些关于其导出的包的有用信息：“这是API的1.0.0版”。进口商现在只能导入与预期版本兼容、已编译/测试并拒绝接受的版本
打包模块和元数据 我们的模块系统需要一种方法来将模块的内容以及描述导入和导出的元数据打包到可部署单元中
所以