面向服务架构从设计到实施再到测试，在这个过程中一些系统和服务之间不可避免的会产生代沟。可能是因为机构数据间旧基础设施元素二者分离时间太久，也可能是因为设计变化企图在系统和服务之间进行数据交换，或者参与数据流。

　　通常在这种情况下，我们会用传统的方法创建一个客户程序。这个客户程序理解数据表述，交易语法，并且能够在双方缺少联系的要素间提供通信功能。这样就可以把那些先前分离的要素联系在一起了。这个方法很管用。但是，许多人都认为他们很了解交易双方，实际上，他们只了解其中一方。因此程序的功能也受到了影响。此外，还有系统维护和升级这样更为令人头痛的事宜：当程序和服务必须维持互连变化时，二者之间联系的密码也要随之发生改变。IT部门越想弥补二者之间的差距，就越难建立这些程序。我认为“将来总会出台一个更好的办法来解决该问题”。但愿，读者的想法和我一样。

　　事实上，确实有许多更好的方法，但是几乎所有的这些方案都涉及到了XML。这是因为，XML能够出色地捕获数据表述，转换内容，并处理复杂句法，使这些方案能够在应用和服务之间建立起沟通的桥梁。有时在SOA维护polite fiction的同时，所有操作者的连通性也会得到维护，但是这种情况并不多见。

　　例如，考虑一下业内的移动销售和服务力量，它们能够愉快地接受命令，处理现场活动，业务原则必须确保所有的数据同步，但是通信只有在业内一些员工使用时才会发挥作用。另外还有一个普遍的情况就是，统一性是一个只有当多个供应商的系统和数据库相互发生作用时才产生的polite fiction。在这种情况下，有时需要将数据渗透到基础设施的各个角落，这样原先设想中的单个、统一数据套装，现在终于得以真正实现了。

　　微软公司的ADO.NET可以帮助我们在分离的基础设施组件之间建立一个传递数据的结构。它也可以帮助我们解决与版本相关的问题（是否当前版本是最新版本？）以及一致性问题（跟踪读取的用户，更重要的是编写数据，防止不完整或者错误的升级）。当应用访问数据时，Snapshot机制也会发挥作用，在反对数据以前，它们首先要对数据进行快照：应用完成工作之后，我们会拿原始快照和完成后的主集进行比较。如果二者仍旧是相同的，升级就完成了，如果二者不同，则需要新的快照，并重新启动升级过程。

　　ADO.NET使用XML在SOA各要素之间进行通信，以便传递数据。这意味着只要寄件人和接受者都能意识到XML，就可以保证所有的数据都精确的得以描述，并且可以在二者明确、清晰理解XML的基础上交换数据。二者可以共享Schema， DTD 或者原语言描述。因为ADO.NET是在这种方式下工作的，寄件人和接受者在交换数据时不一定必须实施ADO.NET。只要双方都能接受XML形式的输入，并创建一个XML形式的输出，数据交换就可以继续进行。

　　服务数据目标或者SDO为SOA抽取数据访问提供了一种方式。当数据库作为数据源和汇时，ADO.NET运行十分顺利，但是SDO不只限于特定的几个类型的数据源。SDO 定义了一个松耦合架构，在该架构中，用户在操作源内容时，不必为数据源维护活动连接。SDO常用于为服务组件架构定义一个标准机制，一个服务组件集成模型。

　　他们的方法就是用一系列工作中的数据建立一个相互关联的数据目标图表，并跟踪图表发生的变化，以及图表中所有节点的原始状态。这叫做变化概要。其本质就是要审核所有操作，以及这些操作发生的相应的变化。该图表方法可以使用户将通信限定在工作所需的范围内，并提供了一个用于决策的一致性机制。

　　同ADO.NET一样， SDO也依赖XML描述通信的本质。这个描述数据的图表机制，在整个结构中进行导航，进行价值比较，处理升级，以及数据变化，所有的这一切都是在明确、清晰的XML基础之上完成的。因此，任何能够以XML形式输入并产生XML的服务，流程或者应用都可以使用SDO。

　　该方法回避了许多在操作特定编程语言时固有的问题。例如Java或C#，在所有的通信方，它们依靠一个共享的运行时间环境。ADO.NET和SDO的XML基础令开发商将注意力集中到数据交换上，帮助他们解决间歇式SOA或者连接式SOA基础设施中固有的问题。要想确保数据在需要时可以及时的被使用，并要保持数据的现实性和准确性。没有哪种方法是一成不变的。但是它确实提供了一种令广泛分散的系统和组件在SOA相互联系的一种方式。