java - OSGI 包和组件之间有什么区别？

Question

开始使用 osgi，我想知道包和组件之间的概念差异是什么。以及何时使用其中的哪一个。欢迎任何指点。

编辑:

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

• ComponentContext

• BundleContext

Answer 1

A component是:

• 系统的积极参与者
• 了解并适应环境
  • 环境 = 其他组件提供的服务
  • 环境 = 资源、设备……
• 可以向其他组件提供服务并使用来自其他组件的服务
• 有生命周期

简而言之:

• 组件提供服务
• 捆绑管理生命周期

一个 bundle 只能有一个激活器(需要 BundleContext)，并且可以有任意数量的激活组件。
这意味着您最终可能会尝试将几个松散相关的问题放入一个激活器中，放入一个类中。
这就是为什么它可能更容易管理 those components by Declarative Services , 通过 the SCR (“服务组件运行时”是一个“扩展包”，实现了新的和改进的 OSGi R4.2 DS - 声明式服务 - 规范)。
自 OSGi 4.2 以来尤其如此，因为现在将 DS 组件编写为 POJO 变得更加容易:activate 和 deactivate 方法不再需要获取 ComponentContext 参数。另见 Lazy Declarative Service .

---

注意:

它可以帮助在 OSGi 的上下文中替换这些术语并查看“我们如何到达那里”(excellent blog post by Neil Bartlett)

这里是一些相关的摘录，其中“模块”最终成为 OSGi Bundle(管理声明服务的组件):

模块分离

Our first requirement is to cleanly separate modules so that classes from one module do not have the uncontrolled ability to see and obscure classes from other modules.
In traditional Java the so-called “classpath” is an enormous list of classes, and if multiple classes happen to have the same fully-qualified name then the first will always be found and the second and all others will be ignored.

The way to prevent uncontrolled visibility and obscuring of classes is to create a class loader for each module. A class loader is able to load only the classes it knows about directly, which in our system would be the contents of a single module.

模块访问级别

If we stop here then modules will be completely isolated and unable to communicate with each other. To make the system practical we need to add back in the ability to see classes in other modules, but we do it in a careful and constrained way.
At this point we input another requirement: modules would like the ability to hide some of their implementation details.

We would like to have a “module” access level, but the problem today is that the javac compiler has no idea where the module boundaries lie.

The solution we choose in our module system is to allow modules to “export” only portions of their contents. If some part of a module is non-exported then it simply cannot be seen by other modules.

When importing, we should import what we actually need to use, irrespective of where it comes from and ignoring all the things that happen to be packaged alongside it.

导出和导入的粒度

OSGi chooses packages.
The contents of a Java package are intended to be somewhat coherent, but it is not too onerous to list packages as imports and exports, and it doesn’t break anything to put some packages in one module and other packages in another module.
Code that is supposed to be internal to our module can be placed in one or more non-exported packages.

封装布线

Now that we have a model for how modules isolate themselves and then reconnect, we can imagine building a framework that constructs concrete runtime instances of these modules. It would be responsible for installing modules and constructing class loaders that know about the contents of their respective modules.

Then it would look at the imports of newly installed modules and trying to find matching exports.

An unexpected benefit from this is we can dynamically install, update and uninstall modules. Installing a new module has no effect on those modules that are already resolved, though it may enable some previously unresolvable modules to be resolved. When uninstalling or updating, the framework knows exactly which modules are affected and it will change their state if necessary.

版本

Our module system is looking good, but we cannot yet handle the changes that inevitably occur in modules over time. We need to support versions.

How do we do this? First, an exporter can simply state some useful information about the packages it is exporting: “this is version 1.0.0 of the API”. An importer can now import only the version that is compatible with what it expects and has been compiled/tested against, and refuse to accept

打包模块和元数据

Our module system will need a way to package the contents of a module along with metadata describing the imports and exports into a deployable unit.

So the only question is, where should we put the metadata, i.e. the lists of imports and exports, versions and so on?

As it happens OSGi was designed before 2000, so it did choose either of these solutions. Instead it looked back at the JAR File Specification, where the answer is spelled out:
META-INF/MANIFEST.MF is the standard location for arbitrary application-specific metadata.

后期绑定(bind)

The final piece of modularity puzzle is late binding of implementations to interfaces. I would argue that it is a crucial feature of modularity, even though some module systems ignore it entirely, or at least consider it out of scope.

We should look for a decentralised approach.
Rather than being told what to do by the God Class, let us suppose that each module can simply create objects and publish them somewhere that the other modules can find them. We call these published objects “services”, and the place where they are published the “service registry”.
The most important information about a service is the interface (or interfaces) that it implements, so we can use that as the primary registration key.
Now a module needing to find instances of a particular interface can simply query the registry and find out what services are available at that time. The registry itself is still a central component existing outside of any module, but it is not “God”… rather, it is like a shared whiteboard.