通常来说,大部分企业不会明智到从其创业伊始就开始着手建立 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 的其他文章:
评论