随着面向服务架构（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）的基础。在本文中，我们将对每个编程模型进行简单的概览。
