3.2门面模式、工厂模式对外部暴露API接口
为了避免后台应用系统，即中间件的客户端过分耦合，采用门面模式（Facade）对系统内部、外部实现清晰的隔离。处理流程可参见图6所示的序列图。客户端仅仅与Facade类建立联系，如果Facade接口定义得足够清晰，客户端可以对中间件的内部实现一无所知，这体现了面向对象中的封装性。
类的设计参见源代码示例，从中可以看出，采用简单工厂模式（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）;
&nnbsp; ｝
工厂类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｛
& nbsp; 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;
&
nbsp; 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对多厂商阅读器的支持
中间件与阅读器之间的接口、通信方式以及信息格式，也无法做到统一标准。对多厂商阅读器的支持、至少对少数几家主流厂商的阅读器的支持，已经是对中间件所提出的基本要求。
