中间件将事件源抽象为一个逻辑概念——逻辑阅读器，一个逻辑阅读器可以包含多个物理阅读器，甚至可更细化为包含多个物理阅读器的多个天线。
逻辑阅读器的划分可以根据实际的系统部署情况来确定，比如，某一个仓库两个出口部署了4个阅读器，可根据需要将这4个阅读器配置成为一个逻辑阅读器，不妨命名为“仓库出口”。应用系统在需要仓库出口的标签数据时，可基于这个逻辑阅读器下发清点命令，而逻辑阅读器名称作为部分应用程序接口(API)调用的参数。
2.2 标签清点实现原理
如前所述，规则是整个中间件功能的关键元素。规则相当于应用系统发给中间件的订货单，定义了对货品(标签数据)的时间(事件周期)和规格(如何过滤、如何分组、报告样式等)的要求，原理描述部分参考EPCglobal相关内容。
规则、报告有自身的信息模型，表征其承载的信息，同时，规则拥有其自身的状态机模型。在接受应用系统的长期预订、单次预订时，这些预订操作会激发规则的状态变迁，如从“未被请求”状态跃迁到“已被请求”状态。
规则由应用系统通过API定义。
(1) 规则信息模型
规则信息模型的描述采用了统一建模语言(UML)，如图3所示。
图3 规则信息模型图
在面向对象的语境中，规则可表征为一个类(ECSpec)。从信息模型描述中可看出，一个规则类，与其他多个类具有关联关系，或者说拥有如下属性：一个或者多个逻辑阅读器的列表(readers)、事件周期边界定义(boundaries)、一个或者多个报告的定义(reportSpecs)、是否在报告中包含规则本身的标记(includeSpecInReports)。
(2) 报告信息模型
与规则信息模型类似，报告信息模型如图4所示。
图4 报告信息模型图
其中，事件报告组类(ECReports)拥有如下属性：规则名称(specName)、时间上报时间(date)、事件周期时长(totalMilliseconds)、事件周期结束条件(terminationCondition)、规则定义类实例(spec)、一个或者多个报告类的实例列表(reports)。
报告类(ECReport)中包含了具体的标签数据信息。
(3) 标签清点API
应用系统下发的定义规则、预订数据等请求，以调用中间件提供的API的方式完成。API调用过程可采用Java RMI、SOAP等相关具体技术实现，其中最重要的API参见表1。
表1 标签清点应用程序接口
其中，poll操作相当于subscribe操作收到一个事件周期的数据之后调用unsubscribe操作；immediate操作相当于define操作定义规则之后，调用poll操作，然后调用undefine操作。
(4) 规则状态机模型
规则从其定义开始，可能存在于3种状态：未被请求状态(Unrequested)、已被请求状态(Requested)、激活状态(Active)。
当规则创建之后，还没有被任何客户端(即应用系统)预订，规则处于Unrequested状态；对规则的第一个预订动作将使规则跃迁到Requested状态；当事件周期开始条件满足时，规则进入Active状态；当事件周期结束条件满足时，如果规则存在预订者，则跃迁到Requested状态，否则跃迁到Unrequested状态。
3、中间件系统架构
中间件系统作为一个软件系统(或称组件)，在实现一定功能、性能要求之外，可理解性、可扩展性、可修改性(或称可重构性)、可插入性、可重用性等质量属性都将作为软件设计的要求被提出来。
