现在的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.