在 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 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论