应用数据联合模式时，务必理解其特征以及其受以下所述的非功能要求的影响情况。一定要注意，我们列出的功能要求并不考虑缓存和数据复制模式。我们认为，当采用以基本模式（本例中为数据联合）为基础模式时，可以随后通过其他模式对其进行扩展，以便满足服务的额外非功能要求和功能要求。可以使用缓存和数据复制模式来补充数据联合或形成组合模式。应小心使用这些模式以及可以在总体实现中使用的其他模式，因为它们可能会妨碍最初选择数据联合来解决的一些非功能要求的实现。例如，它们可能会增加数据延迟和导致数据冗余。需要了解非功能要求和体系结构决策之间的得失。
非功能要求的所有特征既适用于传统的非 SOA 上下文，也适用于 SOA 上下文。其包括：
只有具有所集成源中的恰当凭据的用户和应用程序才允许访问集成视图。可以对此进行进一步的限制。应用此模式的一个主要原因是要利用现有源系统的数据和功能。因此，架构师经常还希望利用现有的安全机制，如源系统的身份验证和授权。由于此环境具有异构和分布式的特点，可能会出现数据联合模式外的有关单点登录和全局访问控制的挑战。为了应对这些挑战，架构师将需要把数据联合模式与其他安全相关的模式结合使用。
数据联合模式允许以实时集成的方式访问源，具有最高的数据并发级别。
由于能在接收到集成视图请求时实时地访问源数据，因此数据联合将始终返回最新的源信息。由于数据联合模式并不会创建源数据的副本，因此源更改并不一定要采用这种方法进行传播或处理。
由于需要执行的复杂数据清理、标准化和转换操作的频率增加，因此对总体响应时间造成负面影响的概率也会增加。这是由于数据联合模式中的请求对应的响应的实时同步特征造成的。任何额外的转换都将意味着响应集成查询时会存在额外的工作负载。最好的做法是尽可能减少所需的字段转换的复杂性和数量。
集成数据的可用性依赖于数据联合服务器和集成源服务器在请求时的可用性。如果某个服务器或联合与源服务器间的任何连接失败，集成视图就不可用。
数据联合模式的一个非常重要的好处是，能够屏蔽在源系统中实现的很多模型更改。如果能够将更改限制在联合服务器中，就可以减少将这些更改向服务的发起方或使用者公开的可能性。此外，还能够在无需将更改传播给数据源模型的情况下在集成视图中进行更改。
对联合服务器的请求是采用同步方式执行的。只要接收到响应，请求者就可以调用后续请求了。联合服务器应支持由多个请求者发起的并发请求。频繁的后续请求应该与单个请求具有相同的性能特征。如果源——或联合服务器和源之间的连接器——具有特定特征，在访问频繁时会导致响应性能下降，则可能会出现异常。联合服务器高速执行事务的能力是由联合服务器访问源系统的速度以及这些源系统响应的能力决定的。
在很多情况下，数据联合服务器都具有与数据库或内容服务器很类似的特征。有效管理并发访问的能力由数据联合服务器和所集成的源服务器的性能特征决定。
事务响应时间由很多因素决定，包括：
- 联合查询的复杂性：为了执行查询，联合服务器需要执行多少筛选、联接、排序之类的子操作
- 数据联合服务器的查询优化和处理功能：联合服务器的设计用于处理以下方面的成熟程度——接收联合查询，将其拆分为子操作并进行优化（例如，首先应用筛选器等一些子操作来减少数据集大小，然后执行排序等子操作）
- 数据量：数据量越高，每个子操作执行的时间越长，因此查询的完成时间也就越长
- 网络带宽：联合服务器和源之间的网络连接的吞吐量将影响联合服务器访问源的速度，因此也会影响联合查询的总体响应时间
- CPU 使用率：联合服务器和数据源所在的计算机上的资源使用率的差异需要影响总体联合查询的哪些子操作在联合服务器上执行、哪些在源上执行（如果可能）
- 源服务器的查询处理能力：有些源服务器在其处理和优化影响总体性能的查询方面具有特定的特征和限制
- 联合服务器标识每个数据源的最后查询策略的能力：如果联合服务器能了解源服务器的查询处理能力，则可以确定可委派何种类型的子操作以及何种子操作要在联合服务器层执行
数据联合模式（从分布源获取数据）实现的虚拟数据库的查询响应时间可能比在具有相同功能的单个物理数据库上执行相同的查询长。响应时间的差异将根据上面列出的各个元素的不同而有所变化。因此，在单个物理数据库中提供集成数据集的替代模式的响应时间会有所改善。数据联合模式的有些实现可以将部分或全部子操作（子查询）以并行方式发送到集成源系统。子操作的并行处理能够大幅度改进响应时间。
大部分联合实现都支持不同程度的读写访问。有些实现会对写入操作的逻辑工作单元进行协调，这被称为两阶段提交。在大多数情况下，由于写访问非常复杂，因此数据联合模式主要用于进行读访问。如果没有两阶段提交支持，请求者需在更新数据时负责确保源中的一致性。由于两阶段提交通常要求使用事务管理器，写访问的支持程度可能会根据事务管理器实现的不同以及源服务器在应用和提交更改方面的功能的差异而有所不同。
响应时间受到每个事务需要从远程源传输到联合服务器的数据量的影响：数据量越大，响应时间越长。优化联合查询对联合服务器非常重要，能尽可能减少必须在联合服务器和源之间传输的数据量，特别在联合数据量很大时更要如此。另外，务必还要了解网络基础设施所支持的功能和带宽以及可能对所传输的数据的数量和频率的影响。
正如价值主张中提到的，数据联合可以大幅度改进集成各种源时的交付时间。
数据联合模式的重点是数据源的集成和通过面向数据的接口提供单个系统映像。当将集成信息作为服务提供时，开发人员还将需要理解各个 SOA 概念、标准和技术。
有关定义数据访问和聚合的逻辑可以在不同的项目中加以重用。
数据联合并不会减少维护多个数据源的成本，但由于对现有数据源进行了集成和重用，可以获得更大的好处。
假定已经配备了联合服务器基础设施，则使用最好的联合引擎会相对较为廉价。
本文的重点是结构化数据的联合。目前，最常见的模型是采用 SQL 标准的关系模型。XML 和 XQuery 则是两项新兴标准，正越来越多地在信息管理中采用。数据联合模式的实现通常至少支持其中一种模型，有时候会同时支持这两类模型。数据联合模式的大部分实现都比较强调一个（或数量很有限的）目标模型，以最有效地处理请求。
在 IBM SOA 参考体系结构中，企业服务总线（Enterprise Service Bus，ESB）是基础设施中的一个关键组件。ESB 的责任之一是提供有保证的交付。由于协调逻辑工作单元（如在联合环境中通过两阶段提交协议进行协调）的复杂性，并非数据联合模式的所有实现都支持此功能。当使用支持此功能的联合服务器时，需要对其数据库锁定策略进行仔细分析，以避免对源系统的性能造成负面影响。
联合服务器仅在处理从使用者接收到的请求时才会使用资源。联合服务器的资源使用率水平是由请求的复杂性决定的：请求越复杂，查找将此联合请求分解为子操作的最优计划的任务就越复杂。资源使用率的另一个影响因素是需要在联合服务器上执行的子操作（如补偿源系统所缺少的功能）与可以下推到源系统的子操作的百分率比值。另外，从源系统接收到的数据量和需要通过联合服务器的数据量也影响资源使用率。
联合模式的重点是让数据保持在原来的位置，并提供实时的虚拟集成视图。此模式中的解决方案对可以应用何种转换并没有限制。可以在很多实现中使用基本转换来将异类源格式转换为联合层的公共视图。不过，复杂转换对联合模式的性能有负面影响，从而会降低此模式对此类场景的适用性。因此，大部分数据联合模式的实现对复杂转换功能的关注相对较少，而更强调查询优化技术。
数据联合处理有关集成来自异类源模型的数据的问题，包括将这些不同的源模型映射到联合层的公共模型的概念。数据联合模式的实现在其可以集成的具体源模型的能力方面各有不同。
当在运行时期间将基础源映射到集成视图时，源模型的大小、属性的数量和类型可能对映射任务造成负面影响。范围越大（例如要访问的属性数量越多），标识对应元素的时间可能越长。
联合服务器会将其接收到的每个请求的子操作转发到源系统。这将对源系统的资源使用率造成负面影响，因为需要对来自联合服务器的子操作做出响应。联合服务器接收到的请求越多，发送到所集成的源系统的子操作越多。
