無線射頻識別（RFID）技術(shù)是一種快速、實時、準確的信息采集與處理技術(shù)，通過射頻信號對實體對象進行唯一有效的標識，可廣泛應(yīng)用于生產(chǎn)、零售、物流、交通、醫(yī)療、國防、畜牧、采礦等各個行業(yè)。

基本的RFID系統(tǒng)一般由3部分組成：標簽、閱讀器以及應(yīng)用支撐軟件。中間件是應(yīng)用支撐軟件的一個重要組成部分，是銜接硬件設(shè)備如標簽、閱讀器和企業(yè)應(yīng)用軟件如企業(yè)資源規(guī)劃（ERP）、客戶關(guān)系管理（CRM）等的橋梁。中間件的主要任務(wù)是對閱讀器傳來的與標簽相關(guān)的數(shù)據(jù)進行過濾、匯總、計算、分組，減少從閱讀器傳往企業(yè)應(yīng)用的大量原始數(shù)據(jù)、生成加入了語意解釋的事件數(shù)據(jù)?？梢哉f，中間件是RFID系統(tǒng)的“神經(jīng)中樞”。

對于RFID中間件的設(shè)計，有諸多問題需要考慮，如：如何實現(xiàn)軟件的諸多質(zhì)量屬性、如何實現(xiàn)中間件與硬件設(shè)備的隔離、如何處理與設(shè)備管理功能的關(guān)系、如何實現(xiàn)高性能的數(shù)據(jù)處理等等。

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

無線射頻識別網(wǎng)絡(luò)的框架結(jié)構(gòu)如圖1所示。

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

標簽數(shù)據(jù)經(jīng)過中間件的分組、過濾等處理上報給應(yīng)用系統(tǒng);應(yīng)用系統(tǒng)負責事件數(shù)據(jù)的持久化存儲，以及標簽綁定的業(yè)務(wù)信息的管理。

RFID系統(tǒng)共享公共服務(wù)平臺提供根節(jié)點對象名稱服務(wù)（ONS）、企業(yè)應(yīng)用鑒權(quán)管理、標簽信息發(fā)現(xiàn)和企業(yè)授權(quán)碼管理等公共服務(wù)。其中，根節(jié)點ONS連同所有企業(yè)級RFID系統(tǒng)的內(nèi)部ONS，組成一個ONS樹，任何一個標簽都可以在ONS樹上找到標簽所對應(yīng)的標簽信息庫的地址，即可以進一步訪問到標簽對應(yīng)的詳細信息。

2、中間件功能及實現(xiàn)原理

一言蔽之，中間件的功能就是接受應(yīng)用系統(tǒng)的請求，對指定的一個或者多個閱讀器發(fā)起操作命令如標簽清點、標簽標識數(shù)據(jù)寫入、標簽用戶數(shù)據(jù)區(qū)讀寫、標簽數(shù)據(jù)加鎖、標簽殺死等，并接收、處理、向后臺應(yīng)用系統(tǒng)上報結(jié)果數(shù)據(jù)。

其中，標簽清點是最為基本、也是應(yīng)用最為廣泛的功能。

2.1 標簽清點功能概述

標簽清點的工作流程可簡單描述為：

應(yīng)用系統(tǒng)以規(guī)則的形式定義對標簽數(shù)據(jù)的需求，規(guī)則由應(yīng)用系統(tǒng)向中間件提出，由中間件維護。規(guī)則中定義了：需要哪些閱讀器的清點數(shù)據(jù)，標簽數(shù)據(jù)上報周期（事件周期）的開始和結(jié)束條件，標簽數(shù)據(jù)如何過濾，標簽數(shù)據(jù)如何分組，上報數(shù)據(jù)為原始清點數(shù)據(jù)、新增標簽數(shù)據(jù)還是新減標簽數(shù)據(jù)，標簽數(shù)據(jù)包含哪些原始數(shù)據(jù)等。

應(yīng)用系統(tǒng)指定某項規(guī)則，向中間件提出對標簽數(shù)據(jù)的預(yù)訂。

中間件根據(jù)應(yīng)用系統(tǒng)對標簽數(shù)據(jù)的預(yù)訂情況，適時啟動事件周期，并向閱讀器下發(fā)標簽清點命令。

閱讀器將一定時間周期（讀取周期）中清點到的數(shù)據(jù)，發(fā)送給中間件。讀取周期可由中間件與閱讀器制定私下協(xié)商確定。

中間件接由收閱讀器上報的數(shù)據(jù)。

中間件根據(jù)規(guī)則的定義，對接收數(shù)據(jù)做過濾、分組、累加等操作，并在事件周期結(jié)束時，按照規(guī)則的要求生成數(shù)據(jù)結(jié)果報告，發(fā)送給規(guī)則的預(yù)訂者。過濾過程可去除重復(fù)數(shù)據(jù)、應(yīng)用系統(tǒng)不感興趣的數(shù)據(jù)，大大降低了組件間的傳輸數(shù)據(jù)量。

此流程可參見圖2。

圖2：中間件標簽清點概要流程圖。

此處，需要說明一下邏輯閱讀器的概念。

中間件將事件源抽象為一個邏輯概念——邏輯閱讀器，一個邏輯閱讀器可以包含多個物理閱讀器，甚至可更細化為包含多個物理閱讀器的多個天線。

邏輯閱讀器的劃分可以根據(jù)實際的系統(tǒng)部署情況來確定，比如，某一個倉庫兩個出口部署了4個閱讀器，可根據(jù)需要將這4個閱讀器配置成為一個邏輯閱讀器，不妨命名為“倉庫出口”。應(yīng)用系統(tǒng)在需要倉庫出口的標簽數(shù)據(jù)時，可基于這個邏輯閱讀器下發(fā)清點命令，而邏輯閱讀器名稱作為部分應(yīng)用程序接口（API）調(diào)用的參數(shù)。

2.2 標簽清點實現(xiàn)原理

如前所述，規(guī)則是整個中間件功能的關(guān)鍵元素。規(guī)則相當于應(yīng)用系統(tǒng)發(fā)給中間件的訂貨單，定義了對貨品（標簽數(shù)據(jù)）的時間（事件周期）和規(guī)格（如何過濾、如何分組、報告樣式等）的要求，原理描述部分參考EPCglobal相關(guān)內(nèi)容。

規(guī)則、報告有自身的信息模型，表征其承載的信息，同時，規(guī)則擁有其自身的狀態(tài)機模型。在接受應(yīng)用系統(tǒng)的長期預(yù)訂、單次預(yù)訂時，這些預(yù)訂操作會激發(fā)規(guī)則的狀態(tài)變遷，如從“未被請求”狀態(tài)躍遷到“已被請求”狀態(tài)。

規(guī)則由應(yīng)用系統(tǒng)通過API定義。

（1） 規(guī)則信息模型

規(guī)則信息模型的描述采用了統(tǒng)一建模語言（UML），如圖3所示。

圖3

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

（2） 報告信息模型

與規(guī)則信息模型類似，報告信息模型如圖4所示。

圖4：報告信息模型圖。

其中，事件報告組類（ECReports）擁有如下屬性：規(guī)則名稱（specName）、時間上報時間（date）、事件周期時長（totalMilliseconds）、事件周期結(jié)束條件（terminationCondition）、規(guī)則定義類實例（spec）、一個或者多個報告類的實例列表（reports）。

報告類（ECReport）中包含了具體的標簽數(shù)據(jù)信息。

（3） 標簽清點API

應(yīng)用系統(tǒng)下發(fā)的定義規(guī)則、預(yù)訂數(shù)據(jù)等請求，以調(diào)用中間件提供的API的方式完成。API調(diào)用過程可采用Java RMI、SOAP等相關(guān)具體技術(shù)實現(xiàn)，其中最重要的API參見表1。

表1：標簽清點應(yīng)用程序接口。

其中，poll操作相當于subscribe操作收到一個事件周期的數(shù)據(jù)之后調(diào)用unsubscribe操作;immediate操作相當于define操作定義規(guī)則之后，調(diào)用poll操作，然后調(diào)用undefine操作。

（4） 規(guī)則狀態(tài)機模型

規(guī)則從其定義開始，可能存在于3種狀態(tài)：未被請求狀態(tài)（Unrequested）、已被請求狀態(tài)（Requested）、激活狀態(tài)（Active）。

當規(guī)則創(chuàng)建之后，還沒有被任何客戶端（即應(yīng)用系統(tǒng)）預(yù)訂，規(guī)則處于Unrequested狀態(tài);對規(guī)則的第一個預(yù)訂動作將使規(guī)則躍遷到Requested狀態(tài);當事件周期開始條件滿足時，規(guī)則進入Active狀態(tài);當事件周期結(jié)束條件滿足時，如果規(guī)則存在預(yù)訂者，則躍遷到Requested狀態(tài)，否則躍遷到Unrequested狀態(tài)。

3、中間件系統(tǒng)架構(gòu)

中間件系統(tǒng)作為一個軟件系統(tǒng)（或稱組件），在實現(xiàn)一定功能、性能要求之外，可理解性、可擴展性、可修改性（或稱可重構(gòu)性）、可插入性、可重用性等質(zhì)量屬性都將作為軟件設(shè)計的要求被提出來。

近十余年來，面向?qū)ο笏枷霂缀跞嬲碱I(lǐng)軟件設(shè)計領(lǐng)域，成為最主流的分析、設(shè)計方法。而近數(shù)年來，對設(shè)計模式的研究也已日臻完善，模式幾乎已成為一種“更高級編程語言”（相比于Java、C++等高級編程語言）被廣泛應(yīng)用。

面向?qū)ο笏枷?、設(shè)計模式都是以實現(xiàn)軟件的可理解、可擴展、可修改、可插入、可重用等目標為己任的，本文也將應(yīng)用面向?qū)ο笏枷搿⒖寄Ｊ秸Z言，對中間件的軟件架構(gòu)做一個初步的探討，下文的例子如涉及高級編程語言，均采用Java語言。

3.1 封裝、隔離處理流程中的各個節(jié)點

將中間件的業(yè)務(wù)流程中的各個節(jié)點分作不同模塊處理，可以獲得封裝、高內(nèi)聚、低耦合等優(yōu)勢，參見圖5。

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

其中，報告上傳模塊，負責實現(xiàn)不同類型的報告上傳方式，如HTTP、JMS等;API接口模塊，負責隔離應(yīng)用系統(tǒng)和中間件核心業(yè)務(wù)邏輯處理模塊，向應(yīng)用系統(tǒng)提供中間件API接口;中間件核心業(yè)務(wù)邏輯處理模塊，負責中間件核心業(yè)務(wù)，包括數(shù)據(jù)接收過濾、數(shù)據(jù)分組、報告生成、規(guī)則對象的狀態(tài)跳轉(zhuǎn)等;閱讀器通信模塊，負責中間件系統(tǒng)與閱讀器的通信。

3.2 門面模式、工廠模式對外部暴露API接口

為了避免后臺應(yīng)用系統(tǒng)，即中間件的客戶端過分耦合，采用門面模式（Facade）對系統(tǒng)內(nèi)部、外部實現(xiàn)清晰的隔離。處理流程可參見圖6所示的序列圖。客戶端僅僅與Facade類建立聯(lián)系，如果Facade接口定義得足夠清晰，客戶端可以對中間件的內(nèi)部實現(xiàn)一無所知，這體現(xiàn)了面向?qū)ο笾械姆庋b性。

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

類的設(shè)計參見源代碼示例，從中可以看出，采用簡單工廠模式（Simple Factory）能夠在客戶端不知情的情況下，靈活地替換API實現(xiàn)類的版本。中間件API接口清晰地定義了中間件提供的操作，客戶端只須知道工廠類（APIFactory）能夠得到中間件API接口的實例即可。

中間件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的實現(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)機

規(guī)則在其生命周期中擁有不同的狀態(tài)，在每個狀態(tài)對一系列操作都有著不同的表現(xiàn)，于是可以利用狀態(tài)模式（state）來模擬規(guī)則的狀態(tài)機，將不同狀態(tài)的不同表現(xiàn)作為可變化因素封裝起來，參見代碼示例。

規(guī)則狀態(tài)接口ECState：

publicinterfaceECState{

voidsubscribe（StringspecName，String uri）;

voidunsubscribe（StringspecName，String uri）;

EPCReportspoll（StringspecName）;

}

未被請求狀態(tài)類ECStateUnrequested：

publicclassECStateUnrequestedimplements ECState {

}

已被請求狀態(tài)類ECStateRequested：

publicclassECStateRrequestedimplements ECState {

}

激活狀態(tài)類ECStateActive：

publicclassECStateActiveimplements ECState {

}

規(guī)則類ECSpec：

publicclassECSpec{

privateECStatestate;

publicECStategetState（）{

return state;

}

publicvoidsetState（ECStatestate） {

this.state = state;

}

}

這樣，在針對規(guī)則實施相應(yīng)操作的時候，就可以直接把相應(yīng)操作委派給其狀態(tài)屬性（ECState）去做即可。比如，ECSpec的subscribe操作，只需一行代碼“state.suscribe（specName， uri）;”即可。其中，specName、uri為臨時變量，具體取值在方法調(diào)用之前確定。

由面向?qū)ο蟮亩鄳B(tài)性特征，根據(jù)state字段目前所指向的對象來動態(tài)確定由ECState接口的哪一個具體的實現(xiàn)類的代碼來完成工作。ECState接口的實現(xiàn)類根據(jù)實際情況確定是否需要在處理過程中修改ECSpec對象的狀態(tài)屬性（state），此處在應(yīng)用狀態(tài)模式時，需要設(shè)計多個定時器類來輔助狀態(tài)機的跳轉(zhuǎn)。

3.4 策略模式切換多種報告上傳、命令下發(fā)方式

事件周期結(jié)束之后，中間件需要組裝報告上傳給規(guī)則的預(yù)訂者，即應(yīng)用系統(tǒng)。上傳的方式有多種，如HTTP、Socket、JMS等等。中間件的核心邏輯處理模塊不應(yīng)該關(guān)心具體的上傳技術(shù)，相應(yīng)工作應(yīng)交給報告上傳模塊來做，核心邏輯處理模塊只須完成自己的工作，然后把一定格式的數(shù)據(jù)通過報告上傳模塊發(fā)送，參見代碼示例。

報告發(fā)送接口ReportSender：

publicinterfaceReportSender{

voidsendReport（ECReportsreports）;

}

通過Http方式發(fā)送報告的ReportSender接口實現(xiàn)類ReportSenderByHttp：

publicclassReportSenderByHttpimplements ReportSender {

public void sendReport（ECReports reports） {

}

}

通過Socket方式發(fā)送報告的ReportSender接口實現(xiàn)類ReportSenderBySocket：

publicclassReportSenderBySocketimplements ReportSender {

publicvoidsendReport（ECReportsreports） {

}

}

通過JMS方式發(fā)送報告的ReportSender接口實現(xiàn)類ReportSenderByJms：

publicclassReportSenderByJmsimplements ReportSender {

publicvoidsendReport（ECReportsreports） {

}

}

報告發(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ā)送消息的工人類可通過設(shè)置ReportSender的實例來靈活設(shè)置其發(fā)送方式。

同樣，中間件的清點命令下發(fā)，即中間件與閱讀器之間的接口，也存在多種方式，如Socket、SOAP等，也可采用類似的設(shè)計。

3.5 觀察者模式處理上報消息

閱讀器的消息上報轉(zhuǎn)換為消息對象，對消息對象的接收、分發(fā)可采用經(jīng)典的觀察者模式實現(xiàn)。

4、中間件發(fā)展方向

4.1 與閱讀器管理系統(tǒng)的融合

中間件是閱讀器與后臺應(yīng)用系統(tǒng)之間的橋梁，而閱讀器通常有設(shè)備管理需求，比如軟件版本下載、設(shè)備告警管理、參數(shù)配置等等，閱讀器管理系統(tǒng)也是直接與閱讀器交互的軟件模塊。于是，如何處理好中間件與閱讀器管理系統(tǒng)之間的關(guān)系成為一個亟待解決的問題。

從軟件部署（部署在同一臺主機上）、軟件模塊重用（重用閱讀器通信模塊）等角度考慮，中間件與閱讀器管理系統(tǒng)的融合勢必成為中間件本身的一個優(yōu)勢。

4.2 對多標準標簽的支持

RFID技術(shù)在國內(nèi)外的發(fā)展和應(yīng)用方興未艾，國際上多個標準組織都試圖統(tǒng)一RFID標準，但在一定的時期內(nèi)，勢必出現(xiàn)多標簽并存的情況。于是，對多標準標簽的支持也是中間件系統(tǒng)的一個發(fā)展方向。

4.3 對多廠商閱讀器的支持

中間件與閱讀器之間的接口、通信方式以及信息格式，也無法做到統(tǒng)一標準。對多廠商閱讀器的支持、至少對少數(shù)幾家主流廠商的閱讀器的支持，已經(jīng)是對中間件所提出的基本要求。