SOA 中的数据联邦技术解密

  • 胡键

2008 年 10 月 17 日

话题:SOADevOps语言 & 开发架构

通常来说,大部分企业不会明智到从其创业伊始就开始着手建立 SOA 的地步。在他们打算实施 SOA 时,不论他们是出于什么原因和目的,企业内部已经堆积了大量支撑业务的系统。而你,作为 SOA 的实施人员,“如何有效地利用这些浩如烟海的数据”是你不得不面对的问题。

无法访问,就无法利用。关于如何在 SOA 环境中有效地访问数据,已经有了大量的文章,而 Oracle 的Dain Hansen最近在SOA 杂志 上发表的文章《Demystifying Data Federation for SOA》不失为是对这些文章的一个很好总结。同时,正如标题所暗示的,它也是一篇关于数据联邦的很好介绍。

在 SOA 环境中,数据的访问也是通过服务实现的,只不过在这里它被叫做“数据服务”。Dain Hansen 在文中指出了数据服务的作用:

为了更好地访问聚合管理数据,数据服务将数据源转换成了可重用的组件。

至于导致数据服务出现的原因,Dain Hansen 总结:

  • 数据无处不在。
  • 数据来自结构化和非结构化数据源
  • 没有数据服务,数据访问将非常复杂
  • 随 IT 实现不断增加而出现的“意大利面条式”的点对点数据消费方式
  • 缺少实时、统一、跨多个数据源的数据视图很难保证数据的一致利用

同时,他列出了 3 种常见的数据服务实现方式并给出了优缺点:

  • 简单数据访问:将数据源封装成适配器,消费者使用它来访问各个数据源,并自行将数据进行组装。
    • 优点:简单、低前期投入
    • 缺点:不适于大型 SOA 项目;当元数据频繁变动时,数据分析师和消费者将面临令人头痛的映射管理问题。
  • 数据集线器(Data Hub),利用 ETL 方式将数据抽取、加载和转换到一个统一的数据集线器中,消费者通过集线器访问数据。
    • 优点:主要适用于数据仓库和 BI 应用,对于大批量数据实现有良好的伸缩性;合并后的数据为访问和管理数据提供优化;可离开原始来源进行脱机管理。
    • 缺点:依赖数据复制,为了保持数据同步要求具有"数据变更捕获(Change Data Capture,CDC)"特性;对于小型 SOA 实现来说,技巧要求太高;在某些情况下,数据不允许复制。
  • 数据联邦服务(Data Federation Service),将来自多个来源的数据聚合成一个数据视图,并作为服务被应用利用。
    • 优点:简单、可重用、数据管理方便,并且不依赖复制和同步。
    • 缺点:需要密切关注它的性能

根据以上列表,虽然存在潜在的性能问题,数据联邦无疑是 SOA 环境下理想的数据访问模式。在接下来的文章中,Dain Hansen 对数据联邦进行了简要介绍。并指出,一个联邦解决方案应该包含:

  • SOA 的数据源抽象层
  • 联邦、经优化的查询
  • CRUD 风格的数据更新
  • 丰富的层次结构
  • 安全

在实际应用中,Dain Hansen 认为并不存在“一刀切”的模式选择。并指出:

事实上,多数务实的组织一开始是以“点对点”方式集成业务服务,并只在必要的时候想虚拟化的方法转变。

无独有偶,James Kobielus 在其文章《Federation Supplements The Data Warehouse - Not Either/Or, Never Was》中认为,数据联邦和 EDW(Enterprise Data Warehousing,企业数据仓库)(译注:在不考虑其后续分析功能的前提下,该方式基本和 Dain Hansen 文中所说的数据集线器一样)是互补的,并认为:

……数据联邦比部署于大多数企业中面向批操作的 EDW 更适合近实时的 BI 需求。

在文末,Dain Hansen 以数据联邦在一个金融组织中应用案例结束了本文。并认为:

随着数据仓库、SOA 和 BI 技术的日益成熟,数据服务将可能继续演变。

欲了解全文的内容,请参见这里

关于 SOA 中数据的其他内容,请参见 InfoQ 的其他文章:

SOADevOps语言 & 开发架构