OSGi3. 大纲 OSGi介绍 OSGi实现框架 扩展Equinox Equinox高级实战 分布式OSGi 8. Bundle类隔离机制 Java ClassLoader机制 类由ClassLoader来实现加载,Java动态化实现的基础; 默认情况下有BootStrapClassLoader(jre/lib、jre/classes)、Extension ClassLoader(jre/lib/ext)以及System ClassLoader(-classpath指定)三个级别的ClassLoader; 应用可自行实现ClassLoader以动态的加载类,或加载相应目录下的类; 11. Bundle类共享机制 Bundle类加载过程 java.*委派给parent classloader加载; bootdelegation参数中配置的也委派给parent classloader加载,在parent classloader中未找到也继续下面的步骤; 是否在Import-Package中,在则委派给Export-Package的bundle的classloader; 是否在Require-Bundle中,在则委派给相应的Bundle ClassLoader,未找到则继续下面步骤; 在Bundle-Classpath中寻找,未找到则继续下面的步骤; 在fragments bundle的classpath中寻找,未找到则继续下面的步骤; 是否在Export-Package中,未找到则继续下面的步骤; 是否在DynamicImport-Package中,在则委派给相应的Bundle ClassLoader寻找,不在则抛出ClassNotFound异常。 16. Bundle生命周期 Resolve Bundle时要做的事情 寻找Bundle中所需依赖的包或Bundle是否存在以及被resolve,包括寻找匹配的import-package、require-bundle等,如寻找到则进入检查,检查完冲突后形成绑定关系,以便加载类时能直接加载; 冲突示例 A Bundle依赖org.osgiusers.china.demo;version=1.0.0,org.osgiusers.china.user;version=2.0.0; B Bundle提供了org.osgiusers.china.demo;version=1.0.0,但同时import了org.osgiusers.china.user;version=1.1.0 如成功,则将Bundle状态置为RESOLVED。 18. Bundle生命周期 Stop Bundle时要做的事情 卸载当前Bundle对外提供的所有OSGi Service,并释放当前Bundle引用的所有OSGi Service; 调用MANIFEST.MF中对应的Bundle-Activator的类的stop方法; 将Bundle状态置为RESOLVED。 19. Bundle生命周期 Uninstall Bundle时要做的事情 检查Bundle状态,如状态为ACTIVE,则先STOP; 释放Bundle对其他Bundle的类依赖; 如当前Bundle中有其他Bundle的类依赖,则进行记录,如没有则释放该Bundle的ClassLoader; 将当前Bundle的状态置为UNINSTALLED。 22. Bundle交互 Service registry packages packages 直接类访问的方式(不推荐),结合上面之前的Bundle生命周期的介绍,为什么?; Service交互方式 直接通过BundleContext.getServiceReference以及BundleContext.registerService这样的方式(使用不方便,不推荐); Declarative Services方式,类似IoC type 2; OSGi Framework Bundle Bundle JAVA Operating System Hardware 23. Bundle交互 Declarative Services(简称DS) Service-Oriented Component Model 需要对外提供的功能均定义为接口; 接口的实现定义以XML方式定义为Component; 按接口的方式访问其他Bundle的功能; 以XML方式定义对其他Bundle的功能的访问; Component也是有生命周期的。 OSGi R4.0的重大改进就是这点! 25. Bundle交互 提供服务关键配置 provide interface,声明对外提供的接口; property,可增加一些服务实现的关键词,以便匹配过滤,例如<property name=“KEY” value=“DB”/> 调用服务关键配置 cardinality 配置调用服务的数量,例如0..1、1..n、0..n; policy 配置引用的服务变化时的策略,主要有static和dynamic这两种; target 配置引用的服务的过滤,例如target=“(KEY=DB)”,这样即使有多个提供了接口的服务,也只会注入配置了KEY=DB的这个; 26. Bundle交互 DS 1.1的可喜变化 Service-Component后指定的文件可用通配符,例如:Service-Component: OSGi-INF/*.xml 可以配置activate和deactivate方法,并且提供了多种方法签名的支持; bind、unbind方法加了两种签名的支持; void <method-name>(ServiceReference) void <method-name>(<parameter-type>,Map) 增加的这个方法签名至关重要,尤其是对于按服务属性来选择服务的场景而言。 28. Bundle交互 Component生命周期 当有Bundle启动时,会触发Declarative services的介入,以将其中的Service-Component对应的配置文件的Component载入; 当有Bundle通过BundleContext直接注册服务时,也将触发Declarative Services,以检查是否有Component可被激活; 当有Bundle STOP时,也会触发DS的介入,以将相关的OSGi Service卸载和释放,并检查相关的Component是否要被销毁; 如何做到引用的服务更新了,但当前Component并不会重新创建实例? 29. R 4.2将会带来的变化 Launch Framework API 这个API的引入就意味着以后可以以一种统一的方式在程序中启动OSGi Framework了,示例如下: Map p=new HashMap(); p.put(“org.osgi.framework.storage”,System.getProperties(“user.home”)+File.separator+”osgi”); FrameworkFactory factory=Class.forName(factoryClassName).newInstance(); Framework framework=factory.newFramework(p); framework.init(); BundleContext context=framework.getBundleContext(); …//安装Bundles framework.start(); framework.waitForStop(); 30. OSGi提供的服务 Http Service 以便支持简单的通过http访问OSGi应用; 但复杂的场景还是比较难支撑,这主要是由于目前还只有jetty实现的HttpService,再加上它所支持的Servlet版本太低,这也导致了目前OSGi对于Web类型的应用而言支持不足,但可喜的是RFC 66会带来很多变化; Log Service 支持简单的日志记录,直接输出到console,不过可以结合log4j自行实现; EventAdmin Service 基于此可实现事件通知性质的功能; ConfigurationAdmin Service 基于此可实现配置信息的动态管理。 31. OSGi对模块化、动态化的满足程度 模块化 完全满足。 动态化 能够动态的增加、删除或更新模块,并完成依赖的OSGi Service的引用迁移; 但要自行处理由此带来的模块中对象的状态保持和恢复的问题,因此基于OSGi了,并不就代表应用一定可动态了,要合理的基于Bundle生命周期改变和Component生命周期改变会带来的变化做相应的处理。 33. OSGi实现框架 Equinox Equinox是R 4.0的RI,并且也是Eclipse的核心,可谓是久经考验,Spring-DM也是基于Equinox。 Felix Felix作为后起之秀,表现算得上是非常突出了。 其他 Oscar、Knoperfish已是昨日黄花了; 35. OSGi实现框架 Equinox中的类加载顺序 根据启动时的bootdelegation属性判断是否需要从parent classloader中加载,具体parent classloader是哪个,则可以通过osgi.parentClassLoader属性来指定,支持的为:app(SystemClassLoader)、ext(Extension ClassLoader)和fwk(Equinox ClassLoader)三种; 调用Equinox的ClassLoaderDelegateHook的preFindClass来加载; 从Import-Package中寻找; 从Require-Bundle中寻找; 尝试从当前Bundle中加载; 尝试从DynamicImport-Package中加载; 调用Equinox的ClassLoaderDelegateHook的postFindClass来加载; 尝试使用Eclipse的buddy机制来加载; 对比规范而言,Equinox除了增加了Hook机制以及buddy机制外,完全遵守OSGi规范。 36. OSGi实现框架 Equinox Install Bundle 按照提供的Bundle文件加载流,并根据MANIFEST.MF的信息形成Bundle对象,并将Bundle的状态置为INSTALLED; 对外广播Bundle INSTALLED事件。 37. OSGi实现框架 Equinox Resolve Bundle 如bundle为singleton,则首先检查singletons bundle是否已存在,如存在则resolve失败; 对所依赖的package进行寻找、检查和绑定; 寻找require-bundle、import-package匹配的bundle; 检查这些bundle之间是否有冲突,尽可能的选择没有冲突的bundle; 绑定通过检查的bundle,以便在加载类时可直接去这些bundle中寻找。 将Bundle状态设置为RESOLVED。 38. OSGi实现框架 Equinox Start Bundle 检查状态是否为RESOLVED,如未resolve则先进行resolve动作,resolve失败则直接抛出异常,成功则继续下面步骤; 调用MANIFEST.MF中配置的bundle-activator对应的类的start方法。 将Bundle状态置为ACTIVE。 39. OSGi实现框架 Equinox Stop Bundle 注销发布的OSGi服务以及释放对其他OSGi服务的引用; 调用MANIFEST.MF中配置的bundle-activator的类的stop方法; 将Bundle状态置为RESOLVED。 40. OSGi实现框架 Equinox Uninstall Bundle 如Bundle为Active,先停止Bundle; 检查是否有其他Bundle依赖了当前Bundle的package,如有则先不关闭此bundle的classloader,如没有则关闭; 将Bundle状态置为UNINSTALLED。 41. OSGi实现框架 Equinox Update Bundle 如状态为ACTIVE,先停止; 创建新的Bundle对象,如有Bundle依赖老版本的Bundle,则暂时将老版本的Bundle放入removalPendings中,如没有,则清除老版本Bundle的所有信息; 恢复新版本的Bundle到更新前的状态。 43. OSGi实现框架 Equinox DS在这些过程中的处理 Start Bundle时 扫描MANIFEST.MF中对应的Service-Component指定的文件,加载这些文件; 判断其中指定的Component是否符合激活条件,如符合,则激活并调用activate方法,对于提供了OSGi Service的Component,则注册此OSGi Service; Stop Bundle时 不做任何动作; 有服务注册时 寻找当前的Component是否有可激活的,如有则进行激活; 寻找当前已激活的Component中是否有需要此OSGi Service的,如有则调用其bind-method进行注入; 有服务注销时 对于依赖了此OSGi Service的component,调用其unbind-method; 检查是否有Component因此不到激活条件的,则尝试调用Component的deactivate方法并销毁Component的实例。 46. OSGi实现框架 Felix Install Bundle 解析Bundle的MANIFEST.MF文件,读取OSGi标准中定义的头信息; 检查Bundle的唯一性,如不唯一则抛出异常; 将Bundle状态置为INSTALLED。 47. OSGi实现框架 Felix Resolve Bundle 寻找需要依赖的Package或Bundle,并将其中未resolve的Bundle进行resolve,如resolve失败,则将其从潜在的Bundle列表中删除,这步完全遵循OSGi规范; 检查是否有符合条件的Bundle,如没有,则抛出异常,有则继续; 检查这些符合条件的潜在的Bundle,如多个同名称的单态Bundle、版本冲突等问题,如这些问题均不存在,则继续下面的步骤; 完成绑定。 48. OSGi实现框架 Felix Start Bundle 检查Bundle状态,如未resolve则先resolve; 执行MANIFEST.MF中对应的Bundle-Activator配置的类的start方法,如未配置则跳过此步; 将Bundle状态设置为ACTIVE; 49. OSGi实现框架 Felix Stop Bundle 执行MANIFEST.MF中对应的Bundle-Activator配置的类的stop方法,如未配置则跳过此步; 注销Bundle对外发布的Service; 释放Bundle引用的Service; 50. OSGi实现框架 Felix Uninstall Bundle 检查状态,如为ACTIVE,则先停止; 如有其他Bundle引用了当前Bundle的package,则将当前Bundle的RemovalPending设置为true; 将Bundle状态设置为UNINSTALLED; 如未被其他Bundle使用,则对当前Bundle执行refresh动作; 52. OSGi实现框架 Felix Refresh 在指定Bundle的情况下,递归找到依赖当前Bundle提供的package的Bundle,作为此次refresh动作需要操作的Bundles;在未指定Bundle的情况下,则将已卸载的且RemovalPending为true的Bundles,以及还未resolve的Bundle作为此次需要操作的Bundles; refresh负责将需要uninstall的Bundle对外export的package彻底关闭,并对需要依赖这些package的bundle执行STOP动作; 对于不需要Uninstall但在refresh动作范畴的bundles恢复为之前的状态。 53. OSGi实现框架 Felix DS在这些过程中的处理 和Equinox基本一致; 但值得注意的是Felix DS 1.0.8对于policy=dynamic、cardinality=“0..1” | “0..n”这类依赖服务变更时的处理有个bug,会造成在依赖的服务更新后出现需要此服务的Component拿不到服务引用的现象。 56. 扩展Equinox 在外部程序中启动Equinox 示例 // 配置Equinox的启动 FrameworkProperties.setProperty("osgi.noShutdown", "true"); FrameworkProperties.setProperty("eclipse.ignoreApp", "true"); FrameworkProperties.setProperty("osgi.bundles.defaultStartLevel", "4"); FrameworkProperties.setProperty("osgi.bundles", "// 指定需要装载的Bundle的路径"); // 指定需要加载的bundles所在的目录 FrameworkProperties.setProperty("osgi.syspath", "// 例如plugins"); EclipseStarter.run(new String[]{"-configuration","configuration","-console"}, null); // 通过EclipeStarter获取到BundleContext context=EclipseStarter.getSystemBundleContext(); 到了R 4.2后就可以遵循标准的API来启动了 61. 扩展Equinox 注册Hook类的方法 属性中指定 在启动时指定osgi.hook.configurators,但要注意的是要加上目前Equinox所需的hooks配置,格式为: hook.configurators=hook类名,hook类名 此文件需要放在Equinox框架的classpath下; 配置文件中指定 增加一个hookconfigurators.properties,其中的格式为: hook.configurators=hook类名,hook类名 65. Equinox高级实战 将非DS的应用迁移为DS方式 迁移的方法 将之前直接类的调用方式改为基于接口的方式,这也将对动态化的实现更为有利; 将接口放入一个独立的Bundle中,也是为了动态化; 将注册服务的代码去掉,改为通过编写xml文件来注册服务; 将调用服务时依赖BundleContext获取的方式去掉,改为set注入的方式,并通过unset来感知服务的注销; 编写XML文件来定义需要调用的OSGi Service; 最后就是在运行的Bundle中增加DS实现的Bundle。 67. Equinox高级实战 将非DS的应用迁移为DS方式 DS的四种经典用法 set注入单个依赖的服务; <reference name=… interface=… bind=… unbind=… policy=…/> set注入单个指定标识的依赖的服务; <reference name=… interface=… bind=… unbind=… policy=… target=“(key=DB)”/> set注入多个依赖的服务,在调用时进行全调用,类似filter chain或hook; <reference name=… interface=… bind=… unbind=… policy=… cardinality=“0..n”/> set注入多个依赖的服务,调用时根据某标识来调用其中的一个服务,实现类似的Factory机制; <reference name=… interface=… bind=… unbind=… policy=… cardinality=“0..n”/> set方法签名则改为void <method-name>(interface,Map) (必须是DS 1.1+) 从上面四种用法来看,DS甚至强于了现在所有的IoC容器。 68. Equinox高级实战 经常会碰到的一些问题 ClassNotFoundException 几乎是所有使用OSGi的人都会经常碰到的问题; 解决的方法是掌握Bundle Class的加载方式; ClassCastException 几乎是所有使用OSGi的人都会经常碰到的问题; 解决的方法是掌握ClassLoader的基本原理以及Bundle Class的加载方式; OSGi Component没启动 这是比较麻烦的问题; 解决的方法首先是掌握OSGi Component的激活条件; 然后是通过OSGi Console,查看log,或仔细检查Component .xml的配置; 70. 分布式OSGi 你所期望的? 我所期望的 透明的将OSGi服务发布为可远程调用的服务; 透明的调用远程的OSGi服务; OSGi服务的动态化感知不是必须的 由于这受限于网络等各种因素,而且如果服务有多级调用的话就会出现类似的雪崩效应; 73. 分布式OSGi R-OSGi 能达到的效果 透明的将OSGi Service对外发布; 只需要在注册OSGi Service时加上properties.put(RemoteOSGiService.R_OSGi_REGISTRATION, Boolean.TRUE); 属性 透明的调用远程的OSGi Service; 只需获取RemoteOSGiService,然后就可以调用远程的OSGi Service; 由于调用时基于的是TCP/IP,例如其提供了基于mina的调用,因此性能还是不错的; 可基于jSLP实现Service Discovery,从而更加简单的找到需要调用的远程OSGi Service。 74. 分布式OSGi R-OSGi 实现机制 监听了服务注册事件,当有服务注册时,检查其注册的属性,如属性中有RemoteOSGiService.R_OSGi_REGISTRATION,并且值为true,那么则做一个服务接口名与此服务的映射,并将此映射作为tcp/ip某端口的处理器集合。 对于客户端,当通过RemoteOSGiService拿到引用时,为一个服务端调用的代理,当调用此引用的方法时,即代理访问到远端服务器,过程即为一个类似的自定义的java远程RPC。 75. 分布式OSGi CXF DOSGi 能达到的效果 透明的将OSGi Service对外发布; 只需在注册服务时增加如下属性即可: props.put("osgi.remote.interfaces", "*"); props.put("osgi.remote.configuration.type", "pojo"); props.put("osgi.remote.configuration.pojo.address", WebService URL); 透明的调用远程OSGi Service 增加一个remote-services.xml,按照格式描述所需调用的远程OSGi Service; 调用时直接以接口的方式调用远程OSGi Service即可,完全透明; 从这点对比而言,CXF DOSGi要强于R-OSGi,毕竟R-OSGi的完全透明还是需要做点包装的。 76. 分布式OSGi CXF DOSGi 实现机制 监听服务注册事件,当注册时有相应的属性时,则将其发布为Webservice; 对于客户端,则通过扫描相应的service-description的描述来生成一个调用远程Webservice的代理,并将此代理注册为相应的OSGi Service。