OSGi Bundle的构建策略及实践 .
分类: OSGi Architecture Design 2008-02-18 01:02 1286人阅读 评论(0) 收藏 举报
软件编程发展到今天可以看作是一个量变引发质变的过程。最初,程序开发面向过程,开发人员需要编写大量的过程代码,随着过程代码的不断积累(量变产 生),从代码维护和重用的角度,过程开发变得越来越不适应,质变产生,面向对象的开发逐渐被采用。由于面向对象的开发很好的封装了过程,而且从面向对象的 角度可以很好的描述实际应用中的需求模型,因此面向对象的开发逐渐成为主流。同样,随着面向对象开发的不断应用(量变产生),出现了大量的可复用的类及 包,维护这些类/包变得越来越困难,而且,尽管面向对象的编程机制可以很好的适应小规模应用的开发,但随着应用系统的规模越来越大,如同用细小的沙粒构建 堤坝,面向对象的机制难于适应,质变产生,面向组件的开发被引入开发过程。面向组件的开发目前仍可以认为是处于一种探索状态,目前还不存在一种统一的标准 可以遵循。
从另一个角度,历史是今天存在的基础,没有历史就没有今天。同样的道理,应用系统采用面向组件的开发实现,组件仍需要对象来构造,而对象在一定程度上是封 装的功能过程,三者相辅相成。不管是从上而下还是从下而上,应用系统需求模型在其实现过程中,系统设计者应该充分关注组件、对象和功能过程三个层面。
OSGi可以看作是面向组件开发的一种思路和基础环境。在OSGi环境中实现应用系统的需求模型要求开发人员对组件、对象开发具有充分的理解。衡量一个应 用系统实现好坏的标准之一是该系统是否是松耦合高内聚。面向对象的开发实现此目标的关键是接口/抽象的应用,OSGi面向组件的开发在此基础之上充分利用 了对象类包封装的机制。
1. Bundle的构建策略
通常,当我们构建应用系统时,我们需要充分重视所构建应用的业务需求模型即领域模型,同样的,在用软件代码实现业务需求模型时,我们也应当对软件系统的架 构模型给予充分的重视。采用OSGi技术实现应用系统时,展现在我们面前的将是一个个的Bundle组件,此时,我们必须首先弄清楚我们要构建什么样的 Bundle。
1.1 明确Bundle的构建需求及实现粒度
从需求模型的角度看,Bundle可以看作是需求模型中的一个功能模块实现,因此,在开发Bundle之前系统开发人员必须明确Bundle的功能需求。 需求模型中的功能模块的边界可大可小,同样,Bundle的实现粒度也是可大可小,极端情况下,小的Bundle可以仅实现一个微小的功能,大的 Bundle可以实现整个业务系统。
以记录日志为例,如果记录日志仅输出到控制台,则一个类就可以实现整个的功能,如果记录日志输出到数据库系统,则开发人员需要在整个功能用一个 Bundle实现,还是将日志记录功能和记录信息的数据库存储分为两个不同的Bundle实现,两个选择甚至更多的选择中做出决策。通常这个问题在现有的 软件开发方式中不需要过多的重视,但在OSGi开发中,开发人员必须根据需求确定Bundle的实现粒度。
1.2 确定Bundle的类型
我们在面向对象的系统开发过程中,经常会将一些通用的功能设计成为工具类,多个工具类封装为一个工具类包。由于OSGi开发建立在面向对象的开发之上, Bundle的开发也存在这种特点。OSGi开发的另一个特点是服务机制的引入,一个Bundle可以将其提供的功能发布成为一个或多个服务,供其他 Bundle查找使用。此外,建立在OSGi环境之上的组件开发也区别于通常的组件开发方式,因为我们可以利用OSGi环境提供的某些特性(参见下一节 充分利用OSGi环境的特性)。综上所述,我们可以将Bundle划分为如下几种类型(实际开发中,并不存在清晰的边界):
•Utility Bundle
这种Bundle与通常开发方式中的工具类或工具类包没有本质的区别,仅仅是将这些工具类发布到OSGi环境中,这些工具类也不依赖任何的OSGi环境或 特性。通常,这种Bundle特别适合目前存在的众多的第三方组件引入到OSGi环境中直接供OSGi开发人员使用。例如,我们可以将Apache开源项 目Log4j发布的工具包通过修改其META-INF目录下的MANIFEST.MF文件,添加Bundle的元数据信息就可以直接将其封装为可供 OSGi环境中其他Bundle使用的工具类Bundle。
•依赖OSGi特性的Bundle
这类Bundle可以被其他Bundle引用,为其提供功能,但是这类Bundle不能离开OSGi运行环境,否则不能使用。举例来说,一个提供数据缓存 功能的Bundle可能使用Bundle的数据存储区来缓存数据。Bundle的数据存储区的位置对Bundle开发者来说是透明的(参见下一节 充分利用OSGi环境的特性)。如果将该Bundle的数据缓存功能迁移到OSGi运行环境之外,则必须修改实现添加对缓存区位置的处理功能。
•引用和(或)发布OSGi服务的Bundle
这类Bundle也可以认为是依赖OSGi特性的Bundle,唯一的区别就是,该类Bundle充分利用的OSGi中服务的特性,引用其他Bundle 发布的服务和(或)向OSGi环境中发布自己的服务。OSGi环境提供的服务机制可以使得系统的实现遵循最大程度的松耦合。
1.3 隐藏Bundle的功能接口
组件开发除了应对系统的开发规模之外,其最重要的目标是降低系统耦合。开发人员采用OSGi Bundle开发时,应尽量屏蔽Bundle所提供功能的内部实现机制,仅将为其他Bundle提供的交互接口暴露出来。在OSGi中,这可以通过两种方 式,一种是通过Export供其他Bundle引用的类包;一种是向OSGi环境发布服务。
在Equinox中,Bundle内部实现的类包通常以"internal"标注,如org.eclipse.equinox.internal.cm.reliablefile。标注为"internal"的类包通常不包含在Export列表中,或者通过"x-internal"属性标记(该属性仅在Eclipse开发环境中提供)。
隐藏Bundle功能接口的一种良好机制是通过OSGi服务。开发人员仅将自己开发的Bundle的接口类包发布给其他Bundle可见,同时,将功能接 口的实现注册为OSGi中的服务,其他Bundle通过查找OSGi服务注册表获取该服务,通过服务的接口调用服务的功能。
1.4 尽可能应用OSGi提供的标准服务
OSGi联盟为一些经常用到的功能定义了标准服务,如应用程序管理服务,日志服务,事件服务,配置管理服务,用户管理服务,HTTP服务等等。如果开发人 员采用的OSGi环境提供了上述服务的实现,且这些服务实现满足系统的需求,则开发人员应尽可能使用这些服务,而不是为这些类似的功能定义自己的实现。
2.充分利用OSGi环境的特性
2.1 OSGi环境的动态特性
OSGi是一个动态的环境,OSGi运行环境内部状态的变化通过事件发布/监听机制进行交互。开发人员在构建Bundle时应充分利用OSGi环境的事件 监听机制。如,开发人员可以在自己的Bundle中注册Bundle事件的监听用来处理其他Bundle的安装,启动,停止,卸载等事件。
OSGi运行环境内部的事件主要包括三类:
•框架事件(FrameworkEvent)
STARTED 框架已经启动
ERROR 某个Bundle启动过程中引发错误
WARNING 某一Bundle引发一个警告
INFO 某一Bundle引发一个INFO类型的事件
PACKAGES_REFRESHED PackageAdmin.refreshPackage操作执行完成
STARTLEVEL_CHANGED StartLevel.setStartLevel操作执行完成
•Bundle事件(BundleEvent)
INSTALLED Bundle被安装到OSGi环境后系统发布该事件
RESOLVED Bundle被成功解析
LAZY_ACTIVATION Bundle将被延迟激活
STARTING Bundle正在被激活
STARTED Bundle被成功激活
STOPPING Bundle被停止
STOPPED Bundle正在被停止
UPDATED Bundle被更新
UNRESOLVED Bundle被UNRESOLVED
UNINSTALLED Bundle被卸载
•服务事件(ServiceEvent)
REGISTERED 服务被注册
MODIFIED 服务被修改
UNREGISTERING 服务正在被注销
关于上述事件的详细信息参考OSGi API文档。
下述代码展示了如何在Bundle组件中通过实现FrameworkListener,BundleListener和ServiceListener接口,并使用BundleContext注册监听OSGi环境的各种事件:
package com.example;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.BundleEvent;
import org.osgi.framework.BundleListener;
import org.osgi.framework.FrameworkEvent;
import org.osgi.framework.FrameworkListener;
import org.osgi.framework.ServiceEvent;
import org.osgi.framework.ServiceListener;
public class Activator implements BundleActivator, FrameworkListener,
BundleListener, ServiceListener {
public void start(BundleContext context) throws Exception {
//注册监听
context.addFrameworkListener(this);
context.addBundleListener(this);
context.addServiceListener(this);
}
public void stop(BundleContext context) throws Exception {
}
//处理框架事件
public void frameworkEvent(FrameworkEvent event) {
if ((event.getType() & FrameworkEvent.ERROR) != 0) {
System.err.println("Framework ERROR: " + event.getBundle());
}
}
//处理Bundle事件
public void bundleChanged(BundleEvent event) {
if ((event.getType() & BundleEvent.STARTED) != 0) {
System.err.println("Bundle STARTED: " + event.getBundle());
} else if ((event.getType() & BundleEvent.STOPPED) != 0) {
System.err.println("Bundle STOPPED: " + event.getBundle());
}
}
//处理服务事件
public void serviceChanged(ServiceEvent event) {
if ((event.getType() & ServiceEvent.REGISTERED) != 0) {
System.err.println("Service REGISTERED: "
+ event.getServiceReference());
}
}
}
2.2 Bundle的生命周期及OSGi上下文特性
在Java虚拟机运行环境中,类的生命周期开始于虚拟机的加载,终止于被提前卸载或虚拟机停止,通常不需要开发人员干预。在OSGi环境中,开发人员可以参与Bundle的生命周期过程并能够获取Bundle在OSGi环境中运行的上下文。
通过实现org.osgi.framework.BundleActivator接口,并在Bundle的元数据头属性"Bundle- Activator"中指明该接口的实现类,如"Bundle-Activator: com.example.Activator"。当Bundle被启动或停止时,OSGi框架会将该Bundle的运行上下文BundleContext 注入到该实现类实例中,开发人员可以在该Bundle的运行过程中使用该上下文访问OSGi环境信息,访问OSGi环境中的其他Bundle,注册事件监 听,发布或引用服务等。
下面的代码片段展示了如何利用Bundle运行上下文与OSGi环境进行交互:
public void start(BundleContext context) throws Exception {
// 获取OSGi环境中的所有安装的bundle
for (Bundle bundle : context.getBundles()) {
System.out.println("Bundle Symbolic Name: "
+ bundle.getSymbolicName());
}
// 获取OSGi运行环境中的属性(查找范围包括系统属性)
System.out.println("osgi.framework = "
+ context.getProperty("osgi.framework"));
//注册其他Bundle
context.installBundle("file:C://test_bundle_1.0.0.jar");
//在该Bundle的数据存储区中构建datacache.file文件
context.getDataFile("datacache.file");
//注册监听
context.addFrameworkListener(this);
context.addBundleListener(this);
context.addServiceListener(this);
}
2.3 Bundle的资源管理特性
在通常的应用系统开发中,开发人员通常要考虑配置文件的存储路径,系统临时文件的存储路径等信息。由于OSGi环境中Bundle实际上是由一组文件资源 构成,开发人员在开发Bundle时可以充分利用这种特点,使用Bundle存储与Bundle相关的配置信息。OSGi环境在运行时为每一个 Bundle构建一个序列化数据存储区,开发人员可以使用该存储区存储Bundle在运行时生成的临时信息。
下述代码片段展示了如何通过Bundle提供的功能接口获取Bundle内部的资源:
•context.getBundle.getEntry("") 只查询Bundle内部资源,返回Bundle的URL,该URL与实现相关,如:bundleentry://256/
•context.getBundle.getEntry("/") 只查询Bundle内部资源,返回Bundle的URL,该URL与实现相关
•context.getBundle.getEntry("/build.properties") 只查询Bundle内部资源,返回Bundle内部build.properties文件的URL,该URL与实现相关,如:bundleentry://256/build.properties
•context.getBundle().getResource("build.properties") 使用Bundle的ClassLoader查询Bundle类域内的资源,如果Bundle不能被解析(RESOLVED),则只查询Bundle内部资源,返回Bundle内部build.properties文件的URL,该URL与实现相关。
开发人员在获取上述资源的URL后,可以转换成与Bundle运行系统相关的文件URL,如:file:C:/test_bundle_1.0.0。
下述代码片段展示了通过BundleContext接口获取Bundle运行时数据存储区资源:
•context.getDataFile("") 返回该Bundle的运行时数据存储区位置,如:E:/worksapce/.metadata/.plugins/org.eclipse.pde.core/CobWeb/org.eclipse.osgi/bundles/256/data
•context.getDataFile("config.xml") 返回该Bundle的运行时数据存储区内的config.xml文件,如果该文件不存在,则创建该文件。
2.4 面向服务的组件特性
OSGi的服务层提供了一个动态服务发布,绑定和查找模型,所谓的服务即指实现了某个(些)接口的Java对象。在面向对象的系统开发中,接口在分离系统的耦合方面扮演至关重要的角色,OSGi环境充分利用了这一点。
OSGi运行框架维护着一个服务注册表,Bundle可以通过Bundle上下文向该服务注册表中发布服务(只需指明服务实现的接口,服务的实例和服务的 属性),也可以使用Bundle上下文从服务注册表中根据接口名称及服务的属性查找其他Bundle注册的服务。在此模式下,Bundle之间的耦合关系 只存在接口层面,而与接口的实现无关。
下述代码片段展示了如何向OSGi服务注册表发布服务以及如何查找其他Bundle发布的服务:
public void start(BundleContext context) throws Exception {
//获取OSGi Log服务的服务引用
ServiceReference logSr = context.getServiceReference(LogService.class.getName());
//根据Log服务引用获取LogService服务实例
log = (LogService) context.getService(logSr);
//创建StringService接口服务实例
StringService ss = new StringServiceImpl(log);
//设定StringService的属性
Hashtable
//使用BundleContext注册发布StringService服务
context.registerService(StringService.class.getName(), ss, properties);
}
3.Bundle的开发实践
实践1、构建Utility类型的Bundle
该示例将第三方log4j工具包(版本为1.2.13)封装为OSGi Bundle组件。操作步骤如下:
•步骤一:在C盘根目录下创建名称为"org.apache.log4j"目录,将log4j.1.2.13.jar文件拷贝到该目录中;
•步骤二:在"org.apache.log4j"目录下构建META-INF目录,并在此目录下创建名称为"MANIFEST.MF"文件;
•步骤三:编辑"MANIFEST.MF"文件,在此文件中添加以下内容:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Apache Log4j
Bundle-SymbolicName: org.apache.log4j
Bundle-Version: 1.2.13
Bundle-ClassPath: .;log4j.1.2.13.jar
Export-Package: org.apache.log4j;version="1.2.13",
org.apache.log4j.config;version="1.2.13",
org.apache.log4j.helpers;version="1.2.13",
org.apache.log4j.jdbc;version="1.2.13",
org.apache.log4j.jmx;version="1.2.13",
org.apache.log4j.net;version="1.2.13",
org.apache.log4j.or;version="1.2.13",
org.apache.log4j.or.jms;version="1.2.13",
org.apache.log4j.or.sax;version="1.2.13",
org.apache.log4j.spi;version="1.2.13",
org.apache.log4j.varia;version="1.2.13",
org.apache.log4j.xml;version="1.2.13"
经过上述步骤后,名称为org.apache.log4j的OSGi Bundle已经构建完成。开发人员可以在其他Bundle中如同平常的开发模式一样引用Log4j的类包,获取Logger实例记录日志。
实践2、构建Service类型的Bundle
该示例Bundle由StringService接口,StringServiceImpl类和Activator类构成。该Bundle发布StringService接口服务,同时引用OSGi的标准LogService服务。
StringService接口是该示例Bundle发布的String服务实现接口。
package com.example;
public interface StringService {
String concat(String str1, String str2);
}
StringServiceImpl类是StringService接口的实现类,该类使用OSGi的标准LogService服务记录日志。
package com.example.internal;
import org.osgi.service.log.LogService;
import com.example.StringService;
public class StringServiceImpl implements StringService {
private LogService log;
public StringServiceImpl(LogService log) {
this.log = log;
}
public String concat(String str1, String str2) {
String str = str1 + str2;
if (log != null)
log.log(LogService.LOG_INFO, "Concat String Result is " + str);
return str;
}
}
Activator类为Bundle的生命周期入口,该类根据注入的BundleContext上下文获取OSGi LogService服务,然后注册StringService服务。
package com.example.internal;
import java.util.Hashtable;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.Constants;
import org.osgi.framework.ServiceReference;
import org.osgi.service.log.LogService;
import com.example.StringService;
public class Activator implements BundleActivator {
private LogService log;
public void start(BundleContext context) throws Exception {
//获取OSGi Log服务的服务引用
ServiceReference logSr = context.getServiceReference(LogService.class.getName());
//根据Log服务引用获取LogService服务实例
log = (LogService) context.getService(logSr);
//创建StringService接口服务实例
StringService ss = new StringServiceImpl(log);
//设定StringService的属性
Hashtable
//使用BundleContext注册发布StringService服务
context.registerService(StringService.class.getName(), ss, properties);
}
public void stop(BundleContext context) throws Exception {
}
}
Bundle的元数据清单如下:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Example Plug-in
Bundle-SymbolicName: com.example
Bundle-Version: 1.0.0
Bundle-Activator: com.example.internal.Activator
Bundle-Vendor: EGRID
Eclipse-LazyStart: true
Import-Package: org.osgi.framework;version="1.3.0",
org.osgi.service.log;version="1.3.0"
Export-Package: com.example
4. 结论
通过本文的探讨,开发人员可以明确在OSGi环境下进行Bundle开发时所要面临的一些决策及注意事项。下一篇文章我们将要详细探讨OSGi环境下Bundle编程的细节。本文中的点击此处下载。
分类: OSGi Architecture Design 2008-02-18 01:02 1286人阅读 评论(0) 收藏 举报
软件编程发展到今天可以看作是一个量变引发质变的过程。最初,程序开发面向过程,开发人员需要编写大量的过程代码,随着过程代码的不断积累(量变产 生),从代码维护和重用的角度,过程开发变得越来越不适应,质变产生,面向对象的开发逐渐被采用。由于面向对象的开发很好的封装了过程,而且从面向对象的 角度可以很好的描述实际应用中的需求模型,因此面向对象的开发逐渐成为主流。同样,随着面向对象开发的不断应用(量变产生),出现了大量的可复用的类及 包,维护这些类/包变得越来越困难,而且,尽管面向对象的编程机制可以很好的适应小规模应用的开发,但随着应用系统的规模越来越大,如同用细小的沙粒构建 堤坝,面向对象的机制难于适应,质变产生,面向组件的开发被引入开发过程。面向组件的开发目前仍可以认为是处于一种探索状态,目前还不存在一种统一的标准 可以遵循。
从另一个角度,历史是今天存在的基础,没有历史就没有今天。同样的道理,应用系统采用面向组件的开发实现,组件仍需要对象来构造,而对象在一定程度上是封 装的功能过程,三者相辅相成。不管是从上而下还是从下而上,应用系统需求模型在其实现过程中,系统设计者应该充分关注组件、对象和功能过程三个层面。
OSGi可以看作是面向组件开发的一种思路和基础环境。在OSGi环境中实现应用系统的需求模型要求开发人员对组件、对象开发具有充分的理解。衡量一个应 用系统实现好坏的标准之一是该系统是否是松耦合高内聚。面向对象的开发实现此目标的关键是接口/抽象的应用,OSGi面向组件的开发在此基础之上充分利用 了对象类包封装的机制。
1. Bundle的构建策略
通常,当我们构建应用系统时,我们需要充分重视所构建应用的业务需求模型即领域模型,同样的,在用软件代码实现业务需求模型时,我们也应当对软件系统的架 构模型给予充分的重视。采用OSGi技术实现应用系统时,展现在我们面前的将是一个个的Bundle组件,此时,我们必须首先弄清楚我们要构建什么样的 Bundle。
1.1 明确Bundle的构建需求及实现粒度
从需求模型的角度看,Bundle可以看作是需求模型中的一个功能模块实现,因此,在开发Bundle之前系统开发人员必须明确Bundle的功能需求。 需求模型中的功能模块的边界可大可小,同样,Bundle的实现粒度也是可大可小,极端情况下,小的Bundle可以仅实现一个微小的功能,大的 Bundle可以实现整个业务系统。
以记录日志为例,如果记录日志仅输出到控制台,则一个类就可以实现整个的功能,如果记录日志输出到数据库系统,则开发人员需要在整个功能用一个 Bundle实现,还是将日志记录功能和记录信息的数据库存储分为两个不同的Bundle实现,两个选择甚至更多的选择中做出决策。通常这个问题在现有的 软件开发方式中不需要过多的重视,但在OSGi开发中,开发人员必须根据需求确定Bundle的实现粒度。
1.2 确定Bundle的类型
我们在面向对象的系统开发过程中,经常会将一些通用的功能设计成为工具类,多个工具类封装为一个工具类包。由于OSGi开发建立在面向对象的开发之上, Bundle的开发也存在这种特点。OSGi开发的另一个特点是服务机制的引入,一个Bundle可以将其提供的功能发布成为一个或多个服务,供其他 Bundle查找使用。此外,建立在OSGi环境之上的组件开发也区别于通常的组件开发方式,因为我们可以利用OSGi环境提供的某些特性(参见下一节 充分利用OSGi环境的特性)。综上所述,我们可以将Bundle划分为如下几种类型(实际开发中,并不存在清晰的边界):
•Utility Bundle
这种Bundle与通常开发方式中的工具类或工具类包没有本质的区别,仅仅是将这些工具类发布到OSGi环境中,这些工具类也不依赖任何的OSGi环境或 特性。通常,这种Bundle特别适合目前存在的众多的第三方组件引入到OSGi环境中直接供OSGi开发人员使用。例如,我们可以将Apache开源项 目Log4j发布的工具包通过修改其META-INF目录下的MANIFEST.MF文件,添加Bundle的元数据信息就可以直接将其封装为可供 OSGi环境中其他Bundle使用的工具类Bundle。
•依赖OSGi特性的Bundle
这类Bundle可以被其他Bundle引用,为其提供功能,但是这类Bundle不能离开OSGi运行环境,否则不能使用。举例来说,一个提供数据缓存 功能的Bundle可能使用Bundle的数据存储区来缓存数据。Bundle的数据存储区的位置对Bundle开发者来说是透明的(参见下一节 充分利用OSGi环境的特性)。如果将该Bundle的数据缓存功能迁移到OSGi运行环境之外,则必须修改实现添加对缓存区位置的处理功能。
•引用和(或)发布OSGi服务的Bundle
这类Bundle也可以认为是依赖OSGi特性的Bundle,唯一的区别就是,该类Bundle充分利用的OSGi中服务的特性,引用其他Bundle 发布的服务和(或)向OSGi环境中发布自己的服务。OSGi环境提供的服务机制可以使得系统的实现遵循最大程度的松耦合。
1.3 隐藏Bundle的功能接口
组件开发除了应对系统的开发规模之外,其最重要的目标是降低系统耦合。开发人员采用OSGi Bundle开发时,应尽量屏蔽Bundle所提供功能的内部实现机制,仅将为其他Bundle提供的交互接口暴露出来。在OSGi中,这可以通过两种方 式,一种是通过Export供其他Bundle引用的类包;一种是向OSGi环境发布服务。
在Equinox中,Bundle内部实现的类包通常以"internal"标注,如org.eclipse.equinox.internal.cm.reliablefile。标注为"internal"的类包通常不包含在Export列表中,或者通过"x-internal"属性标记(该属性仅在Eclipse开发环境中提供)。
隐藏Bundle功能接口的一种良好机制是通过OSGi服务。开发人员仅将自己开发的Bundle的接口类包发布给其他Bundle可见,同时,将功能接 口的实现注册为OSGi中的服务,其他Bundle通过查找OSGi服务注册表获取该服务,通过服务的接口调用服务的功能。
1.4 尽可能应用OSGi提供的标准服务
OSGi联盟为一些经常用到的功能定义了标准服务,如应用程序管理服务,日志服务,事件服务,配置管理服务,用户管理服务,HTTP服务等等。如果开发人 员采用的OSGi环境提供了上述服务的实现,且这些服务实现满足系统的需求,则开发人员应尽可能使用这些服务,而不是为这些类似的功能定义自己的实现。
2.充分利用OSGi环境的特性
2.1 OSGi环境的动态特性
OSGi是一个动态的环境,OSGi运行环境内部状态的变化通过事件发布/监听机制进行交互。开发人员在构建Bundle时应充分利用OSGi环境的事件 监听机制。如,开发人员可以在自己的Bundle中注册Bundle事件的监听用来处理其他Bundle的安装,启动,停止,卸载等事件。
OSGi运行环境内部的事件主要包括三类:
•框架事件(FrameworkEvent)
STARTED 框架已经启动
ERROR 某个Bundle启动过程中引发错误
WARNING 某一Bundle引发一个警告
INFO 某一Bundle引发一个INFO类型的事件
PACKAGES_REFRESHED PackageAdmin.refreshPackage操作执行完成
STARTLEVEL_CHANGED StartLevel.setStartLevel操作执行完成
•Bundle事件(BundleEvent)
INSTALLED Bundle被安装到OSGi环境后系统发布该事件
RESOLVED Bundle被成功解析
LAZY_ACTIVATION Bundle将被延迟激活
STARTING Bundle正在被激活
STARTED Bundle被成功激活
STOPPING Bundle被停止
STOPPED Bundle正在被停止
UPDATED Bundle被更新
UNRESOLVED Bundle被UNRESOLVED
UNINSTALLED Bundle被卸载
•服务事件(ServiceEvent)
REGISTERED 服务被注册
MODIFIED 服务被修改
UNREGISTERING 服务正在被注销
关于上述事件的详细信息参考OSGi API文档。
下述代码展示了如何在Bundle组件中通过实现FrameworkListener,BundleListener和ServiceListener接口,并使用BundleContext注册监听OSGi环境的各种事件:
package com.example;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.BundleEvent;
import org.osgi.framework.BundleListener;
import org.osgi.framework.FrameworkEvent;
import org.osgi.framework.FrameworkListener;
import org.osgi.framework.ServiceEvent;
import org.osgi.framework.ServiceListener;
public class Activator implements BundleActivator, FrameworkListener,
BundleListener, ServiceListener {
public void start(BundleContext context) throws Exception {
//注册监听
context.addFrameworkListener(this);
context.addBundleListener(this);
context.addServiceListener(this);
}
public void stop(BundleContext context) throws Exception {
}
//处理框架事件
public void frameworkEvent(FrameworkEvent event) {
if ((event.getType() & FrameworkEvent.ERROR) != 0) {
System.err.println("Framework ERROR: " + event.getBundle());
}
}
//处理Bundle事件
public void bundleChanged(BundleEvent event) {
if ((event.getType() & BundleEvent.STARTED) != 0) {
System.err.println("Bundle STARTED: " + event.getBundle());
} else if ((event.getType() & BundleEvent.STOPPED) != 0) {
System.err.println("Bundle STOPPED: " + event.getBundle());
}
}
//处理服务事件
public void serviceChanged(ServiceEvent event) {
if ((event.getType() & ServiceEvent.REGISTERED) != 0) {
System.err.println("Service REGISTERED: "
+ event.getServiceReference());
}
}
}
2.2 Bundle的生命周期及OSGi上下文特性
在Java虚拟机运行环境中,类的生命周期开始于虚拟机的加载,终止于被提前卸载或虚拟机停止,通常不需要开发人员干预。在OSGi环境中,开发人员可以参与Bundle的生命周期过程并能够获取Bundle在OSGi环境中运行的上下文。
通过实现org.osgi.framework.BundleActivator接口,并在Bundle的元数据头属性"Bundle- Activator"中指明该接口的实现类,如"Bundle-Activator: com.example.Activator"。当Bundle被启动或停止时,OSGi框架会将该Bundle的运行上下文BundleContext 注入到该实现类实例中,开发人员可以在该Bundle的运行过程中使用该上下文访问OSGi环境信息,访问OSGi环境中的其他Bundle,注册事件监 听,发布或引用服务等。
下面的代码片段展示了如何利用Bundle运行上下文与OSGi环境进行交互:
public void start(BundleContext context) throws Exception {
// 获取OSGi环境中的所有安装的bundle
for (Bundle bundle : context.getBundles()) {
System.out.println("Bundle Symbolic Name: "
+ bundle.getSymbolicName());
}
// 获取OSGi运行环境中的属性(查找范围包括系统属性)
System.out.println("osgi.framework = "
+ context.getProperty("osgi.framework"));
//注册其他Bundle
context.installBundle("file:C://test_bundle_1.0.0.jar");
//在该Bundle的数据存储区中构建datacache.file文件
context.getDataFile("datacache.file");
//注册监听
context.addFrameworkListener(this);
context.addBundleListener(this);
context.addServiceListener(this);
}
2.3 Bundle的资源管理特性
在通常的应用系统开发中,开发人员通常要考虑配置文件的存储路径,系统临时文件的存储路径等信息。由于OSGi环境中Bundle实际上是由一组文件资源 构成,开发人员在开发Bundle时可以充分利用这种特点,使用Bundle存储与Bundle相关的配置信息。OSGi环境在运行时为每一个 Bundle构建一个序列化数据存储区,开发人员可以使用该存储区存储Bundle在运行时生成的临时信息。
下述代码片段展示了如何通过Bundle提供的功能接口获取Bundle内部的资源:
•context.getBundle.getEntry("") 只查询Bundle内部资源,返回Bundle的URL,该URL与实现相关,如:bundleentry://256/
•context.getBundle.getEntry("/") 只查询Bundle内部资源,返回Bundle的URL,该URL与实现相关
•context.getBundle.getEntry("/build.properties") 只查询Bundle内部资源,返回Bundle内部build.properties文件的URL,该URL与实现相关,如:bundleentry://256/build.properties
•context.getBundle().getResource("build.properties") 使用Bundle的ClassLoader查询Bundle类域内的资源,如果Bundle不能被解析(RESOLVED),则只查询Bundle内部资源,返回Bundle内部build.properties文件的URL,该URL与实现相关。
开发人员在获取上述资源的URL后,可以转换成与Bundle运行系统相关的文件URL,如:file:C:/test_bundle_1.0.0。
下述代码片段展示了通过BundleContext接口获取Bundle运行时数据存储区资源:
•context.getDataFile("") 返回该Bundle的运行时数据存储区位置,如:E:/worksapce/.metadata/.plugins/org.eclipse.pde.core/CobWeb/org.eclipse.osgi/bundles/256/data
•context.getDataFile("config.xml") 返回该Bundle的运行时数据存储区内的config.xml文件,如果该文件不存在,则创建该文件。
2.4 面向服务的组件特性
OSGi的服务层提供了一个动态服务发布,绑定和查找模型,所谓的服务即指实现了某个(些)接口的Java对象。在面向对象的系统开发中,接口在分离系统的耦合方面扮演至关重要的角色,OSGi环境充分利用了这一点。
OSGi运行框架维护着一个服务注册表,Bundle可以通过Bundle上下文向该服务注册表中发布服务(只需指明服务实现的接口,服务的实例和服务的 属性),也可以使用Bundle上下文从服务注册表中根据接口名称及服务的属性查找其他Bundle注册的服务。在此模式下,Bundle之间的耦合关系 只存在接口层面,而与接口的实现无关。
下述代码片段展示了如何向OSGi服务注册表发布服务以及如何查找其他Bundle发布的服务:
public void start(BundleContext context) throws Exception {
//获取OSGi Log服务的服务引用
ServiceReference logSr = context.getServiceReference(LogService.class.getName());
//根据Log服务引用获取LogService服务实例
log = (LogService) context.getService(logSr);
//创建StringService接口服务实例
StringService ss = new StringServiceImpl(log);
//设定StringService的属性
Hashtable
//使用BundleContext注册发布StringService服务
context.registerService(StringService.class.getName(), ss, properties);
}
3.Bundle的开发实践
实践1、构建Utility类型的Bundle
该示例将第三方log4j工具包(版本为1.2.13)封装为OSGi Bundle组件。操作步骤如下:
•步骤一:在C盘根目录下创建名称为"org.apache.log4j"目录,将log4j.1.2.13.jar文件拷贝到该目录中;
•步骤二:在"org.apache.log4j"目录下构建META-INF目录,并在此目录下创建名称为"MANIFEST.MF"文件;
•步骤三:编辑"MANIFEST.MF"文件,在此文件中添加以下内容:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Apache Log4j
Bundle-SymbolicName: org.apache.log4j
Bundle-Version: 1.2.13
Bundle-ClassPath: .;log4j.1.2.13.jar
Export-Package: org.apache.log4j;version="1.2.13",
org.apache.log4j.config;version="1.2.13",
org.apache.log4j.helpers;version="1.2.13",
org.apache.log4j.jdbc;version="1.2.13",
org.apache.log4j.jmx;version="1.2.13",
org.apache.log4j.net;version="1.2.13",
org.apache.log4j.or;version="1.2.13",
org.apache.log4j.or.jms;version="1.2.13",
org.apache.log4j.or.sax;version="1.2.13",
org.apache.log4j.spi;version="1.2.13",
org.apache.log4j.varia;version="1.2.13",
org.apache.log4j.xml;version="1.2.13"
经过上述步骤后,名称为org.apache.log4j的OSGi Bundle已经构建完成。开发人员可以在其他Bundle中如同平常的开发模式一样引用Log4j的类包,获取Logger实例记录日志。
实践2、构建Service类型的Bundle
该示例Bundle由StringService接口,StringServiceImpl类和Activator类构成。该Bundle发布StringService接口服务,同时引用OSGi的标准LogService服务。
StringService接口是该示例Bundle发布的String服务实现接口。
package com.example;
public interface StringService {
String concat(String str1, String str2);
}
StringServiceImpl类是StringService接口的实现类,该类使用OSGi的标准LogService服务记录日志。
package com.example.internal;
import org.osgi.service.log.LogService;
import com.example.StringService;
public class StringServiceImpl implements StringService {
private LogService log;
public StringServiceImpl(LogService log) {
this.log = log;
}
public String concat(String str1, String str2) {
String str = str1 + str2;
if (log != null)
log.log(LogService.LOG_INFO, "Concat String Result is " + str);
return str;
}
}
Activator类为Bundle的生命周期入口,该类根据注入的BundleContext上下文获取OSGi LogService服务,然后注册StringService服务。
package com.example.internal;
import java.util.Hashtable;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.Constants;
import org.osgi.framework.ServiceReference;
import org.osgi.service.log.LogService;
import com.example.StringService;
public class Activator implements BundleActivator {
private LogService log;
public void start(BundleContext context) throws Exception {
//获取OSGi Log服务的服务引用
ServiceReference logSr = context.getServiceReference(LogService.class.getName());
//根据Log服务引用获取LogService服务实例
log = (LogService) context.getService(logSr);
//创建StringService接口服务实例
StringService ss = new StringServiceImpl(log);
//设定StringService的属性
Hashtable
//使用BundleContext注册发布StringService服务
context.registerService(StringService.class.getName(), ss, properties);
}
public void stop(BundleContext context) throws Exception {
}
}
Bundle的元数据清单如下:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Example Plug-in
Bundle-SymbolicName: com.example
Bundle-Version: 1.0.0
Bundle-Activator: com.example.internal.Activator
Bundle-Vendor: EGRID
Eclipse-LazyStart: true
Import-Package: org.osgi.framework;version="1.3.0",
org.osgi.service.log;version="1.3.0"
Export-Package: com.example
4. 结论
通过本文的探讨,开发人员可以明确在OSGi环境下进行Bundle开发时所要面临的一些决策及注意事项。下一篇文章我们将要详细探讨OSGi环境下Bundle编程的细节。本文中的点击此处下载。