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

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

        對于RFID中間件的設計，有諸多問題需要考慮，如：如何實現軟件的諸多質量屬性、如何實現中間件與硬件設備的隔離、如何處理與設備管理功能的關系、如何實現高性能的數據處理等等。

1  RFID網絡框架結構

        無線射頻識別網絡的框架結構如圖1所示。

        標簽數據經過中間件的分組、過濾等處理上報給應用系統；應用系統負責事件數據的持久化存儲，以及標簽綁定的業務信息的管理。

        RFID系統共享公共服務平臺提供根節點對象名稱服務(ONS)、企業應用鑒權管理、標簽信息發現和企業授權碼管理等公共服務。其中，根節點ONS連同所有企業級RFID系統的內部ONS，組成一個ONS樹，任何一個標簽都可以在ONS樹上找到標簽所對應的標簽信息庫的地址，即可以進一步訪問到標簽對應的詳細信息。

2  中間件功能及實現原理

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

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

2.1標簽清點功能概述

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

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

        應用系統指定某項規則，向中間件提出對標簽數據的預訂。

        中間件根據應用系統對標簽數據的預訂情況，適時啟動事件周期，并向閱讀器下發標簽清點命令。

        閱讀器將一定時間周期(讀取周期)中清點到的數據，發送給中間件。讀取周期可由中間件與閱讀器制定私下協商確定。

        中間件接由收閱讀器上報的數據。

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

        此流程可參見圖2。

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

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

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

2.2標簽清點實現原理

        如前所述，規則是整個中間件功能的關鍵元素。規則相當于應用系統發給中間件的訂貨單，定義了對貨品(標簽數據)的時間(事件周期)和規格(如何過濾、如何分組、報告樣式等)的要求，原理描述部分參考EPCglobal相關內容[1]。

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

        規則由應用系統通過API定義。

(1) 規則信息模型

        規則信息模型的描述采用了統一建模語言(UML)，如圖3所示。

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

(2) 報告信息模型

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

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

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

(3) 標簽清點API

        應用系統下發的定義規則、預訂數據等請求，以調用中間件提供的API的方式完成。API調用過程可采用Java RMI、SOAP等相關具體技術實現，其中最重要的API參見表1。

        其中，poll操作相當于subscribe操作收到一個事件周期的數據之后調用unsubscribe操作；immediate操作相當于define操作定義規則之后，調用poll操作，然后調用undefine操作。

(4) 規則狀態機模型

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

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

3  中間件系統架構

        中間件系統作為一個軟件系統(或稱組件)，在實現一定功能、性能要求之外，可理解性、可擴展性、可修改性(或稱可重構性)、可插入性、可重用性等質量屬性都將作為軟件設計的要求被提出來。

        近十余年來，面向對象思想幾乎全面占領軟件設計領域，成為最主流的分析、設計方法。而近數年來，對設計模式的研究也已日臻完善，模式幾乎已成為一種“更高級編程語言”(相比于Java、C++等高級編程語言)被廣泛應用。

        面向對象思想、設計模式都是以實現軟件的可理解、可擴展、可修改、可插入、可重用等目標為己任的，本文也將應用面向對象思想、參考模式語言，對中間件的軟件架構做一個初步的探討，下文的例子如涉及高級編程語言，均采用Java語言[2]。

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

        將中間件的業務流程中的各個節點分作不同模塊處理，可以獲得封裝、高內聚、低耦合等優勢，參見圖5。

        其中，報告上傳模塊，負責實現不同類型的報告上傳方式，如HTTP、JMS等；API接口模塊，負責隔離應用系統和中間件核心業務邏輯處理模塊，向應用系統提供中間件API接口；中間件核心業務邏輯處理模塊，負責中間件核心業務，包括數據接收過濾、數據分組、報告生成、規則對象的狀態跳轉等；閱讀器通信模塊，負責中間件系統與閱讀器的通信。

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

        為了避免后臺應用系統，即中間件的客戶端過分耦合，采用門面模式(Facade)對系統內部、外部實現清晰的隔離。處理流程可參見圖6所示的序列圖。客戶端僅僅與Facade類建立聯系，如果Facade接口定義得足夠清晰，客戶端可以對中間件的內部實現一無所知，這體現了面向對象中的封裝性。

        類的設計參見源代碼示例，從中可以看出，采用簡單工廠模式(Simple Factory)能夠在客戶端不知情的情況下，靈活地替換API實現類的版本。中間件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的實現類A：

publicclassClient{

publicstaticvoidmain(String[] args) {

MiddlewareAPI api = APIFactory.getAPIInstance();

api.define("a new spec", new EPCSpec());

}

}

3.3狀態模式模擬規則的狀態機

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

        規則狀態接口ECState：

publicinterfaceECState{

voidsubscribe(StringspecName,String uri);

voidunsubscribe(StringspecName,String uri);

EPCReportspoll(StringspecName);

}

        未被請求狀態類ECStateUnrequested：

publicclassECStateUnrequestedimplements ECState {

}

        已被請求狀態類ECStateRequested：

publicclassECStateRrequestedimplements ECState {

}

        激活狀態類ECStateActive：

publicclassECStateActiveimplements ECState {

}

        規則類ECSpec：

publicclassECSpec{

privateECStatestate;

publicECStategetState(){

return state;

}

publicvoidsetState(ECStatestate) {

this.state = state;

}

}

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

        由面向對象的多態性特征，根據state字段目前所指向的對象來動態確定由ECState接口的哪一個具體的實現類的代碼來完成工作。ECState接口的實現類根據實際情況確定是否需要在處理過程中修改ECSpec對象的狀態屬性(state)，此處在應用狀態模式時，需要設計多個定時器類來輔助狀態機的跳轉[3]。

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

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

        報告發送接口ReportSender：

publicinterfaceReportSender{

voidsendReport(ECReportsreports);

}

        通過Http方式發送報告的ReportSender接口實現類ReportSenderByHttp：

publicclassReportSenderByHttpimplements ReportSender {

public void sendReport(ECReports reports) {

}

}

        通過Socket方式發送報告的ReportSender接口實現類ReportSenderBySocket：

publicclassReportSenderBySocketimplements ReportSender {

publicvoidsendReport(ECReportsreports) {

}

}

        通過JMS方式發送報告的ReportSender接口實現類ReportSenderByJms：

publicclassReportSenderByJmsimplements ReportSender {

publicvoidsendReport(ECReportsreports) {

}

}

        報告發送示例客戶端類

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;

}

}

        這樣，發送消息的工人類可通過設置ReportSender的實例來靈活設置其發送方式。

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

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

        閱讀器的消息上報轉換為消息對象，對消息對象的接收、分發可采用經典的觀察者模式實現。

4  中間件發展方向

4.1與閱讀器管理系統的融合

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

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

4.2對多標準標簽的支持

        RFID技術在國內外的發展和應用方興未艾，國際上多個標準組織都試圖統一RFID標準，但在一定的時期內，勢必出現多標簽并存的情況。于是，對多標準標簽的支持也是中間件系統的一個發展方向。

4.3對多廠商閱讀器的支持

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