【IT168 技术文章】
介绍
今天，大多数SOA设计技术1,2,3 都是以定义服务为中心的。它们使用面向服务的分解原则，以业务流程为基础、企业业务/功能模型，要求的长期架构性目标和现有企业功能的重用。这种方法通常将现代企业最重要的资产之一——企业数据事后整合。本文中我们将重顾一个典型的SOA架构，概述处理企业数据的复杂性，并讨论几种将数据整合进入SOA实现的设计模式。
典型SOA实现
一个典型的SOA设计方法导致以一种专用层的形式实现企业服务，这个层次基于“理想的”企业业务模型3对现有企业功能(应用)进行了合理化处理。
这样的架构(图1)定义了SOA架构中的多个层次4：
以下是引用片段：
企业资源和操作系统层。这一层描述了现有应用系统的业务职责。(即，遗留系统，COTS和用户自己构建的系统)。
集成层。这一层使用不同的技术暴露现有企业资源和操作系统，这样它们就可以被业务组件使用。
业务组件层。企业业务组件是可部署的软件单元，它提供业务服务需要的功能。这些组件可以是刚刚被开发出来的，或是使用集成层去访问现有企业资源“包装器”。
业务服务层。业务服务提供整个企业的高级业务功能。这一层有效地嫁接了“理想”业务模型和现有企业IT资产——应用系统和业务组件。
业务流程层。业务流程允许通过编制业务服务来创建业务解决方案。
客户体验层。客户体验提供对客户(包括企业内部和外部)的支持，客户可以浏览和控制企业业务流程和/或服务的执行。这些客户可以是使用WEB或富客户端的人，或者是支持企业内部业务流程的B2B连接。
为了加强服务的跨平台的互操作性，这样的架构通常定义语义消息模型——企业范畴的业务对象，它们被服务接口定义使用。这些语义消息模型一般从相同的企业业务模型(被业务定义使用)中派生出来，因而确保所有的服务调用使用一个“通用语言”。结果是，典型的SOA实现有效地引入了两种不同的数据模型5 ——被服务接口暴露的“外部数据”和被服务实现使用的企业数据——“内部数据”。
企业数据存取问题
尽管典型的SOA实现在服务接口后面隐藏了企业数据，它仍然需要解决下面的数据存取问题：
统一多应用系统间的数据。今天的企业数据一般分散在多个应用“竖井”中。每个应用系统仅仅包含企业数据的一个子集(仅限于应用要解决的问题)，这些数据在应用系统之间常常存在重复。这种应用间的数据冗余造成了不准确的企业数据描述，以及应用间需要的定期数据同步，这些应用的每一个都是特殊功能/单元的“主”数据存储。此外，数据描述自身也因应用的不同而不同。这导致通常很难去调和单个应用系统的数据描述。随着单个应用的独立发展和进化，问题变得更加复杂。在一个SOA实现试图去表述企业范围的功能时，它需要操作基于一个定义良好的企业数据模型去进行操作。这意味来自服务实现企业数据存取，需要正确地调整和统一来自多个现有应用的数据，并且确保将数据变化传播到所有使用这个数据的应用系统中。
服务对企业数据的所有权。现代服务定义技术的基础——功能分解不能方便地映射到企业数据上。例如，客户(以及对应的数据)的概念通常被多个功能性服务共享。问题在于功能和数据的分解完全由不同的规则驱动。功能分解是基于企业业务流程——企业功能;然而，数据分解基于企业数据的分类法——企业数据模型的基础。这导致将企业数据向企业服务调整变成一项令人怯步的任务。
接口定义。因为服务调用总是远程的，服务设计倾向于大粒度接口，旨在最小化服务消费者和提供者间的服务流量(对话)。另一方面，依照数据存取的需求，需要高和细颗粒度的接口。最后，数据存取一般实现纯的CRUD(创建、读取、更新、删除)a功能，作为对企业服务实现业务有意义的接口，比如费率策略等。
SOA实现整合企业数据的模式
有好几种设计模式旨在使SOA实现支持企业数据，其中一些是已经广为认知，另一些则是刚刚兴起。下面我会描述三种最重要的。
使用业务服务协调企业数据支持
这是今天SOA实现的主流模式，与所有的SOA实现都合作得很好，如前面所示(图1)。在这个模式里，企业数据存取已经合并到业务服务实现中。数据通过集成层存取，服务实现自身负责定义和支持对特殊数据集的验证、存储、检索规则。这个设计模式的优点是能与所有的服务实现方法合作得很好。这个模式的缺点是：
服务实现不得不除了支持服务的业务功能之外，还需要支持所有的数据验证、存取和协调逻辑。这导致业务实现经常和数据存取以及转换的代码纠缠在一起。
在多个企业业务服务间共享业务数据需要额外的设计考虑，而且一般导致额外的企业服务间耦合。如果多个服务需要对企业数据的相同部分进行存取，可能使用下面的解决办法：
在多个服务间复制数据存取逻辑。这允许每个服务独立存取数据，但是需要在多个服务实现间复制数据存取、转换、同步逻辑。尽管，理论上在有可能在一个单独的组件上封装这些逻辑，以便被多个服务重用，但是实际上几乎不起作用。多个服务实现平台，比如J2EE VS. .Net VS 主机，需要这些组件的不同实现。此外，因为组件不是独立可部署的，该组件的每次变更都需要将依赖它的所有服务重新部署。
扩展一个服务的接口来包含操纵由服务控制的数据的CRUD方法。这个方法导致服务方法粒度的下降，抹杀了服务方法的业务意义。它还额外造成了企业服务间多余依赖，破坏了它们自治的本质。
事实上许多SOA实现都混合使用了上述两种方法。尽管这种模式一般适合小规模初级的SOA实现，但是对于企业级别的实现，它的扩展性不是很好。
