無(wú)線(xiàn)rfid中間件技術(shù)

?。?） 規則狀態(tài)機模型

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

　　當規則創(chuàng )建之后，還沒(méi)有被任何客戶(hù)端（即應用系統）預訂，規則處于Unrequested狀態(tài)；對規則的第一個(gè)預訂動(dòng)作將使規則躍遷到 Requested狀態(tài)；當事件周期開(kāi)始條件滿(mǎn)足時(shí)，規則進(jìn)入Active狀態(tài)；當事件周期結束條件滿(mǎn)足時(shí)，如果規則存在預訂者，則躍遷到 Requested狀態(tài)，否則躍遷到Unrequested狀態(tài)。

　　3、中間件系統架構

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

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

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

　3.1 封裝、隔離處理流程中的各個(gè)節點(diǎn)

　　將中間件的業(yè)務(wù)流程中的各個(gè)節點(diǎn)分作不同模塊處理，可以獲得封裝、高內聚、低耦合等優(yōu)勢，參見(jiàn)圖5。無(wú)線(xiàn)射頻識別（RFID）技術(shù)是一種快速、實(shí)時(shí)、準確的信息采集與處理技術(shù)，通過(guò)射頻信號對實(shí)體對象進(jìn)行唯一有效的標識，可廣泛應用于生產(chǎn)、零售、物流、交通、醫療、國防、畜牧、采礦等各個(gè)行業(yè)。

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

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

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

　　無(wú)線(xiàn)射頻識別網(wǎng)絡(luò )的框架結構如圖1所示。

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

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

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

　　2、中間件功能及實(shí)現原理

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

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

　　2.1 標簽清點(diǎn)功能概述

　　標簽清點(diǎn)的工作流程可簡(jiǎn)單描述為：

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

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

　　中間件根據應用系統對標簽數據的預訂情況，適時(shí)啟動(dòng)事件周期，并向閱讀器下發(fā)標簽清點(diǎn)命令。

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

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

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

　　此流程可參見(jiàn)圖2。

　　圖2：中間件標簽清點(diǎn)概要流程圖。

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

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

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

　　2.2 標簽清點(diǎn)實(shí)現原理

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

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

　　規則由應用系統通過(guò)API定義。

　?。?） 規則信息模型

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

　　圖3

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

　?。?） 報告信息模型

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

　　圖4：報告信息模型圖。

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

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

　?。?） 標簽清點(diǎn)API

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

　　表1：標簽清點(diǎn)應用程序接口。

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

　　圖5：中間件系統模塊劃分圖。

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

　　3.2 門(mén)面模式、工廠(chǎng)模式對外部暴露API接口

　 　為了避免后臺應用系統，即中間件的客戶(hù)端過(guò)分耦合，采用門(mén)面模式（Facade）對系統內部、外部實(shí)現清晰的隔離。處理流程可參見(jiàn)圖6所示的序列圖?？?戶(hù)端僅僅與Facade類(lèi)建立聯(lián)系，如果Facade接口定義得足夠清晰，客戶(hù)端可以對中間件的內部實(shí)現一無(wú)所知，這體現了面向對象中的封裝性。

　　圖6：客戶(hù)端調用APT序列圖。

　　類(lèi)的設計參見(jiàn)源代碼示例，從中可以看出，采用簡(jiǎn)單工廠(chǎng)模式（Simple Factory）能夠在客戶(hù)端不知情的情況下，靈活地替換API實(shí)現類(lèi)的版本。中間件API接口清晰地定義了中間件提供的操作，客戶(hù)端只須知道工廠(chǎng)類(lèi)（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）;

　　}

　　工廠(chǎng)類(lèi)APIFactory：

　　publicclassAPIFactory{

　　publicstaticMiddlewareAPIgetAPIInstance（）{

　　}

　　}

　　API的實(shí)現類(lèi)A：

　　publicclassClient{

　　publicstaticvoidmain（String［］ args） {

　　MiddlewareAPI api = APIFactory.getAPIInstance（）;

　　api.define（a new spec， new EPCSpec（））;

　　}

　　}

　　3.3 狀態(tài)模式模擬規則的狀態(tài)機

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

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

　　publicinterfaceECState{

　　voidsubscribe（StringspecName，String uri）;

　　voidunsubscribe（StringspecName，String uri）;

　　EPCReportspoll（StringspecName）;

　　}

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

　　publicclassECStateUnrequestedimplements ECState {

　　}

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

　　publicclassECStateRrequestedimplements ECState {

　　}

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

　　publicclassECStateActiveimplements ECState {

　　}

　　規則類(lèi)ECSpec：

　　publicclassECSpec{

　　privateECStatestate;

　　publicECStategetState（）{

　　return state;

　　}

　　publicvoidsetState（ECStatestate） {

　　this.state = state;

　　}

　　}

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

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

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

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

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

　　publicinterfaceReportSender{

　　voidsendReport（ECReportsreports）;

　　}

　　通過(guò)Http方式發(fā)送報告的ReportSender接口實(shí)現類(lèi)ReportSenderByHttp：

　　publicclassReportSenderByHttpimplements ReportSender {

　　public void sendReport（ECReports reports） {

　　}

　　}

　　通過(guò)Socket方式發(fā)送報告的ReportSender接口實(shí)現類(lèi)ReportSenderBySocket：

　　publicclassReportSenderBySocketimplements ReportSender {

　　publicvoidsendReport（ECReportsreports） {

　　}

　　}

　　通過(guò)JMS方式發(fā)送報告的ReportSender接口實(shí)現類(lèi)ReportSenderByJms：

　　publicclassReportSenderByJmsimplements ReportSender {

　　publicvoidsendReport（ECReportsreports） {

　　}

　　}

　　報告發(fā)送示例客戶(hù)端類(lèi)

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

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

　　3.5 觀(guān)察者模式處理上報消息

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

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

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

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

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

　　4.2 對多標準標簽的支持

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

　　4.3 對多廠(chǎng)商閱讀器的支持

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