OSGI_面向Java的动态模型系统 - 威林百科weilinceramic.com

OSGI

面向Java的动态模型系统

OSGi（开放服务网关协议，Open Service Gateway Initiative）技术是Java动态化模块化系统的一系列规范。OSGi一方面指维护OSGi规范的OSGI官方联盟，另一方面指的是该组织维护的基于Java语言的服务（业务）规范。简单来说，OSGi可以认为是Java平台的模块层。OSGi服务平台向Java提供服务，这些服务使Java成为软件集成和软件开发的首选环境。OSGi技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语，这些组件能够组装进一个应用和部署中。

简介

开放服务网关协议有双重含义。一方面它指OSGi Alliance组织；另一方面指该组织制定的一个基于Java语言的服务规范——OSGi服务平台。 OSGi Alliance是一个由Sun Microsystems、IBM、爱立信等于1999年3月成立的开放的标准化组织，最初名为Connected Alliance。该组织及其标准原本主要目的在于使服务提供商通过住宅网关，为各种家庭智能设备提供各种服务。该平台逐渐成为一个为室内、交通工具、移动电话和其他环境下的所有类型的网络设备的应用程序和服务进行传递和远程管理的开放式服务平台。

该规范和核心部分是一个框架，其中定义了应用程序的生命周期模式和服务注册。基于这个框架定义了大量的OSGi服务：日志、配置管理、偏好，HTTP（运行servlet）、XML分析、设备访问、软件包管理、许可管理、星级、用户管理、IO连接、连线管理、Jini和UPnP。

这个框架实现了一个优雅、完整和动态的组件模型。应用程序（称为bundle）无需重新引导可以被远程安装、启动、升级和卸载（其中Java包/类的管理被详细定义）。API中还定义了运行远程下载管理政策的生命周期管理。服务注册允许bundles去检测新服务和取消的服务，然后相应配合。OSGI框架一般具备的基础功能：

支持模块化的动态部署。基于OSGI而构建的系统可以以模块化的方式动态地部署至框架中，从而增加、扩展或改变系统的功能。支持模块化的封装和交互。每个工程（模块）可通过声明Export-Package对外提供访问此工程的类和接口。

支持模块的动态扩展。基于OSGI提供的面向服务的组件模型的设计方法，以及OSGI实现框架提供的扩展点方法可实现模块的动态扩展。模块化的设计。在OSGI中模块由一个或多个bundle构成，模块之间的交互通过Import-Package、Export-Package以及OSGI Service的方式实现。

动态化的设计。动态化的设计是指系统中所有的模块必须支持动态的插拔和修改，“即插即用，即删即无”。

可扩展的设计。通常使用定义扩展点的方式。按照Eclipse推荐的扩展点插件的标准格式定义bundle中的扩展点，其它要扩展的bundle可通过实现相应的扩展点来扩展该bundle的功能。每个bundle拥有独立的class loader，通过它来完成本bundle类的加载。

稳定、高效的系统。基于OSGI的系统采用的是微核机制，微核机制保证了系统的稳定性，微核机制的系统只要微核是稳定运行的，那么系统就不会崩溃，也就是说基于OSGI的系统不会受到运行在其中的bundle的影响，不会因为bundle的崩溃而导致整个系统的崩溃。

OSGi服务平台提供在多种网络设备上无需重启的动态改变构造的功能。为了最小化耦合度和促使这些耦合度可管理，OSGi技术提供一种面向服务的架构，它能使这些组件动态地发现对方。OSGi联盟已经开发了例如像HTTP服务器、配置、日志、安全、用户管理、XML等很多公共功能标准组件接口。这些组件的兼容性插件实现可以从进行了不同优化和使用代价的不同计算机服务提供商得到。然而，服务接口能够基于专有权基础上开发。

因为OSGi技术为集成提供了预建立和预测试的组件子系统，所以OSGi技术使你从改善产品上市时间和降低开发成本上获益。因为这些组件能够动态发布到设备上，所以OSGi技术也能降低维护成本和拥有新的配件市场机会。

安全协议

安全机制是建立在Java和Java2安全模型基础之上。Java语言的设计对很多结构进行了限制。例如病毒中经常遇到的缓存溢出是不可能发生的。Java语言中的访问控制符限制了代码可见性。

OSGI平台通过使用私有类（在Java中不能用标准方式使用的机制）扩展了该模型。Java2安全模型提供了一个完整模块检查代码对于资源的可访问性。OSGI增加了完全动态的权限管理，简化了操作者和系统管理员的工作。

OSGI联盟已经定义了很多协议服务，这些服务将外部协议映射为OSGI服务。HTTP服务(HttpService)该HTTP服务是servlet运行器。bundles提供servlets，这些服务端小程序基于HTTP协议成为可用的。OSGi服务平台的动态更新功能使HTTP服务成为一个非常具有吸引力的Web服务器，它能伴随着新的servlet被更新，如果需要可以远程更新而无需重启。

UPnP服务(UPnPService)通用即插即用（UPnP）是一个正在形成中的消费电子标准。OSGi中的UPnP服务在一个UPnP网络上将设备映射到服务注册中。同样，它也可以将OSGi服务映射到UPnP网络。这是发布版本3中的推荐规范。

DMT管理(DMTAdmin)开放移动联盟(OMA)基于设备管理树为移动设备管理提供了一个完整规定。DMT管理服务定义该树如何被访问和/或者在OSGi服务平台中被扩充。

框架结构

OSGI规范的核心组件是OSGI框架。这个框架为应用程序（被叫做组件（bundle））提供了一个标准环境。整个框架可以划分为一些层次：

L0：运行环境

L1：模块

L2：生命周期管理

L3：服务注册

还有一个无处不在的安全系统渗透到所有层。

L0层执行环境是Java环境的规范。Java2配置和子规范，像J2SE，CDC，CLDC，MIDP等等，都是有效的执行环境。OSGi平台已经标准化了一个执行环境，它是基于基础轮廓和在一个执行环境上确定了最小需求的一个小一些的变种，该执行环境对OSGi组件是有用的。

L1模块层定义类的装载策略。OSGi框架是一个强大的具有严格定义的类装载模型。它基于Java之上，但是增加了模块化。在Java中，正常情况下有一个包含所有类和资源的类路径。OSGi模块层为一个模块增加了私有类同时有可控模块间链接。模块层同安全架构完全集成，可以选择部署到部署封闭系统，防御系统，或者由厂商决定的完全由用户管理的系统。

L2生命周期层增加了能够被动态安装、开启、关闭、更新和卸载的bundles。这些bundles依赖于于具有类装载功能的模块层，但是增加了在运行时管理这些模块的API。生命周期层引入了正常情况下不属于一个应用程序的动态性。扩展依赖机制用于确保环境的操作正确。生命周期操作在安全架构保护之下，使其不受到病毒的攻击。

L3层增加了服务注册。服务注册提供了一个面向bundles的考虑到动态性的协作模型。bundles能通过传统的类共享进行协作，但是类共享同动态安装和卸载代码不兼容。服务注册提供了一个在bundles间分享对象的完整模型。定义了大量的事件来处理服务的注册和删除。这些服务仅仅是能代表任何事物的Java对象。很多服务类似服务器对象，例如HTTP服务器，而另一些服务表示的是一个真实世界的对象，例如附近的一个蓝牙手机。这个服务模块提供了完整安全保障。该服务安全模块使用了一个很聪明的方式来保障bundles之间通信安全。

标准服务

在该框架之上，OSGi联盟定义了很多服务。这些服务通过一个Java接口指定。bundles能够实现这个接口，并在注册服务层注册该服务。服务的客户端在注册库中找到它，或者当它出现或者消失时做出响应。这个同SOA架构使用Web服务进行发布的方式相似。

两者主要不同是Web服务总是需要传输层，这个使它比采用直接方法调用的OSGi服务慢几千倍。同时，OSGi组件能够对这些服务的出现和消失做出响应。更多的信息可以从OSGi服务平台发行版本4手册或者PDF下载中找到。需要注意的是每一种服务都是抽象定义的，与不同计算机服务商的实现相独立。

框架服务

OSGi框架提供一个权限管理服务，一个包管理服务和一个开始级别服务。这些服务是一个可选部分，指示框架的操作。框架服务如下：

权限管理(PermissionAdmin)的bundles的权限通过这种服务进行维护。一旦设置了它们，权限服务立即激活。

包管理(PackageAdmin)，bundles同类和资源分享包。bundles的更新可能需要系统重新计算这些依赖。这个包管理服务提供关于系统的实际包分享状态和能够刷新已经共享的包。也就是，取消依赖和重新计算依赖。

启动级别(StartLevel)。启动级别是一个bundles集合，它们应该同时运行或者应该在其它已经启动以前被初始化。启动级别服务设置当前的启动级别，为每个bundle排一个启动级别和审核当前的设置。

URL处理者(URLHandler)。Java环境为URL处理者支持一个提供者模型。然而，这是一个单件，不可能在一个象OSGi可能有很多提供者的协作环境上使用它。此服务规范使任何组件提供额外的URL处理者。

系统服务

系统服务提供水平功能，它在每个系统是必须的。日志服务，配置管理服务，设备访问服务，用户管理服务，IO连接器服务和参数服务都是系统服务的一个方面。

日志服务(LogService)，日志信息，警告，调试或者错误信息通过日志服务来处理的。它接受日志实体并分派这些实体到订阅了这个信息的其他bundles。

配置管理服务(ConfigurationAdminService)，该服务提供一个设置和获取配置信息的灵活、动态模型。

设备访问服务(DeviceAccessService)，设备访问是OSGi为一个新的设备匹配一个驱动，并自动下载一个实现该驱动的bundles的机制。这个可用作即插即用方案。

用户管理服务(UserAdminService)，该服务使用一个用于授权和验证目的的用户信息数据库。

IO连接器服务(IOConnectorService)，该IO连接器服务实现了CDC/CLDCjavax包，并作为一个服务。该服务允许bundles提供新的可交换协议模式。

参数服务(PreferencesService)，该服务提供了参数层级数据库的可访问性，同Windows注册表或者Java参数类相似。

组件运行时服务(ComponentRuntime)，服务的动态特性--它们能够在任何时间来去自由--使编写软件变得更难。组建运行时规范通过提供一个基于依赖声明的XML文件来简化处理这些动态方面。

部署管理服务(DeploymentAdmin)，OSGi的主要部署格式是bundle，它是一个JAR/ZIP文件。部署管理提供第二种可选格式：部署包。部署包能够将bundles和相应资源联接成可被安装和卸载的单个交付。完整的资源处理器模型允许用户代码扩充资源类型。

事件管理服务(EventAdmin)，很多OSGi事件有特定的类型化的接口，使其很难接收和过滤事件。事件服务提供一个泛化的基于主题的事件机制。这个规范包括为所有已存框架和服务事件的映射。

应用程序管理服务(ApplicationAdmin)，OSGibundle模型不同于依赖于启动和关闭形式的典型的桌面或者移动电话应用程序模型。该应用程序管理服务提供了传统应用程序模型和它所要求的管理设施。

HelloWorld

0.前言

这篇文档介绍如何使用OSGi框架的一个实现——Equinox来教你如何配置一个简单的OSGi开发环境，并且在这个环境上开发一个HelloWorld程序，这其中会涵盖前面的入门篇讲到的三个层次的内容，让你在实践的同时巩固之前了解的内容。话不多说，我们开始吧！

开发环境建立

1.1 Equinox是什么

从代码角度来看，Equinox其实就是OSGi核心标准的完整实现，并且还在这个基础上增加了一些额外的功能（比如为框架增加了命令行和程序执行的入口）。我们在之前入门篇讲解的东西其实都是OSGi核心标准的一小部分。其实它的核心就是一个jar包，这个jar包既能执行（作为标准Java包的特性），也是一个bundle（Manifest里面含有OSGi bundle特有的元数据）。

能够利用Equinox项目的代码来运行一个实实在在的OSGi框架，框架启动后，你就可以将你开发好bundle放到里面运行。

1.2下载Equinox

Equinox在Eclipse官方网站上有下载，里面列出了各个版本供我们选择：

1.3 从命令行启动框架

如果启动这个框架的话，有了上面的jar包就足够了，我们进入命令行输入如下命令：java –jar org.eclipse.osgi_3.7.0.v20110613.jar -console ，然后就会进入Equinox的控制台：

如果出现osgi>的提示符，就说明启动成功了。

Equinox的控制台的部分基本命令如下（区分大小写）：

1.4 Eclipse建立环境

在上一节中大家看到启动和控制框架的方法，是相当简单的一个过程。不过单单只是运行环境还不够，我们还需要开发环境。

1.4.1 设置

首先我们不需要安装必须的插件，只要你有较新版本的Eclipse就行了。然后进入Eclipse的window->preferences界面，选中Plug-in Development下的Target Platform

右边只有一个Runing Platform的，我们任务是点击“Add…”按钮来增加一个我们自己的的platform，进入如下界面：

选择默认的第一个就好，点击next。

再点击这里的“Add…”：

选择“Directory”：

选择你的Equinox的jar包所在的路径,然后点击finish，回到刚才的界面：

这时候你就会发现里面多出来了你刚刚设置的路径，路径后面描述的“1 plug-ins available”则就是说的我们放置的Equinox的jar包。

继续点击finish，回到最开始的界面

这时候多出来了一个新的target platform，勾选上，然后确定。

1.4.2 启动

打开菜单项Run->Run configurations…，在OSGi Framework项中，新建一个Runconfiguration：

已经自动包含了Equinox的jar包了，点击Run，看看运行的效果：

Eclipse的控制台中也出现来了osgi的提示符，说明你已经成功启动了。

你可以试试刚才讲的那些命令，看看能输出些什么（比如图1中我输入了ss）。

1.4.3 新建一个project

打开新建project的界面，选择Plug-in Project：

然后输入project的名字，TargetPlatform处选择an OSGi framework->Equinox或者standard都行，点击下一步：

这里实际上是对bundle的Manifest文件的设置，其中的ID就是Bundle-SymbolicName，Version就是bundle的版本号，下面还能决定是否定义BundleActivator，点击finish就创建了一个project

至此，开发环境已经建立完毕（这个project只是为了演示怎么建立，不会在接下来的内容中用到，可删之）。

2 HelloWorld代码

可谓是万事具备，只欠Helloworld了。为了将OSGi框架的三个层次都涵盖到，这个Helloworld可能会比其他你见到的OSGi Helloworld程序要复杂一点点。如果对代码中的一些API感到生疏，记得回到之前的入门篇中找到对应的内容，这样对你理解代码会有帮助。里面的关键代码已经用黄色高亮显示。（出于篇幅考虑，代码中的import语句都省略）

2.1 HelloWorld的定义与实现

首先我们创建一个工程org.serc.helloworld，在这个工程里面，我们创建一个包含sayHello方法的接口，准备作为服务接口：

然后，对这个接口进行实现：

这个类实现的sayHello所做的工作就是输出一个在对象构造的时候得到的helloString 字符串。

为了将这个接口暴露出来，我们需要在MANIFEST文件中加入如下条目：

接下来，为了把这个服务注册到框架中，我们定义了一个Activator：

为了让这个Activator能够工作，需要在MANIFEST文件中做如下定义：

这个bundle 最终的MANIFEST内容如下：

2.2 获得并执行SayHello服务

创建一个工程org.serc.helloworld.client，创建一个叫HelloUser的BundleActivator，其中的start方法会获得接口为Hello的服务对象，并且通过这个对象来调用sayHello方法：

为了获得Hello这个接口的定义，我们还需要在MANIFEST文件中import Hello所在的package：

2.3 HelloWorld程序的流程

可能光看代码会比较不容易看清楚程序的执行流程，图2表示了这几个类的各个功能的相互依赖关系，整个关系从Hello接口的定义开始；然后到Hello接口被实现，得到HelloImpl；再到Activator将HelloImpl注册为框架中的一个服务，再到HelloUser通过与框架交互得到刚才注册的服务，并且使用这个服务从而输出字符串；最后一个可选流程是当我们stop org.serc.helloworld这个bundle的时候，程序会将之前注册的服务注销掉。

2.4 程序的执行

通过上面的工作，我们得到了两个自己定义的bundle：

org.serc.helloworld

org.serc.helloworld.client

打开Run configurations界面，我们会看见Bundles标签里面多出来了这两个bundle：

也就是说，OSGi框架在启动的时候，会自动install和start这2个bundle。

2.5 利用命令行查看程序执行过程中框架状态的变化

2.4其实只给出了一个结果，如果你还不太清楚这个结果具体是怎么出来的，那么这一节的内容应该能够帮助你更好的理解输出结果的过程。下面我们通过Equinox的一些命令行来一步一步安装和执行bundle，并且查看过程中框架的状态变化，来让你们搞清楚这个结果是怎么来的。

首先在Run configuration中取消两个helloworld bundle的自动启动：

然后点击Run，这时候就不会立即输出Hello， OSGi字符串了，先用“ss”命令查看bundle 的状态：

可见两个bundle并不是出于ACTIVE状态，说明并没有启动，我们执行“start 8”来启动org.serc.helloworld这个bundle

在用services命令查看当前已经注册的服务，我们会看到一大堆的系统服务中多出来如下一项服务

这显然是我们在start以后注册上去的，但是还没有任何一个bundle在使用这个服务。

接下来我们start 9号bundle，也就是我们用来调用服务的bundle

这时就输出了“Hello， OSGi”的字符串。

那么如果我们先启动9号bundle而不启动8号bundle会怎么样呢？大家可以试一试，因为我们在代码中已经对没有服务的异常情况做了处理，届时会有相应的输出。

我们先停止8号bundle

大家可以看见刚才注册的服务已经被注销了，我们执行refresh 11（也就是刚才的9号bundle）来重新执行其中BundleActivator的start方法

可见Hello服务已经不复存在了。从这里我们可以看出来，其实Bundle的启动顺序也是一个需要注意的环节，有时候你所定义的bundle是具有顺序敏感性的，必须要某些前置bundle启动了以后，后面的bundle才能正确启动。

3 小结

这篇文档是入门篇的最后一章了，希望读者在花时间看完这4篇文档并且动手实践后能够有所收获，并且对OSGi框架的工作原理及其优势能有一个比较清晰的了解和认识。