在SCA规范草案首次发布四年之后，SCA依旧是一门名气不太响亮的技术，甚至未被理解。然而，两家主要的中间件厂商，IBM和Oracle/BEA却已经将关键的产品套件构建在该技术之上了。Pat Shepherd还刚刚发布了一份关于Oracle SOA Suite 11g如何利用SCA的白皮书。两个开源项目也实现了SCA规范：Tuscany和Fabric3。
究其核心，SCA基于依赖注入模式（Dependency Injection Pattern）提供了一种装配机制，允许你将不同的软件代理装配在一起去执行一个工作单元。SCA建立于一系列的当代的观点之上：分布式组件的接口是双 向的；编排语言是某类分布式组件的核心实现模型；分布式组件必需发布和订阅消息事件（一个事件代表了一个状态的出现，状态通过消息事件进行传递）。由 此，SCA扮演了一个分布式CLR的角色，可在同一装配中支持多种语言和运行时。同时，它还支持被编排的组件与标准的Java、Python或C++组件 进行装配，为这些语言无缝地添加编排语义。
当前，由于其历史原因和领导机构，SCA保留了大量与特定厂商绑定、以Java为中心的技术。然而，一种互操作装配机制势必会改变（并大大简化）我们构建分布式系统的方式。
总的来说，如果你想了解如何构建现代分布式系统，SCA可能是你所能找到的最先进蓝图，即便你可能从来不会使用这项技术本身。
SCA规范集的两位关键作者，Jim Marino和Michael Rowley，在今年夏天出版了一本题为《理解SCA（Understanding SCA）》 的书籍。Jim Marino是Metform Systems Ltd的一名负责人，从一开始就参与了SCA，他同时也是开源Fabric3 SCA运行时的带头人之一。Michael Rowley是Active Endpoints公司的技术和战略主管，从很早就参与了SCA的发展之中，而且已经为15份SCA规范中的12个作出了贡献，这些规范已经作为开放面向服务架构（OSOA）的协作内容发布。
在Jim和Michael看来，在构建分布式系统时：
SCA用现有方法解决了两个关键问题：复杂性和重用。
服务组件架构或SCA，是一种创建服务并将其装配成组合应用系统的一门技术。SCA解决了一个长期存在的问题：如何从一系列互连部件构建系统。在SCA 中，这些部件是通过提供执行特定功能的服务进行交互的。服务可能使用不同技术和编程语言实现。例如，一个服务可能用Java、C++或象业务流程执行语言 （BPEL）这样的特定语言实现。服务还可能被配置到同一操作系统进程中，或者分布在运行于不同机器上的多个进程中。SCA提供了构建这些服务、描述它们 之间如何交互以及装配到一起的框架。
本书开篇就从“复合组件（composite）的装配和部署”，“使用Java进行基于服务的开发”和“使用Java进行会话交互”三个章节对SCA编程模型进行了整体介绍。
在深入探索SCA编程模型之后，接下来的章节涵盖了SCA的主要概念：组装（composition）、策略（policy）、连线（wires）、 绑定（bindings）和域（domain）。在这些章节中，作者解释了如何使用SCA开发模块化应用、使用事务、配置诸如安全和可靠性这样的跨应用策 略、集成外部系统、部署应用程序和构造协作框架等。
本书的最后三个章节完成了对SCA编程模型的介绍：“使用BPEL进行基于服务的开发”，“持久化”和“展现层”。
SCA建立于四个关键概念之上：服务、组件、复合组件和域：
应用程序被组织成一系列完成特定任务的服务，如接受贷款申请，执行信用审核或者执行库存查询。服务这一术语已经被业界被用来指代过很多事物了。在SCA中，服务具备两个主要性质：契约和地址。组件是一段经过配置的代码，提供了一个或多个服务。客户端通过地址连接服务，调用它的操作。组件可以用不同语言实现。
创建组件的第二个步骤是配置。使用XML配置文件配置过的组件被称为复合组件。复合组件提供了将SCA服务暴露给域之外客户端以及访问域之外服务的机制。
复合组件被部署到一个运行SCA中间件的环境之中，该环境被称为“域”。域包含了一个或多个协同操作的SCA服务器或者SCA运行时，它们将组件托管于容器之中。
“使用Java进行基于服务的开发”这章就“基于服务的实现”如何区别于之前的分布式对象技术这个问题，提供了独特的视角。尤其是，作者坚持版本控制是一个根本区别：
远程服务契约必需考虑版本控制——远程服务契约应该是可演变的。API在第一次迭代就满足需求极为罕见。此外，新需求往往在应用已经转变成产品之后才出现。除非是根本性的变更，都应该有可能对服务进行版本控制，使其不破坏与现有客户端的兼容性。
他们还强调SCA的仲裁能力：
在SCA中，对仲裁引入这一问题的决策可被推迟直到应用程序已经变成产品。
接下来的章节以贷款申请为例，详细介绍了SCA规范集的方方面面。
作者和出版商真诚地提供了本书第10章。它涉及“使用BPEL进行基于服务的开发”。作者大胆地阐述了BPEL与服务之间的关系：
从现在开始，不要管业务流程的概念。如果你打算从头设计一种专门为使用异步Web服务而设计的语言，你设计出来的东西很可能与BPEL极为相似。在前面的陈述中，异步这个限定词很关键，但是在处理它之前，要让这门语言成为一门针对Web服务的语言要包括如下特性：
- XML模式类型的变量和参数
- WSDL规定的操作签名
- 使用XPath指定的表达式和条件
- 针对语言本身的XML语法
他们继续说道：
BPEL非常适合SCA世界。一个BPEL流程定义可被用来作为SCA组件实现使用。BPEL合作伙伴连接作为服务和引用（稍后再详细介绍），并且这些服 务和引用的接口使用组成BPEL合作伙伴连接类型的WSDL端口类型来指定。SCA的会话接口提供了被BPEL称为“引擎管理的关联（engine- managed correlation）”的功能，这让开发者不必再显式指定关联信息。
第11章解释了在SCA实现中如何使用Java持久化API。在最后一章，第12章，介绍了SCA的创新和近况：表现层，这也给SCA编程模型的介绍画上了一个句号。
SCA并没有提供可供选择的表现层技术。只要谈到用户界面，SCA的法宝就是集成。使用SCA构建的服务层可以和多种客户端技术集成，包括Swing和使 用Adobe Flex的富客户端、AJAX和诸如Struts及Java Server Faces（JSFs）这样的Web框架。
SCA已经引入了Web组件的概念，这使得：
Servlet和JSP[将]连线到SCA服务。
纵览全书，作者给出了他们对众多重要问题的理解，如：
- SCA是一门SOA技术吗？
- SCA跟Java EE的关系是包含、扩展、替代，还是仅仅为了混淆视听？
- 互操作性和可移植性。
- Spring和SCA：小规模和大规模的连线。
- 没有WSDL的服务？
- EJB和位置透明的神话。
- 服务松耦合的度在哪里？
- 应该选择哪种数据绑定？
- 组合的性能暗示。
- 声明性策略和API。
- 为什么SCA不使用UML？
- 在指定服务契约的时侯，应该使用WSDL吗？
- 为什么不直接使用JMS？
- 真正大规模的连线。
- 针对可移植性的架构。
整本书对SCA进行了全面的介绍。如果你不熟悉该技术且正在构建SOA，你确实值得投入一些时间去使用该技术或实现这里的一些模式。
查看英文原文：Book Review: Understanding SCA。
