查看文章 |
基于一卡通行业的应用现状,如何在各系统之间找到一种简单、通用、高效的数据交换机制,是一件很有意义的事情。本文主要探讨的就是这个数据交换问题,供大家参考交流。 一卡通,简言之即一卡通用,用户持一张卡可在多个应用领域进行使用。最常见的如企业一卡通、校园一卡通、小区一卡通、酒店一卡通等等。不同行业的一卡通系统,其基本架构一般都采用平台+应用的模式,即在一卡通平台之上来构筑跟卡相关的各类应用子系统。 IC卡技术发展到现在,终端用户往往仍对IC卡的应用及其相关技术缺乏足够的了解,在选择一卡通系统时,往往会选择二家以上的子系统供应商,如选择A供应商的考勤管理子系统,同时又选择了B供应商的消费、门禁管理子系统。因为在用户看来,这两家供应商各有所专长,且供应商表示可实现所谓的一卡通用。对IC卡系统熟悉的读者就会知道,这实际上并非是真正意义上的一卡通(卡通、库通、网通三者缺一不可),至少数据库就未真正通起来。因此,如何在不同的一卡通子系统间进行数据交换呢,这就要迫使企业投入足够的人力和物力去协调各系统间的数据交换及同步问题。 常用数据交换模式 一卡通各子系统间需要共享的数据一般均为基础数据,如人员信息(包括人员姓名、性别、部门、出生年月、部门以及在职状态等)、卡片信息(包括卡ID号、流水号、卡状态、日期、卡有效期等)等。而对业务明细数据则相对要求比较少,除非用户想基于这些业务数据做一些深层次的数据挖掘工作。 基础数据交换的方式一般常见的有以下几种,外部文件(如Txt、CSV、XML)导入导出、数据库视图(DataView)方式、数据库触发器(Trigger)方式、中间服务(如Web Service)方式。下面分别作一些简单介绍。 文件共享模式(TXT、CSV、XML) 文件的格式通常有以下几种: 2、CSV格式(Comma Separate Values):以逗号为分隔符的数据交互格式,具体格式定义如下: 3、XML格式(Extensible Markup Language):XML是一种扩展标记语言,它是一种简单的数据储存语言,采用一系列简单的标记来描述数据,极易被第三方系统掌握和使用。 在实际应用中,具体选择哪种数据格式并不重要,重要的是看哪一种格式更适合于双方之间的数据交换,即要减少工作量而且要能提高数据交换的时效性。 数据文件共享模式的优点在于其完全的松耦合性,安全性也比较好,双方系统之间无需直接通讯,只要系统双方事先约定好一定的数据格式,即可通过一定的介质或载体将数据传递至另外一个系统。 这种模式的缺点是数据传递的实时性不好,无法快速响应用户对数据实时性要求较高的场合。 数据视图模式(Data View) 在这种数据交互模式下,A系统一般会创建一个单独的用户,供B系统获取Data View专用,该用户一般只拥有读取指定视图数据的权限,所以不必担心B系统通过该用户会对A系统的数据造成破坏的可能。 数据视图模式下的B系统对数据的访问相对外部文件模式来说更主动和实时一些,只要B系统一有数据变动,视图便会自动反映出来,只要B系统的数据获取机制足够灵活和实时即可获得不错的数据交互效果。 数据视图模式也是一种松耦合型的数据接口模式,其优点在于提供数据方的工作量较少,只要建好视图、开放用户即可。另外视图也可灵活定义,只要保证输出项不变即可,至于数据条件可灵活设置。缺点是由于其数据库部分对外开放,在数据交互量较大的情况下会对数据提供方的后台数据库性能造成一定的影响。 触发器模式(Trigger) 该模式下,A系统会在自己的数据库中有针对性地创建一些数据表Trigger,通过这Trigger可以将数据表的异动情况及时传递出去;而B系统一般会先创建一个单独的用户,供A系统的Trigger直接将异动数据传递到B系统之用。另外,在B系统方一般会创建一个或多个中间数据表,供A系统的Trigger通过指定的用户进行读和写。 Trigger模式与Data View模式有点相似,都是A系统主动将异动数据准备好,由B系统实时或非实时地去读取。Trigger模式下数据交互的实时性取决于B系统,在Trigger模式下,如果B系统中的中间数据表也建立相应的触发器,实时地对传递过来的数据进行解析,则这种实时性就相当不错了。但如果B系统是通过上位应用软件来定时分解中间数据表内的数据,则实时性的效果就不是很明显了。 一般常用SQL Server或Oracle数据库系统均可对表建立触发器,所以这种模式对数据同步的实时性要求很高的系统来说不失为一种选择。触发器模式是一种紧耦合的模式,它要求被同步的系统开放其部分数据表的可写功能,而这种开放数据库的可写性是数据接口的避讳。所以这种模式在不得已的情况下不建议大家去采用。 中间服务模式(Web Service) 中间数据服务模式对数据接口的开放性和安全性方面来说都是最佳的一种模式。数据提供方通过建立一系列的中间数据服务,针对不同的第三方系统灵活定制不同的数据服务,同时制定不同的开放策略,灵活性很高。数据接收方要获取数据,必须先获得调用中间服务的许可权,有了许可权,就可以直接调用开放的中间数据服务来获取想要的数据。 中间数据服务的开发语言可以有很多种,最常见的有基于Net或J2EE架构下开发的Web Service服务。Web服务(Web Service)是近年内兴起的另一种基于Internet的技术,在近几年受到了极大的关注。该技术的出现标志着人类已经迈入应用程序开发技术的新纪元,它使得Internet不仅是传输数据的平台,也变成了传递服务的平台。 简单的说,一个Web服务就是一个能够使用XML消息通过网络来访问的接口,这个接口描述了一组可访问的操作。它是由企业驱动和应用驱动而产生的;它具有分布性、松散藕合、可复用性、开放性以及可交互性等特性。 中间数据服务虽然有以上诸多优点,但仍无法满足对数据的实时性要求,即无法做到数据的实时同步。 通用数据交换模式初探 前面我们讨论了一卡通系统之间一些常用的数据交换模式,包括各自的优缺点,下面我们来对一卡通系统之间的通用数据交换模式来做一个初步的探讨。 通用数据交换模式的定义 通用数据交换架构模型 从图7可以简单地看出“通用数据交换系统”的基本功能及工作原理,从第三方系统的数据安全性考虑,数据交换系统尽量避免直接对第三方的数据库进行操作。由此,我们可以引出“通用数据交换系统”中间件的概念。 中间件(MiddleWare)是基础软件的一大类,属于可复用软件的范畴。顾名思义,中间件处于操作系统软件与用户的应用软件的中间。中间件在操作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。 中间件分为两大类:一类是底层中间件,用于支撑单个应用系统或解决单一类问题,包括交易中间件(TPM)、应用服务器(WAS)、消息中间件(MOM)、 数据访问中间件(UDA)等;另一类是高层中间件,更多用于系统整合,包括企业应用集成中间件(EAI Suites)、工作流中间件(Workflow)、门户中间件(Portal)等,它们通常会与多个应用系统打交道,在系统中的层次较高,并大多基于底层中间件运行。 数据交换中间件既包括底层中间件,用来与特定的第三方系统进行数据交换,也包括高层中间件,用来整合多个第三方系统之间的数据交互。 有了数据交换中间件,我们可以对数据交换系统架构模型进行细化。 我们将数据交换系统的中间件分两部分,位于数据中心方(即待同步数据方)的中间件称之为中间件服务端,位于第三方系统(即待接收数据方)的中间件称之为中间件用户端。这样从数据中心出来的数据经过中间件才到达第三方系统的数据库中,我们就可以将很多数据业务逻辑、安全检查以及数据处理规则等放在中间件端,从而减轻了数据库方的压力。 “通用数据交换系统”采用了流行的中间件技术,重点加强了数据交换的灵活性、传输的安全性,以及易实施性等诸多优点。 结语 随着各行各业对一卡通系统的要求越来越高,除了稳定性、可扩展性被视为重要因素之一外,一卡通各子系统厂家之间的信息数据共享也显得越来越重要,客户不希望买了一堆信息相互孤立的系统,所以数据交换和共享成了一卡通厂家要优先考虑的事情。 本文粗略对一卡通系统之间的数据交换模式进行了枚举式的讲解,并大胆提出“通用数据交换模式”的概念。由于篇幅有限,本文只能先简单地对“通用数据交换系统”作抛砖引玉式的讲解,作者将会在后续的文章中继续对“通用数据交换系统”在用户端授权、用户端加密策略及加密字等方面展开讨论,希望有兴趣的读者可以一起来加以补充和完善。 文/欧阳晓建 |