一、前言
    一卡通，简言之即一卡通用，用户持一张卡可在多个应用领域进行使用，最常见的如企业一卡通、校园一卡通、小区一卡通、酒店一卡通等等。不同行业的一卡通系统，其基本架构一般都采用平台+应用的模式，即在一卡通平台之上来构筑诸跟卡相关的应用系统，如达实公司自主研发的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。 

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