在SOA中整合企业数据.pdfVIP

在SOA 中整合企业数据 作者 Boris Lublinsky 译者 王志雄 发布于 2008 年2 月4 日 下午10 时28 分 介绍 今天，大多数SOA 设计技术1,2,3 都是以定义服务为中心的。它们使用面向服务的 分解原则，以业务流程为基础、企业业务/功能模型，要求的长期架构性目标和 现有企业功能的重用。这种方法通常 将现代企业最重要的资产之一——企业数 据事后整合。本文中我们将重顾一个典型的SOA 架构，概述处理企业数据的复杂 性，并讨论几种将数据整合进入SOA 实 现的设计模式。 典型SOA 实现 一个典型的SOA 设计方法导致以一种专用层的形式实现企业服务，这个层次基于 3 “理想的”企业业务模型 对现有企业功能（应用）进行了合理化处理。 图1 典型SOA 实现 4 这样的架构（图1）定义了SOA 架构中的多个层次 ：  企业资源和操作系统层。这一层描述了现有应用系统的业务职责。（即， 遗留系统，COTS 和用户自己构建的系统）。  集成层。这一层使用不同的技术暴露现有企业资源和操作系统，这样它们 就可以被业务组件使用。  业务组件层。企业业务组件是可部署的软件单元，它提供业务服务需要的 功能。这些组件可以是刚刚被开发出来的，或是使用集成层去访问现有企 业资源 “包装器”。  业务服务层。业务服务提供整个企业的高级业务功能。这一层有效地嫁接 了 “理想”业务模型和现有企业IT 资产——应用系统和业务组件。  业务流程层。业务流程允许通过编制业务服务来创建业务解决方案。  客户体验层。客户体验提供对客户（包括企业内部和外部）的支持，客户 可以浏览和控制企业业务流程和/或服务的执行。这些客户可以是使用 WEB 或富客户端的人，或者是支持企业内部业务流程的B2B 连接。 为了加强服务的跨平台的互操作性，这样的架构通常定义语义消息模型——企业 范畴的业务对象，它们被服务接口定义使用。这些语义消息模型一般从相同的 企 业业务模型（被业务定义使用）中派生出来，因而确保所有的服务调用使用一个 5 “通用语言”。结果是，典型的SOA 实现有效地引入了两种不同的数据模型 —— 被服务接口暴露的 “外部数据”和被服务实现使用的企业数据—— “内部数 据”。 企业数据存取问题 尽管典型的SOA 实现在服务接口后面隐藏了企业数据，它仍然需要解决下面的数 据存取问题：  统一多应用系统间的数据。今天的企业数据一般分散在多个应用“竖井” 中。每个应用系统仅 仅包含企业数据的一个子集（仅限于应用要解决的 问题），这些数据在应用系统之间常常存在重复。这种应用间的数据冗余 造成了不准确的企业数据描述，以及应用 间需要的定期数据同步，这些 应用的每一个都是特殊功能/单元的 “主”数据存储。此外，数据描述自 身也因应用的不同而不同。这导致通常很难去调和单个应用系 统的数据 描述。随着单个应用的独立发展和进化，问题变得更加复杂。在一个SOA 实现试图去表述企业范围的功能时，它需要操作基于一个定义良好的企业 数据模 型去进行操作。这意味来自服务实现企业数据存取，需要正确地 调整和统一来自多个现有应用的数据，并且确保将数据变化传播到所有使 用这个数据的应用系统中。  服务对企业数据的所有权。 现代服务定义技术的基础——功能分解不能 方便地映射到企业数据上。例如，客户（以及对应的数据）的概念通常被 多个功能性服务共享。问题在于功能和数据的分 解完全由不同的规则驱 动。功能分解是基于企业业务流程——企业功能；然而，数据分解基于企 业数据的分类法——企业数据模型的基础。这导致将企业数据向企业 服 务调整变成一项令人怯步的任务。  接口定义。因为服务调用总是远程的，服务设计倾向于大粒度接口，旨在 最小化服务消费者和提供者间的服务流量（对话）。另一方面，依