SOA最佳实践之构建数据服务层

 
   | |

导读:SOA最佳实践之构建数据服务层,将信息封锁在整体化的应用程序monolithic application中是现代业务所需的灵活性开发的极大障碍。

关键词:SOA 数据服务层 信息 应用程序

 
正在加载数据...

  最近,几乎所有大型企业或者已在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中构建所有服务的基础。

  最有效的数据存取方式对构建数据服务层的重要性

  向任何一位业务管理人员询问IT对业务的价值,他都有可能会说数据(以有效信息的形式)才是业务的生命之源,而不是应用程序。从本质上来说他们是对的;信息技术嘛,从定义上来说就是一切都取决于信息。但实际上这两者(数据和应用程序)只能在理论上区别开来,在实际应用中却是密不可分的。如果不经过应用程序的处理,数据经常是无法访问且/或无法理解的;反之,如果没有数据,大多应用程序也无法提供实际的业务功能。

  要让数据在SOA最佳实践中发挥最大效应,建立一个数据服务层是必需的;同样,认识到数据存取是这个数据服务层的基础组成部分也很重要。而数据存取又取决于像ODBC、JDBC、ADO.NET和SDO等标准。即使采用了(比如用Hibernate开源工具包构建的)持久层,高质量的数据存取中间件也是相当重要的。Hibernate下的低速JDBC driver或者LINQ(Microsoft’s Language Integrated Query)下的底速ADO.NET provider不可避免地终将妨碍服务的发展。后果是多方面的。以最有效、最灵活的方式对企业中的各种数据存储进行数据存取操作是建立数据服务的主要原因,因此也是构建SOA中所有服务的关键。

  数据存取中间件不存在任何影响速度性能的问题。并且,由于数据服务层实质上是数据存取的一种抽象,因此这些服务可以隐藏数据存取中的诸多潜在缺陷。其它可隐藏的缺陷还包括:

  可伸缩性问题

  数据库平台、应用程序和版本的兼容性问题

  各种数据源处理标准的数据存取操作(比如创建、读取、更新和删除)的细节上的差异

  各数据库、表格甚至各行之间都不相同的数据源的安全等级问题

  由于异类数据中的语义差异产生的数据映像问题

  结构化和非结构化数据混合产生的问题,比如文件格式问题

  SQL版本差异问题

  SOA实际上会将数据存取对扩展性、性能和互操作性产生的影响放大,因为企业不但很可能重用底层的代码,还会在许多服务和组合应用中使用现有的数据服务。

  因此解决这些数据相关的问题的第一步就是建立共享的、集中的数据服务,这会使所部署的SOA适应性强并且易于维护。这样,不管有多少应用程序在使用,数据存取逻辑只会出现在一个地方。结果就是,集中的数据存取取代了将所有数据相关的服务调用代码分散到各个业务服务中的方式,为你创建了一个以最有效的数据存取方案解决所有数据存取问题的环境。

  在这一点上——采用最有效的存取方案——即使再多的强调也毫不过分。即使是对于在做数据管理工作的大多人,数据存取中间件几乎也只是一个一闪即逝的想法而已。其中一个原因是各种商业数据库都有与数据库软件相应的默认连接驱动。实际上,这些“免费”驱动可能一点也不适合给定的IT环境。但除非并且直到技术或维护方面的问题达到一定的严重程度,以致可以查到根源所在的数据连接层,这种情况通常不会浮出水面。正如我们已经说过的原因,这种问题可能渗透在SOA深处,并且可能极其难以分析解决。

  简而言之,让企业SOA的数据服务层依赖于与数据库绑定的数据存取中间件是很不理智的做法。对于免费的开源驱动也是如此。数据存取方式作为数据服务层的根本,需要你的慎重考虑和详细计划。在多重服务重用数据存取代码以及不断部署新服务的动态环境中需要能满足苛刻要求的代码。

  你的最佳选择是第三方的数据存取中间件,并且最好选择核心业务和技术包含数据连接内容的供应商。要确定你的数据存取中间件所需的具体特性,包括能极大地提高查询性能的功能。这些特性包括连接池、以及对数据存取可调性的支持,比如调整网络数据包的大小。为有更好的可伸缩性和高度可用性,数据存取中间件应该是多线程并且线程安全的,并为客户端提供到其它服务器的负载平衡和故障转移功能。

  同时,数据存取中间件也要对不同类型和版本和数据库以及各相应略不相同的SQL提供良好的支持。这种对相异性的支持也应该包括对多重计算平台、芯片和操作系统的支持。另外,为达到最佳性能和最好的灵活性,数据存取中间件应该包含线协议驱动,以避免由于使用过时的数据库驱动产生的管理费用和维护方面的问题。线协议驱动对数据库客户端软件和库的没有任何要求,简化了安装和管理过程并能使用更有效、性能更好的操作。这种驱动必须支持全部的相关协议,包括JDBC、ODBC、ADO.NET、以及正在发展中的SDO。

  最后,还要全面地考虑数据存取中间件在IT安全方面的问题,包括网络安全与数据库安全,以保证通信安全和代码安全。当然,还应该包含多种身份验证和授权验证方式。

  任何企业都应该将选择最有效的数据存取中间件作为构建SOA的关键部分。数据存取是SOA的基础组成部分,如果选择不妥,整个服务体系都会受到很深的影响。原则上,甚至可以说不管数据服务层上面的SOA基础设施如何,都可以毫无疑问地认为数据存取技术是SOA中的关键技术。


数据服务
 在需要时进行数据处理(二)
 在需要时进行数据处理(一)
 数据服务:SOA的最后一英里
 数据服务:连接SOA与元数据管理的桥梁(二)
 数据服务:连接SOA与元数据管理的桥梁(一)
 SOA最佳实践之构建数据服务层
 整理数据的XML主题地图
 基于SOA实时数据仓库的研究
 利用原子性获取SOA颗粒度
 精通SOA之构建服务组合

 
来源:IT168    作者:John Goodson,Jason Bloomberg    
 
 
 
 
 

SOA实施

 
就好像是医疗保健行业相当不错地风化了经济衰退,所以一些厂商已经在最近期待投资。甲骨文和Axolotl公司在2010年医疗卫生信息与管理系统协会……
 
虽然你可以在没有SOA实践的情况下使用云计算,你也可以在不使用云计算的情况下利用SOA,但是云计算的真正价值是使用服务、数据和流程……
 
许多基于服务的新应用跨越了单一组织的边界,在集成这些扩展系统时,数据定义经常是最可怕的挑战压力。加州个独立系统运营商(ISO)就是个实例……
 
Harris公司气象学家使用SOA将天气信息集成到下一代空运系统。上个月在亚特兰大举行的美国气象协会(AMS)会议上,他们探讨了这项工作。
 
现在微软Azure市场上有售,早期企业采用者开始在应用程序上进行移植。自从开发人员专门从事.NET云平台,微软可能就再三思考调查其他云厂商。

热门技术手册排行

 

随着开源技术越来越成熟,一个稍有开发经验的人通过学习就可以用开源的产品和技术构建一套可用的系统。对于从事软件开发的人员,尤其是对Java或动态语言相关领域的人来说,“开源”也许是他们最喜爱的单词。但是,很多时候我们需要的不仅仅是一个可用的系统,而是希望这个系统开发更简易、性能更高和扩展性更好等。这确实是一个令人头痛的问题。本指南很多地方都是点到为止,要深入了解相关信息的读者请借助参考资料、网站等自行挖掘。

 

本专题分六部分探讨SOA设计模式,当初设计面向服务架构的一大初衷就是降低服务间耦合度,由此提高服务的灵活性和自由度。

 

业务流程管理(business process management,bpm)不是一个新概念,甚至不是一个新名词。它是从相关的业务流程变革领域,如业务流程改进(bpi)、业务流程重组(bpr)、业务流程革新中发展起来的。流程管理技术也是从早期的工作流管理、eai、流程自动化、流程集成、流程建模、流程优化等技术中发展起来的。

 

TOAGF是一个架构框架,简而言之,TOGAF是一种协助发展,验收,运行,使用,和维护架构的工具。它是基于一个迭代(Iterative)的过程模型,支持最佳实践和一套可重用的现有架构资产。

 

云计算的概念越来越流行,Amazon、Google和IBM是第一批将云计算引入公众视线的公司。云计算就是新的Web2.0,一种既有技术上的市场绽放。

 

Mashup是一个非常cool的新的应用程序种类。如果你想真正的了解它们,我们需要回过头来看看你现在的计算机,其实它就是一个非常好的帮助你理解mashup的模型。现在开源的操作系统无疑是非常好的apis的集合或应用程序编程接口,帮助开发者去构建其应用程序。计算机本身也是一个很好的为用户提供接口的例子,键盘和鼠标可以被理解为你通过计算机的接口而使用的不同的应用程序。本技术手册为读者提供了一些相关信息,如果需要深入了解mashup,读者可以借助其他参考资源。

查看更多
 
 

登录TechTarget中国

关闭
本服务仅向TechTarget中国的会员开放,请登录或立即免费注册
电子邮件地址:
请输入您的电子邮件地址
密码:
下次自动登录