一卡通系統(tǒng)數(shù)據(jù)交換模式初探

文章出處：http://botanicstilllife.com 作者：歐陽(yáng)小建   人氣： 發(fā)表時(shí)間：2011年12月03日

一、前言

    一卡通，簡(jiǎn)言之即一卡通用，用戶(hù)持一張卡可在多個(gè)應(yīng)用領(lǐng)域進(jìn)行使用，最常見(jiàn)的如企業(yè)一卡通、校園一卡通、小區(qū)一卡通、酒店一卡通等等。不同行業(yè)的一卡通系統(tǒng)，其基本架構(gòu)一般都采用平臺(tái)+應(yīng)用的模式，即在一卡通平臺(tái)之上來(lái)構(gòu)筑諸跟卡相關(guān)的應(yīng)用系統(tǒng)，如達(dá)實(shí)公司自主研發(fā)的C3企業(yè)一卡通系統(tǒng)即由企業(yè)一卡通平臺(tái)（人員信息+設(shè)備信息+卡片信息+數(shù)據(jù)庫(kù)后臺(tái)）外加常見(jiàn)的考勤、消費(fèi)、門(mén)禁等應(yīng)用；而校園一卡通系統(tǒng)一般由校園一卡通平臺(tái)外加常見(jiàn)的食堂消費(fèi)、綜合消費(fèi)、考勤管理、門(mén)禁管理、數(shù)字迎新管理、控水、控電節(jié)能管理以及圖書(shū)館管理、機(jī)房管理、多媒教學(xué)、重點(diǎn)設(shè)備管理等應(yīng)用。

    IC卡技術(shù)發(fā)展到現(xiàn)在，形成了不同行業(yè)中的參差不齊的一卡通系統(tǒng)供應(yīng)商，有的供應(yīng)商面向高端市場(chǎng)，也有的面向中低端市場(chǎng)。我們的終端用戶(hù)往往對(duì)IC卡的應(yīng)用及其相關(guān)知識(shí)缺乏足夠的了解，在選擇適合于自己企業(yè)的一卡通系統(tǒng)時(shí)往往選擇了至少2家以上的系統(tǒng)供應(yīng)商，如選擇了A系統(tǒng)供應(yīng)商的考勤管理系統(tǒng)，同時(shí)選擇了B供應(yīng)商的消費(fèi)、門(mén)禁管理子系統(tǒng)，因?yàn)樵谟脩?hù)看來(lái)，這兩家供應(yīng)商各有所專(zhuān)長(zhǎng)，且供應(yīng)商答應(yīng)仍可實(shí)現(xiàn)所謂的一卡通用。對(duì)IC卡系統(tǒng)熟悉的讀者就會(huì)知道，這實(shí)際上并非是真正意義上的一卡通（卡通、庫(kù)通、網(wǎng)通三者缺一不可），因?yàn)橹辽贁?shù)據(jù)庫(kù)就未真正通起來(lái)。這樣的客戶(hù)并不少見(jiàn)，在我接觸的許多用戶(hù)中就有這樣的案例，我們額外所要做的事就是如何在不同的一卡通系統(tǒng)之間做數(shù)據(jù)交換。

    另外，由于大多數(shù)一卡通系統(tǒng)供應(yīng)商做的是專(zhuān)業(yè)的一卡通系統(tǒng)（如專(zhuān)業(yè)做考勤系統(tǒng)或門(mén)禁或停車(chē)場(chǎng)系統(tǒng)），從而使得企業(yè)用戶(hù)在選擇這些供應(yīng)商時(shí)，往往得同時(shí)向多家一卡通供應(yīng)商去購(gòu)買(mǎi)拼湊型一卡通系統(tǒng)。而這些系統(tǒng)的基礎(chǔ)數(shù)據(jù)又恰恰來(lái)源于企業(yè)的HR系統(tǒng)。這又迫使企業(yè)投入足夠的人力物力去協(xié)調(diào)各系統(tǒng)間的數(shù)據(jù)交換及同步問(wèn)題。

    基于一卡通行業(yè)的應(yīng)用現(xiàn)狀，如何在各信息系統(tǒng)之間找到一種簡(jiǎn)單、通用、高效的數(shù)據(jù)交換機(jī)制，就成為一件很有意義的事情。下面我們就來(lái)探討一下這個(gè)數(shù)據(jù)交換問(wèn)題。

二、常用數(shù)據(jù)交換模式

    一卡通系統(tǒng)之間需要共享的數(shù)據(jù)一般均為基礎(chǔ)數(shù)據(jù)，如人員信息（包括人員姓名、性別、部門(mén)、出生年月、部門(mén)以及在職狀態(tài)等）、卡片信息（包括卡ID號(hào)、流水號(hào)、卡狀態(tài)日期、卡狀態(tài)、卡有效期等）等。而業(yè)務(wù)明細(xì)數(shù)據(jù)在這方面則相對(duì)要求比較少，除非客戶(hù)想基于這些業(yè)務(wù)數(shù)據(jù)做一些深層次的數(shù)據(jù)挖掘工作。

    基礎(chǔ)數(shù)據(jù)交換的方式一般常見(jiàn)的有以下幾種，外部文件（如Txt、CSV、XML）導(dǎo)入導(dǎo)出、數(shù)據(jù)庫(kù)視圖（DataView）方式、數(shù)據(jù)庫(kù)觸發(fā)器（Trigger）方式、中間服務(wù)（如Web Service）方式。下面分別作一些簡(jiǎn)單介紹。

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

    文共享模式是最常見(jiàn)的一種松耦合的數(shù)據(jù)交換模式。文件的數(shù)據(jù)格式事先由系統(tǒng)雙方共同約定，之后由導(dǎo)出系統(tǒng)按約定格式導(dǎo)出，待導(dǎo)入系統(tǒng)接收文件后按約定格式進(jìn)行解析并導(dǎo)入系統(tǒng)。示意圖如圖1所示。 

    文件的格式通常有以下幾種：

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

    ii) CSV格式（Comma Separate Values）：以逗號(hào)為分隔符的數(shù)據(jù)交互格式，具體格式定義如下：

    每條記錄占一行；
    以逗號(hào)為分隔符；
    逗號(hào)前后的空格會(huì)被忽略；
    字段中包含有逗號(hào)，該字段必須用雙引號(hào)括起來(lái)；
    字段中包含有換行符，該字段必須用雙引號(hào)括起來(lái)；
    字段前后包含有空格，該字段必須用雙引號(hào)括起來(lái)；
    字段中的雙引號(hào)用兩個(gè)雙引號(hào)表示；
    字段中如果有雙引號(hào)，該字段必須用雙引號(hào)括起來(lái)；
    第一條記錄，可以是字段名；

    iii) XML格式（Extensible Markup Language）：XML是一種擴(kuò)展標(biāo)記語(yǔ)言，它是一種簡(jiǎn)單的數(shù)據(jù)儲(chǔ)存語(yǔ)言，采用一系列簡(jiǎn)單的標(biāo)記來(lái)描述數(shù)據(jù)，極易被第三方系統(tǒng)掌握和使用。

    在實(shí)際應(yīng)用中，具體選擇哪種數(shù)據(jù)格式并不重要，重要的是看哪一種格式更適合于當(dāng)前雙方之間的系統(tǒng)，即要減少工作量而且要能提高數(shù)據(jù)交換的時(shí)效性。

    數(shù)據(jù)文件共享模式的優(yōu)點(diǎn)在于其完全的松耦合性，安全性也比較好，雙方系統(tǒng)之間無(wú)需直接通訊，只要系統(tǒng)雙方事先約定好一定的數(shù)據(jù)格式，即可通過(guò)一定的介質(zhì)或載體將數(shù)據(jù)傳遞至另外一個(gè)系統(tǒng)。

    這種模式的缺點(diǎn)是數(shù)據(jù)傳遞的實(shí)時(shí)性不好，無(wú)法快速響應(yīng)用戶(hù)對(duì)數(shù)據(jù)實(shí)時(shí)性要求較高的場(chǎng)合。

2.2數(shù)據(jù)視圖模式（Data View）

    該模式是通過(guò)在提供數(shù)據(jù)的系統(tǒng)數(shù)據(jù)庫(kù)內(nèi)建立一開(kāi)放數(shù)據(jù)視圖（Data View），專(zhuān)供第三方系統(tǒng)來(lái)主動(dòng)獲取數(shù)據(jù)。我們常見(jiàn)的SQL Server、Oracle數(shù)據(jù)庫(kù)均可建立這樣的視圖。示意圖如圖2所示。 

    這種數(shù)據(jù)交互模式下，A系統(tǒng)一般會(huì)創(chuàng)建一個(gè)單獨(dú)的用戶(hù)，供B系統(tǒng)獲取Data View專(zhuān)用，該用戶(hù)一般只擁有讀取指定視圖數(shù)據(jù)的權(quán)限，所以不必?fù)?dān)心B系統(tǒng)通過(guò)該用戶(hù)會(huì)對(duì)A系統(tǒng)的數(shù)據(jù)造成破壞的可能。

    數(shù)據(jù)視圖模式下的B系統(tǒng)對(duì)數(shù)據(jù)的訪問(wèn)相對(duì)外部文件模式來(lái)說(shuō)更主動(dòng)和實(shí)時(shí)一些，只要B系統(tǒng)一有數(shù)據(jù)變動(dòng)，視圖便會(huì)自動(dòng)反映出來(lái)，只要B系統(tǒng)的數(shù)據(jù)獲取機(jī)制足夠靈活和實(shí)時(shí)即可獲得不錯(cuò)的數(shù)據(jù)交互效果。

    數(shù)據(jù)視圖模式也是一種松耦合型的數(shù)據(jù)接口模式，其優(yōu)點(diǎn)在于提供數(shù)據(jù)方的工作量較少，只要建好視圖、開(kāi)放用戶(hù)即可；另外視圖也可靈活定義，只要保證輸出項(xiàng)不變即可，至于數(shù)據(jù)條件可靈活設(shè)置。缺點(diǎn)是由于其數(shù)據(jù)庫(kù)部分對(duì)外開(kāi)放，在數(shù)據(jù)交互量較大的情況下會(huì)對(duì)數(shù)據(jù)提供方的后臺(tái)數(shù)據(jù)庫(kù)性能造成一定的影響。

2.3觸發(fā)器模式（Trigger）

    觸發(fā)器模式是一種可解決雙方系統(tǒng)數(shù)據(jù)能實(shí)時(shí)進(jìn)行同步的一種模式之一，它是通過(guò)在數(shù)據(jù)提供方的后臺(tái)數(shù)據(jù)庫(kù)中建立一些數(shù)據(jù)觸發(fā)器，達(dá)到當(dāng)數(shù)據(jù)一旦發(fā)生異動(dòng)時(shí)能通過(guò)觸發(fā)器在第一時(shí)間傳遞給第三方系統(tǒng)，從而達(dá)到實(shí)時(shí)的目的。示意圖如圖3所示。 

    該模式下，A系統(tǒng)會(huì)在自己的數(shù)據(jù)庫(kù)中有針對(duì)性地創(chuàng)建一些數(shù)據(jù)表Trigger，通過(guò)這些Trigger可以將數(shù)據(jù)表的異動(dòng)情況及時(shí)傳遞出去；而B(niǎo)系統(tǒng)一般會(huì)先創(chuàng)建一個(gè)單獨(dú)的用戶(hù)，供A系統(tǒng)的Trigger直接將異動(dòng)數(shù)據(jù)傳遞到B系統(tǒng)之用，另外，在B系統(tǒng)方一般會(huì)創(chuàng)建一個(gè)或多個(gè)中間數(shù)據(jù)表，供A系統(tǒng)的Trigger通過(guò)指定的用戶(hù)進(jìn)行讀和寫(xiě)。

    Trigger模式與Data View模式有點(diǎn)相似，都是A系統(tǒng)主動(dòng)將異動(dòng)數(shù)據(jù)準(zhǔn)備好，由B系統(tǒng)實(shí)時(shí)或非實(shí)時(shí)地去讀取。Trigger模式下數(shù)據(jù)交互的實(shí)時(shí)性取決于B系統(tǒng)，在Trigger模式下，如果B系統(tǒng)中的中間數(shù)據(jù)表也建立相應(yīng)的觸發(fā)器，實(shí)時(shí)對(duì)傳遞過(guò)來(lái)的數(shù)據(jù)進(jìn)行解析，則這種實(shí)時(shí)性就相當(dāng)不錯(cuò)了；但如果B系統(tǒng)是通過(guò)上位應(yīng)用軟件來(lái)定時(shí)分解中間數(shù)據(jù)表內(nèi)的數(shù)據(jù)，則實(shí)時(shí)性的效果就不是很明顯了。

    一般常用SQL Server或Oracle數(shù)據(jù)庫(kù)系統(tǒng)均可對(duì)表建立觸發(fā)器，所以這種模式對(duì)數(shù)據(jù)同步的實(shí)時(shí)性要求很高的系統(tǒng)來(lái)說(shuō)不失為一種選擇。觸發(fā)器模式是一種緊耦合的模式，它要求被同步的系統(tǒng)開(kāi)放其部分?jǐn)?shù)據(jù)表的可寫(xiě)功能，而這種開(kāi)放數(shù)據(jù)庫(kù)的可寫(xiě)性是數(shù)據(jù)接口的避諱。所以這種模式在不得已的情況下不建議大家去采用。

2.4中間服務(wù)模式（Web Service）

    中間服務(wù)模式是指由數(shù)據(jù)提供方開(kāi)放并提供一些中間數(shù)據(jù)服務(wù)，這些服務(wù)與數(shù)據(jù)庫(kù)物理分離，數(shù)據(jù)接收方通過(guò)這些數(shù)據(jù)服務(wù)來(lái)獲取對(duì)方數(shù)據(jù)的一種模式。示意圖如圖4。 

    中間數(shù)據(jù)服務(wù)模式對(duì)數(shù)據(jù)接口的開(kāi)放性和安全性方面來(lái)說(shuō)都是最佳的一種模式。數(shù)據(jù)提供方通過(guò)建立一系列的中間數(shù)據(jù)服務(wù)，針對(duì)不同的第三方系統(tǒng)靈活定制不同的數(shù)據(jù)服務(wù)，同時(shí)制定不同的開(kāi)放策略，靈活性很高。數(shù)據(jù)接收方要獲取數(shù)據(jù)，必須先獲得調(diào)用中間服務(wù)的許可權(quán)，有了許可權(quán)，就可以直接調(diào)用開(kāi)放的中間數(shù)據(jù)服務(wù)來(lái)獲取想要的數(shù)據(jù)。 

    中間數(shù)據(jù)服務(wù)的開(kāi)發(fā)語(yǔ)言可以有很多種，最常見(jiàn)的有基于.Net或J2EE架構(gòu)下開(kāi)發(fā)的Web Service服務(wù)。Web服務(wù)（Web Service）是近年內(nèi)興起的另一種基于Internet的技術(shù)，在近幾年受到了極大的關(guān)注。該技術(shù)的出現(xiàn)標(biāo)志著人類(lèi)已經(jīng)邁入應(yīng)用程序開(kāi)發(fā)技術(shù)的新紀(jì)元，它使得Internet不僅是傳輸數(shù)據(jù)的平臺(tái)，也變成了傳遞服務(wù)的平臺(tái)。 

    簡(jiǎn)單的說(shuō)，一個(gè)Web服務(wù)（圖5）就是一個(gè)能夠使用XML消息通過(guò)網(wǎng)絡(luò)來(lái)訪問(wèn)的接口，這個(gè)接口描述了一組可訪問(wèn)的操作。它是由企業(yè)驅(qū)動(dòng)和應(yīng)用驅(qū)動(dòng)而產(chǎn)生的；它具有分布性、松散藕合、可復(fù)用性、開(kāi)放性以及可交互性等特性。

    中間數(shù)據(jù)服務(wù)雖然有以上諸多優(yōu)點(diǎn)，但仍無(wú)法滿(mǎn)足對(duì)數(shù)據(jù)的實(shí)時(shí)性要求，即無(wú)法做到數(shù)據(jù)的實(shí)時(shí)同步。 

三、通用數(shù)據(jù)交換模式初探

    前面我們討論了一卡通系統(tǒng)之間一些常用的數(shù)據(jù)交換模式，包括各自的優(yōu)缺點(diǎn)我們也分別進(jìn)行了一些論述，下面我們來(lái)對(duì)一卡通系統(tǒng)之間的通用數(shù)據(jù)交換模式來(lái)做一個(gè)初步的探討。

3.1通用數(shù)據(jù)交換模式的定義

    通用數(shù)據(jù)交換一般必須滿(mǎn)足以下幾個(gè)要素：

    1） 支持多個(gè)一卡通系統(tǒng)之間進(jìn)行數(shù)據(jù)交換；
    2） 支持多個(gè)異構(gòu)數(shù)據(jù)庫(kù)之間的數(shù)據(jù)交換；
    3） 實(shí)施布署靈活，有較好的人機(jī)對(duì)話(huà)界面；
    4） 采用TCP/IP通訊協(xié)議進(jìn)行數(shù)據(jù)包的傳遞；
    5） 具備消息通知機(jī)制和日志可追查能力；
    6） 具備數(shù)據(jù)交換的授權(quán)接入機(jī)制，保證數(shù)據(jù)安全。

    如圖6所示。 

3.2通用數(shù)據(jù)交換架構(gòu)模型 

    根據(jù)前面的定義，我們可以初步設(shè)想一下通用數(shù)據(jù)交換的架構(gòu)模型。

    首先，該數(shù)據(jù)交換要能同時(shí)支持多個(gè)系統(tǒng)之間的數(shù)據(jù)進(jìn)行交換（或稱(chēng)之為同步），它必須要有一套完整的數(shù)據(jù)收集及數(shù)據(jù)分發(fā)系統(tǒng)，我們暫時(shí)稱(chēng)其為“通用數(shù)據(jù)交換系統(tǒng)”，如圖7所示。 

    圖7可以簡(jiǎn)單地看出“通用數(shù)據(jù)交換系統(tǒng)”的基本功能及工作原理，從第三方系統(tǒng)的數(shù)據(jù)安全性考慮，數(shù)據(jù)交換系統(tǒng)盡量避免直接對(duì)第三方的數(shù)據(jù)庫(kù)進(jìn)行操作。由此，我們可以引出“通用數(shù)據(jù)交換系統(tǒng)”中間件的概念。

    中間件(MiddleWare)，是基礎(chǔ)軟件的一大類(lèi)，屬于可復(fù)用軟件的范疇。顧名思義，中間件處于操作系統(tǒng)軟件與用戶(hù)的應(yīng)用軟件的中間。中間件在操作系統(tǒng)、網(wǎng)絡(luò)和數(shù)據(jù)庫(kù)之上，應(yīng)用軟件的下層，總的作用是為處于自己上層的應(yīng)用軟件提供運(yùn)行與開(kāi)發(fā)的環(huán)境，幫助用戶(hù)靈活、高效地開(kāi)發(fā)和集成復(fù)雜的應(yīng)用軟件。

    中間件分為兩大類(lèi)：一類(lèi)是底層中間件，用于支撐單個(gè)應(yīng)用系統(tǒng)或解決單一類(lèi)問(wèn)題，包括交易中間件（TPM）、應(yīng)用服務(wù)器（WAS）、消息中間件（MOM）、 數(shù)據(jù)訪問(wèn)中間件（UDA）等；另一類(lèi)是高層中間件，更多用于系統(tǒng)整合，包括企業(yè)應(yīng)用集成中間件（EAI Suites）、工作流中間件（Workflow）、門(mén)戶(hù)中間件（Portal）等，它們通常會(huì)與多個(gè)應(yīng)用系統(tǒng)打交道，在系統(tǒng)中的層次較高，并大多基于底層中間件運(yùn)行。

    數(shù)據(jù)交換中間件既包括底層中間件，用來(lái)與特定的第三方系統(tǒng)進(jìn)行數(shù)據(jù)交換，也包括高層中間件，用來(lái)整合多個(gè)第三方系統(tǒng)之間的數(shù)據(jù)交互。 

    有了數(shù)據(jù)交換中間件，我們可以對(duì)數(shù)據(jù)交換系統(tǒng)架構(gòu)模型進(jìn)行細(xì)化，如圖8所示。 

    我們將數(shù)據(jù)交換系統(tǒng)的中間件分兩部分，位于數(shù)據(jù)中心方（即待同步數(shù)據(jù)方）的中間件稱(chēng)之為中間件服務(wù)端，位于第三方系統(tǒng)（即待接收數(shù)據(jù)方）的中間件稱(chēng)之為中間件用戶(hù)端。這樣從數(shù)據(jù)中心出來(lái)的數(shù)據(jù)經(jīng)過(guò)中間件才到達(dá)第三方系統(tǒng)的數(shù)據(jù)庫(kù)中，我們就可以將很多數(shù)據(jù)業(yè)務(wù)邏輯、安全檢查以及數(shù)據(jù)處理規(guī)則等放在中間件端，從而減輕了數(shù)據(jù)庫(kù)方的壓力。 

    “通用數(shù)據(jù)交換系統(tǒng)”采用了流行的中間件技術(shù)，重點(diǎn)加強(qiáng)了數(shù)據(jù)交換的靈活性、傳輸?shù)陌踩?，以及易?shí)施性等諸多優(yōu)點(diǎn)。

四、篇尾總結(jié)

    隨著各行各業(yè)對(duì)一卡通系統(tǒng)的要求越來(lái)越高，除了穩(wěn)定性、可擴(kuò)展性被視為重要因素之一外，各一卡通產(chǎn)家之間的信息數(shù)據(jù)共享也顯得越來(lái)越重要，客戶(hù)不希望買(mǎi)了一堆信息相互孤立的系統(tǒng)。所以數(shù)據(jù)交換和共享成了一卡通廠家要優(yōu)先考慮的事情。

    本文粗略對(duì)一卡通系統(tǒng)之間的數(shù)據(jù)交換模式進(jìn)行了枚舉式的講解，并大膽提出“通用數(shù)據(jù)交換模式”的概念。由于篇幅有限原因，本文只能先簡(jiǎn)單對(duì)“通用數(shù)據(jù)交換系統(tǒng)”作拋磚引玉式的講解，作者將會(huì)在后期的文章中繼續(xù)對(duì)“通用數(shù)據(jù)交換系統(tǒng)”在用戶(hù)端授權(quán)、用戶(hù)端加密策略及加密字等方面展開(kāi)討論，希望有興趣的讀者可以一起來(lái)加以補(bǔ)充和完善。 (作者:達(dá)實(shí)智能,軟件工程部經(jīng)理歐陽(yáng)小建)

    參考文獻(xiàn)

    1. 《CSV文件格式介紹》，http://blog.iyi.cn/billy/2006/06/csv.html.
    2. 《XML格式》，http://www.hoodong.com/wiki/xmlæ ¼å¼.
    3. 《中間件的定義、分類(lèi)以及典型產(chǎn)品》，http://www.51testing.com/77492/action_viewspace_itemid_19488.html