企业中高度分散的数据接口和数据模型早就该进行有效的集成了。在实施SOA的过程中,这是无法跨越的必要环节。为了享受SOA的诸多效益,企业数据需要时刻准备着!
Carlson Hotels Worldwide公司的IT经理John Kolodziejczyk指出:“首先需要解决的问题是:”我们将使用什么样的数据库作为客户的信息来源?‘“为此,这家餐饮企业为其所有的应用设计了一种通用数据架构和一个管理该架构的平台。同样,轴承制造商GGB公司的IT经理Matthias Kenngott认为,GGB需要一个中央集线器确保Oracle电子商务套件与3个老的ERP系统之间一致的数据映射。
如今,大量的企业数据要么深锁在数据库中,要么就被封闭在应用中。通常情况下,应用“知道”数据的含意和处理结果的含意,因此企业至少要在本地创建一个一致性的数据模型。然而,随着企业跨应用组合不同的功能,这些数据模型也被混合在一起,而且常常是在IT开发人员不知道的情况下被混合的。
Starwood Hotels的技术经理Song Park说:“你分发越多的数据,就越可能出现问题。”人们往往会怀疑服务和应用产生结果的准确性。ZapThink高级分析师Ron Schmelzer指出:“对数据而言,始终存在一种上下文关系。甚至当一个字段为空白时,不同应用会对它的含意做出不同的假设。”
而这些问题数据会让集成的应用集合或大量的服务变得不可靠和难于修复。而解决的办法就是以服务的形式提供多种应用需要的数据,即在需要的地方加入上下文元数据,以及调和分散的数据源之间存在的不一致关系。
SOA的训诫
SOA的双重优势是开发执行常用功能的服务以减少多余的开发工作,以及通过利用标准化接口或外壳使应用功能可以跨系统使用,从而增加应用的灵活性。而SOA松耦合的、抽象的本质对于服务使用、处理和生成的数据具有深远意义。
Song Park在Starwood Hotels开始部署SOA时曾发问:“到底是把它分散开还是提供一种中央服务?”这个问题引导这家公司沿着很多企业走向SOA时的必由之路走下去:即用一种基于对数据含意的了解(无论数据来自何方)来处理数据的服务方式。Schmelzer强调:“SOA凸显了数据不一致这一事实。”
当服务交换数据时,发生误搭配和非对应转换的可能性大大增加。Common Sense的DePalma说:“SOA把这个问题推升到了最高层面。”他说,“当你尝试建立第一个3路或4路数据服务,你会很快发觉数据管理之痛。”HurwITz Group总裁Judith Hurwitz说,没有最初的数据架构努力,SOA就无法扩展到整个企业。
专家称,最佳的解决办法是开发一个数据服务层,它会对将要使用的数据进行分类,将其上下文关系展示给其他服务。这种方法把数据逻辑与业务逻辑分离开来,把数据访问和处理作为由业务流程调用的独立服务集合对待。
新需求催生MDM
这种解决办法不同于传统的数据集成。ZapThink的Schmelzer回忆说:“我们过去一直通过在关键堵点上实施控制来解决数据集成问题。而SOA消除了这些堵点。这意味着每个数据访问点都必须能转换和管理数据。”
IDC集成系统集团的副总裁Henry Morris说:“数据集成和流程集成是紧密连接的。”他建议企业必须考虑利用服务来管理数据,以及影响主数据的流程。
Kanbay国际咨询公司主设计师Nikhil Shah指出,SOA还提出了并行性问题。例如,当旧数据通过流程传播,或者当多个服务在不同时间访问数据时,流程过程中数据的变化就会影响到结果,尤其是在复合型应用中。Shah建议,IT要部署监测服务,至少部署在发生变更时通知其他服务的服务,以使它们可以决定是重新启动流程,还是调整对它们的计算。
此外,Shah说,数据服务的颗粒度越细,编排(orchestration)的开销对流程的影响就越大,因为它会增加响应时间,导致同步问题。他建议IT在服务能够消费数据前,就建立数据管理需求模型。
为SOA环境中的数据管理提供缓存技术的Progress 软件公司数据管理副总裁Ken Rugg说,另一个问题是SOA的“雪犁效应”,这种效应发生在服务把有关数据处理的上下文关系传递给复合应用中后续服务的时候。
IDC的Morris说,公布这些转换可以帮助以后的服务了解它们正在使用数据的上下文关系。不过,这也可能使系统被非常庞大的数据文件所淹没,降低每个服务的速度。
SOA的兴起使厂商有理由重新利用他们的工具为SOA和非SOA环境简化数据管理。很多厂商正在推广MDM(主数据管理)工具,来确保应用或服务在正确的上下文关系中使用正确的、当前的数据。“主数据”不仅包含数据本身,而且还包含了供不同系统使用所需要的属性、语义及上下文关系(即元数据)。一些厂商把这类系统称为企业信息集成(EII)工具。