2.3 RFID中间件
RFID中间件的功能是负责管理读写器和应用软件之间的数据流。通过中间件及信息服务，使得RFID系统的相关信息可以在全球得到共享。
RFID中间件是一种面向消息的中间件（Message-Oriented Middleware，MOM），信息（Information）是以消息（Message）的形式，从一个程序传送到另一个或多个程序。信息可以以异步（Asynchronous）的方式传送，所以传送者不必等待回应。面向消息的中间件包含的功能不仅是传递（Passing）信息，还必须包括解译数据、安全性、数据广播、错误恢复、定位网络资源、找出符合成本的路径、消息与要求的优先次序以及延伸的除错工具等服务。
RFID中间件技术涉及的内容比较多，包括并发访问技术、目录服务及定位技术、数据及设备监控技术、远程数据访问、安全和集成技术、进程及会话管理技术等。但任何RFID中间件应能够提供数据读出和写入、数据过滤和聚合、数据的分发、数据的安全等服务。根据RFID应用需求，中间件必须具备通用性、易用性、模块化等特点。
RFID应用的范围愈发广泛，涉及制造、物流、医疗、运输、零售等领域。然而，RFID系统的运营除了标签、天线、设备的认证，还要有应用软件，才能迅速推广。而中间件可称为是RFID运作的中枢，因为它可以加速关键应用的问世。
2.3.1 RFID扮演的角色
面对目前各式各样RFID的应用，企业最关注的第一个问题是：“我要如何将现有的系统与这些新的RFID Reader连接？”这个问题的本质是企业应用系统与硬件接口的问题。因此，透明度是整个应用的关键，正确抓取数据、确保数据读取的可靠性以及有效地将数据传送到后端系统都是必须考虑的问题。传统应用程序与应用程序之间（Application to Application）数据通透是通过中间件架构解决的，并发展出各种Application Server应用软件；同理，中间件的架构设计解决方案便成为RFID应用的一项极为重要的核心技术。
RFID中间件扮演RFID标签和应用程序之间的中介角色，如图2.18所示，从应用程序端使用中间件所提供一组通用的应用程序接口（API），即能连接RFID读写器，读取RFID标签数据。这样一来，即使存储RFID标签情报的数据库软件或后端应用程序增加或改由其他软件替代，或者读写RFID标签的读写器种类增加等情况发生时，应用端不需修改也能处理，省去多对多连接的维护复杂性问题。
图2.18 RFID中间件在系统中的作用
2.3.2 RFID中间件的架构
RFID中间件从架构上可以分为以下两种。
1. 以应用程序为中心
以应用程序为中心的设计概念是通过RFID Reader厂商提供的API和以Hot Code方式直接编写特定Reader读取数据的Adapter，并传送至后端系统的应用程序或数据库，从而达成与后端系统或服务串接的目的。
2. 以架构为中心
随着企业应用系统复杂度的增加，企业无法以Hot Code方式为每个应用程序编写Adapter，同时面对对象标准化等问题，企业可以考虑采用厂商所提供标准规格的RFID中间件。这样一来，即使存储RFID标签情报的数据库软件改由其他软件替代，或读写RFID标签的读写器种类增加等情况发生时，应用端不做修改也能应付。
RFID中间件具有以下特色：
（1）独立并介于RFID读写器与后端应用程序之间，并且能够与多个RFID读写器以及多个后端应用程序连接，以减轻架构与维护的复杂性。
（2）数据流（Data Flow）。RFID的主要目的在于将实体对象转换为信息环境下的虚拟对象，因此数据处理是RFID最重要的功能。RFID中间件具有数据的搜集、过滤、整合与传递等特性，以便将正确的对象信息传到企业后端的应用系统。
（3）处理流（Process Flow）。RFID中间件使用程序逻辑及存储再转送（Store-and-Forward）的功能来提供顺序的消息流，具有数据流设计与管理的能力。
（4）标准（Standard）。RFID为自动数据采样技术与辨识实体对象的应用。EPC Global目前正在研究为各种产品的全球唯一识别码提出通用标准，即EPC。EPC在供应链系统中以一串数字来识别一项特定的商品，通过无线射频辨识标签由RFID读写器读入后，传送到计算机或应用系统中的过程称为对象命名服务（Object Name Service）。对象命名服务系统会锁定计算机网络中的固定点抓取有关商品的消息。EPC存放在RFID标签中，被RFID读写器读出后，即可提供追踪EPC所代表的商品名称及相关信息，并立即识别及分享供应链中的商品数据，有效率地提供信息透明度。
RFID中间件在应用系统中的关系如图2.19所示。
图2.19 RFID中间件在应用系统中的关系
在RFID应用中，透明度是整个应用的关键，正确抓取数据、确保数据读取的可靠性及有效地将数据传送到后端系统都是必须考虑的问题。传统应用程序之间的数据通透是通过中间件架构来解决的，并由此发展出各种Application Server应用软件。
以前的网络主要是客户机与服务器（C/S）结构或浏览器/服务器（B/S）形式的两层结构，随着企业信息的不断扩大，企业级应用不再满足于简单的两层系统，而是向着三层及多层体系结构发展。中间件就是在其中加入一个中间层，以支持更多的功能和服务。
2.3.3 中间件发展方向
1. 与读写器管理系统的融合
中间件是读写器与后台应用系统之间的桥梁，而读写器通常有设备管理需求，比如软件版本下载、设备告警管理、参数配置等，读写器管理系统也是直接与读写器交互的软件模块。于是，如何处理好中间件与读写器管理系统之间的关系成为一个亟待解决的问题。
从软件部署（部署在同一台主机上）、软件模块重用（重用读写器通信模块）等角度考虑，中间件与读写器管理系统的融合势必成为中间件本身的一个优势。
2. 对多标准标签的支持
RFID技术在国内外的发展和应用方兴未艾，国际上多个标准化组织都试图统一RFID标准，但在一定的时期内，势必出现多标签并存的情况。于是，对多标准标签的支持也是中间件系统的一个发展方向。
3. 对多厂商读写器的支持
中间件与读写器之间的接口、通信方式以及信息格式，也无法做到统一标准。对多厂商读写器的支持、至少对少数几家主流厂商的读写器的支持，是对中间件的基本要求。
2.3.4 RFID中间件的应用举例
基本的RFID系统一般由3部分组成：标签、读写器以及应用支撑软件。中间件是应用支撑软件的一个重要组成部分，是衔接硬件设备（如标签、读写器）和企业应用软件（如企业资源规划、客户关系管理等）的桥梁。中间件的主要任务是对读写器传来的与标签相关的数据进行过滤、汇总、计算、分组，减少从读写器传往企业应用的大量原始数据、生成加入了语意解释的事件数据。可以说，中间件是RFID系统的“中枢神经”。
对于RFID中间件的设计，有诸多问题需要考虑。例如，如何实现软件的诸多质量属性、如何实现中间件与硬件设备的隔离、如何处理与设备管理功能的关系、如何实现高性能的数据处理等。
2.3.4.1 RFID网络框架结构
RFID网络框架结构如图2.20所示。
图2.20 RFID网络框架结构
标签数据经过中间件的分组、过滤等处理上报给应用系统；应用系统负责事件数据的持久化存储，以及标签绑定的业务信息的管理。
RFID系统共享公共服务平台提供的根节点ONS、企业应用鉴权管理、标签信息政务发现和企业授权码管理等公共服务。其中，根节点ONS连同所有企业级RFID系统的内部ONS，组成一个ONS树，任何一个标签都可以在ONS树上找到标签所对应的标签信息库的地址，即可以进一步访问到标签对应的详细信息。
中间件的功能在于接受应用系统的请求，对指定的一个或者多个读写器发起操作命令，如标签清点、标签标识数据写入、标签用户数据区读写、标签数据加锁、标签杀死等，并接收、处理、向后台应用系统上报结果数据。
其中，标签清点是最基本也是应用最广泛的功能。
2.3.4.2 标签清点功能概述
标签清点的工作流程可简单描述为：应用系统以规则的形式定义对标签数据的需求，规则由应用系统向中间件提出，由中间件维护。规则中定义了：需要哪些读写器的清点数据，标签数据上报周期（事件周期）的开始和结束条件，标签数据如何过滤，标签数据如何分组，上报数据是原始清点数据、新增标签数据还是新减标签数据，标签数据包含哪些原始数据等。
（1）应用系统指定某项规则，向中间件提出对标签数据的预订。
中间件根据应用系统对标签数据的预订情况，适时启动事件周期，并向读写器下发标签清点命令。读写器将一定时间周期（读取周期）中清点到的数据，发送给中间件。读取周期可由中间件与读写器私下协商确定。
（2）中间件接收读写器上报的数据。
中间件根据规则的定义，对接收数据做过滤、分组、累加等操作，并在事件周期结束时，按照规则的要求生成数据结果报告，发送给规则的预订者。
过滤过程可去除重复数据、应用系统不感兴趣的数据，大大降低了组件间的传输数据量。
中间件标签清点概要流程图如图2.21所示。
图2.21 中间件标签清点概要流程图
2.3.4.3 标签清点实现原理
如前所述，规则是整个中间件功能的关键元素。规则相当于应用系统发给中间件的订货单，定义了对货品（标签数据）的时间（事件周期）和规格（如何过滤、如何分组、报告样式等）的要求，原理描述部分参考EPC Global相关内容。
规则、报告有自身的信息模型，表征其承载的信息，同时，规则拥有其自身的状态机模型。在接受应用系统的长期预订、单次预订时，这些预订操作会激发规则的状态变迁，如从“未被请求”状态跃迁到“已被请求”状态。
规则由应用系统通过API定义。
1. 规则信息模型
规则信息模型的描述采用了统一建模语言（UML），在面向对象的语境中，规则可表征为一个类（ECS pec）。从信息模型描述中可看出，一个规则类，与其他多个类具有关联关系，或者说拥有如下属性：一个或者多个逻辑读写器的列表（Readers）、事件周期边界定义（Boundaries）、一个或者多个报告的定义（Report Specs）、是否在报告中包含规则本身的标记（Include Spec In Reports）。
2. 报告信息模型
与规则信息模型类似，其中事件报告组类（EC Reports）拥有如下属性：规则名称（Spec Name）、事件上报时间（Date）、事件周期时长（Total Milliseconds）、事件周期结束条件（Termination Condition）、规则定义类实例（Spec）、一个或者多个报告类的实例列表（Reports）。
报告类（EC Report）中包含了具体的标签数据信息。
3. 标签清点API
应用系统下发的定义规则、预订数据等请求，以调用中间件提供的API的方式完成。API调用过程可采用Java RMI、SOAP等相关具体技术实现。
4. 规则状态机模型
规则从其定义开始，可能存在于3种状态：未被请求状态（Unrequested）、已被请求状态（Requested）和激活状态（Active）。
当规则创建之后，还没有被任何客户端（即应用系统）预订，规则处于Unrequested状态；对规则的第一个预订动作将使规则跃迁到Requested状态；当事件周期开始条件满足时，规则进入Active状态；当事件周期结束条件满足时，如果规则存在预订者，则跃迁到Requested状态，否则跃迁到Unrequested状态。