本文介绍了 SOA 架构下的新的系统架构的变化,以及当前的 SOA 架构的优点和缺点,传统的数据库定位和 Information On Demand 的数据库的思路的区别,并进一步阐述了 SOA 和 IOD 的关系,并且通过典型的案例来探索新的系统架构的思路。
SOA(Service-Oriented Architecture) 是目前业界最为流行的 IT 架构,其定义有很多种,但是不外乎服务,标准,模块化和可重用等。这类的定义我们从网上可以搜索到很多,读者可以自己从各种定义去理解 SOA 。
在 SOA 的技术架构下,各个厂商纷纷推出了自己相应的产品,以满足 SOA 信息化建设的需要。毫无例外,目前现有的各个主流数据库厂商也纷纷宣称自己的产品支持 SOA 体系。那么,数据库在整个 SOA 的体系中到底是什么样的一个定位,到底什么样的数据库才算是更加 SOA 化的数据库呢?
道可道,非常道。本文只是笔者结合了目前信息化建设过程中的一些趋势,加上自己针对 SOA 和目前数据库的发展做出的一些感悟而形成。笔者仍然希望读者在阅读完本文之后,能够针对 SOA 体系下数据库发展的定位有一个自己的答案。
在介绍数据库的发展定位之前,我们仍然有必要回顾一下目前众多的针对 SOA 的理解。本人在和很多的业界同行接触的过程中,曾经很多次的听到有人在抱怨说,SOA 确实是一个好东西,但是,目前也仅限于博士的论文中,而不是实际的应用过程中。那么,我们首先看一下 SOA 到底是什么?
在这里,我引用一下 Gartner 关于 SOA 的定义:
SOA 是一种客户机 / 服务器软件设计方法,其中的应用程序由软件服务和软件服务使用者(也称为客户机或服务请求方)组成。 SOA 与更为通用的客户机 / 服务器模型不同,其定义强调软件组件间的松散偶合及对独立接口的使用。
从 Gartner 关于 SOA 的定义中我们能够了解到以下信息:
- SOA 是一种技术方法
- SOA 是模块化的方法
- SOA 的载体是服务
那么这是否就是 SOA 信息化建设的全部呢?是否说,我们只要针对应用程序实现了模块化的服务开发,那么我们就能够说,我们的系统就是 SOA 了呢?
我们首先看下面典型的 SOA 系统架构示意图:
图 1. SOA 系统架构示意图
![图 1. SOA 系统架构示意图](https://i-blog.csdnimg.cn/blog_migrate/8ef32fc3c86fa408cc1f3df1fd6be8d5.png)
从上面的这张图,我们能够很清楚地看到,在 SOA 的模块化的服务方式下,IT 系统的构建将会变得非常简单。整个 IT 系统其实就可以理解为针对业务过程的模块化的服务组合。因此,在图中,我们特别标出了 IT “逻辑层”这样一个概念。
这里的 IT 逻辑层其本质就是将原子化的服务直接按照业务的逻辑,组装成复合业务逻辑的一系列的服务的流程。通过这些灵活配置的服务的流程,来映射实际得业务过程。我们在这里将其定义为 IT 逻辑层。
因此,笔者认为,SOA 绝不仅仅是一个技术层面的问题,他更深层次的表现为通过服务实现对业务和 IT 技术之间的相互描述。即如何通过模块化的服务来更好,更灵活的描述现实的业务活动,而这也符合一直以来信息化技术的发展潮流。那就是,如何提供更高级的语言,能够更加方便灵活的实现针对现实世界的描述,并最终能够实现人机的直接交互。
从这个意义上说,笔者认为的 SOA 应该包含以下几个含义:
- SOA 是一种技术方法
- SOA 是模块化的方法
- SOA 的载体是服务
- SOA 直接通过服务描述灵活业务
如果说一定要用一句话来概括 SOA 到底解决了什么问题,可以概括为:前几十年 IT 的发展是强调和解决程序开发和工具的模块化,而程序的模块化并不能带来应用程序的模块化,因此,SOA 将解决应用系统的模块化问题。
同样,通过这张典型的 SOA 架构图,我们在这里也有一些需要思考的问题,比如说,我需要一个特定的员工的信息,而这个人,可能在财务系统里面,也可能在人力资源系统里面,那么我在通过服务去查询相关人的信息的时候,我就需要至少去两个系统里面去查找,如果有更多的系统,那么我们是不是需要去更多的系统里面去查找?有没有一个单一的数据库系统,能够提供给我们应用系统一个单一的服务模块,能够查询所有员工的所有信息?
因此,这里就引出一个问题,SOA 解决了应用系统的模块化问题,同样,也需要信息层提供统一的信息服务模块。就是说,在 SOA 的应用架构下,需要随需应变的信息服务提供,而这也是为什么我们需要实现 Information On Demand (IOD) 的架构原因。
从上面的针对 SOA 体系的描述,我们了解到,目前整个 IT 系统,正朝着模块化,服务化的方向前进,而其最终发展方向是找到更好的方式来描述我们真实的业务流程。而这一潮流也将不可避免的影响到作为整个 IT 系统的一部分的数据库系统。
反观我们以前数据库的发展定位,主要着重在以下几个技术方面:
- 存储数据,存储数据是数据库系统的最为基本的功能之一。在未来 SOA 体系下,数据库不可避免仍然承担这一使命。
- 提供更加全面的功能,将近 20 年的商用关系型数据库系统的发展,其实一直都是在为了提供更加全面的功能。其中,基本功能为存储和查询数据,此外,还有统计分析功能等一系列其他功能。
- 提供更高效的性能,随着数据量的增加,数据库系统为了提供性能做出了很大的改进。目前,随着关系型理论基础之上的技术的发展,从数据库本身提高性能的步伐将会越来越慢,这一点我们可以从 TPCC 的标准测试中可以看出,我们寄希望于硬件本身的性能的提高来带动目前关系型数据库性能的提高。
从上面的分析我们可以看出,传统的数据库的发展其实正在走过它的第一个阶段,即,在一个理论框架基础上不断完善,发展,壮大的过程。但是,随着 IT 系统的发展,现有数据库的缺陷也越来越明显,就是说,现有关系型数据库必须要通过应用系统才能表达真正的逻辑含义,脱离了应用系统,数据库本身没有任何价值。
因此,随着 IT 新技术的发展,数据库需要有一个新的发展。
前面针对 SOA 体系的分析,我们了解到,IT 系统发展的目标就是更方便,更灵活的描述我们的真实世界。因此,在应用系统层,我们通过标准的服务模块来实现应用系统的模块化。但是,在信息提供层,我们现有的信息层并不能提供全面的,统一的业务所需要的信息,而只能基于特定的业务系统提供部分的信息服务,因此,SOA 架构就需要有一个强大的信息服务提供层,能够提供随需应变的信息服务,即实现信息层的 IOD(Information On Demand) 。
针对目前的 IT 现状,我们改进了 SOA 的架构图,在这张架构图中,我们提出了一个基础数据管理层的概念。基础数据管理层的数据主要特点是整合整个企业相关的所有信息,其主要特点有:
- 基础数据管理层的信息是独立于任何应用的信息资产,其本身不属于任何一个特定的应用,但是可以通过标准的服务对外提供信息服务。
- 基础数据管理层的信息是基于整个企业级的,通过数据模型指导构建的数据资产。这里对外提供全局的完整的信息服务,而不是片面的,基于某些部门级的。
通过在 SOA 架构中增加了基础数据管理层,更加丰富了整个 SOA 的架构,让我们模块化,服务化的应用系统,有了模块化,服务化的信息服务基础。这样,在 SOA 架构下,新应用的开发不用再去连接多个系统为了解决一个问题,具体的业务部门的问题,可以通过一个通用的信息服务模块就能够完成相应的业务,真正简化了整个新系统的信息服务提供者的数量。例如,在上面的示意图中,需要客户信息的时候,只需要访问客户数据的服务,就可以得到你所需要的客户的信息,而不需要单独的去访问财务系统,人力资源系统等多个应用系统。
在改进后的 SOA 架构下,我们认为实现了以下几个方面的转变:
- 实现了数据资源向数据资产的转变。通过基础数据管理层,实现了 IT 系统的数据资产化。数据不再是从属于某个应用系统的数字,而是真正脱离了应用系统,在数据模型的指导下成为能够为业务带来价值的数据资产。在业界,我们也可以把这部分的数据称之为主数据。
- 实现了随需应变的信息 (Information On Demand) 提供。通过基础数据管理层,实现了统一的业务元数据,客户不再需要通过应用程序去不同的应用系统中寻找自己特定需要的信息,而只需要调用相应的服务接口,从特定的基础数据中就可以完成相应的操作,真正实现了随需应变的数据提供。
通过上面的分析,我们知道了 IOD(Information On Demand)在整个 SOA 架构下的定位。那么要实现这一功能,我们的数据库还需要哪些方面的发展呢?
从 SOA 的结构体系要求,结合我们上面的分析可以看出,在新的 SOA 的架构条件下,数据库发展的定位主要在于下面几个方面:
- 信息存储:在未来的数据库的发展中,信息存储仍然是数据库不可或缺的功能。考虑到数据量的增长,对数据库的大数据量的处理,高效率的业务系统的支持的需求仍然是对数据库的基本要求。
- 基础数据服务:基础数据服务,或者称之为主数据服务或者业务元数据管理,将是数据库发展的一个重要的方向。只有通过基础数据服务,才能实现信息向资产的转变,才能实现数据库和应用的分离,才能实现 IOD(Information On Demand) 。而 IOD 将会是整个 SOA 架构的信息提供者,是整个 SOA 架构的基础。这个层次包含两个方面的含义:
- 基础数据,是整个企业 IT 系统的信息基础,是企业的数据资产,而并不是仅仅是数据。
- 服务,不仅仅是数据资产,而且是能够通过服务提供给应用程序的一些服务。
因此,从上面的分析,基础数据服务层将会在未来的企业 IT 架构中承担越来越重要的作用。
- 数据建模:在未来的数据库的发展中,数据建模将会得到进一步的发展。特别是随着数据量的增多,怎样将浩瀚的数据变成真正的有用的资产,数据建模将是实现这一转变的重要技术手段。在未来的发展中,数据建模将会结合最新的数据库技术,例如:XML 等新技术,保证数据模型的稳定性、健壮性、灵活性以及兼容性,将是我们在数据建模方面所要考虑的。
我们下面以一个研究院为例,该研究院负责产品的研发,设计和生产。目前,该研究院已经上的应用系统包括,财务系统,人力资源系统,PDM 研发系统以及 ERP 系统。通过若干年的 IT 系统的建设,我们看到,各个系统已经运行稳定,基本满足业务的需要。这样的一个系统架构在我们许许多多的客户那里经常可以看到,是目前较为流行的一种系统设计法。
但是,这样的系统架构设计的缺点也是显而易见的。按照不同的业务需求而设计的专门的业务系统,虽然能够满足该业务部门的需要,但是,很显然,这些系统之间是不能进行信息交互的。随着业务部门之间跨部门的协调工作越来越多,这样架构的系统就显得越来越滞后。因此,针对此类系统架构进行相应的系统之间的整合是系统发展的必然。
图 3. 某研究院已有系统的架构图当该研究院进行系统整合时,最初考虑的只是进行系统之间的整合,保证跨业务部门的业务能够进行。例如,当人力资源部门在人力资源系统中注册新的员工的时候,财务系统中也能够直接反映出来,并可以在系统中为其进行工资评定等一系列财务管理。如上图所示,在研究院的设想中,引入 SOA 的架构,增加一个数据总线,在综合管理模块中,将财务系统和人力资源系统中定义一些 webservices 服务模块,并发布到服务总线上,即可以实现这两个系统的信息交互。
上述的方式能够很简单的实现财务系统和人力资源系统之间的信息交互,但是从整个系统架构考虑,仍然存在着一些值得思考的地方:
- 提供了企业服务总线,但是服务的提供没有规划,例如:提供员工信息的服务的出处就很多,财务系统,人力资源系统以及 ERP 系统等等,而且每个服务只能提供一部分的员工信息,必然导致服务得提供过于凌乱。
- 从整个系统架构看,整合后的系统仍然只是服务于特定的系统,如综合管理等。仍然没有摆脱业务部门提需求,IT 部门去实现的方式,IT 只是被动的去服务业务部门,而不能主动的提供服务。
因此,针对上述的情况,在和客户充分的交流后,我们提出了如下的改进后的系统架构:
图 4. 经过改进后的系统架构图通过同改进前的系统架构的对比,我们很容易的发现,我们只是在整个系统架构中加入了一层基础数据层。这个基础数据层,负责收集整个业务系统层生成的数据,并且按照特定的数据模型加工成有用的数据资产。例如,我们在这里建议将员工数据以及元器件的数据按照特定的模型组织起来,形成了整个研究院的基础数据,这里,我们建立了员工数据中心和元器件的数据中心。企业服务总线之上的新应用和新业务需求,需要任何的员工信息的时候,我们可以直接通过员工基础数据这个数据中心,向企业服务总线提供相应的员工数据。同样,对元器件数据亦然。
经过改进后的这样一个架构,我们认为主要体现了如下几个方面的含义:
- 业务,应用系统和数据库实现了架构上的松耦合。特定的业务再也不需要通过特定的应用系统来实现,而是从整体上实现了业务,应用,数据库分离的特点。三者中的任何一个部分都可以独立存在而不再是相互依存,特别是实现了随徐应变的信息服务提供(Information On Demand),将会是几十年 IT 发展的一个里程碑。
- 真正实现了系统整合。通过基础数据层的数据中心的建设,不仅实现了业务需求的跨系统的业务流程的整合,更加通过数据中心的建立,实现了整个企业的信息整合,形成了整个企业的数据资产,不仅能够提供给业务系统,更能提供给领导辅助决策分析等等。这一变化从而使得 IT 部门不再只是业务部门的辅助部门,而是能够为企业带来更多的新的业务增长点的核心部门。而这一转变,正是暗合了新技术带动新生产力的历史发展规律。
“大学之道,在明明德”,我们的信息化建设,同样需要有一个正确的认识。当前的信息化建设,存在着两个极端。
- 忽如一夜春风来,千树万树梨花开。 SOA 之于信息化建设,同样也是。仿佛一夜之间,所有的 IT 系统都实现了 SOA 了。
- 另外一些人则认为,SOA 仅仅存在于某些人的学术论文上,或者是那么的高不可攀。
上述两种思想其实都要不得,SOA 是实实在在存在于我们周围的,非常真实的,对我们信息化建设同样非常有帮助的一种架构思想。笔者也是处于对 SOA 的进一步的深入认识过程中。这里提到的 SOA 思想对于数据库的发展和影响,怎样才能实现信息管理的 SOA,这些还需要读者们去进一步思考。
最后引用道德经得一段话,同样适用于 SOA 和 IOD,与读者共勉:“曲则全,枉则直,洼则盈,敝则新,少则得,多则惑”。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14780828/viewspace-584495/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14780828/viewspace-584495/