公司和组织间的合并和收购通常要求数据和应用程序架构师将异类数据源集成到数据的统一视图中。此类集成信息的使用者是直接与数据库交互的传统应用程序，需要能够访问经过扩展的数据源集。有关如何最好地提供此统一视图的决策通常是根据组织中的工具可用性、经验、专业知识以及企业文化做出的。使用传统遗留体系结构时，与集成关联的时间、工作量以及成本可能会超过所带来的业务好处。在基于服务的环境中实现了基于模式的信息服务方法后，可以增强系统长期的可重用性特征。
信息服务是 SOA 的核心中枢的一部分。这些信息服务提供了对域信息的创建、读取、更新和删除 (CRUD) 访问。它们还可提供各种信息处理功能，如通过分析和评分算法、数据清理规则等进行处理。对于本文，我们将重点讨论可提供统一数据视图的信息集成服务，而这通常会涉及到对各种异类后端源和服务进行集成。
应用数据联合模式时，我们需要对两个上下文进行区分：传统的非 SOA 上下文（由很多以前的应用程序加以处理）和 SOA 上下文（本文的重点）。务必记住，SOA 是一种体系结构方法，可通过其得到可重用服务，能在很多情况下扩展现有非 SOA 实现的功能。
在我们称为传统上下文的环境中，银行的报表应用程序可能需要分析信用卡事务。考虑到此数据的量（每天数百万事务），将所有这些信息存储在分析数据仓库中并不是有效的办法。会频繁访问很多旧数据，将其作为特定的上下文信息，如旅行路线等。将所有信用卡事务数据——当前的和过期的、核心的和相关的——存储在数据仓库中会对性能造成负面影响。一种更好的解决方案是将两种类型的数据加以分离：例如，可将常用、最近使用的信息库事务存储在数据仓库中，而将旧信息存储在磁带上。不过，报表应用程序应该不需要知道这种可通过联合方法提供的数据分布。
在此传统上下文中，应用程序通常使用标准关系接口和协议来与联合服务器（如 SQL 和 JDBS/ODBC）交互。联合服务器将随后通过各种适配器或包装连接到各种数据源，如关系数据库、XML 文档、已打包的应用程序和内容管理及协作系统。联合服务器是一个虚拟数据库，具有关系数据库的所有功能。请求应用程序或用户可以在其访问权限内执行任何查询请求。查询完成后，将返回一个结果集，其中包含满足选择条件的所有记录。此过程如图 1 中所示。此图旨在演示可以基于使用 SQL (JDBC/ODBC) 或 XQuery 的关系应用程序编程接口的传统实现。
在 SOA 上下文中，服务 getCustomerCreditCardData 可能需要检索有关客户及其信用卡事务的全面信息。此信息可能并不是驻留在单个系统中。客户信息可能存储在客户主数据管理系统或多个存储库中，而信用卡事务则可能存储在另一个数据源中。数据联合将对来自多个源的信息进行联接，以便能作为服务向使用者提供。
在此 SOA 上下文中，联合服务器充当使用 SOA 一致接口的服务提供者和/或服务使用者。请注意，这并不排除服务器还会提供对传统关系接口的支持。支持的深度是一项实现决策，这超出了本文所讨论的范围。当数据联合服务器将集成信息作为服务提供者公开时，服务使用者可以通过服务接口（如 WSDL 和 HTTP/SOAP 或其他事前确定的绑定）来访问此集成信息。数据联合服务器可以使用（为了集成）多个信息源提供的服务。
在 SOA 上下文中使用数据集成模式的基本想法是利用和重用集成信息，即，信息集成服务能以可扩展的方式供各种使用者使用。服务的建模和定义是 SOA 的关键方面。一个受到广泛认可的非常好的实践是，将服务设计为能提供信息或功能的重用和/或跨企业互操作性和/或业务流程支持。很多（如果不是大多数）成功的 SOA 项目都将重点放在作为服务公开的最重要、最广泛使用的业务功能上。由于这些服务扮演着关键的角色，因此经常会涉及多个后端系统。因此，从多个异类源收集信息是 SOA 依赖的一项重要需求和功能。服务并不是传统数据访问上下文中的查询，而是对业务实体的请求，可以由联合服务通过一系列查询和其他服务加以满足。
在 SOA 内启用信息集成服务需要使用额外功能，以在面向服务的接口中封装联合访问。这是通过 Information Service Enablement 实现的。此组件用于在面向服务的接口中提供一些联合查询。例如，可以使用 SQL 编写联合查询，并可以指定对产品信息的访问。通过 Information Service Enablement 组件，此联合查询可以作为使用特定机制（如 SCA 或 WSDL）定义的服务提供。实现对产品数据的访问的服务可以随后在整个企业内和企业外进行共享。
在传统上下文中应用数据联合模式的解决方案可以利用 SQL 的声明性和灵活性特征。通过使用恰当的安全凭据，使用者可以访问源中的任何数据，而此过程可能涉及的不同 SQL 查询的数目几乎没有限制。使用者在访问的内容及结果返回的格式方面具有极大的灵活性。尽管在很多情况下，这个灵活性是一个很大的优势，但也增加了使用者所面临的复杂性。使用者必须了解源数据模型以及如何从这个基础源数据模型构造结果。源数据模型越大，此任务就会变得越复杂。
SOA 方法的重点是首先将数量相对有限的最关键业务功能定义为服务，并在整个企业内和企业外进行共享。因此，面向服务的接口更多的是关注数量有限的需向外提供的特定信息请求。这个清楚而集中的重点可为开发人员带来好处，因为这样可以减少他们设计信息请求的时间。他们可以直接从数量相对有限的选项中选择恰当的服务。
