SOA系统主要用来解决异构环境的系统整合、信息孤岛、数据交换等问题,也可以说SOA所关注的就是如何使封闭的信息系统成为开放的信息系统。虽说SOA的问世已有几年的时间,全界的在IT界对SOA也大力支持,然而时至目前SOA并没有明显地从根本上解决这些。原因何在?问题的根源不在SOA,而在于关系数据库理论和SOA系统的标准化。
一、 关系数据库理论的严重缺陷
关系数据库理论是互联网时代之前的产物。关系数据理论建立在这样的假设的基础之上:所有的数据都存放在某一个数据库中。
关系数据库是一种以自我为中心的封闭系统,它只能处理某一个数据库中的数据。我不处理你的数据库中的数据,你也不能处理我的数据库中的数据。我的数据库中的数据只能存在于我的数据库中,我的数据离开了我的数据库到了你的数据库之后就变成了无意义的数据。关系数据理论中没有关于数据接口、数据交换方面的内容。关系数据库的封闭性的具体表现就是:关系数据库中的任何一个数据都是有结构的而且与数据库系统密切相关的,该数据一旦离开了这个特定的环境(相应的数据库软件、数据结构、应用软件),就变成了无意义的数据。
关系数据库的封闭性适应了同样是以封闭为主的单机时代和局域网时代,并发挥出了巨大的作用。然而,随着互联网的出现,信息系统已从自我封闭的时代过渡到了开放的时代。在开放时代,人们希望各个信息系统之间能够信息共享、互联、互通、互操作、交换数据,此时人们才发现,关系数据库不能有效地解决这些问题。SOA理论虽说先进,却也不能从根本上解决关系数据库理论的这种先天的缺陷,只能进行局部的弥补。
二、 如何解决关系数据库理论的封闭性
火车之所以能够在全国各地运行,关键在于全国的钢轨都是标准的。关系数据库中的数据之所以只能在某个特定的数据库中运行,问题在于它的钢轨(即数据结构)不标准,它要想在其它数据库中运行,就必须为它建立相关的钢轨(数据结构),或者把相应的数据进行转换,使这些数据适应新的钢轨。这是目前解决数据在不同环境中运行的通用的方法。
那么,能不能设计出一种标准的、万能的数据结构,从而使所有的数据都能在这种数据结构中运行呢?如果从关系数据库理论的角度来考虑问题,大概是不可能设计出这种标准的数据结构。“准一维数据结构”是一种万能数据结构,这种数据结构可以存放关系数据库中任何表中的各种数据。用“准一维数据结构”可以有效地解决关系数据库的封闭性。
三、万能的准一维数据结构表
表一即为“万能的准一维数据结构表”,该表存放数据的方式与XML文件存放数据的方式类似,都是以“准一维”的形式来存放数据。
表一:
对象代号 |
对象属性 |
对象属性值 |
计量单位 |
附件 |
开始时间 |
期限 |
权限 |
用户 |
备注 |
001 |
数据库名 |
图书音像 |
|
|
|
|
|
|
|
001 |
表名 |
图书 |
|
|
|
|
|
|
|
001 |
书名 |
C#和ASP.NET程序设计教程 |
|
|
|
|
|
|
|
001 |
作者 |
李四 |
|
|
|
|
|
|
|
001 |
价格 |
50.00 |
元 |
|
|
|
|
|
|
001 |
页数 |
400 |
页 |
|
|
|
|
|
|
001 |
出版社 |
清华大学出版社 |
|
|
|
|
|
|
|
001 |
出版日期 |
2002-1-1 |
|
|
|
|
|
|
|
|
|||||||||
002 |
数据库名 |
人事管理 |
|
|
|
|
|
|
|
002 |
表名 |
职工简历 |
|
|
|
|
|
|
|
002 |
姓名 |
李四 |
|
|
|
|
|
|
|
002 |
出生年月 |
1964.4 |
日期 |
|
|
|
|
|
|
002 |
性别 |
男 |
|
|
|
|
|
|
|
002 |
身高 |
164 |
CM |
|
|
|
|
|
|
002 |
籍贯 |
河南 |
|
|
|
|
|
|
|
002 |
照片 |
|
|
ZP.JPG |
|
|
|
|
|
|
|||||||||
003 |
数据库名 |
Bearing |
|
|
|
|
|
|
|
003 |
表名 |
Bearingone |
|
|
|
|
|
|
|
003 |
轴承代号 |
2204E |
|
|
|
|
|
|
|
003 |
d |
22 |
MM |
|
|
|
|
|
|
003 |
D |
47 |
MM |
|
|
|
|
|
|
003 |
B |
14 |
MM |
|
|
|
|
|
|
注一:可以从理论上证明,所有关系数据库、任何表中的所有数据都可以放到这张表中。 |
|||||||||
注二:表一所示的表也是一张二维表。由于它是固定列数的表,可以把它看作是一张(准)一维表,或线性表。 |
|||||||||
注三:“准一维数据结构表”存放数据的方式与XML存放数据的方式类似,都是“准一维”。 |
|||||||||
注四:“万能的准一维数据结构表”可以用来存放跨平台数据交换时所收到的各种异构的数据。 |
四、信息系统的开放性取决于“数据的独立性”和“数据的完整性”
所谓“数据的独立性”和“数据的完整性”是指一个数据能够不依靠其它的信息而独立、完整地表达清楚具体的含义。
关系数据库的数据并不能独立、完整地表达清楚具体的含义,因为它们都是依赖某个表而存在的。图一中的数据是关系数据库中的数据。这些数据未能准确地表达清楚它们本来的含义。这些数据需要加上其结构信息才能比较清楚地表达出其本来的含义,如图二所示。
图一:
图二:
图二中的信息还少了一个很重要的信息,即数据是拥有者是谁?图二的信息是Access数据库中的示例数据库中的数据,该数据库的拥有者是“罗斯文贸易公司”。
图二中的数据只能在“罗斯文示例数据库”这个特定的环境中才能“生存”,离开了这个特定的环境而到了其它关系数据库中之后,它们就不能生存,因为其它关系数据库中没有对应的数据结构。
XML中就考虑到了“数据的独立性”和“数据的完整性”,也正因如此,XML文件中的数据就可以脱离其原来的生存环境而生存。“万能的准一维数据结构”也考虑到了“数据的独立性”和“数据的完整性”,采用“万能的准一维数据结构”形式存放的数据可以在不同系统中生存而且不会失真。
图二中的数据由于设计者所设计的数据结构比较规范,所以能从中看到数据的真实含义。而很多设计者在设计表时未能用规范的表名和字段名,正因如此,人们就是看到了表中各记录中的数据及各字段的字段名和表名,也不能准确地判断出表中数据的准确含义。例如表二就是某个项目中所设计出的一张表(数据字典)。谁能看懂表二的准确含义?
表二:表名CCPE
属性标识 |
关键字 |
唯一键 |
类型 |
精度 |
字典项 |
非空 |
备注 |
BCCQ22 |
Y |
Y |
S |
14 |
|
Y |
|
BCCQ28 |
|
|
S |
100 |
|
|
|
BCCQ29 |
|
|
S |
19 |
|
|
|
BAE006 |
|
|
S |
14 |
|
|
|
BAE005 |
|
|
S |
19 |
|
|
|
BAE004 |
|
|
S |
8 |
|
|
|
BAE003 |
|
|
S |
19 |
|
Y |
|
BAE002 |
|
|
S |
8 |
|
Y |
|
AAE013 |
|
|
S |
1000 |
|
|
|
表二的真实含义是:该表为某人才市场数据库中党团活动名称表,其中的各字段的含义如表三所示。
表三:党团活动名称表-CCPE
属性名称 |
属性标识 |
拼音码 |
关键字 |
唯一键 |
类型 |
精度 |
字典项 |
非空 |
备注 |
党团活动编号 |
BCCQ22 |
DTHDBH |
Y |
Y |
S |
14 |
|
Y |
|
活动名称 |
BCCQ28 |
HDMC |
|
|
S |
100 |
|
|
|
活动日期 |
BCCQ29 |
HDRQ |
|
|
S |
19 |
|
|
|
创建系统机构代码 |
BAE006 |
CJXTJGDM |
|
|
S |
14 |
|
|
|
最近修改日期 |
BAE005 |
ZJXGRQ |
|
|
S |
19 |
|
|
|
最近修改人 |
BAE004 |
ZJXGR |
|
|
S |
8 |
|
|
|
创建日期 |
BAE003 |
CJRQ |
|
|
S |
19 |
|
Y |
|
创建人 |
BAE002 |
CJR |
|
|
S |
8 |
|
Y |
|
备注 |
AAE013 |
BZ |
|
|
S |
1000 |
|
|
|
|
|
|
|
|
|
|
|
|
|
当前的信息系统之所以是封闭系统,就是因为系统中的数据不是独立的、不是完整的,这些数据离开了相应的信息系统后就会严重失真。
对于真正的开放系统而言,数据库的名称、表的名称、字段的字段名都是非常重要的信息,都要用规范的自然语言来表达,最忌讳的就是用“代码”来表达它们。而这些正是容易被数据库的设计者所忽视的。
关系数据中的数据(记录),都共用一个字段名,这样做减少了数据冗余,但这也是数据失真的重要原因之一。而XML与“万能的准一维数据结构表”中的每个数据都自带对应的字段名信息,这样做虽说增加了存贮空间,但这样做可以使数据在跨平台数据交换中不失真。
在封闭系统中,减少数据冗余是设计目标之一。在开放的系统中,最重要的设计目标是如何确保系统的开放性,数据冗余是次要的,为了确保“数据的独立性”和“数据的完整性”有时数据冗余是必要的,XML及“万能的准一维数据结构表”都是以一定的数据冗余来确保数据在不同的系统都不会失真。(注:千年虫就是一个大教训,初期的设计者为了减少数据的贮存空间而使时间信息失真)。
综上所述,SOA系统的成败的一个关键因素就是如何保证数据在不同的环境中都不失真,即一定要注意“数据的独立性”和“数据的完整性”。“数据的独立性”和“数据的完整性”:可以不依赖数据库系统、数据结构及应用程序而存在,这样就可以确保数据在任何信息系统中都不会失真。要使信息系统成为真正开放的系统,在设计系统时一定要注意不能使数据依赖于某个系统。
五、当前的信息系统在跨平台数据交换中存在的问题
跨平台数据交换非常困难:虽说利用现有的技术,可以实现网上的任意两个信息系统之间的数据交换,由于没有通用的接口,两个系统之间要交换数据,就必须编写专用的接口软件。这就好像火车行驶在不标准的钢轨上,火车每到一个地方就必须更换不同的车轮。关系数据库中的数据只能在自己的地段(自已的数据库)行驶,到了其它地方(在其它的数据库中)就无法行驶。
无接口(或有说接口比较少且不通用):当前的信息系统几乎全是自我封闭型的,很少有与外界交换数据的接口,特别是关系数据库。关系数据库是局域网时代的产物,是典型的以自我为中心的产品,只能处理“我的数据库”中的数据,未考虑如何处理他人的数据库中数据的问题,也未考虑他人如何处理我的数据的问题。关系数据库理论也未考虑数据库之间的接口问题,它所考虑的只是如何处理“我的数据库”中的数据。当前的网站其实也是以自我为中心的,网站之间也不能进行有效的数据交换。你要想查看我的信息,我就必须登录到我的系统上,你不可能利用你的系统而获取我的信息,你也不可能利用你的系统给我的系统发送信息。
接口不标准、不通用:对当前的信息系统而言,若两个系统之间要进行数据交换,就必须开发相应的接口,而开发出的接口都是专用的,如果要与其它系统交换数据,还需要开发新的接口软件,若一个系统要与N个系统交换数据,最少要开发N+1个接口。由于异构数据源问题,无法开发出通用的跨平台数据交换接口。
需要面对无限多的WEB服务:用户若增加一个数据交换方,就需要先调用对方的WEB服务,而且要编写相应的处理软件,无编程经验的普通用户无法处理此类问题。随着数据交换的普及,用户将会面临无限多的WEB服务。在与一方进行数据交换前,都要添加对方的WEB引用。若要与1000个系统交换数据,最少要添加1000个WEB引用,而且还要编写相关的软件,这是非常烦人的。
需要面对无限多的XML文件:当前的数据交换主要是以XML文件的形式实现的,当用户面对成千上万,甚至几十万、几百万个XML文件时,对XML文件及其中的数据的处理(查询、分类、统计等)将是非常困难的。
需要面对无限多的数据结构:跨平台数据交换中所面对的主要是如何把一个关系数据库中的数据发送到另一个关系数据库中。关系数据库的最大特点就是其中的所有数据都是有结构的,数据与结构密不可分。如果说数据库中不存在某个数据的结构,那么该数据就不能存放到该数据库中。随着交换数据的增多,关系数据库将面临越来越多的异构数据,这是关系数据最头痛的,也是关系数据库难以解决的。
难以把数据直接写入到对方的数据库中:由于用关系数据库理论无法解决异构数据源问题,发送方难以把各种异构的数据直接写入到对方的关系数据库中。
六、接口的统一、标准、通用
在建立SOA系统时,接口的统一化、标准化、通用化是非常重要的。统一化、标准化、通用化的接口犹如标准的铁路钢轨,可以确保各个系统之间都能顺利地进行数据交换,而不统一、不标准、不通用的接口,将会使跨平台数据交换变得非常复杂。
利用“万能的准一维数据结构表”可以开发出通用的跨平台数据交换接口,可以实现跨平台数据交换和搜索,能够发送、接收各种异构的数据并把收到的数据直接存放到关系数据库中,使跨平台数据交换犹如收发电子邮件那样简单,只要有了对方的接口地址,就可以把任何结构的数据发送到对方的接口数据库中。
其实电子邮件系统就是一个非常好的、标准的跨平台数据交换接口,只是它不能直接交换有结构的数据,利用“万能的准一维数据结构表”而开发的“通用的跨平台数据交换接口系统(简称IDB)”在实现数据交换时借鉴了电子邮件系统。
IDB像电子邮件那样,具有跨平台发送及接收数据的功能,下图即为IDB收邮件(可称作是数据邮件)读邮件的过程。
IDB接口对所有人开放,任何人都可以向该接口发送信息(只要他知道了该接口的地址)。只有拥有一定权限的用户才能从接口中收取相关数据并处理该数据。
接口专门用来接收数据,对接收到的数据进行下一步的处理由接收者确定,而不能由发送数据者确定。这包括对数据有效性的判断、是否把数据再转换到内部的相关的数据库系统中。数据的发送者不能直接把数据写入到接收者的内部系统中,只能把数据写入到接口的数据库中,这主要是从安全的角度来考虑问题。接口的参数:收件人地址、收件人、发件人地址、发件人、邮件标题、邮件内容(放在DataSet中)。这些参数与电子邮件一样。邮件中的内容主要是具有结构的数据,例如关系数据库中的数据,这些数据可以是各种关系数据库中的任何数据。
IDB接口可为多个用户提供收发数据的功能。不同的用户拥有不同的收取数据的地址,就像电子邮件一样不同的人都有不同的电子邮件地址。
IDB接口是通用的,任何两个IDB接口之间都可以相互收发任何数据,并把收到的数据直接写入“准一维数据结构表”中,只要它们之间物理上是互通的、逻辑上无限制。
IDB接口分为两种,一种是收发数据的接口,另一种是供对方查询信息的接口。这两种接口最好分开部署。信息查询接口分为两类,一种是对所有用户开放,另一种是需要拥有一定的权限、帐户才能查询有关数据。客户端可以把查询到的任何数据都能够保存到自己的数据库系统中。
可以接收任何人的任何数据。若需要过滤恶意的数据、垃圾数据,可以通用对系统的设置来限制系统接收某些地址的数据。犹如电子邮件那样,只要建立了自己的跨平台数据交换接口(犹如电子邮件中的邮件服务器、邮局),或申请一个免费的数据交换接口地址,就可以实现跨平台数据交换,用户不必再编写其它的接口软件。[注:电子邮件服务器提供了邮件系统的基本结构,包括邮件传输、邮件分发、邮件存储等功能,以确保邮件能够发送到Internet网络中的任意地方,目前许多邮件服务器处于电信托管方式(服务器托管、服务器租用)。]
IDB对WEB服务进行了特殊处理,IDB之间进行数据交换时,不需要添加对方的WEB服务。IDB只用三个WEB服务即可实现跨平台数据交换。IDB系统之间进行数据交换时只要有了对方的IP或域名即可与对方交换数据,而不必再添加对方的WEB引用。接口不标准的后果:需要面对成千上万、上百万的WEB服务,进行数据交换前需要添加对方的WEB引用,再编写处理软件,这是非常烦琐的。
针对同一种数据库只需要一种版本的IDB接口。
可以直接把数据发送到对方的数据库中,而不是仅发送XML文件。XML与关系数据之间有一个难以逾越的鸿沟:XML文件中的数据难以转换到关系数据库中。面对成千上万的XML文件时,关系数据库无能为力。
对于所收到的大部分数据,普通用户可以直接对收到的数据进行处理。也可以把处理结果回复给发送方(例如:订单管理、公文管理、供应链管理等)。
接口通用,可交换任何结构的数据,基本上可以满足大部分数据交换问题。从而使接口问题变得非常简单,犹如收发电子邮件,用户不必再关心接口问题。用户可以主要的精力放在发送什么样的数据,发送数据的结构、内容、格式,以及如何处理接收到的数据。
七、设计SOA系统的注意事项
SOA只不过是一种概念,要使SOA系统成功,使信息系统具有良好的开放性,必须注意如下事项:
1、表名、字段名的标准化、规范化,采用自然语言,尽量避免用代码。
2、数据类型要采用常用的类型。
3、数据及数据结构的规范化、标准化。这是一项长期而艰巨的工作。
4、数据的独立性、完整性。
5、要有一个通用的接口并使接口的标准化、规范化、通用化,以此来确保信息系统的开放性,不排斥专用的接口。