介于前端RFID读写器硬件模块和后端数据库与应用软件之间的中介，称为RFID中间件（Middleware）。应用程序端使用中间件提供的一组通用的应用程序接口（Application Pro-gram Interface，API），即能连接到RFID读写器，读取RFID标签数据。中间件实现对底层设备的精确控制、实时采集原始数据、对数据进行过滤，并在其中封装典型的应用逻辑，使系统接口简单透明，从而达到系统的协调工作。RFID中间件位于企业应用程序与底层设备之间，提供统一的应用逻辑接口与设备接口，在实际应用中起到读写器的管理和数据的处理、传递功能。它的最终目的是数据为上层应用系统所用。RFID中间件如图2-14所示，功能上可分为数据采集层和事件处理层。
1.数据采集层
为屏蔽各类设备之间的差异，实现应用对设备的透明操作。中间件将每个设备（阅读器、传感器等）用统一的代理来模拟，由代理和设备直接交互。不同的设备，其代理处理的消息类型、处理的方法也不同。代理之间通过UDP/IP上的XML消息来交流信息。使用XML的优点是它的异构性、可扩展性、灵活性，适用于松耦合特性的分布式系统。数据采集层又细分为代理接口和缓冲两部分。
图2-14 RFID中间件
代理接口是中间件，为设备和应用层提供了双向接口，用代理来模拟设备接口。阅读器代理负责控制阅读器驱动、状态查询、接收RFID标签信息等工作，把设备传进来的数据转换成标准化格式，这样能更好地适应客户需要。在缓冲模块部分，由于RFID阅读器每秒会阅读到成千上万的标签，为防止溢出，采用线程来加速包的卸载，并将数据保存在即时队列中。这里线程和数据队列构成了一个缓冲机制，以满足计算机的实时处理要求，它可以从阅读器接收到的大量简单、重复、无序的数据，按要求平滑进行处理。每个阅读周期（读周期是和读写器交互的最小单位）线程接收一组EPC组合（标签EPC、阅读器ID、时间戳），将其发送到消息队列，对其进行事件有效性验证，检查是否出现读写错误或漏读，实现对数据的初步过滤。正确读取的数据记录在数据库的Observation表中。
2.事件处理层
事件处理层位于数据采集层和业务应用逻辑之间，主要分为事件处理和解析处理两部分。它根据上层系统发送的定义文件和回发地址，生成报告文件，报告反馈给系统。数据采集层提供了硬件的统一接口，事件处理层则定义了应用系统对RFID中间件的标准访问方式。它对原始RFID数据进一步处理，使数据转换为上层系统需要的形式。
在事件处理部分，数据流从代理接口和缓冲机制接收后，还存在着大量的冗余信息，需要对其进行相应的处理，如过滤、聚合，提取出有意义的事件。按解析机制发来的事件，以周期T对数据流进行提取操作，按上层定义的业务规则来判断事件类型，并存储在相应的文档中。(www.xing528.com)
在事务处理中存在的大量重复，分为阅读器重复和标签重复。标签位于一个阅读器识读范围内时，阅读器就会不断地读取标签数据，直到标签离开为止，称为标签重复；另外，当标签同时处于多个阅读器的识读范围内时，它的数据也会被不同的阅读器重复读取。为解决上述问题，对标签重复，只记录标签第一次出现和最后一次出现的时间；对阅读器重复，一是在布置阅读器位置时考虑到交叠情况，尽量用最少的阅读器数量覆盖全部区域。同时过滤后的数据流蕴含大量的语义信息。事务处理根据具体的业务规则，对数据流进行分析，提取出有意义的信息。
在解析器部分，为了使得系统有着更好的可扩展性和可移植性。在数据采集层，代理兼容了不同的设备接口，使中间件与设备无关。而解析机制则将上层系统发来的定义文件转化为中间件可以理解的方式。事件周期T和具体业务规则都是由上层定义的，中间件只需按要求进行处理就可以了。报告文件由事务处理机制生成并发送到指定位置，同时在数据库记录。
3.数据库支持
传统的数据库更新并不频繁地按设定的时间进行，然而RFID数据库的更新非常频繁。阅读器不断地读入原始数据，进行过滤、聚合处理后的数据要进行存储，上层应用程序又不断地进行查询，使得RFID数据库的构建和传统数据库不同，需要分层建立。RFID数据库如图2-15所示。
底层是RFID原始数据库，过滤组合后的数据库位于第二层，然后是具体业务逻辑数据库，为方便查询，最上层由需要频繁查询的数据库组成。
图2-15 RFID数据库
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
