登录
【IT168 专稿】
最近，几乎所有大型企业或者已在SOA部署中取得了一定的进展，或者已将SOA部署计划放到了议事桌上。他们很快发现SOA就像蛛网一样逐渐蔓延，最终几乎涉及到了IT与业务的每个角落。由于数据在业务和系统操作中的重要性，数据库管理员、信息技术专家、数据集成专家以及所有和企业数据管理有关系的人员都被会被（不管是有意识性地或是非意识性地）征去为SOA的建设做贡献。
将信息封锁在整体化的应用程序（monolithic application）中是现代业务所需的灵活性开发的极大障碍。如果要在业务中使用任何高性能敏捷服务，就必须解决技术上的难题：如何在企业中实现跨平台的信息访问（即数据存取）。
在传统的分布式架构中，开发人员可能会写一段数据存取代码，然后接着想办法实现重用性。然而，如果这段数据存取代码有问题，那么这个问题必然会蔓延到所有需要使用这段代码的程序中，带来严重后果。并且将来每有变化产生时（比如基层的数据库、数据模型、或者所用的编译环境等的变化），所有用到这段数据存取代码的地方必须同时更新。
从结构化的数据存储方式（比如相关的数据库、大型主机的数据源和各种企业应用），到半结构化或非结构化的数据（比如网页、PDF文档、office应用文件、XML文档、电子邮件、媒体的内容、显示内容、或者各种各样的内容和数据连接、表格），数据来源的多样化决定了使用传统紧耦合的数据存取方法来存取和处理所有这些来源、类型都不相同的信息必会带来技术支持上的巨大难题。
而架构合理的SOA则能在实现业务功能的同时有效处理各种数据——以抽象的服务的形式。具体到数据存取方面，如果将存取抽象为数据服务的形式并且把存取代码转移到基础的支撑框架中，那么就可以在整个大环境中以一个更为松耦合和更有敏捷性的方式解决上述问题并处理各种变化。实质上，数据服务层已抽象为所有数据存取、更新和设定操作的存取点，这使我们可以对底层的数据持久层所用的数据模型有一个宏观了解。它就像业务服务和底层的数据持久层之间的桥梁；业务用户无需担心他们所用的数据到底来自数据库、某个企业应用、某文件系统、甚至另一公司或者任何地方。这种不受数据源限制的随时随地的自由存取是各公司与各种各样的系统集成问题不断奋斗的成果。
数据服务层必须有一个独立于底层数据源的可对标准的可重用的数据服务进行读写的接口。使用这些服务的应用程序与底层数据源提供者之间的松耦合特性使数据库管理员在修改、整合、转移甚至从数据服务层移除底层数据源时无需调整数据服务层的接口。这样，管理员便可以在保持对这些数据的结构的控制同时为应用程序提供所需的信息。随着时间的推移，灵活性越来越高，企业应用的维护工作的难度也会减小。
在SOA产生之前，开发人员在构建应用的同时人工嵌入硬编码，用这种方式来获得数据服务层的类似功能。将这种数据存取和数据提取代码直接嵌入到应用中的方式限制了应用的灵活性和可重用性，导致企业转向传统的中间件（比如ETL和EAI产品），寻求以中间件的方式提供数据服务层的功能。其中ETL的方法最适合在无需灵活性的静态应用（static application）中使用。但是它的造价昂贵，并且需要很高的管理费用。EAI的方法采用集中的数据交互的管理方式，但仍然无法满足许多企业对（像数据服务层的）灵活性的要求。
即使在企业开始部署真正的SOA时，设计拙劣的数据服务层也会产生性能上的问题。在许多情况下，各个应用都有相应的数据库，其中包含业务参考数据的备份，比如客户信息、产品信息和库存水准。（见图1）
企业必须按固定的计划同步这些数据库，而这种做法会导致数据没有时效性，或者数据在各应用之间的不一致性。这样，即使企业以松耦合服务的方式实现了应用功能，这些服务的灵活性和可重用性仍然会受到数据持久层的限制。在SOA部署中引入数据服务层即可解决这些问题。如图2所示，数据服务程序负责与各应用相关的连接和事务处理。
数据服务层负责管理各数据服务程序之间的联系，保证各个应用能实时了解到数据的变化，而无需知道变化的原因。使用数据服务作为业务服务层下面的基础服务提高了可重用性和敏捷性，并缩短了新服务的开发和部署所需的时间。构架良好的数据服务层依赖于使用标准的API接口（比如ODBC、JDBC、ADO.net和SDO）的有高度兼容性的高性能数据存取中间件。
总而言之，将数据服务层作为SOA部署的基础组成部分可以最大化SOA所能提供的效益。特别是，它能为常见的数据问题提供以下解决方案：
毫无疑问，要建立一个成功的松耦合架构，SOA架构师必须在解决数据存取问题的种种困难中付出艰苦的劳动。以最有效、最灵活的方式对企业中的各种数据仓库进行数据存取操作是建立数据服务的基础，而正因为如此，这也是在SOA中构建所有服务的基础。
| 第1页： 如何在企业中实现跨平台的数据存取 | 第2页： 最有效的数据存取方式对构建数据服务... |
