一卡通系統數據交換模式初探

文章出處：http://5052h112.com 作者：歐陽小建   人氣： 發表時間：2011年12月03日

一、前言

    一卡通，簡言之即一卡通用，用戶持一張卡可在多個應用領域進行使用，最常見的如企業一卡通、校園一卡通、小區一卡通、酒店一卡通等等。不同行業的一卡通系統，其基本架構一般都采用平臺+應用的模式，即在一卡通平臺之上來構筑諸跟卡相關的應用系統，如達實公司自主研發的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