集成看扩展
SOA的缩略版
在SOA的技术实现设计中，最简化的方式就是一个中心三个角色。一个中心就是服务为中心，三个角色就是服务提供者，服务消费者，服务的发布者。
图8
对于面向服务的SCA框架来说扩展也是延续了这种设计模式，框架的作用就是类似于ServicePublisher的角色，然后需要插件的开发者提供另外两种角色，同时为了更好的结合其他资源融入到服务实现中，还提供了Resource Resolver角色用来支持类似于wsdl，spring的配置xml等文件的解析，提供给服务发布者使用。
工厂模式的用武之地
在IOC思想出来之前，工厂模式应用很广泛，通过工厂模式在应用中来绑定不同接口的实现。但是实践证明工厂类的滥用导致了系统耦合性增强，很难做模块的独立单元测试，最后甚至影响了整个架构的可扩展性和需求变更响应能力。
当IOC出现以后工厂模式基本就被废弃了，服务之间的组装通过配置来完成，各种框架都充当组装者的角色，通过Proxy方式能够Lazy instance。但是作为框架级别的开放扩展，可能都根本不知道服务实现提供者，因此这种组装就无法满足。例如JSR 173对于Stax的设计实现来看，就采用了工厂模式结合策略文件的读取来运行期载入服务提供实现的方法。其实现在各种扩展性好的框架都采用了这种方式来支持扩展点的接入。
图9
当看到很多开源项目中的SPI包时，往往就会提供这样的服务提供接口扩展实现方式，动态的支持第三方再次开发并且集成到开源框架中。所以只有使用的恰当与不恰当，没有说某一种模式或者技术有好坏之分。
插件间的协作反看SAAS平台中服务的协作
在问题部分提到了关于插件间的协作，这里的协作耦合的很紧，基本上是一个插件直接调用了另外一个插件的接口。这种方式使用简单，效率高，但是耦合性比较强，同时在服务接口定义上个性化比较强，无法作为一个通用服务接口集成到平台中，提供给平台以及其它业务使用，不过这个可以通过类似于ESB的方式来解决。不过反看SAAS平台中各种应用的集成，如果没有能够使得各种应用互通互用，那么就无法最大化应用的价值，应用本身也就成为了一个个独立的“孤岛”，用户无法定制个性化的服务，大大削弱了SAAS模式的优势。设计和抽象出交互接口，提供给业务应用实现和调用，那么将会成为SAAS平台服务的关键。
结束语
常常有朋友问我，将Spring,Web Service都集成在SCA中使用比单独使用Spring,Web Service要麻烦的多，SCA有什么好处？其实这就是把SCA当作了具体的技术实现规范而不是框架约束规范。我可以用Spring去实现SCA规范，也可以类似Tuscany用java基本原语去实现，这只是手段的不同。面向业务组件进行封装，组合，调用，这些才是SCA框架规范的精华。
同样的，任何一种技术其实都不会凭空产生，SCA也是在经历了面向对象，面向组件，面向服务的积累，将框架设计中抽象提高到了服务，能够满足当前互联网应用的快速响应用户需求变更，灵活组合定制的需求。
最近看到有一篇文章的题目为《SCA让程序员走开》，好奇之下看了一下，其实也是指很多开发人员对于SCA框架的误解。但在我看来应该是SCA让程序员走近看看，架构师和程序员总有着矛盾，这只是两种角色看问题的角度不同，程序员最根本的职责就是高效，高质量完成开发任务，至于采用什么方式和技术优先级放在第二，而架构师的职责是从总体和长期上把握整个项目的进度按时完成，提高响应变更能力，降低维护成本。其实双方是不冲突的，只要架构师在设计的时候能够多考虑开发的便捷高效，程序员能够从复杂的开发过程中解放出来多参与架构设计的学习，那么就可以互相理解形成良性循环。SCA规范是否能够很好的实施关键在于人，如何将面向服务复用的思想通过简单的开发方式展现给程序员，提高程序员的开发效率，测试效率，那么就可以事半功倍。程序员多参与SCA框架的扩展设计，可以提高对于框架的理解，并且提高自身的设计能力与架构师达成共识。
不必太在意SOA、SCA、SAAS、Web2.0等等词汇，需要了解的只是这些概念背后真正对于现实有指导意义的内容，学会用这些内容去指导工作实践，那么才不会漂浮在空中，成为“空中飞人”。
