插件架构体系---开篇

插件架构体系是我一直就非常关注的内容，其实插件架构体系的发展已经有很久的背景了，插件架构体系的优点我们也是能看的非常明显，象硬件一样的即插即用、无论对于公司还是业界而言的良好的积累方式、为公司或业界提供统一而规范的开发方式以及稳定的内核架构等等，这些优点无论对于公司还是业界来说都是非常重要的。
插件架构体系基本的一个概念就是基于松散的模块积累方式，通过新增插件以及扩展原有插件的方法来完成系统的实现，凡事有利必有弊，在看到插件架构体系的这些优点的同时，在实现和使用插件架构体系的时候仍然会碰到不少的问题，我大概的整理了一下，主要有：
1、插件的定义
      插件的定义可谓是插件架构体系在使用时会碰到的最大的问题，首先要解决的问题就是何谓插件、插件如何去定义？何谓插件这个大家的看法都会有所不同，由于对于何谓插件的看法不同，必然就导致了在整个系统的设计时采用了不同的设计方式，主要是在插件的粒度控制上会有不同的设计方式。
      个人觉得也许采用模块作为插件是一种可行的方案，采用模块作为插件的核心思想是按一种从顶至下的设计理念，也就是架构设计中产生的模块视图首先作为系统的插件构成视图，根据对模块的详细设计此时又可对模块的插件进行细一步的划分，或者是将插件划的更细，或者是采用插件的扩展机制去实现。
      插件的定义则是带来了一些设计上的难度的，我仍然觉得需要将插件视为黑盒去看，插件需要提供什么样的功能、插件需要什么样的运行环境、插件需要暴露哪些包等等，这个在Osgi中都有相应的映射，在基于插件架构体系进行系统构建的时候插件的粒度、定义我觉得这是最难把握的，甚至觉得难度上会超过以前的模块设计，需要的是更为规范的模块式的设计，觉得这个在中小型软件企业中往往是很难做到的，主要仍然是架构设计时的控制，在设计时重要的因素在于保持系统的松散结构，至于概要设计时则完全可按照架构设计的约束去进行，详细设计则完全和平时的做法一样。
2、插件的依赖
      插件的依赖主要有两种，一是对于系统已有插件的依赖，另一方面则是对于外部jar包的依赖。这都是在设计时需要做出考虑的，对于插件架构体系而言对已有插件的依赖和对外部jar包的依赖这个差别就比较大了，其实这个在设计上还好办，因为可以通过重构，本来一直依赖觉得最困难的是对其他插件的依赖怎么办，难道要去引用其他plugin的lib，在eclipse ide中是解决了这个问题的，所以现在来说插件的依赖在插件体系架构中就显得没那么困难了，这说明插件的依赖的解决依赖于一个良好的插件开发IDE。
3、插件的测试
      插件的测试我这指的不是运行的功能测试，而是单元测试，感觉这个在现在的插件架构体系里还是比较困难的，因为在一种松耦合的架构体系中，对于其他插件的依赖是要在容器运行期才能够获取的，觉得这个有点变成了当时ejb container的问题，现在好像得通过mock以及其他的方法去解决，另外一个也许是IoC的策略？这方面需要进一步思考，
4、插件的调试
      插件的调试主要是依赖容器的调试，现在的eclipse ide已经支持插件的调试，并且好像是支持插件的远程调试的。
5、插件开发学习的门槛
       就目前来说插件开发学习的门槛并不算低的，个人觉得至少要对插件体系架构有一定的了解(例如基于Osgi的插件框架，那就要求对OSGI有一定的熟悉)，但相对这个门槛而言，其获得的价值是值得的。

其实讲了这么些问题，集中的主要在于基于插件架构体系的应用框架以及业务系统的设计方式将和以前的会有些变化，这个也是可以理解的，毕竟是受技术架构约束的，另外一方面则主要集中在插件开发的简易性和质量的保证，这个就得依靠一个强大的插件开发IDE。