基于中间件技术的讨论

基于中间件技术的讨论（精选七篇）

基于中间件技术的讨论 篇1

1 物联网

1.1 物联网规范

物联网系统比较复杂, 主要由电子标签、ALE中间件、EPC信息服务、ONS对象名服务及RFID识读器等软硬件组成, 涉及到计算机网络、RFID、EPC信息等多个技术领域。

(1) 电子标签

EPC电子标签1.0版本规定了标签内的数据结构和格式 ,可以对标签的头字段进行识别, 描述其头字段定义的位分区。

900MHZ Class 0标签协议将规范划为计划实施标准、接口和指令集的定义、 说明书的程序描述、测试说明和未解决的问题等5部分; 860MHZ-930MHZ Class 1标签协议规范了在频率范围内射频的通信接口及解决器的功能性需求。

(2) ALE中间件

ALE规范定义了一组没有具体实现功能的接口 , 其中RFID中间件的一个基本功能就是支持ALE规范。

(3) EPC信息服务

EPC相关数据的共享使得系统内部和企业之间的信息达到共享, EPCIC (EPC信息服务) 规范主要描述了自身在物联网中的作用和功能, 设计服务的系统框架, 给出具体的技术绑定建议。

1.2 物联网系统

整个物联网系统的核心模块主要由EPC编码体系、EPC信息服务软件、EPC标签、对象名解析服务、识读器和ALE中间件等6部分组成。

物联网对数据的处理分析过程将物联网系统划分为应用层、网络层和感知层, 具体的体系结构如图1所示。

如图1所示, 应用层是应用服务子层, 用于各行业之间信息的共享和协同工作, 包括: 数字农业、智能电力、远程医疗等; 网络层位于中间层, 其主要作用是保障数据的安全可靠传输, 主要依托互联网、卫星通信网、有线电视网等;感知层是整个系统的底层, 对现实世界进行信息的采集。

1.3 物联网的安全

对于物联网的安全问题主要分类两类, 一类是对RFID标签及识读器通信的安全; 另一类是RFID后台网络的安全。

RFID标签及识读器通信的安全可以采用AES算法对其进行交互认证的模式来解决, 具有成本低、效率高、便于实现的优点; 还可以利用WINI技术设计中间件系统的模式来完成。对于RFID后台网络的安全主要分析整个体系中ONS存在的风险, 并与VPN技术充分相结合来保障安全; 另外还可以通过DNS扩展的模式来加强ONS系统的安全。

2 信息交互中间件设计

2.1 EPCIS 服务

EPCIC的设计按层次可以分为服务层、数据定义层和抽象数据模型层。

(1) 服务层

服务层主要完成接口定义, 可以用来捕捉数据、查询数据和控制查询等功能, 通过接口的形式与客户端进行交互。

(2) 数据定义层

数据定义层主要是对抽象数据模型层数据进行明确的定义。

(3) 抽象数据模型层

EPCIS主要处理的数据有事件数据和高级数据两种。其中事件数据主要体现业务的流程, 可以通过查询接口查看; 高级数据是事件数据的有效补充。

在对EPCIS的设计中, 对于数据的捕获是非常重要的,由于整个系统数据的发送方是ALE, EPCIS作为接收方收到的是由ALE经过XML封装后的原始数据, 要对其时行XML解析才可以查看发送的内容。因此, 该模块主要由ALE监听模块、数据处理模块组成, 其中核心代码如下所示:

2.2 ONS 服务器

对象名解析服务 (ONS) 的作用是将一个EPC映射到多个或一个URI上, 利用URI可以找到关于所查找物体的具体信息。ONS系统是分层次的, ONS系统由本地ONS服务器、ONS服务器、ONS根服务器组成。其查询步骤如下: 首先内部网用户先对本地ONS主服务器进行请求, 假如该服务器上有其相关的信息, 则把URI直接转换为合法的DNS格式, 否则查询本地ONS从服务器; 如果本地无法找到相关的记录,则通过互联网络或VPN线路将其信息传至ONS服务器, 返回其DNS记录, 否则再将其信息向ONS根服务器转发, 直至找到相关的记录信息, 并将结果返回给内部网中的客户, 返回时, 所经过的各级ONS服务器将记录该信息。具体的查询过程如图2所示。

ONS的算法过程是将二进制的EPC编码首先转化为八进制数据, 在数据头加上“um:epc:”, 将生成的URI信息进行本地存储, 将URI格式通过清除“um:epc:”和EPC序列号、颠倒数列并附加“.onsroot.org”的方式转换为URL, 最后将URL返回给本地的ONS主服务器进行搜索。

3 物联网信息交互系统

3.1 需求分析

物联网信息交互系统的主要是包含独立的EPCIS模块和ONS模块。对EPCIS和ONS的设计已经进行了详细的分析 ,在此所设计的信息交互系统主要是实现本地各个EPC系统的之间的交互, 完成信息共享的要求。

3.2 系统功能模块

EPC系统主要是在ONS和EPCIS模块的进行应用实现 ,因此整个系统要具有EPCIS事件监听模块、即时查询模块、ONS查询模块和定制查询模块等。除了上述模块外 , 还需要有RFID中间件, 系统的功能模块结构如图3所示。

3.3 具体实现

在整个系统中, 对于数据的监听和查询是最核心的内容,即时查询模块要对数据进行查询之后进行捕捉, 并存放数据库中进行持久化。其核心代码如下所示:

4 结语

基于中间件技术的讨论 篇2

开放统一的OPC(OLE for Process Control)接口为多平台多设备的接入提供了标准,但目前的OPC接口大多只限于本地或局域网内的监视和控制,2004年底,OPC基金会正式颁布了基于Web的OPC可扩展标记语言XML(e Xtensible Markup Language)数据访问DA(Data Access)标准,为远程监控系统的实现提供了技术依据[1]。由于工业自动化领域中针对OPC DA的Web访问较少,少数系统的实现采用通过构建第三方数据库,然后针对第三方数据库建立自己的数据设置程序,再利用Flash或者单纯地利用动态服务器页面ASP(Active Server Page)技术对第三方数据库操作来实现数据的读取或写入,此种方式构建繁琐,延时长,安全性和扩展性差,目前大多停留在对实时性要求不高的数据查看功能上。

本文利用OPC XML-DA规范[2],设计和完成了以中间件为基础的OPC XML-DA数据结构,并给出了具体实现步骤和方法。安全方面的考虑也是本文着重论述的部分。

1 系统设计框架

OPC DA可以实现高性能的现场数据交换,XML-DA能解决远程访问和跨平台访问的问题[3]。如果将现有的已经被大量使用的OPC DA通过中间件服务器包裹成XML-DA服务器,这样可以实现Web远程监控的功能[4]。

系统实现的关键是在中间件设计和Web服务器设计这2个环节上。其中,中间件完成的功能就是将数据从OPC DA服务器上采集,并将其传送到Web服务器上,而Web服务器完成数据的发布[5]。具体的设计思想是先设计OPC Client,将OPC DA数据读取出来,然后用简单对象访问协议SOAP(Simple Object Access Protocol)封装和用户数据包协议UDP(User Datagram Protocol)传输到Web服务器上。Web服务器将数据接收过来解析出SOAP消息里的数据信息,并用互联网信息服务IIS(Internet Information Services)发送到Internet上。数据传输框架见图1。

本文中,将整个数据传输系统分为4层,分别为数据源层、中间件服务层、Web服务层、Web客户表示层。其中数据源层和中间件服务层通过COM接口传输数据,中间件服务层和Web服务层通过UDP传输SOAP包交互信息。Web服务器中开发ASP通信组件,提供接口与Web客户端通信。

1.1 数据源层

数据源层由数个OPC DA服务器构成,主要包括可编程逻辑控制器(PLC)、数字仪表、分布式控制系统DCS(Distributed Control System)及各种现场设备等。这些物理设备取得现场数据后,通过OPC服务器,按照统一开发的标准,以组件对象模型/分布式组件对象模型(COM/DCOM)封装接口供OPC Client操作数据。

1.2 中间件服务层

中间件服务层实现2个功能:第一是通过COM/DCOM接口与OPC DA服务器进行数据交互;第二是将采集的数据传送到Web服务器。这里将中间件层服务器分为3个层次:OPC Client层、SOAP数据封装层、UDP通信层,下面说明它们的具体功能。

a.OPC Client层是客户端从底层控制系统服务器获取服务器的状态信息,获得现场的实时数据。现场的服务器根据原理可有3种形式存在:进程内服务器、本地服务器、远程服务器。必须能够与各种情况下的服务器进行通信。与底层服务器的通信包括同步读写、异步读写、数据订阅及获取服务器运行状况等信息。

b.SOAP数据封装层。一是将OPC Client层取得的实时数据以SOAP形式封装并发送到UDP层,二是将从UDP数据层收到的来自Web客户端的SOAP包进行解析。

c.UDP通信层。一是向Web服务层发送SOAP响应包,二是接收Web服务层SOAP请求包。

1.3 Web服务层

Web服务层实现2个功能:一是与中间件服务层进行数据通信,二是与Web客户端进行数据通信。Web服务层分为3层:UDP通信层、SOAP解析层和IIS服务层。

a.UDP通信层:一是接收从中间件服务层发送过来的SOAP响应包,二是向中间件服务层发送SOAP请求包。

b.SOAP解析层:一是将UDP通信层的SOAP响应包解析为Html格式发送到IIS服务器[6],二是将Web客户端的请求封装为SOAP请求包传递给UDP通信层,由UDP通信层发送到中间件服务层。

c.IIS服务层:实现了与Web客户端的数据交互。

1.4 Web客户表示层

Web客户表示层为网络用户提供网页浏览,用户可通过各种类型的浏览器连接Web服务器获取数据。

2 中间件服务器的通信方式

中间件服务器层是非常重要的一层,它完成2个重要的通信结构,即和Web服务器的通信功能以及和底层OPC DA的通信过程。在本设计中,和Web通信的任务交给UDP组件,和OPC DA服务器的通信功能交给OPC Client组件,另外还有数据打包和解包的过程,这里称为SOAP解析层[7]。

2.1 UDP通信方式设计

从图1可以看出,UDP通信层在这里是起到IIS服务层和中间件层通信的作用,建立UDP连接后传输SOAP包信息。

UDP就是“用户数据报协议”,它是一种无连接的协议,与具有连接的传输控制协议TCP(Transmission Control Protocol)相比较的。当利用TCP传送数据时,必须先建立连接后才可以传输数据。而当计算机利用UDP进行数据传输时,发送方只需要知道对方的IP地址和端口号就可以发送数据,而并不需要进行连接。

UDP是一种不面向连接的网络协议,既有其优点,也有其不足,下面进行具体分析。

a.基于UDP的网络应用程序实现比较简单,并且基于UDP的网络应用程序在运行时,由于受到环境影响较小,所以不容易出错。

b.UDP占用网络资源较少,数据处理较快,所以在网络中传送对安全性要求不是十分高的数据时,其优点比较明显。所谓对安全性要求不高的数据,是指那些不重要的数据,或者是即使丢失若干数据,也不影响其整体的数据。

c.由于UDP不是面向连接的网络协议,其缺点也是非常明显的,有些时候甚至是致命的。因为使用UDP来传送数据时,在数据发送后,在发送方并不确认对方是否接收到。这样就可能导致传送的数据在网络中丢失,尤其在网络条件并不很好的情况下,丢失数据包的现象就更多。所以传送重要数据一般不采用UDP。

综上所述,与TCP相比,本文采用UDP做设计方案,为了弥补UDP的由于无连接性造成的安全性问题,采用了XML扩展标记校验和数据校验[7],即判断每个接收到的SOAP包是否符合预先定义好的格式,如果符合则解析,否则丢弃该SOAP包并通知对方重新发送请求[8]。

经过实验证明,采取UDP通信方式简单快捷,添加了校验环节后,数据的可靠性也大幅增强。数据校验示意图如图2所示。

2.2 UDP通信数据类设计

本文采用Visual C++实现UDP,其中最关键的类就是UDP Client,UDP Client位于命名空间System.Net.Sockets中,Visual C++发送、接收UDP数据包都是通过UDP Client类实现。表1是UDP Client类中常用方法和属性及其简要说明。

3 OPC客户端设计

OPC客户端主要完成的功能:完成SOAP解析层解析出的数据请求,具体是连接OPC服务器,可以要求读取请求点数据或者将数据写入请求点。如果收到的SOAP包为Web客户数据读取请求,则根据解析出请求的Item从OPC服务器中读取出相应Item的点位值。如果收到的SOAP包为写请求包,则根据解析出请求的Item,并判断该Item是否可写,如果可写则向服务器写入数据,并将数据返回到Web端,如果该Item不可写,则发送错误信息给SOAP封装层。结合SOAP封装解析层和OPC客户端层,其流程如图3所示。

当解析出SOAP包的具体要求后,就该建立OPC客户程序访问OPC服务器,实现SOAP包所请求的内容。OPC客户端访问服务端的过程实际上就是一个典型的客户访问进程外组件的过程。

4 Web服务器COM通信组件设计

ASP页面位于Web服务器,当Web客户端访问时,装载访问页面后,就将预先注册好的ASP通信组件这里命名为“ASPOPCObject”COM组件装载,然后判断当前页面是否得到ASP命令,根据命令内容对ASP通信组件进行方法调用,流程如图4所示。

图4中,对于OPC DA点位数据都从ASP通信组件提取,这里把响应标准OPC XML标准方法和接口都定义在同一个COM组件中,用户需注册后才能使用ASP访问。

针对隐含的标志确定是否为写值请求,如为写请求,则调用标准的writeresponse方法向中间件发送写数据请求,本文定义了ASP通信组件中的writeresponse方法实现数据请求。

在实时页面中,用户需调用的ASP通信组件中自定义的订阅数据[9]方法subscript Request订阅数据,函数调用过程如下:

当用户需要临时查看某些点位的数据,可采用本文定义的ASP通信组件中的读数据方法(data Reques方法)读取数据,函数调用过程如下:

以上的各点返回值以“,”分开,用户可用Spli函数进行处理,将各个具体点位值各自分开。

为了方便用户检查数据操作时间,本设计中的ASP通信组件还提供了Get Interval Time和Get SetTime接口,可检查总写点位的时间和读点位的时间以及中间件读写时间,具体的调用方法如下:

以上介绍了ASP通信组件的功能和接口,这些功能和接口按照OPC XML-DA标准定义,方便客户端的使用以及程序的再扩展。

5 测试数据分析

为了分析中间件服务和Web服务器的性能[7],对它们的时间响应做了分析。图5中的数据是当中间件服务和Web服务器位于同一台计算机上测得的。图6中的数据是当中间件服务和Web服务器位于不同计算机上测得的(图5、6中,n为测量次数;曲线1、2、3、4分别为写入总时间、中间件写时间、读值总时间和中间件读时间曲线,数值与表2、3相对应)。表2和表3是利用本文组件中的提取CPU的主频时间设计的精确至微秒级别的时间记录(表中,t1、t2、t3、t4分别为写入总时间、中间件写时间、读值总时间和中间件读时间;下同)。

从图中的实验数据可得出以下分析结果,各曲线标准方差及期望如表4、表5所示。

根据以上数据可得出4点结论。

a.由于写入点位为1位Item,故在中间件对OPC DA操作上对1位Item的写操作比8位Item的读操作时间要少,如表3中提取的数据中,读操作平均花费时间16722μs,写操作平均花费时间9418μs。

b.从实测数据的数字特征可看出中间件读写操作用时都比较平稳,而经过网络传输后写入总时间和读值总时间数据分散较大。这是由于中间件对OPC DA的操作是采用单线程联系的,所以数据连接比较平稳,相比UDP通信由于通信信道和网络环境的关系所以数据传输不稳定。所以数字特征反映了实际的网络传输情况,与预测相符。

μs

μs

μs

μs

c.写入总时间的期望要大于读值总时间,可看出,由于读出的是8个点,其传输的SOAP包要略大于写入值的SOAP包,故造成了期望的差别。

d.根据表4和表5的数学期望值可看出,Web服务器与中间件在机器上的独立与否与操作时间没有较大关系,UDP通信层时间主要在于UDP对数据的打包上,在网络上的通信时间较少。这就为更安全更方便地构建分布式的Web OPC系统提供了支持。

6 安全措施

本文提出了一种最新的针对Web客户端访问的多重安全隧道构架,该安全隧道采用多重安全措施,很好地考虑到了速度和安全上的互补。

6.1 IIS安全设置

系统采用了Web服务器中构建ASP通信组件,结合ASP.NET环境下的安全性配置,利用ASP通信组件中的UDP通信接口与中间件通信。通信组件提供的IP筛选接口将符合要求的客户端过滤出来,不符合要求的客户端无法访问。所提出的中间件服务器和Web服务器是通过UDP传输数据的,而UDP具有无连接性的特点,不能保证数据传输的完整性,提出采用2次校验方式对接收到的SOAP包进行校验。在XML文档中定义一个数据校验元素,这个元素包含了数据包长度信息和数据类型信息2个子元素。数据传到对方后,先提取出数据长度信息,验证通过后再比较数据类型信息。二者都通过验证方可进行下一步操作,2次数据校验极大提高了数据传输的安全,弥补了UDP快速但容易丢包的问题。在实验中还未发现错包现象,且经过千次记录,最大响应时间<50 ms,完全满足工业控制的需要。

6.2 IP用户筛选

系统采用2种方法对请求数据的用户身份进行判断,第1种是对用户发送的SOAP包的用户身份进行判断,第2种对向中间件发送UDP通信包的Web服务器进行IP地址的筛选,符合要求通过并由中间件向OPC DA请求数据并将得到的数据进行SOAP打包,然后回应发送请求数据的Web服务器正确的数据。

6.3 中间件数据校验

同Web服务器上构建的ASP COM组件采用2次校验类似,在中间件上对UDP服务接口接收到的SOAP也采用2次校验,第1次对XML标记逐条判断,第2次对接收到的SOAP包的大小和从SOAP包中的数据长度标记进行比较,相符则通过。2次校验可确保对错误数据的检测,防止对OPA DA的错误动作。

6.4 中间件与OPC DA的连接

COM连接,对于中间件与OPC DA位于同一机器,可采用内进程与外进程2种形式与OPC DA建立连接,其中内进程为动态连接(DLL)库形式存在,在客户程序的内存空间内运行。由于DLL形式可视性和控制性较差,故采用本地外进程设计中间件。外进程以可执行程序(EXE)形式存在,有独立的地址空间,通过远程过程调用协议RPC(Remote Procedure Call protocol)与客户程序通信。本文采用控制方便的EXE程序,通过友好的用户交流窗体进行控制。

如果用户需要将中间件与OPC DA分离,可采取分布式COM对象(DCOM)同本地外进程COM对象连接,由于DCOM必须使用RPC远程调用,且采用多种安全措施,所以DCOM的速度只有COM的万分之一,且安全性高,如果用户在安全性高和速度要求不高时可采用DCOM[8]。

传统的COM设计有统一的接口调用方式,客户程序无法知道COM对象的位置,这种方式对数据的安全造成了隐患,为防止错误发生可在接口设计中加入如所提供的UDP客户身份认证接口或采用用户通信包密码认证方式实现数据安全。

7 总结

本文将局限于局域网使用的OPC DA服务器转换成可以在广域网使用的OPC XML-DA服务器,实现基于Web的监控系统。首先,研究了OPC DA协议和OPC XML-DA协议[4],比较了它们的优缺点,提出了将OPC DA转换成OPC XML-DA服务器的可行性,并且给出了设计框架。将整个系统分成OPC DA层、中间件服务层、Web服务层、Web客户端层。详细分析了中间件服务层和Web服务层的具体功能并给出了实现方法。在安全性方面,用XML数据校验和IP地址筛选等方法保证了系统的安全性。将Web服务器通过UDP于中间件进行机器分离,这种方式解决了COM访问易受病毒攻击造成不安全的问题[8,9],并采用了双重数据校验来增强系统的安全性,从而兼顾了数据处理速度和安全。

本文提供了大量的时间响应数据,并对这些响应数据进行了详细的分析,得出系统高可靠性和实时性结论。

摘要：提出了基于OPC中间件技术的设计框架,系统分成OPC DA层、中间件服务层、Web服务层及Web客户表示层;采用用户数据包协议(UDP)通信方式在各层间传递SOAP数据包。研究并比较了OPC DA协议和OPC XML-DA协议的优缺点,分析了中间件服务层和Web服务层的具体功能并给出了实现方法。在安全性方面,论述了XML数据校验和IP地址筛选等方法。通过对系统测试数据的分析得出设计出的系统能够满足实际监控需要。

关键词：OPCXML-DA,SOAP,中间件,Web服务端

参考文献

[1]OPC Foundation.OPC DA 3.0 specification[EB/OL].2007-05-15.http∥www.opcfoundation.org.Downloads.aspx?CM=1&CN=KEY&CI=274&CU=4.

[2]张云勇,张智江,刘锦德,等.中间件技术原理与应用[M].北京:清华大学出版社,2004:42-60.

[3]李善宣.OPC技术在工业控制系统中的应用研究[D].成都:西南交通大学系统工程学院,2003:41-43.LI Shanxuan.Application of middleware OPC technology in in-dustrial control system[D].Chengdu:Southwest Jiaotong Univer-sity,2003:41-43.

[4]杨清宇,施仁.多总线混合分布式网络控制系统研究[J].小型微型计算机系统,2004,25(5):934-937.YANG Qingyu,SHI Ren.Research on multibus,mixed distributednetwork control system[J].Mini Micro Systems,2004,25(5):934-937.

[5]阳宪惠.开放工控系统的中间件——OPC技术[J].自动化博览,2002(2):6-8.YANG Xianhui.The middleware in open industrial control sys-tem-OPC technology[J].Automation Panorama,2002(2):6-8.

[6]任小林,桂仕伟,吴祈宗.基于XML的Web信息发布系统及其J2EE实现[J].计算机应用,2003(10):48-50.REN Xiaolin,GUI Shiwei,WU Qizong.XML-based Web infor-mation publication system[J].Computer Applications,2003(10):48-50.

[7]MI Yauchi.XML signature/encryption-the basic of Web servicesecurity[J].NEC Journal of Advanced Technology,2005,2(1):3-5.

[8]潘爱明.COM原理和应用[M].北京:清华大学出版社,2006:45-46.

基于中间件技术的讨论 篇3

当前企事业单位一般都建有完善的基于传统互联网的OA系统, OA系统为企事业的发展起到了很大的推动作用。在移动互联网如火如荼的今天, 移动互联网和移动终端设备处理能力的增强, 极大推动了工作人员对移动业务的需求。企事业单位的管理者希望能在任何情况下, 无论是在商务旅途中还是在去公司的路上, 都能对企业业务流转情况和关键数据信息了如指掌, 尤其需要能够及时处理紧急事件;管理者和工作人员也希望能够利用手机这样的方便携带且电池续航能力较强的设备随时随地处理业务。

但是, 对很多企事业单位来说重新开发一套新的OA系统来支持移动互联网并不划算。首先他们的基于PC端的OA系统功能已经比较完善还不需要大规模升级, 再次一套新系统的开发往往要经历比较长的开发和测试周期, 影响公司正常业务不说还要额外负担很多的人力物力。

鉴于以上情况, 本文提出一种中间件模型将传统基于PC的OA系统拓展到手机等移动终端, 可以在原OA系统不需要做任何改变的基础上实现移动OA。在这个中间件模型中, 我们设计实现一个中间件服务器, 它负责移动用户到公司原OA服务器之间的会话转化, 即把原PC端呈现的HTML页面, 处理转化成移动终端可以查看的页面格式。此中间件具有以下功能和特点:

◇基于B/S架构, 利用移动终端的浏览器来屏蔽硬件系统的差异性 (如Android系统、苹果IOS、Symbian等) ;

◇不维护元数据, 移动用户查看的所有数据均来源于公司原网站服务器, 保持信息的一致性且不产生冗余数据, 便于公司维护;

◇通信服务器功能, 建立中间件与公司原OA服务器之间的HTTP连接, 并维护连接;

◇抓页面, 解析HTML页面并获取数据;

◇文件格式转化及预览, 移动终端能力有限支持的文件格式有限, 为了方便用户查看文件内容把PDF等格式的文件转化成网页格式或者图片格式提供给用户;

◇文件下载。

1 中间件模型设计

1.1 数据的获取和中间件工作模型

手机等移动终端用户通过中间件查看到的数据都源自公司的原OA服务器, 中间件依靠抓页面的方式获取数据[2,3], 而不是访问公司的数据库。从数据来源上说, 原OA系统就是中间件服务器的“数据库”。

采用抓页面的方式获取数据的优点在于:

1.无须过多的了解公司的业务逻辑, 公司的原PC端网站已经把业务逻辑处理好了, 加快开发进度;

2.无须额外数据接口的支持, 即, 移动互联网的业务拓展可以不依赖于公司原网站的支持, 不需要原网站做任何改变, 也几乎不需要公司技术人员提供支持, 增加了开发的灵活度, 节省开发成本;

3.可以在中间件中额外增加安全保障, 增强安全性;

4.更好的保证数据一致性。

中间件工作模型设计如图1:

其中, 中间件服务器的主要功能是负责响应用户的请求, 并转发用户请求给原web服务器, 接收原web服务器的响应页面, 然后解析页面提取数据, 最后把数据封装成手机端可读的页面格式返回给用户。

1.2 中间件模型的工作流程设计

在中间件服务器上, 对应每个已登录的用户, 都需要存储两份会话信息。一份是用户登录到中间件服务器的会话信息, 另一份是中间件服务器代替此用户与原OA服务器之间的连接会话信息 (如果不存储会话信息, 中间件服务器每次请求数据时都要向原OA服务器提供身份验证信息) 。

下面以某高校OA系统拓展实现移动OA为例, 阐述中间件模型的工作流设计。此OA系统是基于传统互联网PC端办公系统, 校方需要实现真正的随时随地办公, 但又不希望改变已有的OA系统 (投入成本高, 若新建系统之后教职工需要重新熟悉系统等) 。OA办公系统的每个用户都有自己特有的主页和资源。

假定高校的原OA系统服务器地址为http://oa.university.com, 建成之后的移动OA系统的访问地址为http://mo.university.com。

●身份验证

很多网站都设置有验证码, 用以防止恶意破解密码。关于如何破解验证码认证不是本文的重点 (而且, 验证码生成策略可以询问公司原OA系统的技术人员, 方便移动中间件服务器跳过验证码认证) 。

中间件服务器不存储元数据, 当然也没有用户的账号信息, 身份验证也是需要转发给原OA系统进行验证[4]。

通过对原OA系统登录页面 (如图2) 的源码分析, 我们发现, 用户的账号信息以POST方式被提交到“http://oa.university.com/user Password Validate.portal”。则, 在移动OA系统中, 收到用户的身份信息后, 中间件服务器以通讯服务器的身份和高校的原OA服务器建立HTTP连接, 把用户账号、密码等信息以POST方式提交到“http://oa.university.com/user Password Validate.portal”, 并接收OA服务器返回的响应页面。通过分析响应页面代码, 即可知道用户身份是否合法。如果验证失败, 则提示用户错误信息并要求重新登录;验证成功则在中间件服务器上记录两份会话信息:用户登录到中间件服务器的会话信息及中间件服务器代替此用户与原web服务器之间的连接会话信息。

登录过程如图3所示。

●资源请求

当用户成功登录系统后, 中间件服务器对用户的资源请求的处理流程如图4。

◇页面资源请求, 是指请求对象为HTML页面的资源请求。

◇URL地址转化模块负责将用户的请求映射为对原OA服务器的请求。

◇HTML页面的抓取, 是指中间件服务器与校方原OA服务器交互, 并获取OA服务器返回的响应页面。

◇远程文件下载, 是指中间件服务器与校方原OA服务器交互, 并获取OA服务器返回的响应文件, 将文件缓存至本地服务器。

HTML页面解析器包括两个功能。第一、获取数据:解析从校方原OA服务器抓取的页面, 获取用户所需要的数据;第二、URL地址转换 (与上面提到的地址转化相对) :中间件抓取到的页面中可能包含超链接信息, 这些超链接都是指向服务器www.oa.university.com的, 手机端用户显然无法直接访问, 所以要把所有指向www.oa.university.com超链接信息更改为指向www.mo.university.com的链接。

2 中间件模型的实现及性能表现

2.1 中间件模型的实现

中间件的实现主要有四个方面:

1) 中间件的通信服务器:

它负责中间件服务器与原OA系统之间的交互, 当中间件服务器收到用户的请求之后, 就利用此通信服务器与原OA系统建立HTTP连接, 向原OA服务器请求资源并获取原OA服务器返回响应。通信服务器的实现可以借助Apache Http Component开源项目中的Http Client来实现[5]。

2) HTML页面解析器:

通信服务器抓取到原OA服务器返回的HTML页面之后, 交由HTML页面解析器解析出用户所需要的数据。HTML页面解析器的实现可以借助Apache的开源项目Html Parser来实现[6]。

3) URL地址转换:

URL地址转换涉及到两个地方, 一是, 用户向中间件服务器请求资源时, 中间件服务器应该能够把用户请求的资源正确转换为对原OA系统的资源请求地址 (通信服务器利用转换后的地址从原OA服务器获取资源) ;二是, 通信服务器从原OA系统抓取到的页面中包含的超链接应该转换为对中间件服务器的超链接。

4) 安全机制

安全机制根据各个公司的安全级别, 可以采用PKI、VPN、CA认证等手段来保证。

2.2 中间件模型性能测试

为某高校实现的移动OA系统, 部署的服务器主要配置如下, CPU (Xeon E3-1220) 双核3.1GHZ, 内存2GB。通过手机浏览器访问http://mo.university.com的测试, 抽取了服务器的日志, 得到中间服务器响应速度和原系统响应速度的对比数据如图5所示, 时间单位是毫秒。

测试数据表明, 基于中间件模型的移动OA的表现相当优秀, 它的响应速度与原系统相差无几 (因为不涉及复杂的流程处理, 也不涉及读数据库) 。

3 结论

基于中间件模型的移动OA, 可以比较好的满足企事业单位对移动办公的要求, 并且不需要公司已部署的OA系统做任何改变, 开发简单高效, 需要投入的人力财力比较少, 节约成本。建成之后的中间件系统, 响应速度相差很少。

摘要：根据中国互联网络信息中心第三十次网络调查[1], 截至2012年6月底, 我国手机网民规模达到3.88亿, 相比之下台式电脑为3.80亿, 手机成为了我国网民的第一大上网终端。随着智能手机、平板电脑等智能终端处理能力的加强, 人们希望可以在移动终端上像在PC上方便地查阅学习资料、处理公务等。自2009年, 国内三大运营商获得3G牌照后, 移动互联网获得了迅速的发展, 通信质量的增强给移动互联网应用的发展提供了良好的基础。但移动互联网还是新生事物, 当前很多的网站都还只是基于传统互联网的应用。本文以OA系统为例, 展示了一种将传统互联网web应用扩展到移动互联网的方法。利用本文提出的方法, 可以在原网站不需要做任何改变, 且几乎不需要原网站做任何技术支持的条件下实现向移动互联网应用拓展。

关键词：计算机应用技术,移动互联网,中间件,移动OA

参考文献

[1]中国互联网络信息中心.中国互联网络发展状况统计报告[OL].[2012年7月23日].http://www.cnnic.net.cn/hlwfzyj/hlwxzbg/hlwtjbg/201207/t20120723_32497.htm.

[2]龚真平.基于HTMLParser的Web文献信息提取[J].软件导刊, 2011, 10 (2) :14-15.

[3]桂林斌.基于HtmlParser抽取动态异构Web信息的研究与实现[J].计算机与数字工程, 2009, 237 (7) :161-165.

[4]张铁头, 马丽霞.使用HttpClient实现基于WEB的第三方登录验证[J].电脑知识与技术, 2012, 8 (12) :2779-2780

[5]The Apache Software Foundation.[2012].Apache HttpComponents[OL]:http://hc.apache.org/.

基于中间件技术的讨论 篇4

消息中间件(Message Oriented Middleware,MOM),消息中间件是专门处理通信逻辑的中间件,它向上为其它应用元素屏蔽通信的复杂性,通过提供通用、一致、简单的应用接口,为程序员隐藏通信协议的异构性和复杂性,从而大大简化了分布式环境中的编程;向下为用户解决各种网络问题,如网络资源的命名、事务管理、安全性、动态资源管理和查找定位等。

1 消息中间件中动态优先数算法设计

1.1 消息优先级

消息中间件提供消息的优先级别,系统中提供五种级别的优先级,按级别从低到高依次分为VERY-LOW-MSG-PRIORITY、LOW-MSG-PRIORITY、NORMAL-MSG-PRIORITY、HIGH-MSG-PRIORITY、VERY-HIGH-MSG-PRIORITY。优先级高的消息插入到发送、接收队列的前部,得到优先处理。优先级别只适用于普遍消息和用户自定义消息,系统消息和主题消息不是通过用户消息发送队列发送,因而没有优先级的区别。

1.2 消息队列中动态优先数算法设计

通过上一节对政务信息优先级的分析,在现有消息中间件优先级确定的基础上引入动态优先数调度算法,克服现有的优先数法中优先值不能改变的缺陷,动态优先数调度法使得消息的优先数在执行过程中可以根据情况而改变。在政务处理过程中进行动态优先数的设置进行消息调度更好的体现政府部门的公平效率性。在消息中间件中的消息优先数确定上采取动态优先数确定的方式。并且消息队列采用多级队列的排列方式。下面是基于动态优先数调度算法的消息中间件算法。

对发送方和接收方的消息按照不同的级别设置几个队列,每个优先数级别设置一个队列,每隔一段时间对消息队列中的消息存入时间进行判断,设定一个时间数,对超越一定时间的消息的优先级进行更改。具体的设计流程如图1所示。

2 算法验证及结果分析

基于动态优先数的消息中间件设计是对现有的消息中间件的静态优先级的改进。动态优先级设计与静态优先级设计相比有很大的优势。其突出优点在于动态优先级的设定体现了消息事务执行的公平性。以政府信息管理为例,政府部门有着不同的级别,那么上级所下达的任务,同级部门所传送的消息,公众在部门所办理的业务这三种消息的级别应该有不同的设置,在消息众多的情况下经过一段长的时间,低优先级的消息不被处理,等待的时间就比较的长。因而不能充分体现政府部门公平,公正的原则。采用动态优先级设置,设定一个时间间隔,当消息的等待时间超越一定的时间间隔后就给该消息的优先级升一个级别。因而动态优先数的设置即照顾到优先级别的高低又考虑到等待时间的长短。下面对静态优先数执行效果和动态优先数执行效果差别做简单的测试分析。

设五个优先级,分别为1,2,3,4,5。假设1的优先级最高,5的优先级最低。用javascript语言生成一百个随机数代表现实情况中各优先级消息发送来的顺序。具体的代码与产生的随机数如下:

下面的程序用于产生1-5的随机数:

连续一百次产生1-5的随机数如下所示:

每一个随机数都代表这一级别消息传送到接收者的消息队列,规定消息队列的容量为十条,每取一条消息会再进一条消息。按照静态优先取消息执行顺序如下:

规定每处理一个消息花费时间为1小时,第一次取消息时消息队列中就有十条消息,每取走一条消息,都有另外一条消息补充进来。规定在消息队列中的消息每等待5小时就提升一个优先级,对上数一级数据进行测试得到如表1的比较数据。

从表1的结果显示得知利用动态优先数设置,消息的平均等待处理时间和最长的等待处理时间都较静态优先数设置短。

以上分析数据是消息队列容量为十条消息的情况下,表2的数据为水息队列容量为二十条消息的情况,对静态优先数设置和动态优先数设置的比对。

若取动态优先数设置上面的分析均是以5小时等待时间为提升一个优先级的标准,表3我们对上面的数据进行更进一步的分析,分别用五小时和三小时为提升优先级的标准进行比对分析。

从表3的结果可知采用动态优先数设置时消息队列设置以及提升优先级的等待时间设置对消息提取平均等待时间,以及最长的等待时间的影响。用柱型图表示如图2、图3所示。

3 总结与展望

本文主要提出一种基于动态优先数的消息中间件设计算法,并用测试数据进行了验证分析,得出分析结果使用动态优先数调度算法进行消息中间件中消息队列设计使消息等待平均时间变短、消息队列中的消息最长等待时间变短。兼顾了效率和公平的原则。

进一步研究的重点是把基于动态优先数调度算法的消息中间件技术加以应用。

参考文献

[1]李建峰,许舒人,马建刚.面向大规模数据集成消息中间件系统设计实现[J].计算机工程与设计.2008.

[2]李辉,李绪志.基于消息分类的复合模式消息中间件研究.软件时空[J].2007.

[3]Eugster P T,Pascal A Felber,Rachid Guerraoui,et al.The manyfaces of publish/subscribe[J].ACM Computing Surveys.2003.

[4]胡雅庆.面向消息中间件的设计与实现.计算机与现代化[J].200103.

[5]徐远芳.消息中间件在WEB服务中的应用及面向WEB服务的消息中间件设计[J].广西大学硕士学位论文.2004.

基于中间件技术的讨论 篇5

关键词：OPC,消息中间件,数据集成,实时数据

随着企业信息化进程的推进,流程行业普遍采用WinCC、RSView32等监控组态软件对工业现场实时数据进行采集和监测,这些传统的监控软件可以处理来自现场设备所采集的生产数据。但是,原有专用监控软件存在几个方面的缺陷:首先不能提供随时随地的监控服务;其次无法为企业内部的其他信息系统提供原始数据;而且各监控系统互相独立,不具备统一性。因此,在保证现有监控系统正常运行的情况下,急需对其功能进行延伸和扩展,以达到有效利用的目的。本文提出一种基于过程控制的对象连接和嵌入技术(Object linking and embedding for Process Control,OPC)和消息中间件的实时数据集成系统,(Real-Time Data Integration System,RTDI)以实现这样的目标。经实践应用证明,该系统已经明显改善了原有系统的不足。充分体现了系统便利性、集成性和扩展性的优点。

1 RTDI系统体系结构

RTDI实时监控系统采用多层C/S和B/S的混合结构。基于这种模式下的系统结构如图1所示。消息中间件层是整个系统的核心,他由OPC数据读取发送客户端、Microsoft 消息队列(Microsoft Message Queuing,MSMQ)服务器、OPC数据转发程序组成。

其中,OPC数据读取发送客户端负责读取OPC服务器发布的实时数据,打包成消息并发送到目标消息队列;MSMQ服务器管理进出消息队列的消息;OPC数据转发程序将目标消息队列的消息对照位号数据字典进行解析,存放到对应的数据表中。

消息中间件实现异步通信,在网络通畅的情况下,保证消息通信的实时性;在网络线路不稳定或断连的情况下,消息发送方保证不会因此而阻塞系统运行,已发送消息不会因此丢失。

2 基于OPC和消息中间件的实时数据集成策略

本文提出的基于标准化的实时数据获取及传送策略,他保证了实时数据的规范化获取和可靠传输。

2.1 OPC技术及数据获取策略

OPC是Microsoft公司的对象链接和嵌入技术在过程控制方面的应用,他为工业自动化软件面向对象的开发提供了统一的标准。本文的RTDI系统结构中, OPC Server位于数据源层上,并发布从现场设备获取的实时数据;OPC Client以中间件的形式位于消息中间件层,其任务是从OPC接口获取OPC Server发布的实时数据,然后打包发送到消息队列。这些接口定义符合OPC基金会数据访问用户接口标准[1,2]。

2.2 消息中间件及数据传输

实时数据集成平台应当保证消息通信的实时性、准确性以及平台可扩展性。本文开发的面向消息的中间件,他使用MSMQ作为消息的缓冲存储,具有高度的可靠性;消息中间件进行消息转发时支持断点续传,避免了在较差网络环境下消息传输的“抖动问题”;传输由操作日志控制,保证同一消息不会多次重复发送[3]。RTDI平台采用图2所示的通信框架。

采用持久远程队列传送实时数据,OPC数据读取发送程序只需与本地的MSMQ服务器相连,然后将消息存放到远程队列中。MSMQ负责将远程队列中的消息送到远程目的地的队列上。接收方即OPC数据转发程序与当地的MSMQ服务器相连,从本地专用队列中获取消息。这样,即使目标队列的MSMQ服务器未启动,OPC数据读取发送程序也可以成功地向目标队列发送数据,而且保证向目标队列发送的数据不丢失,保证实时数据传输的可靠性[4]。

3 RTDI系统平台的构建

基于Web的B/S系统结构,采用模拟控制现场的图示、在位查询和智能提示等多种手段,向用户提供易于使用的信息获取方式。这种划分方式的好处是将不同的功能在页面上以模块化分开,便于功能页面的调换,使各个区域各负其责,也便于系统维护。RTDI系统的Web结构如图3所示:

实时数据监控需要进行频繁的数据刷新,本文的做法是把数据获取和数据展示用不同的页面操作。刷新设置区定时获取当前功能区内所有位号的实时点数据,通过JavaScript脚本将数据赋值给功能区内相应的位号层。用户只看到刷新设置区内系统时间和功能区内实时数据在变动,整个系统界面也相对稳定,从而达到系统设计的标准。

4 桌面工具

状态发布工具可以设置和显示3种类型的图:PFD图(过程流程图)、趋势图和报警图。在状态发布工具中,用户可以把过程数据按照他内在的物理或逻辑关系编辑、组织成PFD图显示来自不同实时数据库的实时数据。用户通过PFD图可以对企业的过程数据进行实时监控。状态发布工具可以定义和显示趋势图,用户可查看来自一个/多个实时数据库的一个/多个点的数据,可任意放大、缩小趋势图,借助过程数据的趋势图,用户对实时数据进行分析和跟踪。

5 结 语

基于本文所述的实时数据集成技术所构造的RTDI平台引入了松耦合型的、基于消息队列中间件的分布式体系结构,并采用工业OPC标准和消息队列中间件技术实现了实时数据的规范获取和可靠传输。该系统解决了实时数据的应用问题,保证分布实时数据的可达性和一致性。该平台现已应用到石油行业的生产一线,能实现对实时数据的远程监控和设备的远程维护,为进一步提高企业安全管理、生产管理、预测分析和决策支持能力提供了良好的实时数据监控平台。

参考文献

[1]OPC Foundation.OPC Data Access Specification Version3.00,2003.

[2]OPC Foundation.Product Catalog/OPC Specification,2000.

[3]秦军.基于MSMQ消息通信的研究与实现[J].计算机与现代化,2004(5):22-24.

基于中间件技术的讨论 篇6

企业实施RFID方案的最终目的是将RFID产生的海量信息为业务所用。这就需要解决企业现有的业务系统如何与RFID系统接口的问题,包括连接RFID设备、处理RFID数据、将其转换成业务信息等。为了避免因标签种类变化、系统业务逻辑改变而需要重新编写业务信息的情况,需要将RFID硬件模块的连接控制、中间数据处理与上层应用软件分开,因此引入了RFID中间件的概念。

此外,利用SOA系统具有可扩展性高、可维护性好的特点,以便为用户提供灵活的维护服务,还引入了面向服务体系架构SO A (Service Oriented Architecutures)。

基于上述分析,本文提出了一种基于SOA的RFID中间件方案。该方案可把各个应用RFID技术的功能抽象成服务,应用基于J2EE构建方法,综合应用JMX、JMS、Struts等技术。企业应用系统通过请求服务的方式来获取RFID中间件提供的服务。用XML进行数据传输,并提供Web Service接口。

1 技术基础

1.1 RFID中间件

RFID中间件是实现RFID硬件设备与应用系统之间数据传输、过滤、数据格式转换的一种中间程序,将RFID阅读器读取的各种数据信息,经过中间件提取、解密、过滤、格式转换、导入企业的管理信息系统,并通过应用系统反映在程序界面上,供操作者浏览、选择、修改、查询。中间件技术也降低了应用开发的难度,使开发者不需要直接面对底层架构,而是通过中间件进行调用。

RFID中间件是一种消息导向的软件中间件,信息是以消息的形式从一个程序模块传递到另一个或多个程序模块。消息可以非同步的方式传送,所以传送者不必等待回应。RFID中间件是在企业应用原有的中间件发展的基础上,结合自身应用特性进一步扩展并深化了中间件的应用,使得RFID应用系统的开发变得更容易,提高了软件的可移植性,增强了系统的可维护性和可靠性,所以它的架构设计解决方案是RFID应用的一项极为重要的核心技术[1]。

目前提供RFID中间件平台的厂商主要有IBM、Oracle、Microsoft、SAP、Sun公司。对于这些厂商,RFID中间件只是其现有软件的扩展,其RFID产品可以迅速方便地与各自现有的软件产品线集成在一起。但缺点是其产品对该厂商其他软件产品的依赖性比较大。

1.2 面向服务的体系结构SOA

面向服务的体系结构是一种技术架构风格,它代表了一种开放的、敏捷的、可扩展的、可组合的架构[2],定义了服务提供者和消费者之间的松散耦合关系。其业务敏捷的特点,帮助企业把业务变得更加灵活,能够适时、快速地响应变化。SOA的核心概念就是服务[3],其基本结构如图1所示。其中包含服务的3个基本角色:服务提供者、服务请求者和服务注册。在这些角色之间使用了3种操作:服务发布、服务发现和服务绑定。作为SOA的一种实现技术,Web Services提供了基于XML的标准接口,具有完好的封装性、松散的耦合性、协议规范的标准性以及高度的可集成性等特点,能够良好地满足SOA应用模式的需求。

1.3 JMX和JMS

Java管理扩展JMX(Java Management Extensions)是一个为应用程序、设备、系统等植入管理功能的框架。在JMX规范中,管理组件是一个能代表管理资源的Java对象,遵从一定的设计模式,实现该规范定义的特定的接口。该定义保证了所有的管理组件以一种标准的方式来表示被管理资源。管理接口就是被管理资源暴露出的一些信息,通过对这些信息的修改能够控制被管理资源。管理接口包括:能被接触的属性值、能够执行的操作、能发出的通知事件等[4]。

JMS (Java Message Service)是访问企业消息系统的标准API,定义了Java中访问消息中间件的接口,但JMS只是接口,并没有给予实现,实现JMS接口的消息中间件称为JMS提供者(JMS Provider)。在JMS框架中运转的方法如下:

(1)得到1个JNDI初始化上下文(Context)。

(2)根据上下文以查找1个连接工厂。

(3)从连接工厂得到1个连接(Connect)。

(4)通过连接以建立1个会话(Session)。

(5)查找目的地(Topic/Queue)。

(6)根据会话以及目的地以建立消息制造者(TopicPub lisher/QueueSender)和消费者(TopicSubscrib-er/QueueReceiver)。

2 基于SOA的RFID中间件架构

利用SOA松耦合、面向业务的特点,结合RFID中间件实现的应用系统集成的方案可提供丰富的接口,能够帮助实现对RFID设备的管理以及对数据的处理,简化了对底层设备应用的支持,避免了对底层设备的低级别接口的处理。利用Web Service技术实现RFID中间件与企业系统的集成,完成两者的松耦合集成。

基于SOA的RFID中间件架构,其基础架构层分为设备管理层、事件处理层和服务接口层,并通过Web Service技术包装了每1层相应的功能,且进行了具体实现。本文重点介绍该RFID中间件架构中的基础架构的3个功能层[5]。这3个层次有着明确的功能划分和层间的交互接口。RFID中间件架构如图2所示。

中间件设计包括RFID设备管理组件和事件过程管理组件。RFID设备管理组件是分布式的代理,负责第1级的事件过滤;设备管理包括设备询问器,对每1个阅读器和传感器设备,代理必须互相作用。过程管理组件是通过RFID事件下一级的过滤,把事件放置到交易环境中,然后发布应用层事件ALE(Application Layer Event)[5]。

2.1 设备管理层

设备管理层位于架构的最底层,直接与阅读器交互,实现的主要功能包括:

(1)采集射频卡上的数据。

(2)对于来自不同类型的阅读器的数据进行适配处理,得到统一的、格式化的数据,并进行数据校验。

(3)将校验无误的数据按照用户定义的协议进行封包,并将消息包发送到事件处理层的消息系统。

依据其实现的功能,分别针对射频卡阅读器模块、阅读器接口、数据校验和数据打包4个方面进行研究和开发。阅读器模块是根据硬件供应商提供的规范进行编码实现的;阅读器接口主要解决将来自协议格式的数据转化为系统所需要的EPC码;数据校验采用CRC校验;数据打包先依据获取的卡片编码中“数据分类”内容,判断出该标签数据属于哪种类型,然后按照这种数据类型将标签数据封装成相应的消息包。

由于每个ALE阅读器事件流可能来自多个物理设备配置表,因此设备管理器为每个设备表创建1个询问器,并通知询问器哪种传感器被绑定到指定的阅读器上。询问器发送传感器事件流到设备管理器,设备管理器将1个或多个传感器事件流构造成阅读器事件。设备管理器把初步处理的阅读器事件发送到ALE服务器。

询问器代理:1个设备管理器的配置由它管理的设备和它要咨询的询问器组成,然后与它所对应的设备管理器交互。每个设备概要表由物理设备属性和询问器配置组成。物理设备属性是被命名过的传感器(例如天线和1个金属传感器)。

事件信息空间:事件信息空间类似于公共的容错事件信息经纪人。它支持异步接收来自设备管理器的事件、ALE事件以及其他来自事件过程管理的配置需求。事件信息空间同时提供一个存储转发机制,确保重要的事件在中断的网络或其他组件失效的情况下不丢失[5]。

在系统中,将每个阅读器模块的远程方法调用封装为1个管理组件(MBean)作为JMX服务器的实例注册到JMX服务器中。通过JMX框架对阅读器进行监控和管理,使RFID中间件系统能提供管理、监控阅读器的功能。本部分描述为阅读器管理组件添加时间服务,以达到定时控制阅读器的目的。

2.2 事件处理层

在RFID系统中,一方面是各种应用程序以不同的方式频繁地从RFID系统中取得数据;另一方面却是有限的网络带宽,其存在的矛盾,使其有必要设计1套消息传递系统,使设备管理层产生的事件能够传递到消息系统中,由事件管理过程进行处理,然后把数据传递到相关的应用系统。在这种模式下,阅读器不必关心哪个应用系统需要什么数据。同时,应用程序也不需要维护与各个阅读器之间的网络通道,仅需要将需求发送到消息系统中即可。由此,设计出的消息系统应具有如下功能:(1)数据缓存功能;(2)基于内容的路由功能;(3)数据分类存储功能[6]。

下面将描述创建一个MBean来实现一个数据处理节点。消息组件可以按照MBean来部署。消息处理组件执行功能:从源队列中获取消息,对消息执行处理,然后将结果消息放置到目标队列。消息处理UML图如图3所示。

JBossMQ是通过xml文件jbossmq-destinations-service.xml进行配置的。以下是获得JBOSS JNDI初始化上下文(Context)的代码:

Hashtable props=newHashtable();

props.put (Context.INITIAL CONTEXT FACTORY,"org.jnp.interfaces.NamingContextFactory");props.put (Context.PROVIDER URL,ip+":1099");props.put ("java.naming.rmi.security.manager","yes");

props.put (Context.URL PKG PREFIXES,"org.jboss.nam-ing");

Context context=new InitialContext(props);

来自消息系统的消息以临时XML文件的形式和磁盘文件方式保存,供数据接口使用。消息系统完成消息缓存、分类整合、路由转发、临时存放等操作[4]。

事件过程管理EPM (Event Process Managment)由ALE服务、配置管理、复杂事件过程以及交易规则执行组成,对EVP的访问能通过HTTP、JMS以及网络服务接口实现。

EPM登记/订阅其感兴趣的事件,当在信息空间中有事件发生时,即会通知EPM,一旦接收到这些事件,随后会应用复杂事件处理(过滤器),结合交易规则对这些事件进行处理。另一种情况下是:外部的客户端(如EPC-IS)已经注册接收ALE,这些过滤后的事件会被发送到ALE客户端指定的位置。

2.3 服务接口层

来自事件处理层的数据最终是分类的XML文件。同一类型的数据以XML文件的形式保存,并提供给相应的1个或多个应用程序使用。而服务接口层主要是对这些数据进行过滤、入库操作,并提供访问相应数据库的服务接口。具体操作如下:

(1)将存放在磁盘上的XML文件进行批量入库操作,当XML数据量达到一定数量时,启动数据入库功能模块,将XML数据移植到各种数据库中。

(2)在数据移植前将重复的数据过滤掉。

(3)为企业内部和企业外部访问数据库提供Web Services接口。

其中,数据过滤过程是在处理临时存放的XML文件的过程中完成的。方法是:将同一个卡号的多条记录按照读入的时间戳进行比较,若相邻记录的时间戳差值小于用户定义的阈值,则认为重复读取发生,剔出后1条记录。依次类推,剔出掉所有冗余数据。利用Web Services技术将对数据库的访问以服务的形式发布,供企业内部应用程序和企业合作伙伴调用[2]。以数据过滤为例,其核心代码如下:

以下是服务接口层向应用系统发送SOAP响应,返回处理结果的部分代码[7]。

3 RFID中间件的实现及测试

RIFD中间件系统开发工具采用Eclipse3.2,应用服务器软件采用JBOSS4.0,Web容器为Tomcat5.5。此外,服务器端采用了基于Struts的MVC多层次结构框架,数据服务层则采用MySQL5.0数据库。

实验中,终端通过485网络组网,应用系统使用的是仓库管理系统。仓库管理系统作为服务请求者,根据服务接口层公布的入库信息核对服务WSDL,得到该服务的接口定义和服务端侦听地址,由入库管理模块通过服务代理接口向Web服务发送SOAP请求消息,请求入库信息核对服务,Web服务平台收到该服务请求后,向RFID中间件发送消息,创建一个出库信息核对服务的实例,设备管理层根据服务请求参数,启动相应的RFID阅读器读取标签信息。然后将读取的标签信息经处理后打包传给事件处理层,根据服务请求的参数与捕获的标签信息进行核对处理,处理后向服务接口层返回核对数据正确或者错误的信息,如图4所示。最后,服务接口层向仓库管理系统发送SOAP响应,返回处理结果[5]。

实验表明,原来的应用系统仅仅支持1种固定卡型的阅读器,采用RFID中间件以后,可以在1个系统中采用各种卡型的阅读器,而上层程序不需要再进行修改,增加了系统的可扩展性和易维护性,节约了时间和成本。系统稳定性也有大的提高,有效解决了企业应用中所关心的问题。

本文提出了一个基于SOA,综合应用JMX、JMS等技术的RFID中间件架构,并说明了RFID中间件各部分的含义和作用及基础架构的实现。这种中间件结构能很好地屏蔽低端各种物理设备的信息。由于采取了模块化的结构,可以根据需要进行裁减,在需要的时候再加入相应的模块,例如,可根据需要是否添加认证和安全模块。通过Web Service,可实现对RFID中间件更高层次包装,保证了RFID基础架构中3个功能层之间的相互独立和协同工作。

参考文献

[1]郑勇雪,张大勇.仓储管理系统中RFID中间件的设计与实现[J].计算机工程与设计,2007,23(12):5715-5717.

[2]邓海生,李军怀.基于SOA的RFID中间件的研究与实现[J].电子技术应用,2007,33(10):131-134.

[3]ERLT.SOA概念、技术与设计[M].北京:机械工业出版社,2007.

[4]甘勇,郑富娥,吉星,等.RFID中间件关键技术研究[J].电子技术应用,2007,33(9):130-132.

[5]成修治,李宇成.RFID中间件的结构设计[J].计算机应用,2008,28(4):1055-1057.

[6]吴正大,魏俊荣,张继新.RFID中间件设计技术初探[J].邮电设计技术,2006(8):39-42.

基于中间件技术的讨论 篇7

一个典型的RFID应用系统包括标签、读写器与配套硬件及相应支撑软件。RFID中间件(Middleware)是支撑软件的一个重要组成部分,用来加工、处理来自读写器的所有信息和事件,使用其提供的一组通用应用程序接口(API),能有效集成较大规模应用中涉及的不同种类、众多采集点的RFID产品,读写RFID标签信息,对标签信息进行过滤、分组和计数等处理,加入了语意解释的事件数据,优化数据传输,可减少发往信息网络系统的数据量并防止误读、多读、漏读信息。中间件是RFID系统的“神经中枢”,在RFID硬件产品数据格式变化情况下,以最小的成本升级应用系统,降低开发难度,缩短开发周期,规避开发风险,节省开发费用,提高开发质量;使用RFID中间件可以让用户更加方便的应用RFID技术,更便捷的将此技术融入到各类的业务应用和工作流程当中。

RFID中间件还可以和诸如企业资源计划(ERP)系统、仓储管理系统(WMS)、客户关系管理(CRM)、办公自动化(OA)及其他专有业务系统很有效的整合。良好的适应性使得应用该框架构建RFID应用只需要进行非常少量的程序设计工作量就可以和其他业务系统软件无缝对接。

1 RFID中间件的发展与结构特点

1.1 RFID中间件发展历程

RFID中间件发展大体划分为三个阶段。

第一阶段是以应用为中心的初级阶段。RFID厂商提供API,帮助用户完成RFID读写器的整合、串联。用户完成后端处理系统与读写器API连接、可靠性处理等功能。

第二阶段是架构中间件发展阶段。通过本阶段的发展,RFID中间件不但已经具备基本数据采集、过滤、分组和计数等功能,同时满足用户多点收集、多点应用的需求,并具备平台的管理与维护功能。国内研究成果还涉及到了传输协议和安全管理等领域[2,3,4]。

第三阶段是解决方案阶段,为中间件的成熟阶段,各厂商针对RFID在不同领域的应用,提出了解决方案。用户通过RFID中间件,可以将现有业务系统快速与RFID系统连接,实现对RFID系统可视化管理。此时,中间件即可以部署在靠近阅读器等网络边缘的位置,也可以部署在数据中心,通过广域网与阅读器通信。用户不必过分关心通过中间件来提供阅读器的性能,而是将精力集中在与用户的商务事物中。各大公司提出的方案,大多基于自己目前的核心产品或技术,有太大的依赖性和较小的扩展性,如IBM的Web Sphere,BEA的Web Log-ic等。一些解决方案能够帮助特定领域的用户对采集到数据进行一定程度的挖掘。

中间件在未来除了通过硬件、软件可靠性解决数据脏读、漏读等问题外,还将与大数据处理技术密切结合,提供进一步的相关的过滤、提取、传输、回溯等功能。

当前RFID中间件主要由IBM、Microsoft、SAP、Sybase、Sun、BEA等国际巨头把持,国内的中间件产品,主要针对中小企业的应用开发[5],如深圳立格公司产品,清华同方的“ez ONE易众”中间件,中科院自动化所的RFID公共服务体系基础架构软件和部分产品可追溯管理中间件,华中科技大学支持多通信平台的Smarti和上海交大面向物流的中间件SRM等。

1.2 RFID中间件基础框架分层结构介绍

1)硬件设备接口层

该层由任意扩展的API生成集合以及允许与系统环境无缝连接的特定接口组成,帮硬件供应商建立所谓“设备驱动”,对接的设备包括RFID阅读器、打印机、可识别RFID信号的多用途传感器等。中间件通过RFID软件开发包(SDK)的形式兼容各种设备通讯协议并且支持以往生产的所有相关设备,具有良好的兼容性,可以更容易的发挥整合的效能。如果设备供应商采用了软件开发包编制相应设备驱动程序,网络上的所有RFID设备就都可以被工具软件发现和管理。

2)运转引擎层

该层可以通过由一系列基于业务规则的策略和可扩展的事件处理程序组成的强大事件处理机制,让应用程序能够将未经处理的RFID事件数据转换成为可以识别的信息;通过消除RFID数据中的噪声、失真和其他干扰信号等手段让RFID应用软件在各种复杂的业务处理过程中充分发挥作用,降低配套工具软件的开发成本。

3)OM/APIs层

该层包括了对象模型(OM)和应用程序开发接口集(APIs),可以帮助应用程序开发商设计、部署和管理RFID解决方案,应用程序开发商可以创建各种各样的软件工具来管理RFID中间件基础框架。对象模型提供了很多非常有用的程序开发接口,包括了设备管理、处理过程、应用部署、事件追踪以及性能监测等。这些应用程序接口不但对RFID处理软件的快速设计和部署提高明显,而且可以使应用程序在全软件生命周期得到更有效的管理。此外,本层还包括“事件处理管道”设计和部署所需工具,可将未经处理的RFID事件数据过滤、分组、计数和转换成为后续业务系统可识别的信息所必备的软件组件。

4)设计工具和适配器层

该层包含了RFID中间件的基础框架的设计工具和“适配器”,是开发者在研发不同类型的业务处理软件开发调试很有帮助的软件工具。其中设计工具可以创建一个RFID业务处理过程提供简单、直观的设计模式;“适配器”可以整合服务器软件和业务流程应用软件,使得若干个通过RFID信息传递来完成业务协作的应用软件形成一个有机的整体。通过使用这些设计工具和“适配器”,开发商可以设计开发出各种具有广泛应用前景的应用程序和业务解决方案[6,7,8]。

2 IBM RFID中间件在仓储物流管理系统中的应用

2.1 IBM RFID中间件的结构

IBM中间件主要包括边缘控制器和前端服务器两部分,架构体系如图2所示:边缘控制器由控制器、滤波器、Micro Broker总线和RFID读写器代理服务器等组成,主要负责与硬件设备之间的通信,对RFID读写器收集的数据进行采集、过滤和整合,并将其提供给前端服务器。前端服务器由服务器、MQ中间件、Micro Broker总线、数据库和网络服务器等部分组成,是所有RFID设备采集信息的汇聚中心,存储数据并与后端应用系统进行数据交互、整合。边缘控制器。边缘控制器与前端服务器之间采用发布主题订阅主题的方式通信。[9]

2.2 基于IBM RFID中间件的仓储物流管理系统构建

采用IBM RFID中间件可以使整个物流变得一目了然,极大地简化了开发工作。在RFID硬件系统中,因为读写器可以对粘贴在不同货品中的标签信息随时读写,可以采用基于该中间件技术的平台在仓库的众多管理位置实现仓储物流管理系统对前端各RFID设备的集中智能控制,实现仓储物流信息的实时管控。

1)出入库管理:在仓库门口安装RFID固定阅读器,当货品出入库经过门口时,读写器自动读取存储在货品标签中EPC(电子编码),并将其中存储的货品信息、出入库时间写入数据库,自动完成出入库登记操作。

2)日常业务管理:包括各工作日的货品保存、转移、交接、订单管理等。货品保存是物流业比较重要的一个工作,因此货品保存业务的规范就显得尤为重要。这里主要包括每个工作日货品的状态记录、检査等规范操作登记记录。

3)查询与统计:为管理用户提供查询和统计服务,可查询出各工作日货品的出入库情况、货品位置情况等,统计出货品流向信息报告。

4)货品盘点:采用便携式RFID数据采集器和固定RFID阅读器实现对仓库内货品的盘点和统计。便携式RFID数据采集器方式采集电子标签上的数据,使用方便快捷灵活,在读取标签上信息的同时,可以将数据直接传送到计算机系统,或者暂时存储于采集器内,批量传送到计算机系统。

5)资料管理:建立货品分类,通过阅读器对RFID标签进行信息设置,将EPC(电子编码)与货品分类相对应,并利用RFID标签中剩余存储空间保存货品详细信息。

3 未来发展趋势

RFID中间件的开发和成熟为仓储物流信息管理平台建立了一个发现和管理电子标签设备,实现仓储物流信息实时管控的高效渠道,通过建立丰富的、可升级的事件处理软件架构把众多单个电子标签数据转化成具有实际意义的业务信息,为RFID应用与其他业务系统快速整合提供了一个规范的业务定制模型,是一次重大的技术革新。我国相关企业应该抓住这一机遇,以市场需求带动RFID中间件软件水平的提高。

摘要：介绍了RFID中间件的基本应用情况、发展历程、国际国内市场情况,详细阐述了其基础框架的分层结构及功能。以IBM RFID中间件为应用案例,介绍了该中间件的系统结构,提出了基于该中间件的仓储物流管理系统构建方案,并对RFID中间件下一步的研究工作做了简单说明。