plugin architecture
architecture about plugin system,such as eclipse、maven,always can use osgi to impl this architecture.
摘要: 这篇blog是继之前的一篇提升c/s结构软件的管理性的延续，在这篇blog中会更加的实际的去介绍基于eclipse equinox实现的一个插件框架，而不再是象上篇中那样的提及的想法而已了，通过这篇blog来展现目前一个这样的插件框架的实际应用的情况，为了更加形象的表达，在文中会贴出一些目前这个系统的截图。
摘要: 插件开发框架其实和目前开源界流行的mvc框架之类的相同，都决定了基于这个框架的开发方式，如基于mvc框架，就会按照mvc思想来进行开发，而插件开发框架呢，也是同样如此，就要求基于插件的方式来进行开发，不过插件开发框架和mvc框架又有不同，插件开发框架是一个可以成为系统基础架构的框架，而mvc框架通常来讲不足以成为，如在目前的mvc框架webwork、struts上我们通常都需要加上spring、hibernate来构成系统完整的基础架构，这个时候由于mvc框架的实现是没有标准可参照的，就造成了在各种系统中形成了不同的但很类似的基础架构，但却造成了无法复用的现象；插件开发框架则是作为统一系统基础架构的一种开发方式，它使得系统的复用成为了可能，而同时由于插件开发框架对于动态性的支持，使得系统更加的灵活和可扩展。
来看看一个插件开发框架，应该提供些什么东西，作为改变系统架构思想的框架，插件框架需要考虑很多方面，如开发、测试、部署等，总结下来一个插件框架应提供插件的开发规范；插件开发、调试的ide；插件的测试方法；插件的部署策略以及插件的管理端。
摘要: 继续以osgi r4的declarative services(ds)来讲讲service-oriented component model(socm)，socm对于现有的component-oriented model或者是service-oriented model来说到底有什么不同的地方，到底ds能给我们带来什么样的好处呢？
摘要: jeff在eclipsecon 2006那篇介绍equinox的ppt中提到的declarative services(文中全部采用ds简称)的用法让人极度被吸引，但同时又产生怀疑，想起以前自己看过ds好像不是这样的，没这么强，便再次翻阅了osgi r4中的ds的章节，以验证jeff的说法，^_^，仔细看过ds章节后，确实为declarative services的强大而感到高兴，ds是一个面向服务的组件模型，从组件模型层次上去看，它超越了传统的组件模型，在组件模型描述的完备性上有了很大的进步，例如在组件服务的依赖上、组件服务的延迟加载上、组件服务的多样性控制上、组件服务的配置上以及组件服务的生命周期管理上，不过ds只能在osgi容器中使用，这尽管看上去可能是个弱点，但作为osgi规范中的一部分，这无可厚非，其思想值得很多目前component model的开源框架值得思考和学习，如感兴趣，请阅读osgi r4中ds章节。
摘要: equinox，我不想多做介绍，相信很多人都有所了解了，不了解的可具体去www.eclipse.org/equinox看看。
最近基于equinox做了一个系统，还是碰到了一些问题，当然也得到了在插件体系架构下的不少优点，在这里也做个总结。
总体而言，基于equinox做开发对于大多数java开发人员来说应该不会有太多改变的感觉，最多改变的感觉应该是带给设计师，设计师需要有发挥插件体系架构优点以及减少其带来的缺点的能力，^_^
摘要: 插件架构体系是我一直就非常关注的内容，其实插件架构体系的发展已经有很久的背景了，插件架构体系的优点我们也是能看的非常明显，象硬件一样的即插即用、无论对于公司还是业界而言的良好的积累方式、为公司或业界提供统一而规范的开发方式以及稳定的内核架构等等，这些优点无论对于公司还是业界来说都是非常重要的。
插件架构体系基本的一个概念就是基于松散的模块积累方式，通过新增插件以及扩展原有插件的方法来完成系统的实现，凡事有利必有弊，在看到插件架构体系的这些优点的同时，在实现和使用插件架构体系的时候仍然会碰到不少的问题，在本文中大概的整理了一些也相应的提出了一些自己的看法。
摘要: 大家都知道eclipse是一个典型的插件系统，而从3.0起其插件体系架构就重构为基于osgi规范来实现的，从这也可以看出osgi必然与plugin architecture是有很多的关联性的，在这里就来说说自己对osgi r3与plugin architecture的关联。
摘要: 通过对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
摘要: 通过对上面两种实现plugin architecture的简介，分别都实现了需求中的内容，但都有提升的余地，个
人认为osgi的方式需提升对于plugin管理的关注(不仅是生命周期管理)、而jmx ioc方式则需提高对于
plugin内部结构的关注(就象osgi将plugin分解为了bundle和service)，至于plugin的扩展方面觉得
eclipse的extension point是非常不错的一个设计，不过同时也看出在plugin architecture的实现上基
本都采用了管理和静态结构分离的方法，其实这个好处是非常明显的，可以快速的将系统原有的模块通过
编写一个管理类的方法就可作为plugin放入系统中，这提升了简便性，当然最大的作用还是分清了职责，
说一句题外话，职责单一一直是软件设计的重中之重，此文纯属抛砖引玉，希望能听到更多关于plugin
architecture的声音，也希望大家都关注plugin architecture，最近也出了一个jpf，不知道大家是否有
所了解。
摘要: plugin system现在的流行程度已经勿庸置疑了，在n多的白皮书、凯发天生赢家一触即发官网的解决方案中都可以看到即插即用这样的词语，而市场上面向构件、插件的软件也是越来越多，其实插件式的组装系统或者说”搭积木”式的组装系统一直就是软件界的追求，但对于plugin system还是有些迷惑的地方，还望大家一起讨论讨论，^_^，目前的plugin framework基本都是一种kernel core plugins组成的结构体系，说出来就是all are plugins，^_^，典型的就如eclipse，其实maven也算的上的
"));