SCA全称Service Component Architecture，即服务组件框架。它由BEA、IBM、Oracle等厂商联合制定的一套符合SOA思想的规范。它并非不是什么技术，而是一种规范性的描述，也是一种新的开发模式的指导规范。
但由于SCA在国内尚属新事物，而且BEA、IBM等也未就此做过多的推广，所以如今的SCA正处于起步阶段。但切莫因为SCA只是小儿就忽视它的存在，就像当年的Spring，相信在不久的将来定能得到广泛的应用、书写编程的新篇章。
就SCA的有关话题作者采访了阿里软件(中国)有限公司的架构师岑文初。(文中观点均为岑文初提供)
大将之风
凭什么说SCA小儿将成大器，究竟它有哪些优势、开发者又可以从中获得哪些“好处”呢?岑文初分析主要有以下三点：
1，模块化：
当系统规模已经不能通过手工作坊式的开发来满足需求的时候，有效的模块化设计和开发是系统架构可维护和迅速适应用户需求变更的重要基础。
Spring的推出很大的亮点就是让大家接受了IOC的思想，这一点也是改变程序员开发模式的一个重大转变，模块与模块之间通过注入服务的方式来实现业务组装，但在实际开发过程中对于业务模块本身的封装和组装却只能够靠程序员本身，这会造成在配置日趋庞大的情况下，模块与模块之间的关联和耦合性越来越强。Spring本身对于模块并没有作任何封装，因此哪些服务内部使用，哪些服务外部使用都没有办法得到控制，同时作为服务发布有时候根据程序员的能力参差不齐会导致模块间服务注入的是实现并非接口，模块间协作开发在小范围内还可以应付，但是扩展到更大规模的协作就成了很大的问题。
而SCA规范的服务注入本身就已经体现了服务模块化的概念：
模块间和模块内部的服务在开发模式上就得到了限制和规范，同时面向接口的开发设计不再是约定而是规则。前期开发模式的转变需要一定成本，但是一周适应和培训以后，开发模式的优势就会体现出来。对于程序员本身来说，模块化的开发做业务的单元测试来的更为简单，只要在服务框架中增加一些特性(模块动态解析和载入，监控机制，内嵌轻量级web container方便Web服务调试等)，那么就会在开发过程中大大提高开发效率。其实也是达成了架构师和程序员之间的一个双赢的方案，务实有效的开发模式才能得到程序员的认可。
2，可扩展性：
SCA规范本身对于规范的实现细节并没有加以约束，你可以通过Spring来实现(指需要控制业务组装范围)，也可以类似于Tuscany实现java，c++，php版本，同时每个版本的实现中可以扩展各个语言内部的已有的成熟技术产品作为业务逻辑的实现。就Tuscany的java版本中已经对EJB,Spring,OSGI,WebService,JMS等作了集成。同时自己可以随时根据需要集成开源的成熟产品，或者自己开发特定的业务组件作为SCA的服务实现。那么对于开发者来说，可以吸收任何好的框架，或者扩展自己的业务实现，无疑提供了很好的推广动力，毕竟如果你能对框架贡献自己的思想，就会有成就感，这也是国外开源组织能够蒸蒸日上的原动力。
3，SOA：
这点是SCA本身所具有的，同时也是前两个特点所赋予的一个特质。SOA的目标就是原来一个个信息孤岛连接起来，通过信息交互共享把信息价值最大化。由于过去企业间的信息实现和管理的手段不同，信息共享中出现了无形的壁垒，在今天互联网应用高度发展的情况下，SAAS等概念的提出，SOA越来越引起了大家的重视，但是SOA是概念性的解决方案，具体如何实施，用什么手段实施，都没有较为明确的指出。做正确的事，正确的做事，当在实施SOA时候采取了不是很适合的方法方式的时候，那么效果会适得其反。
而SCA将SOA的概念具体实践化，应该说SCA就是SOA的一种实施规范，采取这种灵活的框架规则能够为SOA真正“落地”打下基础。对于开发者来说，也许不能够了解SOA究竟能解决什么，但是在开发过程中，潜移默化的就将这种理念消化，在回过头看已经实现的业务应用于SOA的场景中，就会理解SOA究竟能够给客户带来什么价值。
成长的烦恼
既为“孩童”，SCA则总有不成熟之处。
岑文初现在所负责的应用服务框架便是基于SCA规范，然后使用了Apache Tuscany内核和框架再次封装和构建的。“Tuscany我接触的时候还是0.9以前的milestone2版本，当时尚未根据SCA v1.0规范做实现，在0.9版本以后已经支持了SCA v1.0规范，同时短短的几个月就发布了0.91,0.99,1.0几个版本，在成熟度上得到了很大的提高，但是还存在很多问题。”岑文初说。
首先就是结构性设计文档以及使用文档的缺失，学习者只能靠Demo以及跟踪源码，分析了解结构;其次是在模块化上做的还不够;还有过于追求扩展而忽略了对于当前已实现的功能的完善。作为SOA的实践性框架实现，对于SOA当前实施的主要技术WebService当然需要有很好的支持，在v0.99之前没有集成webservice security的内容，同时对于数组参数以及返回还有问题，v0.99以后虽然集成了axis2 rampart但是封装过于低，配置有困难。同时最大的问题就是很多细节方面的测试和完善都还不尽如人意，边界和兼容性测试都不够。(这些在我开发过程中都遇到了，并且提交给tuscany，虽然网站确认1.0修复，但是当看到v1发布的时候，还是没有修复)。
总体上来说，Tuscany在结构性框架上很优秀，符合了SCA的灵活可扩展性，但是一些基本功能上的完善尚存在问题，看来做广是他们的目标，而作为用户来说可能更关注某一方面的深。
忌拔苗助长
“SCA/SDO/BPEL就是新十年的软件开发的主流技术，是软件开发的3G时代，而‘2.5G’的那些技术 (Spring, Struts, Hibernate, AOP......)将会融入到‘3G’，并可能将逐渐退出独立发展的市场。”曾有开发者这样高度点评SCA，但岑文初并不认同这样拔苗助长式的观点。
因为SCA可以随时把其他好的开源项目融入到框架中，“2.5G的应用是3G的基础，而非排斥。”
岑文初所在的公司的应用服务框架中spring和SCA就是互通的。因为考虑大家开发的习惯，同时集成老的系统，以及使用spring好的特质(事务，单例，工厂类等)在几个产品组开发中都极大地融入了spring，同时webservice对于axis2的集成，以及webservice security的wss4j的集成，Jetty内置轻量web容器的集成和使用，都为SOA方式的业务实现提供了十分简便的发布和测试。最近需要内部使用高效的远程接口传输，那么就直接把hessian集成进去了。【记者：呐不喊】
岑文初后语：
任何技术和理念都没有绝对的好和坏，只有适用与否，当规范和开发模式适用于这个年代的信息化时，那么它就是好的。作为当前的互联网应用来说，信息开放化，模块化开发集成，面向服务都是当前能够提高信息利用率，适应需求多变，增强系统可靠性，降低耦合度，提高开发效率的解决手段，而SCA作为规范在实现的框架中作了很好的约束，不再是游勇散兵靠经验来决定质量，而是通过实实在在的开发模式转变来改变开发人员的习惯，模式架构决定质量。
记得过去和其他架构师交流的时候，总觉得程序员，架构师总是存在着矛盾，程序员觉得架构师高高在上，制定的架构空而不实，架构师总觉得程序员小聪明不少，但是聪明反被聪明误。两件事情让我很感动深受启发。
一.第一次在业务组推广服务框架的时候，来了不少人，不过睡觉的也有，结束的时候我留了自己的邮箱，希望大家有什么问题和意见都给我发email，第二天收到了一封邮件，邮件中说：“你们平台组的问题是在于总是用不同的方式作同样的事情，我们算是你们的客户，但是你们从来没有调研过客户所关心的，如何提升客户的满意度，或者说你们还不知道如何表达给客户你们的想法对客户有什么好处，没有人愿意总是换着方式做同样的事，还要增加学习成本和开发成本。”以后每一次设计技术新点都回考虑是否能够给开发人员带来什么好处，模块化好，好在可以简单的模拟作多模块的集成测试，随时可以卸载和载入所需要的模块，面向接口好，好在不同业务组开发过程中，实现的变更不会影响对方，单元测试简单，开发组织间的依赖性减小，提高开发人员的时间利用率。SCA规范让我把这些优势都一个个挖掘出来了，因此让我更加有信心去推广，实践是检验真理的唯一标准。
二.在刚开始一段时间内，对于开发效率以及性能，其他架构师提出了疑问，部门经理也很重视，也曾考虑是否缩小使用范围，在我的建议之下做了一次全面的匿名调查，对于新框架的开发过程中各种的疑问和困难做了一次调研，最终结果得到了大部分人的认同，再加上性能测试，最终服务框架继续作为平台基础框架使用。
可见没有任何理念可以很容易推广，SCA也是如此，但是实践将会检验真理。
