Java应用架构设计 - 模块化模式与OSGi

OSGi（Open Service Gateway Initiative）会带来生态系统吗？这个问题值得探讨。

OSGi并不是新鲜的事物，它从20世纪90年代就存在了。

OSGi是Java平台上的动态模块系统，但是它并没有被广泛地采用。

模块化并不是新的理念，OSGi也不是。

OSGi是成熟稳定的规范。

多年以来，OSGi技术在嵌入式系统以及网络设备市场上大放异彩，而对企业级的开发人员来说，OSGi依然是一种相对陌生的技术。

使用OSGI的应用案例有：

　　Eclipse

　　在2003年，Eclipse团队在寻找使Eclipse更动态化的方式。他们的决定是使用OSGi创建支持插件（plug-in）架构的富客户端平台，这是我们今天所了解的生态系统的第一步。开发人员使用Eclipse的一个原因就是有大量可用的插件，这些插件可以让他们高效的完成工作。其他开发人员创建Eclipse插件的原因是Eclipse是被众多开发人员广泛使用的IDE。同样的，生态系统养活了自己。Eclipse团队提供了如今的Eclipse生态系统赖以发展的环境。

　　关于Eclipse和OSGi的历史，可以参考：https://www.eclipse.org/equinox/documents/transition.html

　　Atlassian

　　Atlassian插件框架（Atlassian plugin framework）是另一个使用功能OSGi的样例。

　　Liferay7.0开始引入

　　基于 OSGi 框架，运行在 OSGi 运行时环境中。

OSGi成熟的实现有：Equinox、Felix，另外还有许多大型软件平台和中间件服务器都基于或声明将会基于OSGi规范来实现，例如：IBM Jazz平台、GlassFish服务器、jBOSS OSGi等等。

　　Equinox是Eclipse中的项目之一，Equinox是作为OSGi R4 RI而知名的，同时由于Equinox有Eclipse IDE这么个成功案例，反应出了Equinox作为OSGi框架的优势。
　　Equinox是随着Eclipse版本而发布的，同时，它也提供独立的下载，在独立的下载页面中可以下载到Equinox对于OSGi R4的所有实现以及Equinox扩展OSGi R4而提供的Bundle。
　　Equinox开发小组由IBM的Jeff领衔，开发状态非常的活跃。

　　----百度百科

■ OSGi原理

　　OSGi中的每个模块（bundle）都包含Java包和类。模块可以声明它所依赖的需要导入（import）的其它模块的Java包和类（通过Import-Package），也可以声明导出（export）自己的包和类，供其它模块使用（通过Export-Package）。也就是说，需要能够隐藏和共享一个模块中的某些Java包和类。这是通过OSGi特有的类加载器机制来实现的。OSGi中的每个模块都有对应的一个类加载器。它负责加载模块自己包含的Java包和类。当它需要加载Java核心库的类时（以java开头的包和类），它会代理给父类加载器（通常是启动类加载器）来完成。当它需要加载所导入的Java类时，它会代理给导出此Java类的模块来完成加载。模块也可以显式的声明某些Java包和类，必须由父类加载器来加载。只需要设置系统属性org.osgi.framework.bootdelegation的值即可。

　　OSGi的Bundle类加载器之间只有规则，没有固定的委派关系。

　　一个Bundle类加载器为其他Bundle提供服务时，会根据Export-Package列表严格控制访问范围。如果一个类存在于Bundle的类库中但是没有被Export，那么这个Bundle的类加载器能找到这个类，但不会提供给其他Bundle使用，而且OSGi平台也不会把其他Bundle的类加载器请求分配给这个Bundle来处理。

■ OSGi所能带来的

　　① 模块化开发

　　     开发哲学将从以应用为中心转移到以模块为中心。

　　　 OSGi框架定义了一个模块化单元，并将其称为bundle。

　　　 bundle只是一个jar文件。难道只是普通的jar文件？不是的。

　　　 如果一个jar文件中包含了提供功能的资源以及关于bundle元数据的清单文件（Manifest），那么它就是一个合法的OSGi bundle。

            其中，资源可以是Java类、HTML、图片、Servlet甚至JSP。

　　　　　　 元数据通过一些必需和可选的键值对来进行定义。

　　　  如果jar文件不包含清单文件，那么它就不会被视为合法的OSGi bundle。因为，清单文件包含了描述性元数据，OSGi框架要使用它来初始化bundle。　     

             OSGi bundle是包含了清单文件的标准Java JAR文件。

　　　  OSGi改变了企业级应用程序的部署模型。传统的思考方式是以web应用开发为中心的，团队将其有价值的资源投入到识别Web应用程序中的功能以及跨Web应用的通信上。

　　　　　　　　　　　　　　　　　　　　       借助OSGi，我们不再开发传统的Web应用，只需要开发组成应用程序的bundle。

 　　　　

　　　　bundle状态：

　　　　OSGi框架所管理的bundle都有一个对应的bundle生命周期状态。在任意时刻，OSGi bundle会以下面的某种状态存在：

　　　　● Installed：OSGi bundle成功安装，但是依赖还没有解析。

　　　　● Resolved：OSGi bundle所需要的依赖已经进行了解析。但是，它的服务没有启动，还不可用。

　　　　● Starting：bundle正在启动，它的服务很快就会可用。

　　　　● Active：bundle成功启动，它的服务可以使用了。

　　　　● Stopping：bundle停止，它的服务不能再使用了。

　　　　● Uninstalled：bundle已经被卸载了。

　　② 管理依赖

　　    OSGi将jar作为最佳的模块形式，即jar文件是在Java中主要的重用和部署形式。

　　　OSGi bundle中的清单文件定义了其他模块可以使用的导出包，同时也定义了本bundle要使用的导入包。

　　③ 模块平台

　　　 OSGi并不是分布式的服务技术。

　　　 OSGi的bundle会在同一个JVM中进行部署和交互，这可以在进程内轻量级地跨bundle交互。

　　     OSGi是真正的模块平台，它解决了企业级Java开发和SOA目前并没有解决的关键问题。

　　④ 版本化的bundle

　　    我们可以在OSGi平台中部署同一个bundle的多个版本，而不会出现致命错误。（如果在同一个JVM中多次部署同一个类，经常会出现ClassCastExcepiton之类的异常）

　　⑤ 动态（重）部署

　　　 当一个bundle中的功能发生变化时，只需要将这个bundle重新部署到合适的OSGi平台中即可，bundle的客户端将会通过它所导出的包以及版本自动的发现它。

　　     因此没有必要重新部署整个应用。

　　⑥ 环境相关的控制

　　　 OSGi是一个可管理的容器环境，因此我们可以安装、启动、停止、更新以及卸载各个bundle。

　　总结：在java平台中，OSGi填补了SOA与面向对象设计之间的技术鸿沟。