一卡通系统数据交换模式初探

一、前言

    一卡通，简言之即一卡通用，用户持一张卡可在多个应用领域进行使用，最常见的如企业一卡通、校园一卡通、小区一卡通、酒店一卡通等等。不同行业的一卡通系统，其基本架构一般都采用平台+应用的模式，即在一卡通平台之上来构筑诸跟卡相关的应用系统，如达实公司自主研发的C3企业一卡通系统即由企业一卡通平台（人员信息+设备信息+卡片信息+数据库后台）外加常见的考勤、消费、门禁等应用；而校园一卡通系统一般由校园一卡通平台外加常见的食堂消费、综合消费、考勤管理、门禁管理、数字迎新管理、控水、控电节能管理以及图书馆管理、机房管理、多媒教学、重点设备管理等应用。

    IC卡技术发展到现在，形成了不同行业中的参差不齐的一卡通系统供应商，有的供应商面向高端市场，也有的面向中低端市场。我们的终端用户往往对IC卡的应用及其相关知识缺乏足够的了解，在选择适合于自己企业的一卡通系统时往往选择了至少2家以上的系统供应商，如选择了A系统供应商的考勤管理系统，同时选择了B供应商的消费、门禁管理子系统，因为在用户看来，这两家供应商各有所专长，且供应商答应仍可实现所谓的一卡通用。对IC卡系统熟悉的读者就会知道，这实际上并非是真正意义上的一卡通（卡通、库通、网通三者缺一不可），因为至少数据库就未真正通起来。这样的客户并不少见，在我接触的许多用户中就有这样的案例，我们额外所要做的事就是如何在不同的一卡通系统之间做数据交换。

    另外，由于大多数一卡通系统供应商做的是专业的一卡通系统（如专业做考勤系统或门禁或停车场系统），从而使得企业用户在选择这些供应商时，往往得同时向多家一卡通供应商去购买拼凑型一卡通系统。而这些系统的基础数据又恰恰来源于企业的HR系统。这又迫使企业投入足够的人力物力去协调各系统间的数据交换及同步问题。

    基于一卡通行业的应用现状，如何在各信息系统之间找到一种简单、通用、高效的数据交换机制，就成为一件很有意义的事情。下面我们就来探讨一下这个数据交换问题。

二、常用数据交换模式

    一卡通系统之间需要共享的数据一般均为基础数据，如人员信息（包括人员姓名、性别、部门、出生年月、部门以及在职状态等）、卡片信息（包括卡ID号、流水号、卡状态日期、卡状态、卡有效期等）等。而业务明细数据在这方面则相对要求比较少，除非客户想基于这些业务数据做一些深层次的数据挖掘工作。

    基础数据交换的方式一般常见的有以下几种，外部文件（如Txt、CSV、XML）导入导出、数据库视图（DataView）方式、数据库触发器（Trigger）方式、中间服务（如Web Service）方式。下面分别作一些简单介绍。

2.1文件共享模式（TXT、CSV、XML）

    文共享模式是最常见的一种松耦合的数据交换模式。文件的数据格式事先由系统双方共同约定，之后由导出系统按约定格式导出，待导入系统接收文件后按约定格式进行解析并导入系统。示意图如图1所示。 

    文件的格式通常有以下几种：

    i) TXT格式（Text Document）：纯文本文件； 

    ii) CSV格式（Comma Separate Values）：以逗号为分隔符的数据交互格式，具体格式定义如下：

    每条记录占一行；
    以逗号为分隔符；
    逗号前后的空格会被忽略；
    字段中包含有逗号，该字段必须用双引号括起来；
    字段中包含有换行符，该字段必须用双引号括起来；
    字段前后包含有空格，该字段必须用双引号括起来；
    字段中的双引号用两个双引号表示；
    字段中如果有双引号，该字段必须用双引号括起来；
    第一条记录，可以是字段名；

    iii) XML格式（Extensible Markup Language）：XML是一种扩展标记语言，它是一种简单的数据储存语言，采用一系列简单的标记来描述数据，极易被第三方系统掌握和使用。

    在实际应用中，具体选择哪种数据格式并不重要，重要的是看哪一种格式更适合于当前双方之间的系统，即要减少工作量而且要能提高数据交换的时效性。

    数据文件共享模式的优点在于其完全的松耦合性，安全性也比较好，双方系统之间无需直接通讯，只要系统双方事先约定好一定的数据格式，即可通过一定的介质或载体将数据传递至另外一个系统。

    这种模式的缺点是数据传递的实时性不好，无法快速响应用户对数据实时性要求较高的场合。

2.2数据视图模式（Data View）

    该模式是通过在提供数据的系统数据库内建立一开放数据视图（Data View），专供第三方系统来主动获取数据。我们常见的SQL Server、Oracle数据库均可建立这样的视图。示意图如图2所示。 

    这种数据交互模式下，A系统一般会创建一个单独的用户，供B系统获取Data View专用，该用户一般只拥有读取指定视图数据的权限，所以不必担心B系统通过该用户会对A系统的数据造成破坏的可能。

    数据视图模式下的B系统对数据的访问相对外部文件模式来说更主动和实时一些，只要B系统一有数据变动，视图便会自动反映出来，只要B系统的数据获取机制足够灵活和实时即可获得不错的数据交互效果。

    数据视图模式也是一种松耦合型的数据接口模式，其优点在于提供数据方的工作量较少，只要建好视图、开放用户即可；另外视图也可灵活定义，只要保证输出项不变即可，至于数据条件可灵活设置。缺点是由于其数据库部分对外开放，在数据交互量较大的情况下会对数据提供方的后台数据库性能造成一定的影响。

2.3触发器模式（Trigger）

    触发器模式是一种可解决双方系统数据能实时进行同步的一种模式之一，它是通过在数据提供方的后台数据库中建立一些数据触发器，达到当数据一旦发生异动时能通过触发器在第一时间传递给第三方系统，从而达到实时的目的。示意图如图3所示。 

    该模式下，A系统会在自己的数据库中有针对性地创建一些数据表Trigger，通过这些Trigger可以将数据表的异动情况及时传递出去；而B系统一般会先创建一个单独的用户，供A系统的Trigger直接将异动数据传递到B系统之用，另外，在B系统方一般会创建一个或多个中间数据表，供A系统的 Trigger通过指定的用户进行读和写。

    Trigger模式与Data View模式有点相似，都是A系统主动将异动数据准备好，由B系统实时或非实时地去读取。Trigger模式下数据交互的实时性取决于B系统，在 Trigger模式下，如果B系统中的中间数据表也建立相应的触发器，实时对传递过来的数据进行解析，则这种实时性就相当不错了；但如果B系统是通过上位应用软件来定时分解中间数据表内的数据，则实时性的效果就不是很明显了。

    一般常用SQL Server或Oracle数据库系统均可对表建立触发器，所以这种模式对数据同步的实时性要求很高的系统来说不失为一种选择。触发器模式是一种紧耦合的模式，它要求被同步的系统开放其部分数据表的可写功能，而这种开放数据库的可写性是数据接口的避讳。所以这种模式在不得已的情况下不建议大家去采用。

2.4中间服务模式（Web Service）

    中间服务模式是指由数据提供方开放并提供一些中间数据服务，这些服务与数据库物理分离，数据接收方通过这些数据服务来获取对方数据的一种模式。示意图如图4。 

    中间数据服务模式对数据接口的开放性和安全性方面来说都是最佳的一种模式。数据提供方通过建立一系列的中间数据服务，针对不同的第三方系统灵活定制不同的数据服务，同时制定不同的开放策略，灵活性很高。数据接收方要获取数据，必须先获得调用中间服务的许可权，有了许可权，就可以直接调用开放的中间数据服务来获取想要的数据。 

    中间数据服务的开发语言可以有很多种，最常见的有基于.Net或J2EE架构下开发的Web Service服务。Web服务（Web Service）是近年内兴起的另一种基于Internet的技术，在近几年受到了极大的关注。该技术的出现标志着人类已经迈入应用程序开发技术的新纪元，它使得Internet不仅是传输数据的平台，也变成了传递服务的平台。 

    简单的说，一个Web服务（图5）就是一个能够使用XML消息通过网络来访问的接口，这个接口描述了一组可访问的操作。它是由企业驱动和应用驱动而产生的；它具有分布性、松散藕合、可复用性、开放性以及可交互性等特性。

    中间数据服务虽然有以上诸多优点，但仍无法满足对数据的实时性要求，即无法做到数据的实时同步。 

三、通用数据交换模式初探

    前面我们讨论了一卡通系统之间一些常用的数据交换模式，包括各自的优缺点我们也分别进行了一些论述，下面我们来对一卡通系统之间的通用数据交换模式来做一个初步的探讨。

3.1通用数据交换模式的定义

    通用数据交换一般必须满足以下几个要素：

    1） 支持多个一卡通系统之间进行数据交换；
    2） 支持多个异构数据库之间的数据交换；
    3） 实施布署灵活，有较好的人机对话界面；
    4） 采用TCP/IP通讯协议进行数据包的传递；
    5） 具备消息通知机制和日志可追查能力；
    6） 具备数据交换的授权接入机制，保证数据安全。

    如图6所示。 

3.2通用数据交换架构模型 

    根据前面的定义，我们可以初步设想一下通用数据交换的架构模型。

    首先，该数据交换要能同时支持多个系统之间的数据进行交换（或称之为同步），它必须要有一套完整的数据收集及数据分发系统，我们暂时称其为“通用数据交换系统”，如图7所示。 

    图7可以简单地看出“通用数据交换系统”的基本功能及工作原理，从第三方系统的数据安全性考虑，数据交换系统尽量避免直接对第三方的数据库进行操作。由此，我们可以引出“通用数据交换系统”中间件的概念。

    中间件(MiddleWare)，是基础软件的一大类，属于可复用软件的范畴。顾名思义，中间件处于操作系统软件与用户的应用软件的中间。中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。

    中间件分为两大类：一类是底层中间件，用于支撑单个应用系统或解决单一类问题，包括交易中间件（TPM）、应用服务器（WAS）、消息中间件（MOM）、数据访问中间件（UDA）等；另一类是高层中间件，更多用于系统整合，包括企业应用集成中间件（EAI Suites）、工作流中间件（Workflow）、门户中间件（Portal）等，它们通常会与多个应用系统打交道，在系统中的层次较高，并大多基于底层中间件运行。

    数据交换中间件既包括底层中间件，用来与特定的第三方系统进行数据交换，也包括高层中间件，用来整合多个第三方系统之间的数据交互。 

    有了数据交换中间件，我们可以对数据交换系统架构模型进行细化，如图8所示。 

    我们将数据交换系统的中间件分两部分，位于数据中心方（即待同步数据方）的中间件称之为中间件服务端，位于第三方系统（即待接收数据方）的中间件称之为中间件用户端。这样从数据中心出来的数据经过中间件才到达第三方系统的数据库中，我们就可以将很多数据业务逻辑、安全检查以及数据处理规则等放在中间件端，从而减轻了数据库方的压力。 

    “通用数据交换系统”采用了流行的中间件技术，重点加强了数据交换的灵活性、传输的安全性，以及易实施性等诸多优点。

四、篇尾总结

    随着各行各业对一卡通系统的要求越来越高，除了稳定性、可扩展性被视为重要因素之一外，各一卡通产家之间的信息数据共享也显得越来越重要，客户不希望买了一堆信息相互孤立的系统。所以数据交换和共享成了一卡通厂家要优先考虑的事情。

    本文粗略对一卡通系统之间的数据交换模式进行了枚举式的讲解，并大胆提出“通用数据交换模式”的概念。由于篇幅有限原因，本文只能先简单对“通用数据交换系统”作抛砖引玉式的讲解，作者将会在后期的文章中继续对“通用数据交换系统”在用户端授权、用户端加密策略及加密字等方面展开讨论，希望有兴趣的读者可以一起来加以补充和完善。 (作者:达实智能,软件工程部经理欧阳小建)

    参考文献

    1. 《CSV文件格式介绍》，http://blog.iyi.cn/billy/2006/06/csv.html.
    2. 《XML格式》，http://www.hoodong.com/wiki/xmlæ ¼å¼.
    3. 《中间件的定义、分类以及典型产品》，http://www.51testing.com/77492/action_viewspace_itemid_19488.html