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）; &nnbsp; ｝ 工廠類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｛ & nbsp; 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; & nbsp; 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對多廠商閱讀器的支持 中間件與閱讀器之間的接口、通信方式以及信息格式，也無法做到統一標準。對多廠商閱讀器的支持、至少對少數幾家主流廠商的閱讀器的支持，已經是對中間件所提出的基本要求。