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

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

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

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。⁴。

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

WCF编程模型

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

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

• 端点的地址（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 WCF中的SO实体和OO实体的关系。

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

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

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

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

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

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

Indigo连接器使用很少的概念（端口、消息和信道），使得服务调用独立于传输协议或目标平台。它们中最重要的是信道（channel），它抽象了给（从）端口发送（接收）消息的处理过程。Indigo⁵中定义了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互联网计算）⁸中定义的那样——“JBI是由容器和插件（Plug-in）组成的可插入式架构。这个容器托管使用消息路由进行通信的插件组件。架构上，组件通过一个抽象的服务模型（一个消息传递模型，位于任何特殊协议或消息编码之上的抽象层中）进行交互。"

在基于JBI的实现中，服务之间并不直接交互。取而代之的是，采用类似EAI实现中广泛应用的消息代理架构，JBI容器扮演在服务之间路由消息的通用中介.分离交换的参与者（JBI架构的基础⁹）在服务提供者和消费者之间提供了解耦，以及一个用于协调（mediating）服务通信量（或插入所有额外需要的功能）的明确位置^e。

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

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

• 服务引擎（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的标准控制集合，允许外部管理工具执行不同的系统管理任务，也可以管理组件本身。管理支持为以下情形提供了标准机制⁹：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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