Java应用架构读书笔记(8):<mark><mark>OSGi</mark></mark>与模式

 由  罗俊杰 发布

当为目标平台提供模块化的运行时支持时,模块化软件的优点将体现得更加充分。OSGi是业界模块化方面的事实标准平台。运行时模块系统并非开发模块化软件的必须,但是一个好的运行时模块系统,比如OSGi,能够为我们的开发带来极大的帮助。

关系维护

在OSGi中,任何外部可见的包必须要export,在manifest.mf中申明。同样如果一个bundle需要使用其他的包,则需要在manifest.mf中import该包。 以下是使用模式时,OSGi中的包引入和包导出能够带来的帮助。

Manage Relationships

当进行bundle部署时候,OSGi会基于包的引入和导出关系来检查类的可见性。引入和导出关系提供了一种方便你管理模块间的关系的方法。

Published Interface

仅仅依靠Java,一个模块中的类型是无法完全隐蔽的。基于OSGi,只要我们不导出某个类型,则该类型就是对其他模块完全隐蔽的。

Physical layers

在manifest.mf中可以查看一个bundle所引用的所有其他包,因此我们可以检查是否引入了不该引用的包

动态性

OSGi支持模块的动态热部署,无需系统的重新启动。这种动态性为模式的应用提供了帮助。

Module Reuse

如果我们在模块层强调复用的话,那么OSGi的动态性支持我们将可复用的模块方便的部署到已经存在的系统中。

Abstract Modules

依赖于一个模块的抽象元素,我们可以在新的模块中定义新的实现,并进行热部署,不会影响正在运行的系统的正常使用。

Separate Abstraction

Abstract Modules的一种扩展,如果我们将抽象和实现分离在不同的模块,我们不仅可以动态部署新的实现,而且可以卸载现有的无用实现。

Independent Deployment

如果模块是相互独立的话,那么模块可以被轻松的部署到正在运行的系统中。

Blueprint规范

Blueprint允许开发者使用OSGi技术而无需考虑其编程模型。基于Blueprint,我们的代码可以独立于OSGi的API。

Container Indepedence

这正是blueprint带给我们的:让我们的代码不依赖于OSGi的API。

External Configuration

Blueprint支持我们定义模块的配置,因此我们可以外部定义模块的服务,而无需让模块或者暴露为服务的类与OSGi API耦合。

Implementation Factory

Blueprint提供了一个OSGi uService的工厂,支持这些服务的运行时自动动态连接,比如你可以像注入一个bean一样注入一个OSGi Service。

查看评论