（3） 標(biāo)簽清點(diǎn)API

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

表1：標(biāo)簽清點(diǎn)應(yīng)用程序接口。

其中，poll操作相當(dāng)于subscribe操作收到一個(gè)事件周期的數(shù)據(jù)之后調(diào)用unsubscribe操作;immediate操作相當(dāng)于define操作定義規(guī)則之后，調(diào)用poll操作，然后調(diào)用undefine操作。

（4） 規(guī)則狀態(tài)機(jī)模型

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

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

3、中間件系統(tǒng)架構(gòu)

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

近十余年來(lái)，面向?qū)ο笏枷霂缀跞嬲碱I(lǐng)軟件設(shè)計(jì)領(lǐng)域，成為最主流的分析、設(shè)計(jì)方法。而近數(shù)年來(lái)，對(duì)設(shè)計(jì)模式的研究也已日臻完善，模式幾乎已成為一種“更高級(jí)編程語(yǔ)言”（相比于Java、C++等高級(jí)編程語(yǔ)言）被廣泛應(yīng)用。

面向?qū)ο笏枷?、設(shè)計(jì)模式都是以實(shí)現(xiàn)軟件的可理解、可擴(kuò)展、可修改、可插入、可重用等目標(biāo)為己任的，本文也將應(yīng)用面向?qū)ο笏枷?、參考模式語(yǔ)言，對(duì)中間件的軟件架構(gòu)做一個(gè)初步的探討，下文的例子如涉及高級(jí)編程語(yǔ)言，均采用Java語(yǔ)言。

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

將中間件的業(yè)務(wù)流程中的各個(gè)節(jié)點(diǎn)分作不同模塊處理，可以獲得封裝、高內(nèi)聚、低耦合等優(yōu)勢(shì)，參見(jiàn)圖5。

圖5：中間件系統(tǒng)模塊劃分圖。

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

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

為了避免后臺(tái)應(yīng)用系統(tǒng)，即中間件的客戶端過(guò)分耦合，采用門(mén)面模式（Facade）對(duì)系統(tǒng)內(nèi)部、外部實(shí)現(xiàn)清晰的隔離。處理流程可參見(jiàn)圖6所示的序列圖?？蛻舳藘H僅與Facade類建立聯(lián)系，如果Facade接口定義得足夠清晰，客戶端可以對(duì)中間件的內(nèi)部實(shí)現(xiàn)一無(wú)所知，這體現(xiàn)了面向?qū)ο笾械姆庋b性。

圖6：客戶端調(diào)用APT序列圖。

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

}

工廠類APIFactory：

publicclassAPIFactory{

publicstaticMiddlewareAPIgetAPIInstance（）{

}

}

API的實(shí)現(xiàn)類A：

publicclassClient{

publicstaticvoidmain（String［］ args） {

MiddlewareAPI api = APIFactory.getAPIInstance（）;

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

}

}