OSGi_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
上传于||文档简介
&&osgi研究、介绍
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩46页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢软件开发的家园,编程爱好者的天地.
&&|&&&&|&&
Plugin Architecture简述
来源:Internet
作者:网络收集
　　Plugin Architecture，无疑是如今软件界最为热门的名词，在各种各样的解决方案、白皮书中经常都能看到即插即用这么几个字，但真的又有多少软件做到了呢，当然，不可否认的是也有部分的软件确实做到了，而且做的很好，例如Eclipse，知名的插件式系统，还有象maven这些都是，其实portlet container那些也都是的，列举出来还真的有不少。插件式系统带来的好处很明显，最大程度的重用，为快速的搭建系统提供帮助，潜在的好处在于要求系统以插件式的方式进行设计，帮助你更好的做到模块化的划分以及帮助系统达到良好的封装性。
　　要做Plugin Architecture，首先需要做的是如何考虑Plugin，其实也就是需求，要看你是怎么看待一个Plugin的，认为一个Plugin应该是怎么样的，认为Plugin是怎么样被组装起来构成系统的，这个时候需要的是大家从需求的角度来提出要求，不要从技术角度来提。一个系统既然是按照Plugin的方式搭建出来，那么首先需要知道的是就是Plugin能提供什么样的功能，这些功能需要什么参数，这是最基本的，其次是如何去管理这个Plugin，包括修改它的配置参数，对它的生命周期进行管理(启动/暂停/停止等)，这是以单独的Plugin角度来看，如果这个Plugin又得调用其他Plugin提供的功能，那么应该怎么去做，考虑了这些后又会想到Plugin应该怎么去部署、怎么去自动升级。从扩展方面我们又会考虑到那么我要如何去扩展一个Plugin呢，这也是很关键的。这都只是简简单单的提了一些Plugin的需求，归纳上面的需求可以得出主要的几点就是Plugin的功能的暴露、Plugin的管理、Plugin的调用、Plugin之间的协作、Plugin的部署、Plugin的扩展这几个大的方面。
　　技术简介
　　现有的可参考的Plugin Architecture还是有比较多的，例如Eclipse、Geronimo、Maven、Pluto等等，这些都是做的比较好的插件式的系统，在这里主要讲讲Eclipse如今使用的Osgi和Geronimo所使用的JMX IoC方式实现的Plugin Architecture，应该说两者各有千秋，重点还是看对于Plugin的需求到底是怎么样的，Osgi规范将系统按照Bundle的方法进行组装，每个Bundle下包含了一系列的Service，通过编写Bundle完成对于Bundle的管理(Start、Stop)，而Service则为Bundle所能提供对外的功能，通过MANIFEST.MF这个标准的jar包描述文件来描述bundle所能提供的功能以及一些元数据信息，由于对Osgi研究不深，也只能大概的提提这些了，Eclipse在3.0以后的版本开始采用Osgi，并兼容其原有的Plugin方式，可以通过阅读Eclipse源码去了解关于基于Osgi来实现Plugin Architecture的方式，Eclipse是基本实现了上述需求部分的，不过个人认为在plugin的管理、plugin之间的协作、plugin的部署上还可以加强;接下来提提JMX IoC方式，对JMX稍有了解的人都知道JMX被大量的应用服务器所使用，如Jboss、Tomcat、Weblogic、WebSphere等等，数不胜数，JMX强调的是一个管理概念，对JMX不在此详细的介绍，但其实它同样是一个Plugin的概念，依照JMX系统可以编写MBean的方式来暴露Plugin的功能，并实现对于Plugin的管理(各种方式，http、rmi等等)、Plugin的调用、Plugin的部署，那么为什么要引入IoC呢，IoC帮助实现Plugin之间的协作，并且是通过注入的方式来实现，IoC也不在这里详细的去描述了。
　　通过对上面两种实现Plugin Architecture的简介，分别都实现了需求中的内容，但都有提升的余地，个人认为Osgi的方式需提升对于Plugin管理的关注(不仅是生命周期管理)、而JMX IoC方式则需提高对于Plugin内部结构的关注(就象Osgi将Plugin***为了Bundle和Service)，至于Plugin的扩展方面觉得Eclipse的Extension Point是非常不错的一个设计，不过同时也看出在Plugin Architecture的实现上基本都采用了管理和静态结构分离的方法，其实这个好处是非常明显的，可以快速的将系统原有的模块通过编写一个管理类的方法就可作为plugin放入系统中，这提升了简便性，当然最大的作用还是分清了职责，
本文关键词：
以下留言只代表网友个人观点，不代表本站观点.概述Eclipse中最出彩的部分莫过于它的Plugin Framework，可以说Eclipse在一定程度上使得Plugin机制得以流行，当然，Eclipse的优势不仅仅在此，但正因为采用了Plugin机制，Eclipse才得以被不断的扩充，越来越强大。一直以来就想分析Eclipse的Plugin Framework，由于各种原因一直耽搁，刚好这个周末没什么事，下定决心对其进行了研究和分析，方法很原始，就是对Eclipse的启动过程进行分析，基于的是Eclipse 3.1的版本，分析过程就不在这说了，主要是说说分析出来的心得。架构上来讲Eclipse基本采用的是Kernel+Core Plugins+Custom Plugins的结构体系，除了Kernel部分外均为Plugin，所以可称为all are plugins，凡是Plugin的部分都是可被替换的。
OSGIEclipse 3.0后采用的是OSGI来作为其Plugin Architecture实现的依据，鉴于此就得简单提提OSGI了，主要从Plugin的角度来分析OSGI，OSGI概念中主要分为了Bundle和Service，可以认为Bundle是一个模块的管理器，主要是通过BundleActivator管理模块的生命周期，而Service则是这个模块可暴露对外的服务对象，这里体现了OSGI和传统的Plugin Framework不同的一个地方，管理和静态结构分开，在OSGI中通过在manifest.mf文件中增加一些内容来发布Bundle，在其中描述了Bundle的提供商、版本、唯一ID、classpath、暴露对外的包、所依赖的包；每个Bundle拥有自己的ClassLoader以及context，通过context可进行服务的注册、卸载等，这些操作都会通过事件机制广播给相应的其他的Bundle；一般来说都为通过在Bundle中编写初始需要注册的服务的方法来完成Bundle可供外部使用的服务的暴露功能；如需要调用其他Plugin提供的服务可通过context的getServiceReference先获取Service的句柄，再通过context.getService(ServiceReference)的方法获取Service的实体。
Eclipse Plugin定义Eclipse中的Plugin的概念为包含一系列服务的模块即为一个Plugin。既然是遵循OSGI的，也就意味着Plugin通常是由Bundle和N多Service共同构成的，在此基础上Eclipse认为Plugin之间通常存在两种关系，一种为依赖，一种为扩展，对于依赖可通过OSGI中元描述信息里添加需要引用的Plugin即可实现，但扩展在OSGI中是没有定义的，Eclipse采用了一个Extension Point的方式来实现Plugin的扩展功能。结合OSGIEclipse遵循OSGI对于Plugin的ID、版本、提供商、classpath、所依赖的plugin以及可暴露对外的包均在manifest.mf文件中定义。Plugin Extension Point对于扩展，Eclipse采用Extension Point的方式来实现，每个Plugin可定义自己的Extension Point，同时也可实现其他Plugin的Extension Point，由于这个在OSGI中是未定义的，在Eclipse中仍然通过在plugin.xml中进行描述，描述的方法为通过&extension-point id="" name="" schema=""&的形式来定义Plugin的扩展点，通过&extension point=""&的形式来定义实现的其他Plugin的扩展点，所提供的扩展点通过schema的方式进行描述，详细见eclipse extension-point schema规范，为了更好的说明扩展点这个概念，举例如下，如工具栏就是工具栏Plugin提供的一个扩展点，其他的Plugin可通过此扩展点添加按钮至工具栏中，并可相应的添加按钮所对应的事件(当然，此事件必须实现工具栏Plugin此扩展点所要求的接口)，工具栏的Plugin将通过callback的方式来相应的响应按钮的动作。可见通过Extension Point的方式可以很好的提供Plugin的扩展方式以及实现扩展的方式。
Eclipse Plugin Framework那么Eclipse是如何做到Plugin机制的实现的呢？？还是先讲讲Eclipse的设计风格，Eclipse在设计时有个重要的分层法则，即语言层相关和语言层无关的代码分开(如jdt.core和core)，核心与UI分开(如workbench.ui和workbench.core)这两个分层法则，这个在Eclipse代码中处处可见，在Plugin Framework部分也充分得体现了这个，遵循OSGI，Eclipse首先是实现了一个OSGI Impl，这个主要通过它的FrameWork、BundleHost、ServiceRegistry、BundleContextImpl等对象来实现，如果关心的话大家可以看看这部分的代码，实现了Bundle的***、触发、卸载以及Service的注册、卸载、调用，在Plugin机制上Eclipse采用的为lazy load的方式，即在调用时才进行实际的启动，采用的为句柄/实体的方式来实现，外部则通过OSGI进行启动、停止等动作，各Plugin则通过BundleContext来进行服务的注册、卸载和调用，这是OSGI的部分实现的简单介绍。那么Extension Point方面Eclipse是如何实现的呢，在加载Plugin时，Eclipse通过对plugin.xml的解析获取其中的&extension-point&节点和&extension&节点，并相应的注册到ExtensionRegistry中，而各个提供扩展点的Plugin在提供扩展点的地方进行处理，如工具栏Plugin提供了工具栏的扩展点，那么在构成工具栏时Plugin将通过Platform.getPluginRegistry().getExtensionPoint(扩展点ID)的方法获取所有实现此扩展点的集合IExtensionPoint[]，通过此集合可获取IConfigurationElement[]，而通过这个就可以获取&extension point=""&其中的配置，同时还可通过IConfigurationElement创建回调对象的实例，通过这样的方法Eclipse也就实现了对于Plugin的扩展以及扩展的功能的回调。在Plugin Framework中还涉及很多事件机制的使用，比如Framework的事件机制，以便在Bundle注册、Service注册的时候进行通知。
总结通过对Eclipse启动过程的分析，可清晰的看到Eclipse Kernel+Core Plugins+Application Plugins的方式，在代码中分别对应为loadBasicBundles和registerApplicationServices，loadBasicBundles通过加载config.ini中的osgi.bundles完成基本的bundles的加载，去看看这个配置会发现是org.eclipse.core.runtime还有一个update，core.runtime又会通过IDEApplication来完成整个Eclipse的启动，同时会注册所有与workbench相关的plugin。Eclipse由于以前版本的Plugin Framework是没有采用OSGI的，所以通过EclipseAdaptor的方式来实现与以往的兼容，目前新的Plugin采用的方式基本就是manifest.mf描述Plugin OSGI部分的信息，Plugin.xml描述扩展点的信息。Eclipse中有非常多优秀的设计，这个在看它的代码时会有很深的感触，比如Contributing to Eclipse中提到的Extension Object/Interface的设计，确实是非常的不错，虽然看到你可能觉得很简单，关键是要想得到并合适的去使用。总结陈词，^_^，Eclipse Plugin Framework是采用OSGI Impl+Plugin Extension-Point的方式来共同实现的，实现了Plugin的部署、编写、独立的Classloader和Context、Plugin中Service的注册、Plugin中Service的调用、Plugin的依赖、Plugin的扩展、Plugin生命周期的管理。
带来的思考Eclipse Plugin Framework采用的是OSGI的实现，一定程度上我们也能看到OSGI的优点，那么JMX+IoC方式的Plugin Framework与其的比较又是在哪些方面呢？Eclipse Plugin Framework不足的地方又在哪里呢？哪些地方值得改进呢？
2005年12月
272829301234567891011121314151617181920212223242526272829311234567
阅读排行榜
评论排行榜