在开发Web服务和SOA的早期，应用开发人员开始关注于如何集成各种不同的应用及其元素——数据库也许是最好的例子。如今，可用数据服务十分丰富，包括来自像汤姆森路透社、Dun & Bradstreet等许多公司的产品。

　　Forrester Research分析师Noel Yuhanna说：“这是一个不断演进、不断扩张的世界，许多巨头都参与其中，出现了许多利基服务，不仅仅有财务数据，还包括了天气、资源和技术等等”。这些“数据服务”通常用XML来封装，组合起来然后导入到不同的应用中。为了更好地促进流量增长，一批利基参与者已经出现，包括像微软和IBM这样的IT巨头。

　　据埃森哲全球SOA实践的集成架构师Fawaad Khan的说法，在公司希望对一个外部的商用Web数据服务（或甚至是一个公共的已有数据源）进行治理的时候会面临诸多挑战。

　　“使用商用Web数据服务，首当其冲的问题是需要对前端接收的数据的质量和可靠性进行验证”，Khan说。

　　对于正在购买产品目录的员工来说，使用第三方的Web服务来获取条目及价格清单是非常吸引人的—可以在中途通过测试来发现数据质量问题。
　　
　　据Khan认为使用商用Web数据服务存在的另一个主要的风险是，作为一个业务实体，提供商的财务和组织稳定性方面的隐患。一开始就对商用Web数据服务提供商执行相应的尽职调查是一项明智的策略，可避免以后潜在的返工问题。

　　在内部，Khan表示你应当以某种方式设计企业应用，使得当商用Web数据服务因某种原因不可用时也不会丧失全部的功能。可考虑利用缓存技术，这是可行的，可将外部依赖最小化，并潜在地增强性能和响应能力，还能保证你的集成架构通过定义好的接口提供隔离。就算商用Web服务的传输或消息协议改变了，如从SOAP变成了RESTful，你也不必被迫对企业应用做出改变。

　　把目光放到外部，第一步通常是对感兴趣的Web数据服务分析其API，以便既能理解其输入输出，还能理解需要进行哪些类型的数据验证，从而去对Web服务进行成功的调用，以及如何在调用不成功的事件中如何处理例外。

　　可汗帮助许多客户设计并实现了基于SOA及Web技术的企业解决方案，他说到的第二点是，你必须考虑已有的消息格式（如REST、SOAP和Ajax）以及传输协议，并同时设计你的Web服务和技术平台，以便调用外部的Web数据服务。

　　接着，他提到：“如果你的应用天生就不支持Web服务集成的话，你也许还需要在内部的Web服务和感兴趣的企业应用之间设计和实现集成层”。

　　Khan解释道用开放的、基于标准或事实标准的技术，如HTTP、XML、JSON、Ajax等去调用商用Web数据服务，要比使用专有的工具和专门的技术或应用连接器好。通过运用企业服务总线（ESB）应用，这个过程是可以简化的。

　　Khan把ESB视为一种架构模式的实现，用以支持对Web’服务提供商和消费者之间的数据进行集成。一个ESB能通过支持各种服务质量保证（QoS）来实现跨企业的Web数据服务，包括有保证的交付、安全、审计/日志、仲裁和转换等，比如从外部的HTTP转为内部的JMS。换句话说，ESB是用来将消费者从Web服务提供商处解耦出来的，这样使得双方都可以随需求变化而演进。

　　因此，ESB能为更容易地实现Web服务的各种集成设计模式提供一个平台。例如，任何先进的ESB产品都能执行安全、数据验证、动态路由和转换（传输级和消息级均可）等工作，而且是即开即用。这些能力，若需要的话，应该从开源社区或商业供应商处获得，而非客户自行建立，他这样建议。

　　TT SOA编辑推荐：SOA数据集成学习指南

　　对由Web服务供应商提供服务的响应时间的服务水平协议进行完全性能测试是关键。此外，测试基于用户规模的可伸缩性也是很重要的，尤其是当与执行关键任务的企业系统集成在一起时。从运营的角度而言，捕捉审计信息，像进来的数据元素，它们的值以及在商用Web服务的响应时间，这些都有助于更有效地进行故障查找和问题解决。

　　最后他补充说：“不要低估实现安全功能，如验证和授权等，其所需的付出的努力的复杂性，这对于外部Web服务来说尤其是个挑战。”，特别是，如果你需要在限制其他功能的同时，还要为某些功能提供颗粒化的访问这种情况。