Web services被大肆宣扬，在市场是随处可见，也通常被人们误解。像所有的新技术一样，Web services用了很短时间就进入了人们的日常生活应用中。由于缺乏实现标准，Web services的发展受到了影响。
Web services建立在很多技术标准之上，并由世界上最大的技术公司如微软和IBM等支持。这些实现Web services的明确标准包括简单对象访问协议（SOAP）、Web services描述语言（WSDL）、通用描述、发现和集成（UDDI）。问题就出来了：那些就足够了吗？
答案是否定的。虽然Web services技术提供标准的定位、描述以及访问远程服务的方法，但是还有一些更重要的问题它没有涉及到，比如说数据标准、接口标准以及商业过程标准。
数据标准是指数据一致的格式。一般来说，工业界和应用程序中都会有一个数据标准。例如电子数据交换（EDI）就是一个很流行的数据标准，能被应用到很多行业和应用程序中。在新的应用程序中，这个标准变成了XML，但是XML本身并没有满足工业界和应用程序更多的需要。
数据标准问题的解决方法是XML应用程序——就是用一组特定的XML语法去描述一个特定的问题空间，比如说人力资源或者保健。但主要的问题是由于竞争这些标准被采用的速度非常快。解决方法就是遵守现行的标准，在不重新使用一个新的XML语法的情况下使其工作。
XML数据标准之外的另一个问题是接口标准。你可能会说，Web services提供动态定位和服务描述，所以接口标准很容易。但这还不够。
仅仅是因为公司注册了他们的服务描述并不意味着你不用担心他们的服务之间的接口的问题。想象你需要集成三个不同的供应商的基本服务，由于他们带的参数不一样，每个服务的接口也会有稍微的不同。对你来说很容易从一个UDDI服务器上取得每个服务的WSDL。但是你怎样将你的数据请求映射到每个服务呢？接口变了又怎么办？你的应用程序能自动地知道怎样重新映射请求吗？
因为接口只有很少的正式标准，所以公司更乐意将他们自己的接口作为接口标准。仅仅是因为你的接口建立在Web services之上不意味着你不要为每个连接点创建多“连接器”或者至少是“翻译器”。
很难说接口的解决方法是什么样的；但是现在已经有一些接口标准比较流行。由Sun微系统公司发起的Java团体化进程（JCP）打算建立一个团体来创建和支持标准Java接口。例如JCP包括七个Java规范要求（JSR）用以规范电信运营提供商（OSS）的管理。
公司间的商业过程也是非常困难的。Web services事务通常都是围绕对话模型建立的，所谓的对话模型是指使用多接口来发送多种类型的XML数据。对于其中一方，它以特定的顺序使用一组接口来发送特定的XML数据，而对于另一方，一次发送所有的数据。
即使是完成同一个目标的处理也可能非常的不同。有几个步骤帮助标准化Web services的处理过程。能使处理过程一致对于Web services架构来说意义重大。最流行的解决方案是由IBM、微软和BEA共同开发的Business Process Execution Language for Web Services(BFEL4WS)，它允许你制定模型或者一组动作来裁剪商业过程。很多集成工具提供商，例如Vitria等在它们的产品中也完全支持BPEL4WS。
