在 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 。
感谢马国耀对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论