無(wú)線射頻識(shí)別(RFID)技術(shù)是一種快速、實(shí)時(shí)、準(zhǔn)確的信息采集與處理技術(shù)，通過(guò)射頻信號(hào)對(duì)實(shí)體對(duì)象進(jìn)行唯一有效的標(biāo)識(shí)，可廣泛應(yīng)用于生產(chǎn)、零售、物流、交通、醫(yī)療、國(guó)防、畜牧、采礦等各個(gè)行業(yè)。
   
    基本的RFID系統(tǒng)一般由3部分組成：標(biāo)簽、閱讀器以及應(yīng)用支撐軟件。中間件是應(yīng)用支撐軟件的一個(gè)重要組成部分，是銜接硬件設(shè)備如標(biāo)簽、閱讀器和企業(yè)應(yīng)用軟件如企業(yè)資源規(guī)劃(ERP)、客戶關(guān)系管理(CRM)等的橋梁。中間件的主要任務(wù)是對(duì)閱讀器傳來(lái)的與標(biāo)簽相關(guān)的數(shù)據(jù)進(jìn)行過(guò)濾、匯總、計(jì)算、分組，減少?gòu)拈喿x器傳往企業(yè)應(yīng)用的大量原始數(shù)據(jù)、生成加入了語(yǔ)意解釋的事件數(shù)據(jù)?？梢哉f(shuō)，中間件是RFID系統(tǒng)的“神經(jīng)中樞”。
   
    對(duì)于RFID中間件的設(shè)計(jì)，有諸多問(wèn)題需要考慮，如：如何實(shí)現(xiàn)軟件的諸多質(zhì)量屬性、如何實(shí)現(xiàn)中間件與硬件設(shè)備的隔離、如何處理與設(shè)備管理功能的關(guān)系、如何實(shí)現(xiàn)高性能的數(shù)據(jù)處理等等。
   
    1、RFID網(wǎng)絡(luò)框架結(jié)構(gòu)
   
    無(wú)線射頻識(shí)別網(wǎng)絡(luò)的框架結(jié)構(gòu)如圖1所示。

圖1 RFID網(wǎng)絡(luò)結(jié)構(gòu)框架圖

    標(biāo)簽數(shù)據(jù)經(jīng)過(guò)中間件的分組、過(guò)濾等處理上報(bào)給應(yīng)用系統(tǒng)；應(yīng)用系統(tǒng)負(fù)責(zé)事件數(shù)據(jù)的持久化存儲(chǔ)，以及標(biāo)簽綁定的業(yè)務(wù)信息的管理。
   
    RFID系統(tǒng)共享公共服務(wù)平臺(tái)提供根節(jié)點(diǎn)對(duì)象名稱服務(wù)(ONS)、企業(yè)應(yīng)用鑒權(quán)管理、標(biāo)簽信息發(fā)現(xiàn)和企業(yè)授權(quán)碼管理等公共服務(wù)。其中，根節(jié)點(diǎn)ONS連同所有企業(yè)級(jí)RFID系統(tǒng)的內(nèi)部ONS，組成一個(gè)ONS樹(shù)，任何一個(gè)標(biāo)簽都可以在ONS樹(shù)上找到標(biāo)簽所對(duì)應(yīng)的標(biāo)簽信息庫(kù)的地址，即可以進(jìn)一步訪問(wèn)到標(biāo)簽對(duì)應(yīng)的詳細(xì)信息。
   
    2、中間件功能及實(shí)現(xiàn)原理
   
    一言蔽之，中間件的功能就是接受應(yīng)用系統(tǒng)的請(qǐng)求，對(duì)指定的一個(gè)或者多個(gè)閱讀器發(fā)起操作命令如標(biāo)簽清點(diǎn)、標(biāo)簽標(biāo)識(shí)數(shù)據(jù)寫(xiě)入、標(biāo)簽用戶數(shù)據(jù)區(qū)讀寫(xiě)、標(biāo)簽數(shù)據(jù)加鎖、標(biāo)簽殺死等，并接收、處理、向后臺(tái)應(yīng)用系統(tǒng)上報(bào)結(jié)果數(shù)據(jù)。
   
    其中，標(biāo)簽清點(diǎn)是最為基本、也是應(yīng)用最為廣泛的功能。
   
    2.1 標(biāo)簽清點(diǎn)功能概述
   
    標(biāo)簽清點(diǎn)的工作流程可簡(jiǎn)單描述為：
   
    應(yīng)用系統(tǒng)以規(guī)則的形式定義對(duì)標(biāo)簽數(shù)據(jù)的需求，規(guī)則由應(yīng)用系統(tǒng)向中間件提出，由中間件維護(hù)。規(guī)則中定義了：需要哪些閱讀器的清點(diǎn)數(shù)據(jù)，標(biāo)簽數(shù)據(jù)上報(bào)周期(事件周期)的開(kāi)始和結(jié)束條件，標(biāo)簽數(shù)據(jù)如何過(guò)濾，標(biāo)簽數(shù)據(jù)如何分組，上報(bào)數(shù)據(jù)為原始清點(diǎn)數(shù)據(jù)、新增標(biāo)簽數(shù)據(jù)還是新減標(biāo)簽數(shù)據(jù)，標(biāo)簽數(shù)據(jù)包含哪些原始數(shù)據(jù)等。
   
    應(yīng)用系統(tǒng)指定某項(xiàng)規(guī)則，向中間件提出對(duì)標(biāo)簽數(shù)據(jù)的預(yù)訂。
   
    中間件根據(jù)應(yīng)用系統(tǒng)對(duì)標(biāo)簽數(shù)據(jù)的預(yù)訂情況，適時(shí)啟動(dòng)事件周期，并向閱讀器下發(fā)標(biāo)簽清點(diǎn)命令。
   
    閱讀器將一定時(shí)間周期(讀取周期)中清點(diǎn)到的數(shù)據(jù)，發(fā)送給中間件。讀取周期可由中間件與閱讀器制定私下協(xié)商確定。
   
    中間件接由收閱讀器上報(bào)的數(shù)據(jù)。
   
    中間件根據(jù)規(guī)則的定義，對(duì)接收數(shù)據(jù)做過(guò)濾、分組、累加等操作，并在事件周期結(jié)束時(shí)，按照規(guī)則的要求生成數(shù)據(jù)結(jié)果報(bào)告，發(fā)送給規(guī)則的預(yù)訂者。過(guò)濾過(guò)程可去除重復(fù)數(shù)據(jù)、應(yīng)用系統(tǒng)不感興趣的數(shù)據(jù)，大大降低了組件間的傳輸數(shù)據(jù)量。
   
    此流程可參見(jiàn)圖2。

圖2 中間件標(biāo)簽清點(diǎn)概要流程圖

    此處，需要說(shuō)明一下邏輯閱讀器的概念。
   
    中間件將事件源抽象為一個(gè)邏輯概念——邏輯閱讀器，一個(gè)邏輯閱讀器可以包含多個(gè)物理閱讀器，甚至可更細(xì)化為包含多個(gè)物理閱讀器的多個(gè)天線。
   
    邏輯閱讀器的劃分可以根據(jù)實(shí)際的系統(tǒng)部署情況來(lái)確定，比如，某一個(gè)倉(cāng)庫(kù)兩個(gè)出口部署了4個(gè)閱讀器，可根據(jù)需要將這4個(gè)閱讀器配置成為一個(gè)邏輯閱讀器，不妨命名為“倉(cāng)庫(kù)出口”。應(yīng)用系統(tǒng)在需要倉(cāng)庫(kù)出口的標(biāo)簽數(shù)據(jù)時(shí)，可基于這個(gè)邏輯閱讀器下發(fā)清點(diǎn)命令，而邏輯閱讀器名稱作為部分應(yīng)用程序接口(API)調(diào)用的參數(shù)。
   
    2.2 標(biāo)簽清點(diǎn)實(shí)現(xiàn)原理
   
    如前所述，規(guī)則是整個(gè)中間件功能的關(guān)鍵元素。規(guī)則相當(dāng)于應(yīng)用系統(tǒng)發(fā)給中間件的訂貨單，定義了對(duì)貨品(標(biāo)簽數(shù)據(jù))的時(shí)間(事件周期)和規(guī)格(如何過(guò)濾、如何分組、報(bào)告樣式等)的要求，原理描述部分參考EPCglobal相關(guān)內(nèi)容。
   
    規(guī)則、報(bào)告有自身的信息模型，表征其承載的信息，同時(shí)，規(guī)則擁有其自身的狀態(tài)機(jī)模型。在接受應(yīng)用系統(tǒng)的長(zhǎng)期預(yù)訂、單次預(yù)訂時(shí)，這些預(yù)訂操作會(huì)激發(fā)規(guī)則的狀態(tài)變遷，如從“未被請(qǐng)求”狀態(tài)躍遷到“已被請(qǐng)求”狀態(tài)。
   
    規(guī)則由應(yīng)用系統(tǒng)通過(guò)API定義。
   
    (1) 規(guī)則信息模型
   
    規(guī)則信息模型的描述采用了統(tǒng)一建模語(yǔ)言(UML)，如圖3所示。

圖3 規(guī)則信息模型圖

    在面向?qū)ο蟮恼Z(yǔ)境中，規(guī)則可表征為一個(gè)類(ECSpec)。從信息模型描述中可看出，一個(gè)規(guī)則類，與其他多個(gè)類具有關(guān)聯(lián)關(guān)系，或者說(shuō)擁有如下屬性：一個(gè)或者多個(gè)邏輯閱讀器的列表(readers)、事件周期邊界定義(boundaries)、一個(gè)或者多個(gè)報(bào)告的定義(reportSpecs)、是否在報(bào)告中包含規(guī)則本身的標(biāo)記(includeSpecInReports)。 
   
    (2) 報(bào)告信息模型 
   
    與規(guī)則信息模型類似，報(bào)告信息模型如圖4所示。 

圖4 報(bào)告信息模型圖

其中，事件報(bào)告組類(ECReports)擁有如下屬性：規(guī)則名稱(specName)、時(shí)間上報(bào)時(shí)間(date)、事件周期時(shí)長(zhǎng)(totalMilliseconds)、事件周期結(jié)束條件(terminationCondition)、規(guī)則定義類實(shí)例(spec)、一個(gè)或者多個(gè)報(bào)告類的實(shí)例列表(reports)。 
   
    報(bào)告類(ECReport)中包含了具體的標(biāo)簽數(shù)據(jù)信息。 
   
    (3) 標(biāo)簽清點(diǎn)API 
   
    應(yīng)用系統(tǒng)下發(fā)的定義規(guī)則、預(yù)訂數(shù)據(jù)等請(qǐng)求，以調(diào)用中間件提供的API的方式完成。API調(diào)用過(guò)程可采用Java RMI、SOAP等相關(guān)具體技術(shù)實(shí)現(xiàn)，其中最重要的API參見(jiàn)表1。 

表1 標(biāo)簽清點(diǎn)應(yīng)用程序接口

    其中，poll操作相當(dāng)于subscribe操作收到一個(gè)事件周期的數(shù)據(jù)之后調(diào)用unsubscribe操作；immediate操作相當(dāng)于define操作定義規(guī)則之后，調(diào)用poll操作，然后調(diào)用undefine操作。 
   
    (4) 規(guī)則狀態(tài)機(jī)模型 
   
    規(guī)則從其定義開(kāi)始，可能存在于3種狀態(tài)：未被請(qǐng)求狀態(tài)(Unrequested)、已被請(qǐng)求狀態(tài)(Requested)、激活狀態(tài)(Active)。 
   
    當(dāng)規(guī)則創(chuàng)建之后，還沒(méi)有被任何客戶端(即應(yīng)用系統(tǒng))預(yù)訂，規(guī)則處于Unrequested狀態(tài)；對(duì)規(guī)則的第一個(gè)預(yù)訂動(dòng)作將使規(guī)則躍遷到Requested狀態(tài)；當(dāng)事件周期開(kāi)始條件滿足時(shí)，規(guī)則進(jìn)入Active狀態(tài)；當(dāng)事件周期結(jié)束條件滿足時(shí)，如果規(guī)則存在預(yù)訂者，則躍遷到Requested狀態(tài)，否則躍遷到Unrequested狀態(tài)。 
   
    3、中間件系統(tǒng)架構(gòu) 
   
    中間件系統(tǒng)作為一個(gè)軟件系統(tǒng)(或稱組件)，在實(shí)現(xiàn)一定功能、性能要求之外，可理解性、可擴(kuò)展性、可修改性(或稱可重構(gòu)性)、可插入性、可重用性等質(zhì)量屬性都將作為軟件設(shè)計(jì)的要求被提出來(lái)。 
   
    近十余年來(lái)，面向?qū)ο笏枷霂缀跞嬲碱I(lǐng)軟件設(shè)計(jì)領(lǐng)域，成為最主流的分析、設(shè)計(jì)方法。而近數(shù)年來(lái)，對(duì)設(shè)計(jì)模式的研究也已日臻完善，模式幾乎已成為一種“更高級(jí)編程語(yǔ)言”(相比于Java、C++等高級(jí)編程語(yǔ)言)被廣泛應(yīng)用。 
   
    面向?qū)ο笏枷?、設(shè)計(jì)模式都是以實(shí)現(xiàn)軟件的可理解、可擴(kuò)展、可修改、可插入、可重用等目標(biāo)為己任的，本文也將應(yīng)用面向?qū)ο笏枷?、參考模式語(yǔ)言，對(duì)中間件的軟件架構(gòu)做一個(gè)初步的探討，下文的例子如涉及高級(jí)編程語(yǔ)言，均采用Java語(yǔ)言[2]。 
   
    3.1 封裝、隔離處理流程中的各個(gè)節(jié)點(diǎn) 
   
    將中間件的業(yè)務(wù)流程中的各個(gè)節(jié)點(diǎn)分作不同模塊處理，可以獲得封裝、高內(nèi)聚、低耦合等優(yōu)勢(shì)，參見(jiàn)圖5。

圖5 中間件系統(tǒng)模塊劃分圖

    其中，報(bào)告上傳模塊，負(fù)責(zé)實(shí)現(xiàn)不同類型的報(bào)告上傳方式，如HTTP、JMS等；API接口模塊，負(fù)責(zé)隔離應(yīng)用系統(tǒng)和中間件核心業(yè)務(wù)邏輯處理模塊，向應(yīng)用系統(tǒng)提供中間件API接口；中間件核心業(yè)務(wù)邏輯處理模塊，負(fù)責(zé)中間件核心業(yè)務(wù)，包括數(shù)據(jù)接收過(guò)濾、數(shù)據(jù)分組、報(bào)告生成、規(guī)則對(duì)象的狀態(tài)跳轉(zhuǎn)等；閱讀器通信模塊，負(fù)責(zé)中間件系統(tǒng)與閱讀器的通信。 
   
    3.2 門(mén)面模式、工廠模式對(duì)外部暴露API接口 
   
    為了避免后臺(tái)應(yīng)用系統(tǒng)，即中間件的客戶端過(guò)分耦合，采用門(mén)面模式(Facade)對(duì)系統(tǒng)內(nèi)部、外部實(shí)現(xiàn)清晰的隔離。處理流程可參見(jiàn)圖6所示的序列圖。客戶端僅僅與Facade類建立聯(lián)系，如果Facade接口定義得足夠清晰，客戶端可以對(duì)中間件的內(nèi)部實(shí)現(xiàn)一無(wú)所知，這體現(xiàn)了面向?qū)ο笾械姆庋b性。

圖6 客戶端調(diào)用APT序列圖

    類的設(shè)計(jì)參見(jiàn)源代碼示例，從中可以看出，采用簡(jiǎn)單工廠模式(Simple Factory)能夠在客戶端不知情的情況下，靈活地替換API實(shí)現(xiàn)類的版本。中間件API接口清晰地定義了中間件提供的操作，客戶端只須知道工廠類(APIFactory)能夠得到中間件API接口的實(shí)例即可。  
    
    中間件API接口MiddlewareAPI： 
   
    publicinterfaceMiddlewareAPI{ 
    void define(String specName, ECSpec spec); 
    void undefine(String specName); 
    void subscribe(String specName, String uri); 
    void unsubscribe(String specName, String uri); 
    EPCReports poll(String specName); 
    EPCReports immediate(ECSpec spec);  
    } 

    工廠類APIFactory： 
   
    publicclassAPIFactory{ 
    publicstaticMiddlewareAPIgetAPIInstance(){ 
    } 
    } 

    API的實(shí)現(xiàn)類A： 

    publicclassClient{ 
    publicstaticvoidmain(String[] args) { 
    MiddlewareAPI api = APIFactory.getAPIInstance(); 
    api.define(a new spec, new EPCSpec());  
    } 
    } 

3.3 狀態(tài)模式模擬規(guī)則的狀態(tài)機(jī) 
   
    規(guī)則在其生命周期中擁有不同的狀態(tài)，在每個(gè)狀態(tài)對(duì)一系列操作都有著不同的表現(xiàn)，于是可以利用狀態(tài)模式(state)來(lái)模擬規(guī)則的狀態(tài)機(jī)，將不同狀態(tài)的不同表現(xiàn)作為可變化因素封裝起來(lái)，參見(jiàn)代碼示例。 
   
    規(guī)則狀態(tài)接口ECState： 
   
    publicinterfaceECState{ 
    voidsubscribe(StringspecName,String uri); 
    voidunsubscribe(StringspecName,String uri); 
    EPCReportspoll(StringspecName); 
    } 
   
    未被請(qǐng)求狀態(tài)類ECStateUnrequested： 
   
    publicclassECStateUnrequestedimplements ECState { 
    } 
   
    已被請(qǐng)求狀態(tài)類ECStateRequested： 
   
    publicclassECStateRrequestedimplements ECState { 
    } 
   
    激活狀態(tài)類ECStateActive： 
   
    publicclassECStateActiveimplements ECState { 
    } 
   
    規(guī)則類ECSpec： 
   
    publicclassECSpec{ 
    privateECStatestate; 
    publicECStategetState(){ 
    return state; 
    } 
    publicvoidsetState(ECStatestate) { 
    this.state = state; 
    } 
    } 
   
    這樣，在針對(duì)規(guī)則實(shí)施相應(yīng)操作的時(shí)候，就可以直接把相應(yīng)操作委派給其狀態(tài)屬性(ECState)去做即可。比如，ECSpec的subscribe操作，只需一行代碼“state.suscribe(specName, uri);”即可。其中，specName、uri為臨時(shí)變量，具體取值在方法調(diào)用之前確定。 
   
    由面向?qū)ο蟮亩鄳B(tài)性特征，根據(jù)state字段目前所指向的對(duì)象來(lái)動(dòng)態(tài)確定由ECState接口的哪一個(gè)具體的實(shí)現(xiàn)類的代碼來(lái)完成工作。ECState接口的實(shí)現(xiàn)類根據(jù)實(shí)際情況確定是否需要在處理過(guò)程中修改ECSpec對(duì)象的狀態(tài)屬性(state)，此處在應(yīng)用狀態(tài)模式時(shí)，需要設(shè)計(jì)多個(gè)定時(shí)器類來(lái)輔助狀態(tài)機(jī)的跳轉(zhuǎn)。 
   
    3.4 策略模式切換多種報(bào)告上傳、命令下發(fā)方式 
   
    事件周期結(jié)束之后，中間件需要組裝報(bào)告上傳給規(guī)則的預(yù)訂者，即應(yīng)用系統(tǒng)。上傳的方式有多種，如HTTP、Socket、JMS等等。中間件的核心邏輯處理模塊不應(yīng)該關(guān)心具體的上傳技術(shù)，相應(yīng)工作應(yīng)交給報(bào)告上傳模塊來(lái)做，核心邏輯處理模塊只須完成自己的工作，然后把一定格式的數(shù)據(jù)通過(guò)報(bào)告上傳模塊發(fā)送，參見(jiàn)代碼示例。
 
    報(bào)告發(fā)送接口ReportSender： 
   
    publicinterfaceReportSender{ 
    voidsendReport(ECReportsreports); 
    } 
   
    通過(guò)Http方式發(fā)送報(bào)告的ReportSender接口實(shí)現(xiàn)類ReportSenderByHttp： 
   
    publicclassReportSenderByHttpimplements ReportSender { 
    public void sendReport(ECReports reports) { 
    } 
    } 
   
    通過(guò)Socket方式發(fā)送報(bào)告的ReportSender接口實(shí)現(xiàn)類ReportSenderBySocket： 
   
    publicclassReportSenderBySocketimplements ReportSender { 
    publicvoidsendReport(ECReportsreports) { 
    } 
    } 
   
    通過(guò)JMS方式發(fā)送報(bào)告的ReportSender接口實(shí)現(xiàn)類ReportSenderByJms： 
   
    publicclassReportSenderByJmsimplements ReportSender { 
    publicvoidsendReport(ECReportsreports) { 
    } 
    } 
   
    報(bào)告發(fā)送示例客戶端類 
   
    SendReportWorker： 
   
    publicclassSendReportWorker{ 
    privateReportSendersender; 
    privateECReportsreports; 
    publicvoidsetReports(ECReportsreports) { 
    this.reports = reports; 
    } 
    publicstaticvoidmain(String[] args) { 
    SendReportWorker worker = new  
    SendReportWorker(); 
    worker.sender.sendReport(reports); 
    } 
    publicvoidsetSender(ReportSendersender) { 
    this.sender = sender; 
    } 
    } 
   
    這樣，發(fā)送消息的工人類可通過(guò)設(shè)置ReportSender的實(shí)例來(lái)靈活設(shè)置其發(fā)送方式。 
   
    同樣，中間件的清點(diǎn)命令下發(fā)，即中間件與閱讀器之間的接口，也存在多種方式，如Socket、SOAP等，也可采用類似的設(shè)計(jì)。 
   
    3.5 觀察者模式處理上報(bào)消息 
   
    閱讀器的消息上報(bào)轉(zhuǎn)換為消息對(duì)象，對(duì)消息對(duì)象的接收、分發(fā)可采用經(jīng)典的觀察者模式實(shí)現(xiàn)。 
   
    4、中間件發(fā)展方向 
   
    4.1 與閱讀器管理系統(tǒng)的融合 
   
    中間件是閱讀器與后臺(tái)應(yīng)用系統(tǒng)之間的橋梁，而閱讀器通常有設(shè)備管理需求，比如軟件版本下載、設(shè)備告警管理、參數(shù)配置等等，閱讀器管理系統(tǒng)也是直接與閱讀器交互的軟件模塊。于是，如何處理好中間件與閱讀器管理系統(tǒng)之間的關(guān)系成為一個(gè)亟待解決的問(wèn)題。 
   
    從軟件部署(部署在同一臺(tái)主機(jī)上)、軟件模塊重用(重用閱讀器通信模塊)等角度考慮，中間件與閱讀器管理系統(tǒng)的融合勢(shì)必成為中間件本身的一個(gè)優(yōu)勢(shì)。 
   
    4.2 對(duì)多標(biāo)準(zhǔn)標(biāo)簽的支持 
   
    RFID技術(shù)在國(guó)內(nèi)外的發(fā)展和應(yīng)用方興未艾，國(guó)際上多個(gè)標(biāo)準(zhǔn)組織都試圖統(tǒng)一RFID標(biāo)準(zhǔn)，但在一定的時(shí)期內(nèi)，勢(shì)必出現(xiàn)多標(biāo)簽并存的情況。于是，對(duì)多標(biāo)準(zhǔn)標(biāo)簽的支持也是中間件系統(tǒng)的一個(gè)發(fā)展方向。 
   
    4.3 對(duì)多廠商閱讀器的支持 
   
    中間件與閱讀器之間的接口、通信方式以及信息格式，也無(wú)法做到統(tǒng)一標(biāo)準(zhǔn)。對(duì)多廠商閱讀器的支持、至少對(duì)少數(shù)幾家主流廠商的閱讀器的支持，已經(jīng)是對(duì)中間件所提出的基本要求。