SOA 编程模型

随着面向服务架构（Service-Oriented Architecture）使用率的增长，由 Web 服务 API（目前最流行的 SOA 实现技术），如 Java 中的 JAX-RPC 或.NET 中的 Web 服务扩展（Web Services Extension，WSE）API，所提供的抽象级别对于有效实现 SOA 越来越显得力不从心：

• 这些 API 的语义更偏向服务调用的技术方面和 SOAP 处理过程，其次才是服务的使用和支持。
• 它们中的大多数只提供 SOAP over HTTP 的支持 a ，对于 SOA 实现来说，这并不总是最优的传输方式。
• 它们中的大多数只提供同步和单向的服务调用 b ，而这只是服务交互风格的子集。
• 这些 API 直接暴露给实现代码，导致了以下后果：
  • 业务实现代码经常与服务通信支持代码搅和在一起，它使得实现、理解、维护和调试变得更加困难。
  • 任何 API 改变（至少每一年发生一次）都要求在业务实现中更改。
• 这些 API 对于很多重要的服务运行时模式没有提供直接支持。如，要实现动态路由请求必须自己编程，同时使用额外的 API（Java 中是 JAX-R）来访问注册中心。

目前尝试通过定义 SOA 编程模型（其中，从其他技术中借用了很多元素）来提高 API 的抽象级别，这样可解决当前 API 集合中的一些问题。编程模型的目标是，降低应用程序开发者直接处理中间件或 Web 服务特定 API 时面临的复杂度。通过从业务代码中移除大部分的通信支持，并将它们隐藏在编程模型抽象 / 实现之后，这样可以获得以下好处 1 ：

• 简化业务服务的开发。
• 简化作为服务网络构建的业务解决方案的装配和部署。
• 增加敏捷和灵活性。
• 保护业务逻辑资产，使其不受底层技术改变的影响。
• 改善测试能力。

Web 服务调用框架（Web Services Invocation Framework，WSIF） 2 3 是创建这种模型的最早尝试之一，最初由 IBM 发起，目前是 Apache 基金的一部分。

WSIF 试图将服务使用模型与基于 WSDL 的服务定义结合起来——WSIF API 直接支持 WSDL 语义。这使得 WSIF 能为使用不同传输协议的不同服务实现提供统一的调用模型。尽管 WSIF 本身从来没有获得广泛地采用，但它作为服务调用的 API，被很多 BPEL 引擎使用，如 IBM 的 WPC 和 Oracle 的 BPEL 管理器。

对于 SOA 实现来说，以下 3 个模型是目前最流行的：

• 来自微软的 Windows 通信基础（Indigo）编程模型，它试图为所有服务元件创建统一的 OO 模型来简化服务编程。
• 来自 Java Community Process 的 Java Business Integration（JBI）模型，它通过创建专用（服务）容器形式的抽象层，解决服务编程的复杂度和可变性。
• 来自 IBM、BEA、IONA、Oracle、SAP、Siebel、Sybase 等的服务组件架构（Service Components Architecture，SCA），它基于的前提是：以结构良好的组件为基础，兼具清晰的接口和明确的组件责任，这样的体系结构有充分的理由被视为 SOA。 4 。

通过支持无缝的服务编排（orchestration）和许多对于成功实现 SOA 必需的模式，这些编程模型试图超越简单的服务调用，并期望提供更多的功能。它们同样也是实现企业服务总线（Enterprise Service Bus，ESB）的基础。在本文中，我们将对每个编程模型进行简单的概览。

Indigo 编程模型

Indigo 是微软最新的面向服务架构的编程模型实现，支持丰富的技术集合，用于“创建，消费，处理和传送消息”。Indigo 计划与下一版的 Windows Vista 一起发布。

Indigo 将服务定义为暴露一组端点（endpoint）的程序，每个端点是 3 个主要元素的组合 5 ：

• 端点的地址（address）——它是一个网络地址，通过它，端点可以被寻址。
• 端点的绑定（Binding）——它指明了与端点进行通信的额外细节，包括传输协议（如 TCP、HTTP）和编码策略（如文本、二进制），安全需求（如 SSL、SOAP 消息安全）等。
• 端点的契约（Contract）——它指明由该端点暴露的操作，被这些操作使用的消息，以及消息交换模式（Message Exchange Patterns，MEP），如单向、双向和请求 / 答复。

通过允许使用包含不同绑定和端点契约（QoS）的复合端点（multiple endpoints）来暴露相同的功能（服务），这些定义有效地扩展了基于 WSDL 的服务定义。

Indigo 编程模型的基础之一是使用 OO 实现 SOA 编程的所有方面。

SO 实体 OO 实体 标注 服务契约 接口 使用 _[ServiceContract]]标注接口 服务操作 方法 使用[OperationContract]标注接口方法 实现类 类 使用[ServiceBehavior]标注类，它由服务契约接口派生。 实现方法 方法 使用[OperationBehavior]_ 数据契约 类 使用 _[DataContract]标注类，[DataMember]_ 标注成员 表 1 Indigo 中的 SO 实体和 OO 实体的关系。

表 1 显示了 SO 实体与 OO 概念之间的映射（由 Indigo 编程模型定义），以及将它们关联起来的标注 6 。SO 与 OO 的融合既是 Indigo 的主要优点，也是它的缺点：

• OO 是被大多数开发者所熟悉的行之有效的范式。这意味着可以使用一种熟悉的技术开始开发新的面向服务架构解决方案。这种情况下，Indigo 运行时会在幕后将 OO 风格的调用转变成用来通信的可互操作的 SOAP 消息。
• SO 与 OO 有很大的不同。使用 OO 作为定义和实现服务的一种机制会创建出一个高度不匹配的实现（粒度、耦合等等），这可能导致非最优甚至苍白的面向服务架构实现。

Indigo 支持 2 种主要的服务调用方式：

• 携带一组类型参数（最初的 Web 服务版本）的 RPC 风格调用（同步和异步）。这种类型的服务调用非常类似传统的方法调用，使用在分布式对象和 RPC 实现中。
• 消息传递风格调用（同步和异步）。这种类型的服务调用类似传统的消息系统（类似本书前面介绍的语义消息传递）。

根据服务提供的访问类型（RPC vs. 消息传递），它的契约被定义成接口（RPC）或消息（消息传递）契约形式（参见表 1）。

Indigo 的另一个基本特性是：引入连接器（提供安全可靠的通信的托管框架）用于访问服务端点。通过将“管道部分”分离进入单独的类（类层次），并在大多数情况下提供“标准”实现，连接器减少了用于构建互操作服务所必须的“管道代码（plumbing code）”，从而简化了“被连接系统”网络的创建 7 。

Indigo 连接器使用很少的概念（端口、消息和信道），使得服务调用独立于传输协议或目标平台。它们中最重要的是信道（channel），它抽象了给（从）端口发送（接收）消息的处理过程。Indigo 5 中定义了 2 类信道：

• 传输信道（Transport channels）用于支持特定的传输协议，如 HTTP、TCP、UDP 或 MSMQ 和拓扑结构，如点对点、使用中介（intermediaries）的端到端、对等、发布 / 订阅。
• 协议信道（Protocol channels）用于支持特定的 QoS 特性，如安全信道加密消息和增加安全头。Indigo 使用 WS-*c 规范来实现协议信道。坚持标准使得 Indigo 的实现可以与其他基于 WS-* 兼容性实现的系统互操作 d 。

Indigo 同样支持组合信道概念——将一个信道置于其他信道之上。如，可以使用将安全协议信道置于 HTTP 传输信道之上来提供安全的 HTTP 传输通信。

Indigo 连接器提供了一个构建（Build）为中介提供支持，包括防火墙、代理和应用程序级网关。这些中介是成功实现 SOA 所必须的很多模式的实现基础，包括消息验证、安全性加强、传输层交换、监视和管理、负载均衡和基于上下文的路由。

除了支持业务服务创建，Indigo 还提供几个系统服务，它们可以被任何业务服务实现使用。这些服务的例子如下：

• 联邦认证。这个服务基于 WS-Federation，支持企业内部和来自外部边界的身份管理和验证。它的实现在服务和相应的可信凭证之间代理认证。
• 事务支持。这个服务基于 WS-AtomicTransaction 规范，简化了基于服务的事务编程（它支持 SQL Server、ADO.NET、MSMQ、分布式事务协调器（DTC）等）。

JBI 编程模型

Java Community Process 利用应用服务器托管应用程序的成功，将它的 JBI 实现建立在服务容器概念之上。

就像 Java 业务集成（IEEE 互联网计算） 8 中定义的那样——“JBI 是由容器和插件（Plug-in）组成的可插入式架构。这个容器托管使用消息路由进行通信的插件组件。架构上，组件通过一个抽象的服务模型（一个消息传递模型，位于任何特殊协议或消息编码之上的抽象层中）进行交互。"

在基于 JBI 的实现中，服务之间并不直接交互。取而代之的是，采用类似 EAI 实现中广泛应用的消息代理架构，JBI 容器扮演在服务之间路由消息的通用中介，（见图 1）。

图 1 通过 JBI 协调消息交换

分离交换的参与者（JBI 架构的基础 9 ）在服务提供者和消费者之间提供了解耦，以及一个用于协调（mediating）服务通信量（或插入所有额外需要的功能）的明确位置 e 。

此时，协调器（Mediation）可以支持广泛的功能，从消息传送和安全加强，到基于内容的路由和服务标本标定。

JBI 容器托管了 2 类不同的插件组件 9 ：

• 服务引擎（Service Engine，SE）。SE 本质上是用来托管 JBI 环境内部服务提供者和消费者的标准容器 f 。例如，在 JBI 环境中经常出现的 SE 包括数据转换器、业务规则容器和 BPEL 引擎。
• 绑定组件（Binding Component，BC）。BC 为 JBI 环境外部的服务消费者和提供者提供互联性。BC 允许集成不提供 Java API 的组件 / 应用程序，并使用远程存取技术访问它们。

组件间的交互利用了基于 WSDL 2.0 的标准化服务定义。WSDL 2.0 定义在服务消费者和提供者之间提供了共享的协议，并作为 JBI 实现互操作能力的基础。

除了标准化的服务定义，JBI 使用“通用化（normalized）”消息的概念支持全局组件互操作能力。消息通用化将协议与业务特定的上下文映射成一个通用的、可传输风格，这与 EAI 实现中经常使用的“规范（canonical）”消息表示概念非常类似 g 。

每个 JBI 容器存在于一个单独的虚拟机中，并容纳所有的 BC 和 SE，容器提供了一组服务，为 SE 和 BC 实现提供操作性支持。

JBI 也定义了基于 JMX 的标准控制集合，允许外部管理工具执行不同的系统管理任务，也可以管理组件本身。管理支持为以下情形提供了标准机制 9 ：

• 安装 plug-in 组件。
• 管理 plug-in 组件的生命周期（启动 / 停止等。）。
• 部署服务器件给组件。

服务组件架构（Service component Architecture，SCA）

尽管服务组件架构（SCA） 10 被作为规范定义（该规范定义了使用面向服务架构构建系统的模型），但它是一个有效的模型（该模型用来将组件组合成服务），并为服务组合成解决方案提供了额外支持。

SCA 基于 2 个主要的元模型 11 ：

• 类型元模型。
• 组合元模型。

类型元模型

这个元模型（见图 2）描述组件类型、接口和数据结构 11 。

图 2 描述组件、接口和它们依赖的元模型

一个组件实现由以下的 4 组规范定义 10 ：

• 被提供的接口——组件定义的接口集。这些接口通常定义为 WSDL 端口类型或语言接口，如 Java 或 C++。一个组件可以暴露 0 或多个接口。每个接口包含几个方法。
• 被要求的规范（引用）——组件实现使用的接口集。这些接口通常定义为 WSDL 端口类型或语言接口，如 Java 或 C++。一个组件可以有 0 或多个接口。
• 用来裁剪或自定义组件行为的属性。每个属性定义为一个属性元素。一个组件可以包含 0 或多个属性元素。
• 定义组件实现的实现元件。SCA 允许很多不同的实现技术，如 Java、BPEL、C++、SQL 等。SCA 为引入新的实现类型定义了扩展机制。

组合元模型

这个元模型（见图 3）定义了组件实例，以及它们是如何连接的 11 。

图 3 组件实例和它们在组合元模型中的连接

这个元模型中实例的概念有别于在 OO 中使用的实例概念。此处的组件实例是指一个带有被完整解析的属性集，为解决特殊问题而修改组件行为的组件实现。

一个组合定义了很多组件实例，它们彼此交互，这里的交互使用连线（wire）来定义。

在 SCA 中，连线使得绝大多数的底层代码被抽出（与 Indigo 中的信道类似）。如，连线可以被定义同步的或异步的，支持组件调用的事务行为等。SCA 在幕后处理这些底层细节。连线同样可以在任意方向上连接 2 个不同的接口语言（如 Java 接口和 WSDL 端口类型 / 接口），只要这 2 个接口定义的操作是等价的就行了。

除了连线，SCA 也支持通过特殊的组件类型，如导入（imports）和导出（exports），进行模块间通信。连线、导入和导出组件的结合使得组件可以引用外部服务。

组合元模型定义的组件组合，与服务组合既类似又不同，尽管两者都定义了使组件 / 服务一起工作的方式。通过被组合本身引入的功能，服务组合增强了参与服务的功能；而这个元模型只定义组件（更接近于服务实现）间的连接。

SCA 实现依赖于服务数据对象（Service Data Objects，SDO） 10 ，它提供了表示数据的通用模型的技术。SDO 是组件的数据交换基础。SDO 架构中的基本概念是数据对象——包含基本类型数据和（或）其它数据对象的容器。元数据提供了被包含数据的信息，它被数据对象显式引用。在 SDO 中数据对象的组合由数据图表示。除了对象本身，图中还包含变更概要，用来记录图中数据对象和属性在处理过程中变化的信息（类似微软环境中的 ADO）。除了 SDO，SCA 还引入了服务消息对象（Service message objects，SMO），它提供了服务间处理和交换消息的抽象层（类似 JBI 中的标准化消息）。

SCA 目前尚显稚嫩（本文写作时版本为 0.9），并且还不支持 SOA 实现要求的大多数模式。作为替代，目前 IBM 的 Websphere ESB/WPS 6.0 的 SCA 实现引入了协调器框架 12 ，它基于 SCA 并为协调器实现和定位提供了定义良好的机制。（类似 Indigo 中的中介）。

如果 GUI 支持，SCA 实现会非常强大，可以在面板上实现图形化组件的连接，这种方式正是 IBM 的 WebSphere Integration developer（WID） 13 14 中所实现的。

关于作者

Boris Lublinsky 在软件工程和技术架构方面拥有超过 25 年的经验。最近几年，他关注企业架构，SOA 和过程管理。在他的整个职业生涯中，Lublinsky 博士是一个活跃的技术演讲者和作者。他已在不同杂志超过 40 份的技术出版物上发表文章，包括：Avtomatika i telemechanica，IEEE Transactions on Automatic Control，Distributed Computing，Nuclear Instruments and Methods，Java Developer’s Journal，XML Journal，Web Services Journal，JavaPro Journal，Enterprise Architect Journal 和 EAI Journal。目前 Lublinsky 博士为大型保险公司工作，他的职责包括开发和维护 SOA 策略和框架。通过 blublinsky@hotmail.com 可以联系他。 - - - - - -

参考文献

1 Michael Beisiegel，Henning Blohm, Dave Booz，Jean-Jacques Dubray, Adrian Colyer，Mike Edwards，Don Ferguson，Bill Flood，Mike Greenberg，Dan Kearns，Jim Marino，Jeff Mischkinsky，Martin Nally，Greg Pavlik，Mike Rowley，Ken Tam 和 Carl Trieloff。“服务组件架构。使用面向服务架构构建系统”，2005 年 11 月。
2 B. Lublinsky。“ Web 服务调用框架，第一部分”。WebSphere 开发者期刊，2003 年 6 月。
3 B. Lublinsky。“ Web 服务调用框架，第二部分”。WebSphere 开发者期刊，2003 年 7 月。
4 Rob High，Jr.，Stephen Kinder，Steve Graham。“ IBM 的 SOA 基础。架构介绍和概览”。2005 年 11 月。
5 “ Windows 通信基础架构概览”。微软公司，2006 年 3 月。
6 David Pallmann。“ Indigo 编程：编程模型”。2005 年 7 月。
7 Chris Peiris。“ Indigo 编程模型”。200 年 6 月，15 秒。
8 Steve Vinoski。“ Java 业务集成”。IEEE 互联网计算，2005 年 7 月。
9 “ JSR 208: Java Business Integration (JBI) ”。
10 “规范：服务组件模型架构（SCA）与服务数据对象（SDO）”。
11 Tom Stahl 和 Markus Vlter。“模型驱动软件开发。技术，工程，管理”。Wiley，2006 年。
12 Nigel Daniels。“为 WebSphere 企业服务总线开发自定义协调器”。Developworks，2006 年 1 月。
13 Roland Barcia 和 Jeff Brent。“使用服务组件架构构建 SOA 解决方案，第一部分” 。IBM WebSphere 开发者技术期刊，2005 年 10 月。
14 Roland Barcia 和 Jeff Brent。“使用服务组件架构构建SOA 解决方案，第二部分” 。IBM WebSphere 开发者技术期刊，2005 年12 月。 - - - - - -

a 尽管 Apache Axis 和 Websphere 中的特有扩展提供了 JMS 支持，并且 Indigo 支持 MSMQ（见下），但是这些实现并不是标准。
b 尽管 WSE 2.0 及后续版本和 JAX-WS 提供某种类型的异步调用，但是这些实现有局限性，且离主流 SOA 实现尚远。
c WS-* 代表 Web 服务标准集合，包括 WS-Security，WS-Atomictransactions，WS-Addressing，WSPolicy，WS-ReliableMessaging 等等。
d 尽管这在理论上是正确的，但是目前很多 WS-* 规范仍在发展中，由不同厂商实现的不同版本的标准经常使得被宣传的互操作能力被削弱。
e 这种拦截是很多容器技术的基础，如 J2EE 应用服务器，微软的 MTS 等。
f 术语"容器"在 JBI 规范中有 2 种使用方式。服务引擎可以作为引擎特定功能的容器，而 JBI 环境本身是服务引擎和绑定组件的容器，因为这个原因，JBI 有时亦称"容器的容器" 9 。
g 规范消息表示不应与同样经常用在 EAI 代理中的规范消息结构相混淆。规范消息表示支持技术上的互操作能力，而规范消息结构的目的是提供业务上的互操作能力。 查看英文原文： SOA Programming Models

译者简介：胡键，自 2000 年西安交通大学硕士毕业后一直从事软件开发。2002 年开始使用 Java，在项目开发中经常采用 OpenSource 工具，如 Ant、Maven、Hibernate、Struts 等，目前正在研究信息集成方面的规范和技术。可以通过 jianhgreat AT hotmail.com 与他联系，或访问博客： http://foxgem.javaeye.com/ 。与 InfoQ 中文站分享内容，请邮件至 china-editorial@infoq.com 。