将企业数据存取封装为业务服务
克服上一个模式缺点的一种方法就是将企业数据存取当作第一级的业务服务。在这种方式下，业务服务的一种特殊类型——数据服务——封装了所有企业数据存取、同步、验证、转换需要的逻辑。这个模式的优点是：
服务功能(业务逻辑)的实现和企业数据支持逻辑的实现在关系上的明确分离。企业数据服务有效地创建了一个抽象层，使业务功能避开数据存取细节。
通过将非常稳定的数据存取代码从服务实现中分解出来，获得更佳的实现划分。
类似其他业务服务，数据服务的接口通常也基于企业语义模型。通过业务服务大大简化了企业数据的消费。
这个模式的缺点是：
因为企业数据大多数来自于企业应用系统，数据服务的实现将一般类似业务服务的实现——它由实现数据存取逻辑的组件和使用集成层来存取存在于现有应用系统的数据的组件一起构建。这使得常常很难区分以功能重用为目的的集成和以企业数据存取为目的的集成。企业数据存取集成，一般不会直接依靠企业数据存储——在数据存取和验证时，它们通常利用已有的遗留实现。这导致通常不容易把一部分实现归为单纯的数据服务或者业务服务。
正如我们上面提到的，一个典型的数据服务接口设计是CRUD，它被认为是服务接口设计的反模式6。此外，因为数据服务需要支持一个范围广泛的企业数据存取选项(被业务服务所需求的)，它们必须具备高度的灵活性。这些需求通常反映在数据服务接口的低粒度上。
通过专门的数据服务集中化所有企业数据的存取要求业务服务的所有数据存取也通过这些数据服务完成。这样的实现导致完全的“聊天式(chatty)”实现，造成在数据服务上业务服务的强依赖性，这会一定程度上破坏服务的自主权。最小化这些依赖的一个方法是创建服务流程(组合服务)，它管理基础服务需要的所有企业数据，将所有需要的企业数据当作一个参数集传给业务服务。尽管这个方法改善了业务服务的自主权，它通常导致流程状态和服务消息的“膨胀(bloating)”，对业务流程的伸缩性和服务调用性能有负面影响。
企业数据总线
今天SOA实现最流行的方法之一是使用企业服务总线模式7，它允许“可视化”企业服务存取b。 同样，企业数据总线允许可视化企业数据存取。从大多数方面来说，这个模式类似上面描述的企业数据存取服务。与将数据存取提升为第一级的业务服务不同的是，在这个方法中，这个模式作用在集成层上，它提供了任意服务直接访问企业数据任意部分的功能，如图2。
企业数据总线的起源可以追溯到数据库联邦技术——可视化存取企业中的异种数据库。不幸的是，这个技术对于SOA实现几乎不具有可应用性。这儿的问题是现有应用通过实现数据存取和验证逻辑有效控制了企业数据的访问。绕过这些应用系统直接访问数据库，需要重新实现这些逻辑，一般说来这很不划算。结果是，数据总线一般由集成层(图1)实现。市场上的新产品，例如IBM Information Server8就支持直接数据库存取和集成两种方法。这种产品通过“搭配”集成解决方案和直接数据库存取c，扩展了企业数据总线实现的灵活性。有效地实现这种模式，需要将提供企业数据存取的集成和提供企业功能能力的集成进行分离。考虑到数据和功能集成两者都获取/返回企业数据d，最直接的方法是考虑所有的集成都作为数据存取集成e。这导致SOA实现的全面修改。(图3)
这种实现(图3)增加了额外的一层——企业数据总线，它提供对包含于企业应用或是应用下属数据库中的企业数据的存取。这也修改了企业组件层的实现;在这种实现中它不再包含“包装器”组件。这种情况下，业务组件将仅仅由基于现有功能实现的服务功能组件和使用企业数据总线的数据存取组件组成。这种模式的优点是：
服务功能(业务逻辑)和企业数据支持逻辑的实现在关系上的明确分离(和上一个模式相似)。企业数据总线有效的创建了抽象层，使业务功能避开企业数据/功能存取的细节。
通过封装对企业数据/功能的所有访问，企业数据总线给所有的企业语义数据模型和企业应用系统的数据模型间的转换提供了一个单一位置。
这种情况下，因为任何服务实现能访问它需要的任意企业数据，这样的实现允许显著地减少服务间的耦合——服务调用仅仅包含极少变化的数据引用(键)，而实际的数据存取由使用企业数据总线的服务自身来实现。这意味着如果服务实现需要用于它的流程的额外数据，它可以在不影响它的消费者的情况下直接存取到数据。
这种模式的缺点是：
由于大量的存取(同步)，性能成为企业数据总线最重要的指标之一。总线上任何的一个性能下降，都会大大破坏SOA实现。
结论
随着SOA实现的范围从局部部门级实现扩展到企业范围，企业数据存取迅速成为最重要的实现问题之一。 如果每次一开始都不能正确的架构，企业数据存取将成为一个主要拦路虎。本文中展示的设计模式定义了在SOA环境中处理企业数据的不同方法，以及每个方法优缺点。
