企业数据管理是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?