面向服务架构SOA编程模型简介

　　随着面向服务架构（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编程的所有方面。