OSGi理论和实战BlueDavyhttp://china.osgiusers.org09.09.15

目标学习OSGi规范 R4.1，掌握OSGi核心概念；学习OSGi R4实现框架的实现机制，以更好的使用这些框架；学习基于Equinox开发OSGi Based的应用；扩展Equinox，更好的基于Equinox来开发各类应用；学习分布式OSGi；

大纲OSGi介绍 OSGi实现框架扩展EquinoxEquinox高级实战分布式OSGi

1、OSGi介绍在OSGi中，模块是什么？模块之间的类是如何做到隔离的？怎么访问其他模块中的类？模块的生命周期是怎么样的？模块之间怎么交互？OSGi提供了哪些常用的Service？

我期望的模块化、动态化模块化（Java 7中最重要的Feature）独立，不受其他模块的影响；其他模块只能访问该模块对外提供的功能；模块具备独立的生命周期，例如启动、停止、更新等。动态化能动态的增加、更新或删除模块，而对于模块来说不需要做额外的处理；你期望中的？

OSGi是什么一个标准，基于此标准实现的框架可轻松的构建模块化、动态化的系统；Dynamic Module System For Java；JSR 232、JSR 291；众多Java Application Server（Weblogic、Glassfish等）所选择的底层框架；

BundleBundle是OSGi中部署的最小单位，因此可以认为Bundle就是模块；Bundle就是一个普通的jar包，只是其在MANIFEST.MF中加入了一些特殊的头信息，例如Bundle-Name；

Bundle类隔离机制Java ClassLoader机制类由ClassLoader来实现加载，Java动态化实现的基础；默认情况下有BootStrapClassLoader(jre/lib、jre/classes)、Extension ClassLoader(jre/lib/ext)以及System ClassLoader(-classpath指定)三个级别的ClassLoader；应用可自行实现ClassLoader以动态的加载类，或加载相应目录下的类；

Bundle类隔离机制每个Bundle均为独立的ClassLoader，典型的Bundle的ClassLoader结构如下所示：

Bundle类共享机制Java经典的Delegation模型在寻找类时首先从parent classloader中寻找，如找不到才在当前classloader中寻找；

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异常。

Bundle类共享机制因此可以通过在MANIFEST.MF中定义Require-Bundle、Import-Package、Export-Package以及DynamicImport-Package来实现类共享；Import-Package: org.osgiusers.china.demoExport-Package: org.osgiusers.china.demoDynamicImport-Package: org.osgiusers.*注意：OSGi支持包的版本的定义！Import-Package: org.osgiusers.china.demo;version=“[1.0,2.0)”

Bundle类共享机制Import-Package寻找机制比较提供了相应package的Bundle的状态，resolved优先于未resolved的；如均为resolved的bundle，则比较package的版本，默认package版本为0.0.0，版本高的优先于版本低的；如版本也一样，则比较bundle id，bundle id小的优先于大的，也就是先安装的bundle优先。

Bundle生命周期OSGi按照下面的状态转换方式来管理Bundle的生命周期；可通过OSGi提供的API来主动改变Bundle的生命周期。BundleContext.installBundleBundle.startBundle.updateBundle.stopBundle.uninstallBundle生命周期改变时所做的动作将直接影响动态化。INSTALLEDSTARTINGstartRESOLVEDACTIVEstopUNINSTALLEDSTOPPING

Bundle生命周期Install Bundle时要做的事情解析Bundle的MANIFEST.MF信息，判断格式是否符合标准以及是否存在相同的Bundle；分配新的Bundle ID后；生成Bundle对象，并放入已安装的Bundles集合中，状态置为INSTALLED。

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。

Bundle生命周期Start Bundle时要做的事情检查Bundle的状态，如未Resolve，则先Resolve；寻找MANIFEST.MF中配置的Bundle-Activator，如寻找到，则调用其start方法；将Bundle状态标识为ACTIVE。

Bundle生命周期Stop Bundle时要做的事情卸载当前Bundle对外提供的所有OSGi Service，并释放当前Bundle引用的所有OSGi Service；调用MANIFEST.MF中对应的Bundle-Activator的类的stop方法；将Bundle状态置为RESOLVED。

Bundle生命周期Uninstall Bundle时要做的事情检查Bundle状态，如状态为ACTIVE，则先STOP；释放Bundle对其他Bundle的类依赖；如当前Bundle中有其他Bundle的类依赖，则进行记录，如没有则释放该Bundle的ClassLoader；将当前Bundle的状态置为UNINSTALLED。

Bundle生命周期Update Bundle时要做的事情首先停止当前Bundle；重新安装并RESOLVE Bundle；恢复到Bundle更新之前的状态。

Bundle生命周期总结除了DynamicImport-Package外，其他的Package引用哪个Bundle在Resolve时就已经决定了；如希望更新Bundle所引用到的类，则必须进行refresh动作；但refresh动作也只对目前处于unresolve状态的以及之前uninstall时还有其他bundle类依赖的Bundle进行unresolve动作，并重新resolve对他们有依赖的bundle。从上可见，当Bundle有Start动作时，有可能会造成有Bundle的ClassLoader建立成功，当发生Refresh动作时，有可能会造成某些Bundle Resolve失败，也有可能造成某些Bundle重建ClassLoader。

Bundle交互Serviceregistrypackagespackages直接类访问的方式（不推荐），结合上面之前的Bundle生命周期的介绍，为什么？；Service交互方式直接通过BundleContext.getServiceReference以及BundleContext.registerService这样的方式（使用不方便，不推荐）；Declarative Services方式，类似IoC type 2；OSGi FrameworkBundleBundleJAVAOperating SystemHardware

Bundle交互Declarative Services（简称DS）Service-Oriented Component Model需要对外提供的功能均定义为接口；接口的实现定义以XML方式定义为Component；按接口的方式访问其他Bundle的功能；以XML方式定义对其他Bundle的功能的访问；Component也是有生命周期的。OSGi R4.0的重大改进就是这点！

Bundle交互对外提供服务示例调用其他Bundle的服务示例

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的这个；

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)增加的这个方法签名至关重要，尤其是对于按服务属性来选择服务的场景而言。

Bundle交互Component生命周期如Component有对外提供服务，在没有其他Component需要此服务时，这个Component是不会被激活的，只有当有其他Component需要此服务，且当前Component所需的服务均满足条件时，才会被激活；如Component没有对外提供服务，那么只要此Component所需依赖的服务均可用，则会被激活。

Bundle交互Component生命周期当有Bundle启动时，会触发Declarative services的介入，以将其中的Service-Component对应的配置文件的Component载入；当有Bundle通过BundleContext直接注册服务时，也将触发Declarative Services，以检查是否有Component可被激活；当有Bundle STOP时，也会触发DS的介入，以将相关的OSGi Service卸载和释放，并检查相关的Component是否要被销毁；如何做到引用的服务更新了，但当前Component并不会重新创建实例？

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(); …//安装Bundlesframework.start();framework.waitForStop();

OSGi提供的服务Http Service以便支持简单的通过http访问OSGi应用；但复杂的场景还是比较难支撑，这主要是由于目前还只有jetty实现的HttpService，再加上它所支持的Servlet版本太低，这也导致了目前OSGi对于Web类型的应用而言支持不足，但可喜的是RFC 66会带来很多变化；Log Service支持简单的日志记录，直接输出到console，不过可以结合log4j自行实现；EventAdmin Service基于此可实现事件通知性质的功能；ConfigurationAdmin Service基于此可实现配置信息的动态管理。

OSGi对模块化、动态化的满足程度模块化完全满足。动态化能够动态的增加、删除或更新模块，并完成依赖的OSGi Service的引用迁移；但要自行处理由此带来的模块中对象的状态保持和恢复的问题，因此基于OSGi了，并不就代表应用一定可动态了，要合理的基于Bundle生命周期改变和Component生命周期改变会带来的变化做相应的处理。

2、OSGi实现框架有哪些实现框架？它们是如何实现OSGi规范的？它们是否遵循OSGi标准？对比而言，谁更有优势？

OSGi实现框架EquinoxEquinox是R 4.0的RI，并且也是Eclipse的核心，可谓是久经考验，Spring-DM也是基于Equinox。FelixFelix作为后起之秀，表现算得上是非常突出了。其他Oscar、Knoperfish已是昨日黄花了；

OSGi实现框架EquinoxEquinox的ClassLoader结构

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规范。

OSGi实现框架EquinoxInstall Bundle按照提供的Bundle文件加载流，并根据MANIFEST.MF的信息形成Bundle对象，并将Bundle的状态置为INSTALLED；对外广播Bundle INSTALLED事件。

OSGi实现框架EquinoxResolve Bundle如bundle为singleton，则首先检查singletons bundle是否已存在，如存在则resolve失败；对所依赖的package进行寻找、检查和绑定；寻找require-bundle、import-package匹配的bundle；检查这些bundle之间是否有冲突，尽可能的选择没有冲突的bundle；绑定通过检查的bundle，以便在加载类时可直接去这些bundle中寻找。将Bundle状态设置为RESOLVED。

OSGi实现框架EquinoxStart Bundle检查状态是否为RESOLVED，如未resolve则先进行resolve动作，resolve失败则直接抛出异常，成功则继续下面步骤；调用MANIFEST.MF中配置的bundle-activator对应的类的start方法。将Bundle状态置为ACTIVE。

OSGi实现框架EquinoxStop Bundle注销发布的OSGi服务以及释放对其他OSGi服务的引用；调用MANIFEST.MF中配置的bundle-activator的类的stop方法；将Bundle状态置为RESOLVED。

OSGi实现框架EquinoxUninstall Bundle如Bundle为Active，先停止Bundle；检查是否有其他Bundle依赖了当前Bundle的package，如有则先不关闭此bundle的classloader，如没有则关闭；将Bundle状态置为UNINSTALLED。

OSGi实现框架EquinoxUpdate Bundle如状态为ACTIVE，先停止；创建新的Bundle对象，如有Bundle依赖老版本的Bundle，则暂时将老版本的Bundle放入removalPendings中，如没有，则清除老版本Bundle的所有信息；恢复新版本的Bundle到更新前的状态。

OSGi实现框架Refresh找到所有removalPendings中的bundle，unresolve这些bundle，并重新resolve依赖了这些bundle的bundle；恢复重新resolve了的bundle的状态。

OSGi实现框架EquinoxDS在这些过程中的处理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的实例。

OSGi实现框架FelixFelix的ClassLoader结构

OSGi实现框架Felix中的类加载顺序判断是否为bootdelegation中配置的package，如交由Felix ClassLoader进行加载；尝试从Import-Package中加载，如在则交由相应的Bundle ClassLoader去加载，即使加载不到也继续下面的步骤；尝试从当前Bundle的Classpath中加载；尝试从DynamicImport-Package中加载；从上面步骤来看，Felix在Import-Package时这步上未遵循OSGi规范，这有些时候可能会造成一些问题。

OSGi实现框架FelixInstall Bundle解析Bundle的MANIFEST.MF文件，读取OSGi标准中定义的头信息；检查Bundle的唯一性，如不唯一则抛出异常；将Bundle状态置为INSTALLED。

OSGi实现框架FelixResolve Bundle寻找需要依赖的Package或Bundle，并将其中未resolve的Bundle进行resolve，如resolve失败，则将其从潜在的Bundle列表中删除，这步完全遵循OSGi规范；检查是否有符合条件的Bundle，如没有，则抛出异常，有则继续；检查这些符合条件的潜在的Bundle，如多个同名称的单态Bundle、版本冲突等问题，如这些问题均不存在，则继续下面的步骤；完成绑定。

OSGi实现框架FelixStart Bundle检查Bundle状态，如未resolve则先resolve；执行MANIFEST.MF中对应的Bundle-Activator配置的类的start方法，如未配置则跳过此步；将Bundle状态设置为ACTIVE；

OSGi实现框架FelixStop Bundle执行MANIFEST.MF中对应的Bundle-Activator配置的类的stop方法，如未配置则跳过此步；注销Bundle对外发布的Service；释放Bundle引用的Service；

OSGi实现框架FelixUninstall Bundle检查状态，如为ACTIVE，则先停止；如有其他Bundle引用了当前Bundle的package，则将当前Bundle的RemovalPending设置为true；将Bundle状态设置为UNINSTALLED；如未被其他Bundle使用，则对当前Bundle执行refresh动作；

OSGi实现框架FelixUpdate Bundle停止当前的Bundle；重新读取并解析Bundle流，将Bundle状态置为INSTALLED；恢复Bundle到更新前的状态。

OSGi实现框架FelixRefresh在指定Bundle的情况下，递归找到依赖当前Bundle提供的package的Bundle，作为此次refresh动作需要操作的Bundles；在未指定Bundle的情况下，则将已卸载的且RemovalPending为true的Bundles，以及还未resolve的Bundle作为此次需要操作的Bundles；refresh负责将需要uninstall的Bundle对外export的package彻底关闭，并对需要依赖这些package的bundle执行STOP动作；对于不需要Uninstall但在refresh动作范畴的bundles恢复为之前的状态。

OSGi实现框架FelixDS在这些过程中的处理和Equinox基本一致；但值得注意的是Felix DS 1.0.8对于policy=dynamic、cardinality=“0..1” | “0..n”这类依赖服务变更时的处理有个bug，会造成在依赖的服务更新后出现需要此服务的Component拿不到服务引用的现象。

OSGi实现框架对比

3、扩展Equinox如何在外部程序中启动Equinox？是否可以对Equinox进行扩展？如可以扩展，应如何做？

扩展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来启动了

扩展EquinoxEquinox中可用的扩展ClassLoadingHookClassLoaderDelegateHookClassLoadingStatsHookAdaptorHook借助这些扩展可以更好的控制Equinox。

扩展EquinoxClassLoadingHook可用于拦截Bundle ClassLoader的创建、类的处理、Classpath的处理等；ClassLoaderDelegateHook可用于在某个阶段干预类的加载，例如在类从Import-Package中扫描之前或在DynamicImport-Package扫描之后。

ClassLoaderDelegateHook

可用于在某个阶段干预类的加载，例如在类从Import-Package中扫描之前或在DynamicImport-Package扫描之后。

扩展EquinoxClassLoadingStatsHook可用于拦截类从Bundle-Classpath中加载的动作，包括加载之前以及加载之后。AdaptorHook可用于拦截BaseAdaptor的创建过程，例如在初始化时、framework启动时、停止时。

ClassLoadingStatsHook

可用于拦截类从Bundle-Classpath中加载的动作，包括加载之前以及加载之后。

扩展Equinox注册Hook类的方法属性中指定在启动时指定osgi.hook.configurators，但要注意的是要加上目前Equinox所需的hooks配置，格式为：hook.configurators=hook类名,hook类名此文件需要放在Equinox框架的classpath下；配置文件中指定增加一个hookconfigurators.properties，其中的格式为：hook.configurators=hook类名,hook类名

Equinox扩展的启示框架级的软件都应提供良好的扩展支持，方式可以为：Filter可通过扩展OSGiService模型来实现；适合组装为一连串的处理来完成一个功能。Interceptor可通过扩展OSGi Service模型来实现；适合方法执行前后的扩展处理；Hook直接基于OSGi Service模型即可实现；适用于方法执行过程中的扩展处理；

4、Equinox高级实战将上节的东西应用到实战中！如何控制Equinox的ClassLoader？如何将非DS的应用迁移为DS方式？如何应对采用OSGi后一些常见的错误？

Equinox高级实战控制Equinox的ClassLoader基于ClassLoaderDelegateHook实现实现ClassLoaderDelegateHook以及HookConfigurator接口；可自行控制是在Import-Package寻找前进行类或资源加载的处理还是在之后；增加hook.configurators文件或修改启动属性：osgi.hook.configurators。实际的一个场景有些Bundle类需要加载外部容器中的类，就可以用这种方法。

Equinox高级实战将非DS的应用迁移为DS方式迁移的方法将之前直接类的调用方式改为基于接口的方式，这也将对动态化的实现更为有利；将接口放入一个独立的Bundle中，也是为了动态化；将注册服务的代码去掉，改为通过编写xml文件来注册服务；将调用服务时依赖BundleContext获取的方式去掉，改为set注入的方式，并通过unset来感知服务的注销；编写XML文件来定义需要调用的OSGi Service；最后就是在运行的Bundle中增加DS实现的Bundle。

Equinox高级实战将非DS的应用迁移为DS方式示例迁移好处解放之前对于BundleContext.registerService等这些难用的用法；避免需要自己基于ServiceTracker或ServiceListener来实现服务状态的感知。

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容器。

Equinox高级实战经常会碰到的一些问题ClassNotFoundException几乎是所有使用OSGi的人都会经常碰到的问题；解决的方法是掌握Bundle Class的加载方式；ClassCastException几乎是所有使用OSGi的人都会经常碰到的问题；解决的方法是掌握ClassLoader的基本原理以及Bundle Class的加载方式；OSGi Component没启动这是比较麻烦的问题；解决的方法首先是掌握OSGi Component的激活条件；然后是通过OSGi Console，查看log，或仔细检查Component .xml的配置；

5、分布式OSGi有哪些实现框架？它们是如何实现的？对比而言，谁更有优势？

分布式OSGi你所期望的？我所期望的透明的将OSGi服务发布为可远程调用的服务；透明的调用远程的OSGi服务；OSGi服务的动态化感知不是必须的由于这受限于网络等各种因素，而且如果服务有多级调用的话就会出现类似的雪崩效应；

分布式OSGiJava远程通信（TCP/IP、UDP/IP、多播）+NIO/BIOJava远程RPCRMI：基于代理、反射机制Webservice：基于http RPC机制

分布式OSGi分布式OSGiR-OSGi老牌，有一定的优势，但用户群不多；CXF DOSGi作为将来的R 4.2的RFC119的实现，值得期待！

分布式OSGiR-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。

分布式OSGiR-OSGi实现机制监听了服务注册事件，当有服务注册时，检查其注册的属性，如属性中有RemoteOSGiService.R_OSGi_REGISTRATION，并且值为true，那么则做一个服务接口名与此服务的映射，并将此映射作为tcp/ip某端口的处理器集合。对于客户端，当通过RemoteOSGiService拿到引用时，为一个服务端调用的代理，当调用此引用的方法时，即代理访问到远端服务器，过程即为一个类似的自定义的java远程RPC。

分布式OSGiCXF 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的完全透明还是需要做点包装的。

分布式OSGiCXF DOSGi实现机制监听服务注册事件，当注册时有相应的属性时，则将其发布为Webservice；对于客户端，则通过扫描相应的service-description的描述来生成一个调用远程Webservice的代理，并将此代理注册为相应的OSGi Service。

分布式OSGi个人的经验分布式OSGi的实现多数和OSGi并没有多大的关系，其核心原理均为实现一个透明的远程RPC；如需关注性能、稳定性来说完全可以自行实现；所需的知识为代理、反射、网络通信以及服务发现；

END!