随着面向服务架构(Service-Oriented Architecture，SOA)使用率的增长，由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)的基础。在本文中，我们将对每个编程模型进行简单的概览。