理想的基于面向服务的体系结构系统设计的需求是在服务消费者与服务提供者之间进行解耦。解耦可采用多种形式，其范围从静态(在编译时通过请求端存根来解耦)到全动态解耦(在所有服务调用的运行时完全封装并建立解耦)。显然，全动态解耦是一个严格的要求。如果一个服务被动态解耦，然后服务特性中的更改导致了服务实现中的修正，但是所有其它的系统元素，特别是调用机制，仍旧保持不变。这种设计的优点显而易见。
对于 SOA 与 Web服务的更强大功能与性能的日益增长的期望与需求经常导致显著增长的软件复杂性。今天，SOA 实现的实际情况是，尽管规划了服务的功能模块化，但是它们仍旧经常与独立的中间件或通信协议(如基于 MOM 的 JMS、HTTP/SOAP 等等)耦合。在大多数组织中，当应用程序扩展功能时，开发者关注的，在某种程度上，是静态解耦(通常是指绑定)，并强制为每一个 Web 服务创建独立的客户端，而不是单独的能够同时访问多个服务的客户端。
静态绑定的局限性是非常明显的——代码中的静态绑定阻止了不同应用程序中贯穿整个企业的服务的重用。简而言之，即使需要提取并封装所用的不同中间件及协议来执行服务组件之间的交互，这些组件被包括在服务消费者与服务提供者的交互中，这样的需求非常普遍，但是封装了 Web 服务接口的体系结构还未得到广泛应用。造成这种状态的其中一个主要原因就在于，尽管动态绑定的几种机制已被设计用来适应这种局限性，但是对动态绑定相关联的实际技术依然存在很多的误解。
Web 服务调用的剖析
已经有许多关于 SOA 最重要的概念——服务接口(换句话说，调用功能)及在运行时如何定位并调用它们的文章。换句话说， Web 服务调用应该在后期绑定。需要指明的是 Web 服务调用已经被设计为传统的 Remote Procedure Call(RPC)方法，该方法准许一个应用程序调用由第二个应用程序发布的功能。RPC 工作方式如下(如图 1 所示):
被调用的应用程序的功能是以本地功能的形式展示给调用的应用程序的。
通过向调用的应用程序提供功能存根达到定位透明性。
功能存根，当它被调用时，访问一个中间件层，该层向被调用的应用程序传输调用及其相关的数据。
图 1. 基于 RPC 的 Web 服务调用
在 Web 服务中，存根代码通常是自动产生的，并且是基于使用被调用的功能的接口描述，它通过 Web 服务描述语言(Web Services Description Language，WSDL)来表示，并创建了存根 shell。此外，存根通常是在应用程序开发的编码阶段产生，因为存根是主要是从应用程序代码中直接调用，而且，结果是必须在编译时解决的(换句话说，即所谓的前期绑定)。
大多数应用程序开发者，主要是 Java 开发者，认为使用这样的存根是必要的，因为对他们来说，如何处理从调用服务返回的复杂数据类型是不清楚的。当然，来自被调用应用程序功能的数据必须同 SOAP 消息相分离，而且，当使用 Java 的时候，必须有一个相对应的(兼容的)实现序列化接口的类。显然，同样的存根产生工具被用于产生那些所需求的类。
