一家大型的公司发现自己为一堆低劣的烟囱式应用所累，影响了自己的敏捷性、性能和盈利能力。由于需要通过手工编码来实现供应链、财务、CRM及其他套件式、客户化的遗留程序之间的点对点连接，其IT部门常常进度滞后、预算超支。

　　解决方案：通过采用面向服务架构（SOA）来集成关键业务流程与应用。内部IT人员和顾问设计建造一个松耦合的基础设施，以及基于XML和标准的Web服务协议，如SOAP和WSDL等的可重用服务。一旦系统上线，CFO通过其仪表盘运行一个日常查询。问题回来了：你把数据给忘了。

　　这是一个有趣的虚构，但是它阐明了面向对象架构的风险所在，魔鬼存在于细节之中，这种架构仅关注于业务流程的交互和应用接口，忽视了参与这些流程迥然各异的IT系统之间存在的数据级的不兼容性，包括不同的格式、语义和体系。

　　我们设想中的公司将它的SOA搭建在基于Web服务的企业应用集成（EAI）引擎的基础之上。该技术在使能高级应用集成和协调业务流程方面可以做到完美无缺——但是它的设计不是用来处理散布在企业各处的那些异构不一致的脏数据。

　　结果：只能通过耗钱又耗时的手工编码来解决SOA实现中的数据不一致问题，从而违背了可重用性、可互操作性的这一非常初衷，而正是这个初衷驱动着向SOA趋势的发展。这种企业SOA中缺失的一个要素就是建造在数据集成平台之上的数据服务层。

　　SOA的机遇

　　围绕着SOA的一切动态变化都是快速和激烈的。这不足为奇。组织认识到了这个机遇，通过使用像可扩展标记语言（XML）、简单对象开放协议（SOAP）以及Web服务描述语言（WSDL）这样的开放标准的“松耦合”式的独立应用，从而削减应用和中间件开发成本，并加快上市的时机。

　　IT组织和供应商之流对这些标准的广泛采纳，为Web而交付的作为基于组件服务的应用的出现铺平了道路。通过对底层业务逻辑的抽象，SOA使得服务封装化、可重用、协调一致，给IT和业务两方都带来了好得多的响应性、灵活性以及执行速度。

　　许多早期的基于SOA的实现都是建造在EAI、J2EE和.NET中间件的基础上的，包括消息代理、应用服务器以及企业服务总线。但是数据集成越来越成为一个主要的目标。据AMR研究公司的一份报告《面向对象架构：为未来而部署和规划的调查发现》，AMR研究受访者中约有76%者把或打算把使用SOA化的流程或数据集成作为首要目标。数据集成平台可通过精致的数据服务来丰富SOA，这是以应用集成为中心的技术所不能及的，这份发现反映出人们对此认识在不断增强。

　　换句话说，为了发挥SOA包括松耦合及可重用性在内的全部潜能，让客户端应用以一种一致和精确的方式访问到业务相关数据是至关重要的，无论这些数据在哪里，也不管其需要的形式是什么样的。

　　为黄金时间做好准备：面向服务的数据集成

　　为了帮助SOA成为IT的转型力量，数据集成技术已经做好了准备。过去几年间，通过内置对XML、Web服务协议、JDBC连接性以及Java消息服务（JMS）的支持，数据集成技术得到了增强。先进的数据集成平台亦以元数据能力作为驱动其开发工作和运行时基础设施的核心。这一元数据提供了从技术实现中对业务逻辑的抽象，使得它们能够通过数据服务层为SOA的无数组件带来先进的数据集成功能。

　　许多年以来，数据集成行动都是在缺乏数据服务层的基础进行的，这导致了本来打算要进行集成的烟囱式系统的进一步扩散。举个例子，一位零售商可能已经部署了一种析取、转换和加载（ETL）工具，将零售店的销售点数据同步到一个SAP财务应用中。然后这种工具的另一个实例则可能用来将SAP财务信息搬到DB2数据仓库上以供分析。而第三个实例可能为价值链前端服务，提供产品采购数据给运营数据存储。

　　因此，尽管该零售商将可以通过目标应用实现数据集成，要实现一个流畅的、端到端的数据生态系统仍需要精简若干步骤。SOA则可以清除烟囱式开发的这些壁垒。

　　在一个模块化的SOA里面，有一个数据集成平台来充当另一个基于组件的服务。其功能可以是功能打包然后在多个项目中重用，以便减少开发和部署成本。可以是通过开放标准帮助组织利用当前锁定在大型机、打包的、自产的系统里面的数据资产。可以是消除数据集成连接性手工编码的需要，以及为业务提供快速实现价值的能力。

　　这正是SOA的数据集成技术提供的东西。现在，让我看看另一方面的事情——SOA数据集成干些什么。

　　在《企业数据集成：SOA的关键部分（二）》和《企业数据集成：SOA的关键部分（三）》中，我们将继续为您介绍相关内容，敬请关注。