组件可插拔更换

　　为什么说组件的可插拔非常重要？

　　组件重用目的是为了更好地适应需求变化，但是有了组件重用不代表就快速适应需求变化，因为组件本身也会产生设计错误（提炼得不够抽象或者组件很难以替代），这就必然导致软件系统得维护成本提高，那么快速适应需求变化的目标也就成为一纸空文。实践证明：组件设计问题已经成为导致软件开发失败的一个主要因素。

　　组件设计有两个主要风险：组件提纯的纯度和组件的替代方式。提炼的纯度也就是抽象的高度，组件的抽象程度越高，当然可重用范围越广，但是往往我们只有经历多个项目后，才发现自己的组件提炼还欠火候，这实际是组件的提炼过程成本。

　　组件提练虽然取决于人为设计因素，但是在实现手段上也依赖于组件的替换方式，通过经常反复频繁的微调和更换，才能将组件不断提炼向理想状态靠拢，所以，必须有一种方便的组件替换方式提供频繁更换支持，我们总不希望更换组件象以前更换汽车发动机火花塞一样，需要拆开汽车，打开发动机那样麻烦吧？

　　参考PC电脑硬件设计：更新CPU或内存条，只要直接插拔就可以，这些部件和母版都是一种松散的、可插拔的关系，如果软件组件替换是动态的可插拔更加方便终端用户在软件系统交付后，根据需求改变他们的系统。组件可插拔本质上是这些组件必须是最大化的松耦合，彼此依赖影响非常小，换句话说：如果实现了可插拔更换，说明你的组件已经实现松耦合了。

　　那就有可能设计一种软件框架：它能够为每个部件提供非常棒的服务访问，软件组件是 松耦合'loosely coupled'，这些组件的大部分通过几行代码就可以实现替换。目前这种方便的实现方式是使用XML进行组件的配置。

　　JdonFramework/Spring都是这样的一种框架，JdonFramework更进步的是：JF框架本身的组件也是可以替换的，例如你希望在JF中使用Spring的配置文件，那么你只要做一个Spring配置文件的解析组件，然后替换JF框架原来的XML解析器就可以了。无论EJB2/EJB3等在这方面要稍逊于Ioc/AOP框架，对于支持EJB3的JBoss 4 这样架构，需要动态更换AOP拦截器还不是很方便，因为JBoss 4本身组件没有象JF那样做到可插拔配置，不过，JBoss 5已经开始走上这条路，使用一个微核心来管理所有的可插拔组件，我曾经在"JBoss 5迎来中间件彻底的可配置时代"一文中提出组件是否方便替换是衡量一个组件框架的重要指标。

　　在最近的TheServerSide文章'Service Access' to the software components中，主要是谈论了表现层组件的替换访问方式，GIF这样图片组件不可以随意控制调整，基本不能复用，但是通过SVG或XUI等支持XML组件动态替换技术的使用，则可以实现显示图形组件的复用。

    SOA

　　在软件运行时，给予用户动态插拔式更换组件，达到复用的组件更加适合变化的需求，这是软件业追求的目标，而SOA(Service Oriented Architecture)则是从另外一种方向也是在运行时提供用户一种改变系统的能力。

　　SCBA(Services and Components Based Architecture), SCBA是通过减少需求变化带来的传递损耗和时间来实现的，当需求变化时，SOA的服务将支持跟进变化和替换。

　　SCBA更强调的是一种业务过程重用，而且是跨组织跨多个专业域范围的，例如我以前说的四色图实际是对跨域范围的业务总结，特别是ERP域范围，大多数企业系统都是由MI等四种原始模型组成的，例如JiveJdon3看上去只是一个论坛系统，实际不只是，它的Message模型可以重用在网站内容系统、新闻发布系统、电子商务系统、仓库管理系统、资源管理系统等跨域范围中（部分已经实现）。

　　既然业务过程和IT系统可以跨组织跨域重用，那么类似软件系统的维护和开发就不必再重新开发，JiveJdon3的Message模型重用在新闻发布系统中，我需要把JiveJdon3的项目拷贝到新闻发布系统中，然后再针对新闻发布系统特点做些裁剪修改，这这种复制业会带来工作量和维护量，而SCBA则可以解决这个问题，通过运行时single-copy reuse分享各种服务功能。

　　更多SOA重用可参考“Service Component White Paper”一文。

    总结

　　本文总结了软件复用的不同层次：设计复用、组件架构复用以及业务模型复用，复用技术的不断发展正是由于适应变化需求的要求不断提高导致。