一种基于云端服务器的可重构RFID中间件设计方法

摘要

本发明提供了一种基于云端服务器的可重构RFID中间件的设计方法：利用EPCglobal规范抽象出RFID中间件各个模块功能，同时确定能够对外提供功能扩展的服务模块，进而利用OSGi技术将各个模块构件化；同时由于做RFID上层引用需要用到SSH三个第三方框架，所以需要将SSH三个框架构件化，利用OSGi总线添加至OSGi容器中供RFID应用利用。接着将所有构造好的构件整合到Virgo服务器中各自的仓库，使得基于构件的RFID上层应用能够在Virgo下搭建并且运行；最后采用开源的Cloud Foundry框架，将带有RFID中间件和SSH三个框架功能的Virgo服务器整体整合到Cloud Foundry中，从而实现基于云端服务器的可重构RFID中间件的设计方法。

说明书

技术领域

本发明属于RFID中间件技术领域，特别是提供一种基于云端服务器的可重构RFID 中间件方法。

背景技术

目前随着互联网技术走向成熟，物联网技术已经开始兴起，许多中小型企业开始针对 物联网的核心技术——无线射频识别技术(Radio Frequency Identification，RFID)做相应的 应用。但是由于作为RFID应用的关键组成部分RFID中间件目前还没有一个统一的规范，所 以许多中小型企业要想进行RFID应用开发，都需要自己去寻找RFID中间件规范，并且实现 从底层阅读器到上层应用的所有环节，其中最主要的就是RFID中间件。

RFID中间件是连接底层阅读器和上层应用的桥梁，通过它能够屏蔽底层阅读器类型 的差异而向上层应用提供从阅读器获取的数据，同时上层应用程序利用RIFD中间件提供的 接口向底层阅读器发送命令控制阅读器的相关读取状态，而不需要关心阅读器的类型差别。 因此RFID中间件的功能的强弱、可扩充性能力的大小等系列指标将决定着RFID应用开发的 难易和效率的高低。

通过相关调查发现，目前大部分从事RFID应用开发的中小型企业都是基于公司内部， 每进行一个项目的开发都需要为该项目定制一套完整的RFID中间件来满足需求，从对RFID 中间件规范的选取到完全实现将会需要花费企业很多的人力、物力和财力，这样将会很大程 度上制约企业的开发效率。同时，企业与企业之间由于规范的选取不同，将导致资源共享、 交流困难，使得RFID应用发展缓慢。

其实，每个企业都不需要太注重于对RFID中间件的实现，企业只需要关注自己的RFID 上层应用，而对于RFID中间件可以提升至一个公共的服务场所，以一种服务的形式提供给 所有企业，所有的企业都可以共享、甚至必须的时候可以扩展该RFID中间件服务，从而借 助众多中小型企业的资源来迅速扩展RFID中间件的功能，促使RFID应用更加快速的发展。

发明内容

本发明的目的在于提供一种基于云端服务器的可重构RFID中间件的设计方法。

为了实现上述发明目的，采用的技术方案如下：

一种基于云端服务器的可重构RFID中间件的设计方法，包括如下步骤：

1、选取EPCglobal作为RFID中间件实现规范，通过仔细研究实现规范来准确划分RFID 中间件的各个功能模块，这样可以明确的定义出哪些功能模块能够在以后的应用中继续扩展， 从而做成接口对外一种服务提供。

2、OSGi规范是当今进行基于构件的软件开发(Component-Based Software  Development，CBSD)一种很好的实现方式。所以利用OSGi技术将(1)中的各个功能模块构 件化成为Bundle，同时采用OSGi技术中的DS方式将RFID中间件中的功能能够扩展的相关 模块做成服务对外发布，从而供其他模块获取来扩展功能。

3、通过对Struts、Spring、Hibernate三个框架整体分析，并利用相关构建仓库，获取 到他们对应的所有构件，使得基于SSH三个框架的构件化Web应用能够利用到第三方框架的 功能。

4、将Struts、Spring、Hibernate三个框架的构件整合到Virgo服务器的核心仓库中，扩 充Virgo服务器对基于SSH应用的运行。

5、将RFID中间件的实现的所有构件整合到Virgo服务器的用户仓库中，从而所有进 行RFID应用开发的开发者都可以利用Virgo服务器下的RFID中间件和第三方框架SSH来构 件自己的应用，同时直接在支持构件化应用的Virgo服务器上运行。

6、利用Cloud Foundry云端平台，将整个整合了SSH构件和RFID构件的Virgo服务 器移植到Clouds Foundry中，这样每个拥有Cloud Foundry用户账号的开发者都可以直接提取 RFID中间件服务来构建自己的应用，同时将自己的应用移交至Clouds Foundry中运行，这样 可以利用Cloud Foundry中的云计算特点。

本发明让企业摆脱对进行RFID应用开发时受限于RFID中间件实现环节的困扰。通 过以一种服务的方式将RFID中间件提升至云端服务器，从而使得企业可以迅速利用RFID中 间件服务来定制自己的RFID应用，提升开发效率，降低生产成本；同时企业可以扩充RFID 中间件服务，进而提交至云端服务器供从而使得其他企业有更多的可选择余地，从而逐步扩 充RFID中间件的功能，促进RFID应用的快速发展。

附图说明

图1RFID中间件在RFID应用中的作用；

图2RFID中间件架构；

图3统一设备管理层的功能模块划分；

图4ALE层功能模块划分；

图5整体RFID中间件在RFID应用中的架构；

图6Virgo服务范围划分；

图7云端RFID中间件架构；

具体实施方式

[0022]下面结合附图对本发明做进一步的说明。

通过图1可以观察到RFID中间件起着连接底层阅读器和上层Web应用的桥梁，通过 不断的向RFID中间件中添加其他附属功能如：WMS、ERP等，则能够逐步的扩展RFID中 间件的功能，从而不断的壮大RFID应用的开发。本发明选取EPCglobal作为RFID中间件规 范，来细分出RFID中间件的各个功能模块。

一、RFID中间件功能模块的划分

本发明的RFID中间件如图2大体分成两层：ALE层和统一设备管理层。

统一设备管理层：统一设备管理层的阅读器层主要负责操纵各种类型的RFID阅读器， 通过提供一个统一抽象的AbstractReader接口则可以屏蔽掉阅读器的实际类型，而规定一组 统一的操作。同时将其做成为服务向外提供，则任何RFID应用开发者只需要利用该服务便 可以实现跟自己具体阅读器类型相关的操作。统一设备管理层的消息层则负责从阅读器层获 得从具体阅读器读来的数据，并进行相关解析送至统一设备管理层的传输层。然而数据的格 式有各种类型，比如text、xml等，为了能够准确的解析到以各种不同格式出现的数据，同样 需要在消息层中定义一个统一的ReportParser接口，从而便于以后任何格式文件的消息解析 都能够得到扩展。另外该层需要从ALE层接收来自对底层阅读器的操作命令和向上层ALE 提供对命令所作出的回应，于是需要定义CommandParser和ReplyParser接口作为服务向外提 供，便于利用和扩充。一旦获取到从底层阅读器获得的数据并且经过解析后，就需要向上层 ALE层发送数据，这就需要用到统一设备管理层的传输层，而根据目前的传输协议知道有TCP 和UDP，为了根据各种RFID应用的不同需求，在这个层次也需要定义一种抽象的接口既能 够适应TCP和UDP的传输方式，同时也便于更多的其他传输的形式的扩展。具体的统一设 备管理层的模块划分参考图3。

ALE层：ALE层负责获取从设备管理层获取的RFID阅读器中的消息，经过过滤、筛 选、最终向上层应用程序提交有用的数据。ALE层的ALE处理层提供了数据处理的一系列算 法，同时提供一个Configuration接口来进行对整个RFID中间件的属性配置，通过它来接收 来自底层统一设备管理层的消息，同时做出相应的处理，再提交自ALE消息层。ALE消息层 同样需要定义ReportParser接口来提供统一的解析底层阅读器消息的操作，任何其他形式的 解析方式都可以通过该接口来得到扩展。同时该层像统一设备管理层一样需要接收来自上层 应用层发送来的对底层阅读器进行的操作，所以需要定义CommandParser和ReplyParser接口 来针对不同形式的命令给予不同形式的回应。最后ALE层的传输层与统一设备管理层相似， 需要定义一个统一的接口来规定传输的操作方式，ALE层的功能模块划分参考图4。

通过对EPCglobal规范的一系列研究后，最终将RFID中间件的整体功能模块划分确 定为如图5所示。

二、RFID中间件功能模块的构件化

1、为了能够很好的将RFID中间件中的模块化思想体现出来，本发明利用基于构件化 编程的OSGi规范实现Equinox来进行RFID中间件的实现，在Equinox中每个模块都被构建 成为Bundle，而由于每个Bundle都会有各种不同的生命周期，所以一旦不需要某个模块则可 以直接将该模块对应的Bundle生命周期通过OSGi框架结束掉，同样如果需要添加其他的功 能模块则只需要启动一个对应模块的Bundle生命周期即可以添加到OSGi框架中，这样可以 很好的实现整个RFID中间件的功能重构。

2、为了能够很好的利用和扩展RFID中间件的相应服务，需要利用到OSGi中的DS 方式来将RFID中间件中的相应模块做成服务。如：ALE层中的ALE处理层中需要定义一个 Configuration接口来统一管理配置文件信息。则首先需要在Equinox中构建一个Bundle，该 Bundle下有一个含有接口Configuration的包，并且通过Bundle特有的MANIFEST.MF文件 将含有Configuration的包导出。则任意一个需要扩展该服务的模块Bundle则首先需要通过 MANIFEST.MF将Configuration包导入，同时需要在Bundle目录下建立一个OSGI-INF的文 件夹，添加如下的XML文件：

3、同时任意一个需要利用Configuration服务的模块Bundle则需要首先在 MANIFEST.MF中导入Configuration包，同时在Bundle根目录下建立一个OSGI-INF文件夹， 加入如下XML配置文件：

通过OSGi技术便能够将(一)中确定好的RFID中间件模块完全构件化成为Jar形式的 Bundle，同时通过DS方式便可以实现RFID中间件的服务获取和服务功能扩展。

三、SSH框架构件和RFID中间件构件与Virgo服务器的整合

通过对Struts、Spring、Hibernate三个框架的整体运行架构流程进行分析，分解出框架 的模块信息或者直接将框架已有的Jar包进行构件化，便可以得到三个框架的所有构件，同 时也可以借助于Springsource开发的Enterprise Bundle Repository构件库来直接获取相关构 件，一旦获得了SSH框架构件后，所需要的基础构件和进行RFID应用开发的RFID中间件 构件都已经准备就绪。接下来就需要将这些构件整合到Virgo服务器中，方便应用的快速开 发和运行。

通过观察图6Virgo服务范围的划分，可以知道Virgo服务器提供Kernel服务范围和 User服务范围。通过对这两个服务范围的深入了解，发现Kernel部分提供的是最核心的、支 撑Virgo稳定运行的服务，比如OSGi中构件的动态加载、删除、运行等；该部分服务一般都 是不允许用户进行随便的更改的。而User则是提供给用户进行应用开发时动态的添加应用所 需的依赖的，一般用户可以针对不同应用的依赖进行添加至User中，该服务范围具有很大的 变化性，一般不会对Virgo核心部分照成很大影响。

由于SSH三个框架是大部分J2EE开发所需的第三方依赖，一般不会有太大的变动， 因此决定将SSH构件添加至Virgo服务器的Kernel服务范围中给开发者提供服务。该步所做 的事情相当于将Virgo服务器的核心功能进行扩展，实现该过程需要分两部分：首先，需要 将SSH构件添加至Virgo根目录下的repository下的ext目录下，这样便保重了Virgo的扩展 SSH核心服务所需构件已经就位。然后，需要对Virgo根目录下config目录下的

org.eclipse.virgo.kernel.userregion.properties文件进行修改，修改格式如下：

InitialArtifacts＝repository:bundle/构件名称；plan/构件名称；

如果添加的构件是Bundle则利用bundle+Bundle的唯一标识符；如果添加的构件是plan 则利用plan+plan的唯一标识符。

将SSH添加至Virgo核心服务区域后，接下来便是需要将RFID中间件添加至Virgo 的用户服务范围中，这样不同用户根据自己的RFID应用开发随时添加RFID中间件和扩展 RFID中间件功能而不影响Virgo核心服务的轻易改动，从而在保重具有可扩展的同时具有高 度稳定性。将RFID中间件添加至User服务范围的方法是：将所有RFID中间件放到Virgo 根目录下的repository下的usr目录下即可。

四、将Virgo服务器做成服务添加至Cloud Foundry云端

随着云计算兴起，许多大型IT企业纷纷开始针对云计算推出自己的相关应用。通过对云计算 的了解发现，云计算最终的目的是将连入网络的所有资源作为服务供网络上的用户使用。云 计算的这个特点很适合将整合后的Virgo服务器发布至云端作为服务，这样所有进行RFID应 用的开发者都能够通过云端获取该服务，同时也可以将自己的扩展服务发布至云端供开发者 共享，这将大大推动RFID应用开发向前推进。

通过对Cloud Foundry的研究发现，Cloud Foundry是一个免费的云端服务平台，该平 台上已经发布了MonoDB等框架服务。一旦将Virgo服务器做成为服务上传至Cloud Foundry， 最终实现迅速开发RFID应用的目的，如图7所示。