【IT168 技术文章】
随着面向服务架构（Service-Oriented Architecture）使用率的增长，由Web服务API（目前最流行的SOA实现技术），如Java中的JAX-RPC或.NET中的Web服务扩展（Web Services Extension，WSE）API，所提供的抽象级别对于有效实现SOA越来越显得力不从心：
这些API的语义更偏向服务调用的技术方面和SOAP处理过程，其次才是服务的使用和支持。
它们中的大多数只提供SOAP over HTTP的支持，对于SOA实现来说，这并不总是最优的传输方式。
它们中的大多数只提供同步和单向的服务调用，而这只是服务交互风格的子集。
这些API直接暴露给实现代码，导致了以下后果：
业务实现代码经常与服务通信支持代码搅和在一起，它使得实现、理解、维护和调试变得更加困难。
任何API改变（至少每一年发生一次）都要求在业务实现中更改。
这些API对于很多重要的服务运行时模式没有提供直接支持。如，要实现动态路由请求必须自己编程，同时使用额外的API（Java中是JAX-R）来访问注册中心。
目前尝试通过定义SOA编程模型（其中，从其他技术中借用了很多元素）来提高API的抽象级别，这样可解决当前API集合中的一些问题。编程模型的目标是，降低应用程序开发者直接处理中间件或Web服务特定API时面临的复杂度。通过从业务代码中移除大部分的通信支持，并将它们隐藏在编程模型抽象/实现之后，这样可以获得以下好处：
简化业务服务的开发。
简化作为服务网络构建的业务解决方案的装配和部署。
增加敏捷和灵活性。
保护业务逻辑资产，使其不受底层技术改变的影响。
改善测试能力。
Web服务调用框架（Web Services Invocation Framework，WSIF）是创建这种模型的最早尝试之一，最初由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）的基础。在本文中，我们将对每个编程模型进行简单的概览。
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编程的所有方面。
表1 Indigo中的SO实体和OO实体的关系。
表1显示了SO实体与OO概念之间的映射（由Indigo编程模型定义），以及将它们关联起来的标注6。SO与OO的融合既是Indigo的主要优点，也是它的缺点：
OO是被大多数开发者所熟悉的行之有效的范式。这意味着可以使用一种熟悉的技术开始开发新的面向服务架构解决方案。这种情况下，Indigo运行时会在幕后将OO风格的调用转变成用来通信的可互操作的SOAP消息。
SO与OO有很大的不同。使用OO作为定义和实现服务的一种机制会创建出一个高度不匹配的实现（粒度、耦合等等），这可能导致非最优甚至苍白的面向服务架构实现。
