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放入系统中,这提升了简便性,当然最大的作用还是分清了职责,
说一句题外话,职责单一一直是软件设计的重中之重,此文纯属抛砖引玉,希望能听到更多关于Plugin Architecture的声音,也希望大家都关注Plugin Architecture,最近也出了一个JPF,不知道大家是否有所了解。