現在的web開發真是越來越簡單了

1. 敲了幾個命令，一個web工程就建好了

2.建好一個domain類，把屬性定義好，再寫了一行代碼，就可以直接實現四大金剛的功能 -- CRUB。強悍啊，想想以前的裸寫JDBC，到Hibernate繁雜的O/R配置文件，這年頭寫程序是簡單的不行了。

3.頁面顯示也都自動化了。自動生成新建頁面，還直接把數據讀出來顯示，具有字段排序功能，開發真簡單啊！重復的體力活沒了

 

JAVA的I/O里面一大堆的類，剛開始學的時候，真是狂暈。

認真讀完Core java之后，才發現這一套機制其實還簡單的，只要抓住2條脈絡：byte和Char，Decrator模式

byte和Char的區別，說起來很簡單，一個是8位，一個是16位。為什么在java中要嚴格區分呢？因為java是unicode的，也就是16位的，而很多系統通用的是ASCII（8bit）。正因為這種差異，在I/O機制中，用stream處理8位，Reader處理16位。在從輸入輸出角度來考慮，于是就有了InputStream/OutputStream和InputReader/OutputReader。

然而，這些原始流提供的功能太少了，效率也太低了。例如，一次只能讀多個字符而不能讀一行。為了提高效率，需要對他們進行一層包裝，提供緩沖等功能。這個時候就應用包裝器（Decrator）模式，設計了buffer... LineNumber...Data...等

 

當然，操作文件的時候，可以簡單的用FileReader，FileWriter打開文件，具體操作的時候PrintWriter就可以負責文件寫了，而讀文件一般需緩沖， 于是用BufferReader就行了

應用層事件（Application Level Event）規范，簡稱ALE規范，于2005年9月，由EPCglobal組織正式對外發布。它定義出RFID中間件對上層應用系統應該提供的一組標準接口，以及RFID中間件最基本的功能：收集／過濾（Collect/Filter）。

1. ALE產生的背景 ---- RFID數據的冗余性/業務邏輯

RFID讀寫器工作時，不停的讀取標簽；因而，造成同一個標簽在一分鐘之內可能讀取到幾十次，這些數據如果直接發送給應用程序，將帶來很大的資源浪費，所以需要RFID中間件對這些原始數據（Raw Data）進行一層收集/過濾處理，提供出有意義信息。

“What, when, where” (何時何地發生什么事情) 這是ALE向應用系統提供的最典型的信息內容。例如：“2006-3-20 19:30 門禁處讀取到 epc#1”。此外，在智能貨柜（Smart Shelf）之類的應用中，業務流程只關注物品是否增加或減少。此時，ALE就可以向上層匯報“2006-3-20 19:31 epc#1 在貨柜#1區出現/消失”。

所以說，ALE的出現主要是為了減少原始數據的冗余性，從大量數據中提煉出有效的業務邏輯而設計。

2. ALE與應用系統的關系

ALE層介于應用業務邏輯和原始標簽讀取層之間，如圖1所示。它接收從數據源（一個或多個讀寫器）中發來的原始標簽讀取信息，而后，按照時間間隔等條件累計（Accumulate）數據，將重復或不敢興趣的EPCs剔除過濾(Filter)，同時可以進行計數及組合（Count/Group）等操作，最后，將這些信息對應用系統進行匯報。

在ALE中，應用系統可以定義這些內容：在什么地方（地點可以映射一個或多個讀寫器及天線）讀取標簽。在怎樣的時間間隔內（決定時間、某個外部事件觸發）收集到的數據，如何過濾數據，如何整理數據報告內容（按照公司、商品還是標簽分類），標簽出現或消失時是否對外報告，以及讀取到的標簽數目。

ALE規范定義的是一組接口，它不牽涉到具體實現。在EPCglobal組織的規劃中，支持ALE規范是RFID中間件的最基本的一個功能；這樣，在統一的標準下，應用層上的調用方式就可統一，應用系統也就可以快速部署。

因此，ALE規范定義的是應用系統對RFID中間件的標準訪問方式。

3. ALE 輸入（ECSpec）/輸出（ECReport）

在ALE模型中，有幾個最基本的概念：讀周期（Read Cycle），事件周期（Event Cycle）和報告（Report）。

讀周期是和讀寫器交互的最小單位。一個讀周期的結果是一組EPCs集合。讀周期的時間長短和具體的天線、RF協議有關。讀周期的輸出就是ALE層的數據來源。如圖2所示。

事件周期可以是一個或多個讀周期。它是從用戶的角度來看待讀寫器的，可以將一個或多個讀寫器當作一個整體，是ALE接口和用戶交互的最小單位。應用業務邏輯層的客戶在ALE中定義好事件周期的邊界之后，就可接收相應的數據報告。

報告，則是在前面定義的事件周期的基礎上，ALE向應用層析提供的數據結果。

圖2 事件周期

對于事件周期的定義，在ALE中由ECSpec表達；對于報告的內容，由ECReports負責，如圖3。

4. ECSpec 介紹

ECSpec描述了事件周期以及報告產生的格式。它包括：一組邏輯讀寫器（logical Readers）內，這些邏輯讀寫器的讀周期在該事件周期內；一份定義事件周期邊界的規范；以及在這個事件周期內產生的一組報告（report）的格式規范。如圖4所示

圖4 ECSpec

在ALE規范中，定義出ECSpec的XSD文件，同時有ECSpec的具體例子，如圖5。

圖5 ECSpec示例

從該例子中，我們可以看出，上層應用系統需要邏輯讀寫器dock_1a和dock_1b，在滿足開始及結束的觸發事件文件trigger1/trigger2 定義的條件下，重復周期20000MS，間隔3000MS，對外發送3個報表report1/report2/report3，report1報告當前讀取到的標簽，report2報告每個事件周期內增加的標簽及總個數，report3報告每個事件周期內減少的標簽及總個數，以及標簽進行組合的形式。

5. ECReports介紹

ECReports是ALE中間件向上層應用系統做出報告，如圖6所示。

Report1匯報當前讀取到2個標簽。Report2報告當前讀取到的標簽個數6847。Report3報告EPC為3.0037000.12345類的物品讀取到2個，3.0037000.55555類的物品讀取到3個，讀取到標簽數為6842。

6. 典型ALE調用場景

應用系統與ALE中間件的交互，必須先將事件周期的定義文件（ECSpec）傳送至中間件，同時告知中間件將報告發回的地址。在以ALE交互中，有幾個最基本的方法：define/undefine，subscribe/unsubscribe, poll/Immediate。 define/undefine是定義/撤銷ECSpec的操作，subscribe/unsubscribe是訂閱/撤銷某個ECSpec的服務。

a) 直接訂閱(Direct Subscription)

該模式下，ECSpec由客戶A定義，得到的報告反饋給A。

首先，Client1將名為ECname1的ECSpec定義給ALE中間件，而后Client1訂閱該ECName1的報告，并將它發至地址為notifyURI的接收處。

在時間1內，讀寫器reader1沒有讀到標簽，所以沒有反饋。在時間厄內，讀到標簽，而后，ALE中間件自動將ECreport發送給Client1。

當Client1不需要RFID信息時，它首先退訂notifyURI的ECname1的服務。當ECname1沒有訂閱者之后，就可以撤銷ECname1的時間周期。

b) 間接訂閱(InDirect Subscription)

該模式與直接訂閱的差異是，得到的報告不是反饋給A，而是反饋給B。

該圖顯示的ECspec邊界由觸發器來決定。在第6步中，我們可以看到ECreport發至client1，而不是初始的服務定義者。這是由于在第2步中的服務反饋地址notifyURI指向client1。

c) Poll/Immediate

Poll和Immediate可以看成應用系統對ALE中間件的快照。在很多應用中，不需要一直監聽ALE，而只要知道當時讀到的標簽信息，這2種模式就是為滿足這些需求而設計的

當ALE中間件中已經有定義好的ECSpec時，同時Client需要這個ECSpec提供的信息，就可以使用Poll方法得到反饋。

當ALE中間件中不存在Client需要的事件周期時，這個時候，可以直接轉送這個事件周期的定義ECSpec2，而后得到結果，這就是Immediate。

7. 參考資料

EPCglobal. The Application Level Events(ALE) Specification, version 1.0, Sept 15, 2005.