企业数据管理是 SOA/BPM 硬币的第三面吗？

上周，EDS 名士及 SOA 老将 Fred Cummins 写了一篇名为《SOA 中的数据管理（Data Management for SOA）》的短文。他在文中探讨了，在获得重用及支持变化的环境下，服务设计的某些关键原则（“松耦合”和“自治”）与企业数据的关联之道。

尽管 Fred 承认这些原则是交付 SOA 价值的关键：

SOA 的价值来自在多种业务背景下集成服务的能力，以及在对业务进行优化和适应的同时尽量不影响用户。

但是他还写道：

但是，这种解耦和自治与共享数据库的使用格格不入。

几十年来，那些关注数据管理的人，在紧耦合意味着更好的效率和一致性的哲学下，驱使行业不断合并数据库。

那些数据大师一直都反对让企业数据管理接受 SOA 的松耦合。

他指出， Jill Dyché推荐：

从主数据着手进行 SOA。这听起来并不直观，因为 SOA 讨论的是如何将标准化的业务流程以服务方式交付，但是对于那些只是刚刚开始思考 SOA 的公司来说，“数据即服务”的概念实际上更可行。

以及 Dan Gardner 在“ SOA 和计算云标志着对数据的全面反思：按照角色和权限，而不是行和表”中观察到的：

大多数的企业数据不再被 IT 组织控制

但是 Fred 摒弃了这两种想法，他发现它们只刚刚与 SOA 沾点边。他主张：

在 SOA 中仍然必须重点关注的数据是，由那些代表企业过去、现在或未来状态的业务系统产生、消费和管理的数据。从一个业务角度看，关注点并不是分布式存储，而是数据验证、管理和保护的方式。

Fred 指出他同意 Steve Karlovitz 所说的：

作为所有企业数据存储的单一入口点，实现数据服务层的好处很多。 - 可以一种集中的方式来进行数据访问。

• 各种业务规则将作为数据转换如何发生的参考。
• 通过一个单一入口点，诸如优化和转换这样的问题可以被解决。
• 确保数据的完整性和安全。
• 组织将极大缩短将新特性推向市场的时间。

但是问题是，我们如何设计这个数据服务层？Fred 提出了 3 种不同的可能：

1. 数据服务层是一个数据访问工具，通过所有应用都使用一个共享的数据库正规视图来实现对数据库访问的支持。类似一个对象 - 关系转换工具，
2. 来自各种异构应用数据库的数据被复制和集成到拥有正规数据模式的单个企业数据库中，
3. 通过将请求表达成在一个正规、虚拟的数据库上的查询来提供对异种数据库的访问。

方法 1 基本上是一个共享数据库概念。Fred 指出它基本上是不切实际的，因为：

许多服务将继续使用包含它们自己数据库的遗留或 COTS 系统，并且服务单元实现的异质性是 SOA 机动性的基础。

方法 2 利用了现在在企业数据管理和商业智能讨论组中很普遍的“操作性数据存储”概念。但是这里他还是看出了这里存在的问题：

来自异源数据的更新将会被延迟，因此取得完全的一致性视图可能仍然存在困难。被复制数据应该只被用于查询——管理更新将会很困难；主数据，“唯一的真相”仍然在源数据库中，而且必须被他们的拥有者控制。

方法 3 很好的与企业信息集成功能相对应。Fred 指出：

在几年前引入 EII 的时候，它并没有获得市场广泛地接受，但是借助 SOA，它的时代来临了。

但是，他建议：

尽管某些 EII 工具支持对异种数据库的更新，但是这些更新仍然应该受那些拥有那些数据库的服务单元的控制

这种论调与推荐沿对象生命周期构建服务接口相对应，同时也得到了, 这篇文章的回应。

Fred 总结说：

SOA 中的数据管理应该按照这些方法去完成：必需的企业逻辑数据模型、自治服务单元间数据的联邦和共享机制，以及定义职责、流程、主数据存储、更新延迟、同步策略和数据集成与保护责任制的数据管理规划。

人们常常说，BPM 和 SOA 是“一个硬币的两面”。但是 SOA 实现达到了一个新的成熟度级别，人们意识到，也需要考虑数据以及它们的关系的天性，可能甚至要比业务流程考虑还多。创建“验证、管理和保护”数据的服务并不容易，它要求对大多数 IT 组织来说相对而言比较新的一些技术和精确的方法论。尤其是，它将企业数据管理带到了面向服务架构的核心位置。最终，对象生命周期的概念似乎作为数据、服务和业务流程的统一概念浮现出来。

EDM 对你的服务设计重要吗？你正在利用逻辑数据模型吗？你采用哪种方法来创建数据服务？

查看英文原文： Is Enterprise Data Management the Third Face of the SOA/BPM Coin?