無線射頻識別(RFID" target="_blank">RFID)技術是一種快速,、實時,、準確的信息采集與處理技術，通過射頻信號對實體對象進行唯一有效的標識,，可廣泛應用于生產(chǎn),、零售,、物流,、交通、醫(yī)療,、國防,、畜牧、采礦等各個行業(yè),。
基本的RFID系統(tǒng)一般由3部分組成：標簽,、閱讀器以及應用支撐軟件,。中間件是應用支撐軟件的一個重要組成部分,，是銜接硬件設備如標簽、閱讀器和企業(yè)應用軟件如企業(yè)資源規(guī)劃(ERP),、客戶關系管理(CRM)等的橋梁,。中間件的主要任務是對閱讀器傳來的與標簽相關的數(shù)據(jù)進行過濾、匯總,、計算,、分組，減少從閱讀器傳往企業(yè)應用的大量原始數(shù)據(jù),、生成加入了語意解釋的事件數(shù)據(jù),。可以說,，中間件是RFID系統(tǒng)的“神經(jīng)中樞”,。
對于RFID中間件的設計，有諸多問題需要考慮,，如：如何實現(xiàn)軟件的諸多質(zhì)量屬性、如何實現(xiàn)中間件與硬件設備的隔離,、如何處理與設備管理功能的關系,、如何實現(xiàn)高性能的數(shù)據(jù)處理等等。
1 RFID網(wǎng)絡框架結構
無線射頻識別網(wǎng)絡的框架結構如圖1所示,。
標簽數(shù)據(jù)經(jīng)過中間件的分組,、過濾等處理上報給應用系統(tǒng)；應用系統(tǒng)負責事件數(shù)據(jù)的持久化存儲,，以及標簽綁定的業(yè)務信息的管理,。
RFID系統(tǒng)共享公共服務平臺提供根節(jié)點對象名稱服務(ONS),、企業(yè)應用鑒權管理、標簽信息發(fā)現(xiàn)和企業(yè)授權碼管理等公共服務,。其中,，根節(jié)點ONS連同所有企業(yè)級RFID系統(tǒng)的內(nèi)部ONS，組成一個ONS樹,，任何一個標簽都可以在ONS樹上找到標簽所對應的標簽信息庫的地址,，即可以進一步訪問到標簽對應的詳細信息。
2 中間件功能及實現(xiàn)原理
一言蔽之,，中間件的功能就是接受應用系統(tǒng)的請求,，對指定的一個或者多個閱讀器發(fā)起操作命令如標簽清點、標簽標識數(shù)據(jù)寫入,、標簽用戶數(shù)據(jù)區(qū)讀寫,、標簽數(shù)據(jù)加鎖、標簽殺死等,，并接收,、處理、向后臺應用系統(tǒng)上報結果數(shù)據(jù),。
其中,，標簽清點是最為基本、也是應用最為廣泛的功能,。
2.1標簽清點功能概述
標簽清點的工作流程可簡單描述為：
應用系統(tǒng)以規(guī)則的形式定義對標簽數(shù)據(jù)的需求，規(guī)則由應用系統(tǒng)向中間件提出,，由中間件維護,。規(guī)則中定義了：需要哪些閱讀器的清點數(shù)據(jù)，標簽數(shù)據(jù)上報周期(事件周期)的開始和結束條件,，標簽數(shù)據(jù)如何過濾,，標簽數(shù)據(jù)如何分組，上報數(shù)據(jù)為原始清點數(shù)據(jù),、新增標簽數(shù)據(jù)還是新減標簽數(shù)據(jù),，標簽數(shù)據(jù)包含哪些原始數(shù)據(jù)等。
應用系統(tǒng)指定某項規(guī)則,，向中間件提出對標簽數(shù)據(jù)的預訂,。
中間件根據(jù)應用系統(tǒng)對標簽數(shù)據(jù)的預訂情況，適時啟動事件周期,，并向閱讀器下發(fā)標簽清點命令,。
閱讀器將一定時間周期(讀取周期)中清點到的數(shù)據(jù)，發(fā)送給中間件,。讀取周期可由中間件與閱讀器制定私下協(xié)商確定,。
中間件接由收閱讀器上報的數(shù)據(jù),。
中間件根據(jù)規(guī)則的定義，對接收數(shù)據(jù)做過濾,、分組,、累加等操作，并在事件周期結束時,，按照規(guī)則的要求生成數(shù)據(jù)結果報告,，發(fā)送給規(guī)則的預訂者。過濾過程可去除重復數(shù)據(jù),、應用系統(tǒng)不感興趣的數(shù)據(jù),，大大降低了組件間的傳輸數(shù)據(jù)量。
此流程可參見圖2,。
此處,，需要說明一下邏輯閱讀器的概念。
中間件將事件源抽象為一個邏輯概念——邏輯閱讀器,，一個邏輯閱讀器可以包含多個物理閱讀器,，甚至可更細化為包含多個物理閱讀器的多個天線。
邏輯閱讀器的劃分可以根據(jù)實際的系統(tǒng)部署情況來確定,，比如,，某一個倉庫兩個出口部署了4個閱讀器，可根據(jù)需要將這4個閱讀器配置成為一個邏輯閱讀器,，不妨命名為“倉庫出口”,。應用系統(tǒng)在需要倉庫出口的標簽數(shù)據(jù)時，可基于這個邏輯閱讀器下發(fā)清點命令,，而邏輯閱讀器名稱作為部分應用程序接口(API)調(diào)用的參數(shù),。
2.2標簽清點實現(xiàn)原理
如前所述，規(guī)則是整個中間件功能的關鍵元素,。規(guī)則相當于應用系統(tǒng)發(fā)給中間件的訂貨單,，定義了對貨品(標簽數(shù)據(jù))的時間(事件周期)和規(guī)格(如何過濾、如何分組,、報告樣式等)的要求,，原理描述部分參考EPCglobal相關內(nèi)容[1]。
規(guī)則,、報告有自身的信息模型,，表征其承載的信息，同時,，規(guī)則擁有其自身的狀態(tài)機模型,。在接受應用系統(tǒng)的長期預訂、單次預訂時，這些預訂操作會激發(fā)規(guī)則的狀態(tài)變遷,，如從“未被請求”狀態(tài)躍遷到“已被請求”狀態(tài),。
規(guī)則由應用系統(tǒng)通過API定義。
(1) 規(guī)則信息模型
規(guī)則信息模型的描述采用了統(tǒng)一建模語言(UML),，如圖3所示,。
在面向?qū)ο蟮恼Z境中，規(guī)則可表征為一個類(ECSpec),。從信息模型描述中可看出,，一個規(guī)則類，與其他多個類具有關聯(lián)關系,，或者說擁有如下屬性：一個或者多個邏輯閱讀器的列表(readers),、事件周期邊界定義(boundaries)、一個或者多個報告的定義(reportSpecs),、是否在報告中包含規(guī)則本身的標記(includeSpecInReports),。
(2) 報告信息模型
與規(guī)則信息模型類似，報告信息模型如圖4所示,。
其中,，事件報告組類(ECReports)擁有如下屬性：規(guī)則名稱(specName)、時間上報時間(date),、事件周期時長(totalMilliseconds),、事件周期結束條件(terminationCondition)、規(guī)則定義類實例(spec),、一個或者多個報告類的實例列表(reports),。
報告類(ECReport)中包含了具體的標簽數(shù)據(jù)信息。
(3) 標簽清點API
應用系統(tǒng)下發(fā)的定義規(guī)則,、預訂數(shù)據(jù)等請求,，以調(diào)用中間件提供的API的方式完成。API調(diào)用過程可采用Java RMI,、SOAP等相關具體技術實現(xiàn)，其中最重要的API參見表1,。
其中,，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)建之后,，還沒有被任何客戶端(即應用系統(tǒng))預訂,，規(guī)則處于Unrequested狀態(tài)；對規(guī)則的第一個預訂動作將使規(guī)則躍遷到Requested狀態(tài),；當事件周期開始條件滿足時,，規(guī)則進入Active狀態(tài)；當事件周期結束條件滿足時,，如果規(guī)則存在預訂者,，則躍遷到Requested狀態(tài)，否則躍遷到Unrequested狀態(tài),。
3 中間件系統(tǒng)架構
中間件系統(tǒng)作為一個軟件系統(tǒng)(或稱組件),，在實現(xiàn)一定功能、性能要求之外,，可理解性,、可擴展性、可修改性(或稱可重構性),、可插入性,、可重用性等質(zhì)量屬性都將作為軟件設計的要求被提出來。
近十余年來,，面向?qū)ο笏枷霂缀跞嬲碱I軟件設計領域,，成為最主流的分析、設計方法,。而近數(shù)年來,，對設計模式的研究也已日臻完善，模式幾乎已成為一種“更高級編程語言”(相比于Java,、C++等高級編程語言)被廣泛應用,。
面向?qū)ο笏枷搿⒃O計模式都是以實現(xiàn)軟件的可理解,、可擴展,、可修改、可插入,、可重用等目標為己任的,，本文也將應用面向?qū)ο笏枷搿⒖寄Ｊ秸Z言,，對中間件的軟件架構做一個初步的探討,，下文的例子如涉及高級編程語言，均采用Java語言[2],。
3.1封裝,、隔離處理流程中的各個節(jié)點
將中間件的業(yè)務流程中的各個節(jié)點分作不同模塊處理,，可以獲得封裝、高內(nèi)聚,、低耦合等優(yōu)勢,，參見圖5。
其中,，報告上傳模塊,，負責實現(xiàn)不同類型的報告上傳方式，如HTTP,、JMS等,；API接口模塊，負責隔離應用系統(tǒng)和中間件核心業(yè)務邏輯處理模塊,，向應用系統(tǒng)提供中間件API接口,；中間件核心業(yè)務邏輯處理模塊，負責中間件核心業(yè)務,，包括數(shù)據(jù)接收過濾,、數(shù)據(jù)分組、報告生成,、規(guī)則對象的狀態(tài)跳轉(zhuǎn)等,；閱讀器通信模塊，負責中間件系統(tǒng)與閱讀器的通信,。
3.2門面模式,、工廠模式對外部暴露API接口
為了避免后臺應用系統(tǒng)，即中間件的客戶端過分耦合,，采用門面模式(Facade)對系統(tǒng)內(nèi)部,、外部實現(xiàn)清晰的隔離。處理流程可參見圖6所示的序列圖,?？蛻舳藘H僅與Facade類建立聯(lián)系，如果Facade接口定義得足夠清晰,，客戶端可以對中間件的內(nèi)部實現(xiàn)一無所知,，這體現(xiàn)了面向?qū)ο笾械姆庋b性。
類的設計參見源代碼示例,，從中可以看出,，采用簡單工廠模式(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ī)則實施相應操作的時候,，就可以直接把相應操作委派給其狀態(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)，此處在應用狀態(tài)模式時,，需要設計多個定時器類來輔助狀態(tài)機的跳轉(zhuǎn)[3],。
3.4策略模式切換多種報告上傳、命令下發(fā)方式
事件周期結束之后,，中間件需要組裝報告上傳給規(guī)則的預訂者,，即應用系統(tǒng)。上傳的方式有多種,，如HTTP,、Socket、JMS等等,。中間件的核心邏輯處理模塊不應該關心具體的上傳技術,，相應工作應交給報告上傳模塊來做，核心邏輯處理模塊只須完成自己的工作,，然后把一定格式的數(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ā)送消息的工人類可通過設置ReportSender的實例來靈活設置其發(fā)送方式,。
同樣，中間件的清點命令下發(fā),，即中間件與閱讀器之間的接口,，也存在多種方式，如Socket,、SOAP等,，也可采用類似的設計,。
3.5觀察者模式處理上報消息
閱讀器的消息上報轉(zhuǎn)換為消息對象，對消息對象的接收,、分發(fā)可采用經(jīng)典的觀察者模式實現(xiàn),。
4 中間件發(fā)展方向
4.1與閱讀器管理系統(tǒng)的融合
中間件是閱讀器與后臺應用系統(tǒng)之間的橋梁，而閱讀器通常有設備管理需求,，比如軟件版本下載,、設備告警管理、參數(shù)配置等等,，閱讀器管理系統(tǒng)也是直接與閱讀器交互的軟件模塊,。于是，如何處理好中間件與閱讀器管理系統(tǒng)之間的關系成為一個亟待解決的問題,。
從軟件部署(部署在同一臺主機上),、軟件模塊重用(重用閱讀器通信模塊)等角度考慮，中間件與閱讀器管理系統(tǒng)的融合勢必成為中間件本身的一個優(yōu)勢,。
4.2對多標準標簽的支持
RFID技術在國內(nèi)外的發(fā)展和應用方興未艾,，國際上多個標準組織都試圖統(tǒng)一RFID標準，但在一定的時期內(nèi),，勢必出現(xiàn)多標簽并存的情況,。于是，對多標準標簽的支持也是中間件系統(tǒng)的一個發(fā)展方向,。
4.3對多廠商閱讀器的支持
中間件與閱讀器之間的接口,、通信方式以及信息格式，也無法做到統(tǒng)一標準,。對多廠商閱讀器的支持,、至少對少數(shù)幾家主流廠商的閱讀器的支持，已經(jīng)是對中間件所提出的基本要求,。