基基于SOA應用JMX和JMS技術(shù)的RFID中間件設計
無線射頻識別RFID(Radio Frequency Identification)技術(shù)近年來得到了快速的發(fā)展,目前已進入商業(yè)化應用階段。
企業(yè)實施RFID方案的最終目的是將RFID產(chǎn)生的海量信息為業(yè)務所用。這就需要解決企業(yè)現(xiàn)有的業(yè)務系統(tǒng)如何與RFID系統(tǒng)接口的問題,包括連接RFID設備、處理RFID數(shù)據(jù)、將其轉(zhuǎn)換成業(yè)務信息等。為了避免因標簽種類變化、系統(tǒng)業(yè)務邏輯改變而需要重新編寫業(yè)務信息的情況,需要將RFID硬件模塊的連接控制、中間數(shù)據(jù)處理與上層應用軟件分開,因此引入了RFID中間件的概念。
此外,利用SOA系統(tǒng)具有可擴展性高、可維護性好的特點,以便為用戶提供靈活的維護服務,還引入了面向服務體系架構(gòu)SOA(Service Oriented Architecutures)。
基于上述分析,本文提出了一種基于SOA的RFID中間件方案。該方案可把各個應用RFID技術(shù)的功能抽象成服務,應用基于J2EE構(gòu)建方法,綜合應用JMX、JMS、Struts等技術(shù)。企業(yè)應用系統(tǒng)通過請求服務的方式來獲取RFID中間件提供的服務。用XML進行數(shù)據(jù)傳輸,并提供Web Service接口。
1 技術(shù)基礎(chǔ)
1.1 RFID中間件
RFID中間件是實現(xiàn)RFID硬件設備與應用系統(tǒng)之間數(shù)據(jù)傳輸、過濾、數(shù)據(jù)格式轉(zhuǎn)換的一種中間程序,將RFID閱讀器讀取的各種數(shù)據(jù)信息,經(jīng)過中間件提取、解密、過濾、格式轉(zhuǎn)換、導入企業(yè)的管理信息系統(tǒng),并通過應用系統(tǒng)反映在程序界面上,供操作者瀏覽、選擇、修改、查詢。中間件技術(shù)也降低了應用開發(fā)的難度,使開發(fā)者不需要直接面對底層架構(gòu),而是通過中間件進行調(diào)用。
RFID中間件是一種消息導向的軟件中間件,信息是以消息的形式從一個程序模塊傳遞到另一個或多個程序模塊。消息可以非同步的方式傳送,所以傳送者不必等待回應。RFID中間件是在企業(yè)應用原有的中間件發(fā)展的基礎(chǔ)上,結(jié)合自身應用特性進一步擴展并深化了中間件的應用,使得RFID應用系統(tǒng)的開發(fā)變得更容易,提高了軟件的可移植性,增強了系統(tǒng)的可維護性和可靠性,所以它的架構(gòu)設計解決方案是RFID應用的一項極為重要的核心技術(shù)[1]。
目前提供RFID中間件平臺的廠商主要有IBM、Oracle、Microsoft、SAP、Sun公司。對于這些廠商,RFID中間件只是其現(xiàn)有軟件的擴展,其RFID產(chǎn)品可以迅速方便地與各自現(xiàn)有的軟件產(chǎn)品線集成在一起。但缺點是其產(chǎn)品對該廠商其他軟件產(chǎn)品的依賴性比較大。
1.2 面向服務的體系結(jié)構(gòu)SOA
面向服務的體系結(jié)構(gòu)是一種技術(shù)架構(gòu)風格,它代表了一種開放的、敏捷的、可擴展的、可組合的架構(gòu)[2],定義了服務提供者和消費者之間的松散耦合關(guān)系。其業(yè)務敏捷的特點,幫助企業(yè)把業(yè)務變得更加靈活,能夠適時、快速地響應變化。SOA的核心概念就是服務[3],其基本結(jié)構(gòu)如圖1所示。其中包含服務的3個基本角色:服務提供者、服務請求者和服務注冊。在這些角色之間使用了3種操作:服務發(fā)布、服務發(fā)現(xiàn)和服務綁定。作為SOA的一種實現(xiàn)技術(shù),Web Services提供了基于XML的標準接口,具有完好的封裝性、松散的耦合性、協(xié)議規(guī)范的標準性以及高度的可集成性等特點,能夠良好地滿足SOA應用模式的需求。
Java管理擴展JMX(Java Management Extensions)是一個為應用程序、設備、系統(tǒng)等植入管理功能的框架。在JMX規(guī)范中,管理組件是一個能代表管理資源的Java對象,遵從一定的設計模式,實現(xiàn)該規(guī)范定義的特定的接口。該定義保證了所有的管理組件以一種標準的方式來表示被管理資源。管理接口就是被管理資源暴露出的一些信息,通過對這些信息的修改能夠控制被管理資源。管理接口包括:能被接觸的屬性值、能夠執(zhí)行的操作、能發(fā)出的通知事件等[4]。
JMS(Java Message Service)是訪問企業(yè)消息系統(tǒng)的標準API,定義了Java中訪問消息中間件的接口,但JMS只是接口,并沒有給予實現(xiàn),實現(xiàn)JMS接口的消息中間件稱為JMS提供者(JMS Provider)。在JMS框架中運轉(zhuǎn)的方法如下:
(1)得到1個JNDI初始化上下文(Context)。
(2)根據(jù)上下文以查找1個連接工廠。
(3)從連接工廠得到1個連接(Connect)。
(4)通過連接以建立1個會話(Session)。
(5)查找目的地(Topic/Queue)。
(6)根據(jù)會話以及目的地以建立消息制造者(TopicPub
lisher/QueueSender)和消費者(TopicSubscrib-er/QueueReceiver)。
2 基于SOA的RFID中間件架構(gòu)
利用SOA松耦合、面向業(yè)務的特點,結(jié)合RFID中間件實現(xiàn)的應用系統(tǒng)集成的方案可提供豐富的接口,能夠幫助實現(xiàn)對RFID設備的管理以及對數(shù)據(jù)的處理,簡化了對底層設備應用的支持,避免了對底層設備的低級別接口的處理。利用Web Service技術(shù)實現(xiàn)RFID中間件與企業(yè)系統(tǒng)的集成,完成兩者的松耦合集成。
基于SOA的RFID中間件架構(gòu),其基礎(chǔ)架構(gòu)層分為設備管理層、事件處理層和服務接口層,并通過Web Service技術(shù)包裝了每1層相應的功能,且進行了具體實現(xiàn)。本文重點介紹該RFID中間件架構(gòu)中的基礎(chǔ)架構(gòu)的3個功能層[5]。這3個層次有著明確的功能劃分和層間的交互接口。RFID中間件架構(gòu)如圖2所示。
中間件設計包括RFID設備管理組件和事件過程管理組件。RFID設備管理組件是分布式的代理,負責第1級的事件過濾;設備管理包括設備詢問器,對每1個閱讀器和傳感器設備,代理必須互相作用。過程管理組件是通過RFID事件下一級的過濾,把事件放置到交易環(huán)境中,然后發(fā)布應用層事件ALE(Application Layer Event)[5]。
2.1設備管理層
設備管理層位于架構(gòu)的最底層,直接與閱讀器交互,實現(xiàn)的主要功能包括:
(1)采集射頻卡上的數(shù)據(jù)。
(2)對于來自不同類型的閱讀器的數(shù)據(jù)進行適配處理,得到統(tǒng)一的、格式化的數(shù)據(jù),并進行數(shù)據(jù)校驗。
(3)將校驗無誤的數(shù)據(jù)按照用戶定義的協(xié)議進行封包,并將消息包發(fā)送到事件處理層的消息系統(tǒng)。
依據(jù)其實現(xiàn)的功能,分別針對射頻卡閱讀器模塊、閱讀器接口、數(shù)據(jù)校驗和數(shù)據(jù)打包4個方面進行研究和開發(fā)。閱讀器模塊是根據(jù)硬件供應商提供的規(guī)范進行編碼實現(xiàn)的;閱讀器接口主要解決將來自協(xié)議格式的數(shù)據(jù)轉(zhuǎn)化為系統(tǒng)所需要的EPC碼;數(shù)據(jù)校驗采用CRC校驗;數(shù)據(jù)打包先依據(jù)獲取的卡片編碼中“數(shù)據(jù)分類”內(nèi)容,判斷出該標簽數(shù)據(jù)屬于哪種類型,然后按照這種數(shù)據(jù)類型將標簽數(shù)據(jù)封裝成相應的消息包。
由于每個ALE閱讀器事件流可能來自多個物理設備配置表,因此設備管理器為每個設備表創(chuàng)建1個詢問器,并通知詢問器哪種傳感器被綁定到指定的閱讀器上。詢問器發(fā)送傳感器事件流到設備管理器,設備管理器將1個或多個傳感器事件流構(gòu)造成閱讀器事件。設備管理器把初步處理的閱讀器事件發(fā)送到ALE服務器。
詢問器代理:1個設備管理器的配置由它管理的設備和它要咨詢的詢問器組成,然后與它所對應的設備管理器交互。每個設備概要表由物理設備屬性和詢問器配置組成。物理設備屬性是被命名過的傳感器(例如天線和1個金屬傳感器)。
事件信息空間:事件信息空間類似于公共的容錯事件信息經(jīng)紀人。它支持異步接收來自設備管理器的事件、ALE事件以及其他來自事件過程管理的配置需求。事件信息空間同時提供一個存儲轉(zhuǎn)發(fā)機制,確保重要的事件在中斷的網(wǎng)絡或其他組件失效的情況下不丟失[5]。
在系統(tǒng)中,將每個閱讀器模塊的遠程方法調(diào)用封裝為1個管理組件(MBean)作為JMX服務器的實例注冊到JMX服務器中。通過JMX框架對閱讀器進行監(jiān)控和管理,使RFID中間件系統(tǒng)能提供管理、監(jiān)控閱讀器的功能。本部分描述為閱讀器管理組件添加時間服務,以達到定時控制閱讀器的目的。
2.2 事件處理層
在RFID系統(tǒng)中,一方面是各種應用程序以不同的方式頻繁地從RFID系統(tǒng)中取得數(shù)據(jù);另一方面卻是有限的網(wǎng)絡帶寬,其存在的矛盾,使其有必要設計1套消息傳遞系統(tǒng),使設備管理層產(chǎn)生的事件能夠傳遞到消息系統(tǒng)中,由事件管理過程進行處理,然后把數(shù)據(jù)傳遞到相關(guān)的應用系統(tǒng)。在這種模式下,閱讀器不必關(guān)心哪個應用系統(tǒng)需要什么數(shù)據(jù)。同時,應用程序也不需要維護與各個閱讀器之間的網(wǎng)絡通道,僅需要將需求發(fā)送到消息系統(tǒng)中即可。由此,設計出的消息系統(tǒng)應具有如下功能:(1)數(shù)據(jù)緩存功能;(2)基于內(nèi)容的路由功能;(3)數(shù)據(jù)分類存儲功能[6]。
下面將描述創(chuàng)建一個MBean來實現(xiàn)一個數(shù)據(jù)處理節(jié)點。消息組件可以按照MBean來部署。消息處理組件執(zhí)行功能:從源隊列中獲取消息,對消息執(zhí)行處理,然后將結(jié)果消息放置到目標隊列。消息處理UML圖如圖3所示。
JBossMQ是通過xml文件jbossmq-destinations-service.xml進行配置的。以下是獲得JBOSS JNDI初始化上下文(Context)的代碼:
Hashtable props=newHashtable();
props.put(Context.INITIAL CONTEXT FACTORY,"org.jnp.interfaces.NamingContextFactory");
props.put (Context. PROVIDER URL, ip +":1099");
props.put("java.naming.rmi.security.manager","yes");
props.put(Context.URL PKG PREFIXES,"org. jboss.naming");
Context context=new InitialContext(props);
來自消息系統(tǒng)的消息以臨時XML文件的形式和磁盤文件方式保存,供數(shù)據(jù)接口使用。消息系統(tǒng)完成消息緩存、分類整合、路由轉(zhuǎn)發(fā)、臨時存放等操作[4]。
事件過程管理EPM(Event Process Managment)由ALE服務、配置管理、復雜事件過程以及交易規(guī)則執(zhí)行組成,對EVP的訪問能通過HTTP、JMS以及網(wǎng)絡服務接口實現(xiàn)。
EPM登記/訂閱其感興趣的事件,當在信息空間中有事件發(fā)生時,即會通知EPM,一旦接收到這些事件,隨后會應用復雜事件處理(過濾器),結(jié)合交易規(guī)則對這些事件進行處理。另一種情況下是:外部的客戶端(如EPC-IS)已經(jīng)注冊接收ALE,這些過濾后的事件會被發(fā)送到ALE客戶端指定的位置。
2.3 服務接口層
來自事件處理層的數(shù)據(jù)最終是分類的XML文件。同一類型的數(shù)據(jù)以XML文件的形式保存,并提供給相應的1個或多個應用程序使用。而服務接口層主要是對這些數(shù)據(jù)進行過濾、入庫操作,并提供訪問相應數(shù)據(jù)庫的服務接口。具體操作如下:
(1)將存放在磁盤上的XML文件進行批量入庫操作,當XML數(shù)據(jù)量達到一定數(shù)量時,啟動數(shù)據(jù)入庫功能模塊,將XML數(shù)據(jù)移植到各種數(shù)據(jù)庫中。
(2)在數(shù)據(jù)移植前將重復的數(shù)據(jù)過濾掉。
(3)為企業(yè)內(nèi)部和企業(yè)外部訪問數(shù)據(jù)庫提供Web Services
接口。
其中,數(shù)據(jù)過濾過程是在處理臨時存放的XML文件的過程中完成的。方法是:將同一個卡號的多條記錄按照讀入的時間戳進行比較,若相鄰記錄的時間戳差值小于用戶定義的閾值,則認為重復讀取發(fā)生,剔出后1條記錄。依次類推,剔出掉所有冗余數(shù)據(jù)。利用Web Services技術(shù)將對數(shù)據(jù)庫的訪問以服務的形式發(fā)布,供企業(yè)內(nèi)部應用程序和企業(yè)合作伙伴調(diào)用[2]。以數(shù)據(jù)過濾為例,其核心代碼如下:
for(int i=1;irowcount;i++)
{span=EndTime.Subtract(StartTime);
spantiIDe=sPan.Seconds; //相鄰記錄的時間戳之差
if(spantime=0.002)
{subtime[i]=i;}
//若相鄰時間戳差值小于2 ms,
//標記第2條記錄為冗余數(shù)據(jù)
else subtime[i]=0;}
for(int j=1;jrowcount;j++) //刪除冗余記錄
{if(subtime[j].ToString()!="0")
{ds.Tables[0].Rows[j].Delete();j=j-1;
rowcount=rowcount11;}
}
以下是服務接口層向應用系統(tǒng)發(fā)送SOAP響應,返回處理結(jié)果的部分代碼[7]。
report xmlns="">
process procInsID="503" givenID="231" givenName="
ShipOut">
event eventType="report_tag_event">
header>Product Quantity Match Success
/header>
status>success/status>
tagList>
tag ID="00110011"detectTime="2008-11-01 T13:13:
00.110+08:00"/>
/tagList>
3 RFID中間件的實現(xiàn)及測試
RIFD中間件系統(tǒng)開發(fā)工具采用Eclipse3.2,應用服務器軟件采用JBOSS4.0, Web容器為Tomcat5.5。此外,服務器端采用了基于Struts的MVC多層次結(jié)構(gòu)框架,數(shù)據(jù)服務層則采用MySQL5.0數(shù)據(jù)庫。
實驗中,終端通過485網(wǎng)絡組網(wǎng),應用系統(tǒng)使用的是倉庫管理系統(tǒng)。倉庫管理系統(tǒng)作為服務請求者,根據(jù)服務接口層公布的入庫信息核對服務WSDL,得到該服務的接口定義和服務端偵聽地址,由入庫管理模塊通過服務代理接口向Web服務發(fā)送SOAP請求消息,請求入庫信息核對服務,Web服務平臺收到該服務請求后,向RFID中間件發(fā)送消息,創(chuàng)建一個出庫信息核對服務的實例,設備管理層根據(jù)服務請求參數(shù),啟動相應的RFID閱讀器讀取標簽信息。然后將讀取的標簽信息經(jīng)處理后打包傳給事件處理層,根據(jù)服務請求的參數(shù)與捕獲的標簽信息進行核對處理,處理后向服務接口層返回核對數(shù)據(jù)正確或者錯誤的信息,如圖4所示。最后,服務接口層向倉庫管理系統(tǒng)發(fā)送SOAP響應,返回處理結(jié)果[5]。
實驗表明,原來的應用系統(tǒng)僅僅支持1種固定卡型的閱讀器,采用RFID中間件以后,可以在1個系統(tǒng)中采用各種卡型的閱讀器,而上層程序不需要再進行修改,增加了系統(tǒng)的可擴展性和易維護性,節(jié)約了時間和成本。系統(tǒng)穩(wěn)定性也有大的提高,有效解決了企業(yè)應用中所關(guān)心的問題。
本文提出了一個基于SOA,綜合應用JMX、JMS等技術(shù)的RFID中間件架構(gòu),并說明了RFID中間件各部分的含義和作用及基礎(chǔ)架構(gòu)的實現(xiàn)。這種中間件結(jié)構(gòu)能很好地屏蔽低端各種物理設備的信息。由于采取了模塊化的結(jié)構(gòu),可以根據(jù)需要進行裁減,在需要的時候再加入相應的模塊,例如,可根據(jù)需要是否添加認證和安全模塊。通過Web Service,可實現(xiàn)對RFID中間件更高層次包裝,保證了RFID基礎(chǔ)架構(gòu)中3個功能層之間的相互獨立和協(xié)同工作。
評論