无线射频识别中间件技术

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、中间件系统架构

中间件系统作为一个软件系统（或称组件），在实现一定功能、性能要求之外，可理解性、可扩展性、可修改性（或称可重构性）、可插入性、可重用性等质量属性都将作为软件设计的要求被提出来。

近十余年来，面向对象思想几乎全面占领软件设计领域，成为最主流的分析、设计方法。而近数年来，对设计模式的研究也已日臻完善，模式几乎已成为一种“更高级编程语言”（相比于Java、C++等高级编程语言）被广泛应用。

面向对象思想、设计模式都是以实现软件的可理解、可扩展、可修改、可插入、可重用等目标为己任的，本文也将应用面向对象思想、参考模式语言，对中间件的软件架构做一个初步的探讨，下文的例子如涉及高级编程语言，均采用Java语言[2]。

3.1 封装、隔离处理流程中的各个节点

将中间件的业务流程中的各个节点分作不同模块处理，可以获得封装、高内聚、低耦合等优势，参见图5。

图5 中间件系统模块划分图