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也算的上的
阅读全文