(4) 规则状态机模型

    规则从其定义开始，可能存在于3种状态：未被请求状态(Unrequested)、已被请求状态(Requested)、激活状态(Active)。

    当规则创建之后，还没有被任何客户端(即应用系统)预订，规则处于Unrequested状态；对规则的第一个预订动作将使规则跃迁到Requested状态；当事件周期开始条件满足时，规则进入Active状态；当事件周期结束条件满足时，如果规则存在预订者，则跃迁到Requested状态，否则跃迁到Unrequested状态。

    3  中间件系统架构

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

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

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

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

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

RFID)如何与中间件技术结合 style="BORDER-RIGHT: black 1px solid; BORDER-TOP: black 1px solid; BORDER-LEFT: black 1px solid; BORDER-BOTTOM: black 1px solid; FONT-FAMILY: " alt=(图)看无线射频识别(RFID)如何与中间件技术结合 src="http://img.spn.com.cn/article/0/834/lirNNNLw1vHKg.gif" align=no>

    其中，报告上传模块，负责实现不同类型的报告上传方式，如HTTP、JMS等；API接口模块，负责隔离应用系统和中间件核心业务逻辑处理模块，向应用系统提供中间件API接口；中间件核心业务逻辑处理模块，负责中间件核心业务，包括数据接收过滤、数据分组、报告生成、规则对象的状态跳转等；阅读器通信模块，负责中间件系统与阅读器的通信。

    3.2门面模式、工厂模式对外部暴露API接口

    为了避免后台应用系统，即中间件的客户端过分耦合，采用门面模式(Facade)对系统内部、外部实现清晰的隔离。处理流程可参见图6所示的序列图。客户端仅仅与Facade类建立联系，如果Facade接口定义得足够清晰，客户端可以对中间件的内部实现一无所知，这体现了面向对象中的封装性。

RFID)如何与中间件技术结合 style="BORDER-RIGHT: black 1px solid; BORDER-TOP: black 1px solid; BORDER-LEFT: black 1px solid; BORDER-BOTTOM: black 1px solid; FONT-FAMILY: " alt=(图)看无线射频识别(RFID)如何与中间件技术结合 src="http://img.spn.com.cn/article/0/835/lijlX3FO4fR46.gif" align=no>

    类的设计参见源代码示例，从中可以看出，采用简单工厂模式(Simple Factory)能够在客户端不知情的情况下，灵活地替换API实现类的版本。中间件API接口清晰地定义了中间件提供的操作，客户端只须知道工厂类(APIFactory)能够得到中间件API接口的实例即可。

    中间件API接口MiddlewareAPI：

    publicinterfaceMiddlewareAPI{

    void define(String specName, ECSpec spec);

    void undefine(String specName);

void subscribe(String specName, String uri);

    void unsubscribe(String specName, String uri);

    EPCReports poll(String specName);

    EPCReports immediate(ECSpec spec);

    }

    工厂类APIFactory：

    publicclassAPIFactory{

    publicstaticMiddlewareAPIgetAPIInstance(){

    }

    }

    API的实现类A：

    publicclassClient{

    publicstaticvoidmain(String[] args) {

    MiddlewareAPI api = APIFactory.getAPIInstance();

    api.define("a new spec", new EPCSpec());

    }

    }

    3.3状态模式模拟规则的状态机

    规则在其生命周期中拥有不同的状态，在每个状态对一系列操作都有着不同的表现，于是可以利用状态模式(state)来模拟规则的状态机，将不同状态的不同表现作为可变化因素封装起来，参见代码示例。

    规则状态接口ECState：

    publicinterfaceECState{

    voidsubscribe(StringspecName,String uri);

    voidunsubscribe(StringspecName,String uri);

    EPCReportspoll(StringspecName);

    }

    未被请求状态类ECStateUnrequested：

    publicclassECStateUnrequestedimplements ECState {

    }

    已被请求状态类ECStateRequested：

    publicclassECStateRrequestedimplements ECState {

    }

    激活状态类ECStateActive：

    publicclassECStateActiveimplements ECState {

    }

    规则类ECSpec：

    publicclassECSpec{

    privateECStatestate;

    publicECStategetState(){

return state;

    }

    publicvoidsetState(ECStatestate) {

    this.state = state;

    }

    }

    这样，在针对规则实施相应操作的时候，就可以直接把相应操作委派给其状态属性(ECState)去做即可。比如，ECSpec的subscribe操作，只需一行代码“state.suscribe(specName, uri);”即可。其中，specName、uri为临时变量，具体取值在方法调用之前确定。

    由面向对象的多态性特征，根据state字段目前所指向的对象来动态确定由ECState接口的哪一个具体的实现类的代码来完成工作。ECState接口的实现类根据实际情况确定是否需要在处理过程中修改ECSpec对象的状态属性(state)，此处在应用状态模式时，需要设计多个定时器类来辅助状态机的跳转[3]。

    3.4策略模式切换多种报告上传、命令下发方式

    事件周期结束之后，中间件需要组装报告上传给规则的预订者，即应用系统。上传的方式有多种，如HTTP、Socket、JMS等等。中间件的核心逻辑处理模块不应该关心具体的上传技术，相应工作应交给报告上传模块来做，核心逻辑处理模块只须完成自己的工作，然后把一定格式的数据通过报告上传模块发送，参见代码示例。

    报告发送接口ReportSender：

    publicinterfaceReportSender{

    voidsendReport(ECReportsreports);

    }

    通过Http方式发送报告的ReportSender接口实现类ReportSenderByHttp：

    publicclassReportSenderByHttpimplements ReportSender {

    public void sendReport(ECReports reports) {

    }

    }

    通过Socket方式发送报告的ReportSender接口实现类ReportSenderBySocket：

    publicclassReportSenderBySocketimplements ReportSender {

    publicvoidsendReport(ECReportsreports) {

    }

    }

    通过JMS方式发送报告的ReportSender接口实现类ReportSenderByJms：

    publicclassReportSenderByJmsimplements ReportSender {

    publicvoidsendReport(ECReportsreports) {

    }

    }

    报告发送示例客户端类

    SendReportWorker：

    publicclassSendReportWorker{

privateReportSendersender;

    privateECReportsreports;

    publicvoidsetReports(ECReportsreports) {

    this.reports = reports;

    }

    publicstaticvoidmain(String[] args) {

    SendReportWorker worker = new

    SendReportWorker();

    worker.sender.sendReport(reports);

    }

    publicvoidsetSender(ReportSendersender) {

    this.sender = sender;

    }

    }

    这样，发送消息的工人类可通过设置ReportSender的实例来灵活设置其发送方式。

    同样，中间件的清点命令下发，即中间件与阅读器之间的接口，也存在多种方式，如Socket、SOAP等，也可采用类似的设计。

    3.5观察者模式处理上报消息

    阅读器的消息上报转换为消息对象，对消息对象的接收、分发可采用经典的观察者模式实现。

    4  中间件发展方向

    4.1与阅读器管理系统的融合

    中间件是阅读器与后台应用系统之间的桥梁，而阅读器通常有设备管理需求，比如软件版本下载、设备告警管理、参数配置等等，阅读器管理系统也是直接与阅读器交互的软件模块。于是，如何处理好中间件与阅读器管理系统之间的关系成为一个亟待解决的问题。

    从软件部署(部署在同一台主机上)、软件模块重用(重用阅读器通信模块)等角度考虑，中间件与阅读器管理系统的融合势必成为中间件本身的一个优势。

    4.2对多标准标签的支持

    RFID技术在国内外的发展和应用方兴未艾，国际上多个标准组织都试图统一RFID标准，但在一定的时期内，势必出现多标签并存的情况。于是，对多标准标签的支持也是中间件系统的一个发展方向。

    4.3对多厂商阅读器的支持

    中间件与阅读器之间的接口、通信方式以及信息格式，也无法做到统一标准。对多厂商阅读器的支持、至少对少数几家主流厂商的阅读器的支持，已经是对中间件所提出的基本要求。