CN103944924B - 一种基于RESTful的泛在网发布订阅中间件模型的方法 - Google Patents
一种基于RESTful的泛在网发布订阅中间件模型的方法 Download PDFInfo
- Publication number
- CN103944924B CN103944924B CN201410205763.XA CN201410205763A CN103944924B CN 103944924 B CN103944924 B CN 103944924B CN 201410205763 A CN201410205763 A CN 201410205763A CN 103944924 B CN103944924 B CN 103944924B
- Authority
- CN
- China
- Prior art keywords
- message
- subscription
- middleware
- subscribe
- issue
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明公开了一种基于RESTful的泛在网发布订阅中间件模型，属于通信技术领域，该发布订阅中间件模型包括以下几个组成部分：发布/订阅中间件基础模型；订阅中间件中的消息格式、流程和订阅条件过滤器；发布中间件中的消息格式、流程和节点间消息传递机制；用于处理发布/订阅中间件错误信息的容错机制。与现有技术相比，本发明基于REST架构，相比于SOAP和WDSL，使用双向节点，减少功能模块数量，同时，通过对泛在网中的信息的生产者和消费者之间设置一个中间件来进行交互，在实现泛在网中多对多的通信方式的同时，信息消费者能够通过中间件，及时、可靠地得到发布的感兴趣消息，使得消息的生产者和订阅者在时间、空间上完全解耦。
Description
技术领域
本发明属于通信技术领域，涉及一种基于RESTful的泛在网发布订阅中间件模型。
背景技术
传统的通信模式(如客户机/服务器，RPC调用，消息队列等)，发送消息然后等待响应，使得消息的请求者和发送者在时间上，空间上存在着紧耦合的关系，面对大规模的分布式***显得力不从心。通过使用发布订阅的中间件模型，可以让消息的生产者和订阅者在时间，空间上完全解耦，实现多对多的通信方式。而REST作为一种设计Web服务的方法，其对专有中间件(例如某个应用程序服务器)的依赖比基于SOAP和WSDL的方法更少。将这REST和中间件结合起来可以得到更好的订阅/发布模型。
发明内容
有鉴于此，本发明的目的在于提供一种基于RESTful的泛在网发布订阅中间件模型。
为达到上述目的，本发明提供如下技术方案：
一种基于RESTful的泛在网发布订阅中间件模型，包括以下几个组成部分：发布/订阅中间件基础模型；订阅中间件中的消息格式、流程和订阅条件过滤器；发布中间件中的消息格式、流程和节点间消息传递机制；用于处理发布/订阅中间件错误信息的的容错机制。
进一步，所述基础模型由以下几个部分组成：1)发布/订阅中间件模型中的成员；2)发布/订阅中间件模型的主要活动角色；3)发布/订阅中间件模型管理单元；
所述模型中的成员主要是事件主题，事件主题可以由参与者中的发布者进行发布，也可以能由参与者中的订阅者提出；
所述模型的主要活动角色是发布者与订阅者，两者的关系是相对于事件主题而言的，发布者和订阅者的注册方式通过泛在网统一的标识方式进行规范化管理；
所述中间件模型管理单元，包含了主要的通信特征，并封装了REST传输协议、REST消息编码、REST通信模式、可靠性、安全性、事务管理及互操作性等主要元素，定义各类REST传输协议的抽象接口，包括回调接口和服务绑定。
进一步，所述订阅中间件中的消息格式由以下几个部分构成：订阅中间件消息类型、订阅ID、订阅命令、订阅消息传输位置、订阅消息优先级、订阅时间戳和反馈消息；
所述订阅ID指与订阅者一一对应；订阅中间件消息类型包括了订阅客户端中登录、注册、 注销消息以及***中的订阅和响应消息；订阅命令指判断是否发送订阅条件以及订阅者对订阅条件的更新、取消；订阅消息传输位置与功能模块或中间节点对应，并对传输路径缓存记录；订阅消息优先级是指在超出服务器负载情况下，消息传递需要有先后顺序，可以用收费的方式实现；订阅时间戳用于记录订阅消息存在于***的时间，时间过长会被删除；反馈消息由匹配到的发布内容和***返回的错误提醒组成，错误提醒包括了订阅条件出错和***/网络出错。
进一步，所述订阅中间件流程，通过以下四个步骤进行：步骤一：订阅者进行注册，由此进入订阅客户端；步骤二：用户在客户端中提出订阅条件并发送给订阅管理器；步骤三：订阅管理器将订阅条件发送到数据库，在其中匹配订阅条件；步骤四：数据库在匹配过后将结果经由订阅管理器传送到订阅客户端；
订阅客户端是指用户查找订阅信息时的操作平台；订阅管理器的功能是存储和检索订阅条件，将订阅条件转化为与数据库相容的REST数据，并提供REST服务接口进行订阅或退订服务；数据库中包含有订阅条件过滤器，用以提高匹配效率。
进一步，所述订阅条件过滤器用于对经泛在网统一的标识方式标识后的主题进行筛选；所述订阅条件过滤器的主要功能为匹配订阅条件，筛选时就订阅条件进行拆分，区分订阅条件中名词与名词之间的重要性程度，以更重要的名词作为条件进行筛选，筛选结果排在次要名词筛选的结果之前，或者建立多级过滤器，由订阅者自行选择，进一步减少筛选次数；
所述的订阅条件过滤器在具体设计时还应考虑筛选时间、筛选空间以及事件数据本身的更新，筛选时间就是订阅者在输入订阅条件以后得到结果的时间，空间是指数据存储的空间，事件数据更新就是指发布者新发布的数据和订阅者增加或者取消的订阅。
进一步，所述发布中间件消息格式采用REST风格，由发布消息头和发布消息体构成；其中发布消息头包括了发布ID、发布中间件消息类型、发布命令、发布消息传输位置、权限和发布时间戳；发布消息体包括了发布内容和反馈信息；
发布ID指与发布者一一对应；发布中间件消息类型包括了发布客户端中登录、注册、注销消息、***中的发布、响应消息以及发布者控制和发布内容是否为公共信息；发布命令指判断是否发送发布内容以及发布者对发布内容的更新、取消；发布消息传输位置与功能模块或中间节点对应，并对传输路径缓存记录；权限是指在分为发布者权限与发布内容权限；发布者权限高低与发布内容被订阅次数多少挂钩，发布内容权限指发布者对发布内容可见性的限定；发布时间戳用于记录发布消息存在于***的时间，时间过长会被删除；反馈消息由订阅情况和***返回的错误提醒组成，订阅情况指订阅者对于发布内容的订阅次数以及后续要 求，错误提醒包括了发布内容出错和***/网络出错。
进一步，所述发布中间件流程包括以下四个步骤：步骤一：发布者在发布注册管理器进行注册；步骤二：发布者在发布客户端进行事件或者主题的发布；步骤三：发布的内容通过发布管理器传送到数据库；步骤四：数据库存储发布内容；
所述发布注册管理器首先提供发布者进行注册；发布客户端是发布者的开发并传送结果的平台，发布管理器存储发布内容并转化为与数据库相容的格式，提供REST发布服务接口用以管理来自发布客户端的通知发布请求信息；数据库保存有价值的发布内容等待订阅条件的匹配。
进一步，所述的基于RESTful的泛在网发布/订阅中间件消息传递机制，采用RESTful标识类型对每一个节点的位置进行标识；并包含有各类REST传输网络协议，并可以添加验证码保证安全性；节点位于每个功能模块中间，帮助消息在其中相互传递；相比于SOAP中节点只能单向传输，REST中的节点能够达到双向传输：可以从上一级接收消息发送到下一级，也可以从下一级接收消息返回上一级，减少节点数量，简化***。
所述发布/订阅中间件消息传递机制中的节点是消息传递机制中的最小逻辑组成，且每个节点相互独立，消息传递时，节点根据消息命令，进行一个或者多个节点间传递；
所述节点由三个部分组成：接收器、传输***、发送器；接收器接收命令消息并将订阅信息发送给传输***；传输***通过命令消息进行判断如何进行下一步传送，并将命令消息发送给接收器。
传送原则就是信息传送方式以及传送路径，多数情况下需经过一些中间节点的处理，发送信息才能够到达指定节点；传送原则也包含了当出现了错误，不能够传送到目的节点时的解决方案：可选择把消息先传送到后备处理节点，或者暂存到规定的缓存队列中，等待继续传送的命令消息。
进一步，所述的泛在网发布/订阅中间件容错机制由三个方面组成：硬件容错机制、软件容错机制及传输容错机制；
所述的硬件容错机制采用状态评估***，中间件在运行时可能会出现硬件故障，通过在C/S模式下运用心跳信号机制实现对***的维护；
所述的软件容错机制采用日志***，软件运行日志主要用于开发调试阶段和软件交付使用阶段提供快速跟踪、定位错误位置的工具，为调试、排故提供了有效手段，通过将日志信息分级，出现错误时从最低级信息开始发送给管理人员，不能解决就传送较高的信息，实现快速解决问题；
所述的传输容错机制，传送过程中如果出现了异常，判断出是错误信息就直接丢弃，判断出需要继续传送，就选择最短的一条链路，如果必须经过某些节点，就进行多次选择。
本发明的有益效果在于：本发明提供了一种基于RESTful的泛在网发布订阅中间件模型，与现有技术相比，本发明基于REST架构，相比于SOAP和WDSL，使用双向节点，减少功能模块数量，同时，通过对泛在网中的信息的生产者和消费者之间设置一个中间件来进行交互，在实现泛在网中多对多的通信方式的同时，信息消费者能够通过中间件，及时、可靠地得到发布的感兴趣消息，使得消息的生产者和订阅者在时间、空间上完全解耦。
附图说明
为了使本发明的目的、技术方案和有益效果更加清楚，本发明提供如下附图进行说明：
图1为泛在网发布/订阅中间件关系图；
图2为泛在网发布/订阅中间件订阅条件过滤器示意图；
图3为泛在网发布/订阅中间件节点及路由机制示意图；
图4为泛在网发布/订阅中间件流程示意图。
具体实施方式
下面将结合附图，对本发明的优选实施例进行详细的描述。
本发明实施例的一种基于RESTful的泛在网发布/订阅中间件模型，该基于RESTful的泛在网发布与订阅中间件由以下几部分组成：
发布/订阅中间件基础模型；
订阅中间件中的消息格式、流程和订阅条件过滤器；
发布中间件中的消息格式、流程和节点间消息传递机制；
用于处理发布/订阅中间件错误信息的的容错机制。
基于RESTful的“发布/订阅”模式不仅能够在同一时间提供一对多、多对一以及多对多的异步通信模式，而且它能解除泛在网中用户在时间和空间上的限制，即松耦合，这正是大规模分布式网络***所要求的。
1)本发明实施例的发布/订阅中间件基础模型中成员关系如图1所示：
1.1)发布/订阅中间件模型中成员包括参与者、管理单元和主题等，其中主题是主要对象，由参与者创建或者关注主题可以有多个。
1.2)模型的主要活动角色为参与者，其可创建任何自己关注的主题。其中一部分的人作为发布者通过数据发送模块，发布自己能够提供的信息或者能力；另一部分作为订阅者在 这其中选择自己感兴趣的信息或能力。
作为优化方案，发布者、订阅者的注册方式可以通过泛在网统一标识方式进行规范化管理，方便两者的查询和联系，提供更大的合作空间。
1.3)管理单元：包含了主要的通信特征；封装了REST传输协议：不仅包括了SOAP和WSLD包括的HTTP和XML，还有HTML、URI等；封装了REST消息编码、REST通信模式、可靠性、安全性、事务管理及互操作性等主要元素；定义各类REST传输协议的抽象接口，包括回调接口、服务绑定等，实现与多种应用***之间的互操作，使得发布/订阅***能在泛在网的任意网络类型里面使用。
2)订阅中间件消息格式、订阅中间件流程及订阅条件过滤器
2.1)作为优化方案，订阅中间件消息格式运用了REST风格，由以下订阅消息头和订阅消息体构成；其中消息头包括了订阅ID、订阅消息类型、订阅命令、消息传输位置、订阅消息优先级和订阅时间戳；消息体包括了订阅条件和反馈信息。
2.1.1)订阅消息头
SubID(订阅ID)：8字节，与订阅者注册账号一一对应；
SubMSGType(订阅消息类型)：3字节，001表示登录，010表示注册，011表示注销，100表示订阅，101表示响应。
SubOrder(订阅命令)：2字节，00表示发送订阅条件，01表示不发送订阅条件：订阅者在登陆状态下进行发送，订阅者注销或退出时不发送，并删除此时的订阅命令；10表示对订阅条件的更新，11表示订阅者取消订阅。
SubMSGPosition(订阅消息传输位置)：4字节，与订阅客户端、订阅管理器以及它们的中间节点对应，并对传输路径缓存记录。
SubMSGPriority(订阅消息优先级)：2字节，在超出服务器负载或负载大的情况下，消息传递需要有先后顺序。
作为优化方案，上述优先级的处理可以通过收费的方式实现：在服务器忙碌时收费用户的优先级高于未收费的用户：00表示免费用户，01表示初级会员，10表示中级会员，11表示高级会员，等级依次提高；具体来说：收费用户不仅优先级高，还可以拥有更多的订阅缓存空间，会对提高在服务器上订阅请求保存的时间，并且如果处于离线状态，***会保存相应的通知或者匹配到的内容，再次上线时，***自动取出该消息并发送给收费用户。
SubTimestamp(订阅时间戳)：2字节，用于记录订阅消息存在于***的时间，并设定最高保存时长T1与之相比较，大于T1会丢弃消息，订阅者等级越高，T1的值越大。
2.1.2)订阅消息体
SubRequirement(订阅条件)：订阅者提出的订阅条件保存其中；
FeedbackMSG(反馈信息)：由匹配到的发布内容和***返回的错误提醒组成；匹配到的发布内容指与订阅条件基本相符的内容；错误提醒包括了订阅条件出错和***/网络出错，反馈给订阅者相关信息及处理方法。
2.2)作为优化方案，订阅中间件流程如图4所示：
步骤一：订阅者进行注册，由此进入订阅客户端；
步骤二：用户在客户端中提出订阅条件并发送给订阅管理器；
步骤三：订阅管理器将订阅条件发送到数据库，在其中匹配订阅条件；
步骤四：数据库在匹配过后将结果经由订阅管理器传送到订阅客户端。
作为优化方案，整个消息传输过程中使用REST协议进行传输。订阅客户端是指用户查找订阅信息时的操作平台；订阅管理器的功能是存储和检索订阅条件，将订阅条件转化为与数据库相容的REST数据，并提供REST服务接口进行订阅或退订服务。数据库中包含有订阅条件过滤器，用以提高匹配效率。
2.3)作为优化方案，如图2，订阅条件过滤器的性能主要体现在对订阅者提出的订阅条件的内容匹配，主要应考虑以下几点：
1)筛选对订阅条件进行拆分；2)区分订阅条件中名词与名词之间的重要性程度，以更重要的名词作为条件进行筛选，筛选结果排在次要名词筛选的结果之前；3)筛选时同样的内容只需过滤一次，主要内容大多在名词上有了体现，所以可以排除很多不必要的内容，从而减少筛选次数；4)建立多级过滤器，可以在拆分后的名词搜索结果中继续检索，或者订阅者可以每次对一个关键词进行搜索，这样可以进一步减少筛选次数。
作为优化方案，设计订阅条件过滤器主要考虑的因素还有筛选时间、筛选空间以及事件数据更新。
进一步，需要筛选的时间就是订阅者在输入订阅条件以后得到结果的时间；空间是指数据存储的空间；事件数据更新指发布者新发布的数据和订阅者增加或取消的订阅。
进一步，可利用泛在网的大量数据和RESTful的各类标记语言(例如URI)作为基础，进行数据分块整理，根据历史检索记录把信息进行分类，这样不仅能获得最大化的数据存储，也为筛选时提供更精确的导向。
3)发布中间件消息格式、发布中间件流程和中间件中节点间消息传递机制
3.1)作为优化方案，发布中间件消息格式运用了REST风格，由以下发布消息头和发 布消息体构成；其中发布消息头包括了发布ID、发布消息类型、发布命令、消息传输位置、权限和发布时间戳；发布消息体包括了发布内容和反馈信息。
3.1.1)发布消息头
PubID(发布ID)：8字节，与发布者注册账号一一对应；
PubMSGType(发布消息类型)：3字节，001表示登录，010表示注册，011表示注销，100表示订阅，101表示响应，110表示发布者对发布内容的修改的控制信息，111表示发布者发出的所有用户可见的公共信息。
PubOrder(发布命令)：2字节，00表示发送发布内容，01表示不发送发布内容：发布通过审核且检查后没有重复的内容，不符合条件的不进行发布；10表示对发布内容的更新，11表示发布者取消发布。
PubMSGPosition(发布消息传输位置)：4字节，与功能模块或中间节点对应，并对传输路径缓存记录。
Permission(权限)：4字节，分为发布者权限与发布内容权限；发布者权限高地与发布内容被订阅次数多少挂钩，发布者权限高会在审核发布内容时获得快速通道，减少过程耗时并尽早发布；发布内容权限指发布者对发布内容可见性的限定：可以设定为只有收费用户甚至中、高级订阅者才能订阅，也可以设定为所有订阅者可见。
PubTimestamp(发布时间戳)：2字节，用于记录发布消息存在于***的时间，并设定最长保存时长T2与之相比较，在T2间无任何响应会删除发布消息，发布者权限越高，T2的值越大。
3.1.2)发布消息体
PubContent(发布内容)：发布者的发布内容保存其中；
FeedbackMessage(反馈信息)：由订阅情况和***返回的错误提醒组成；订阅情况指订阅者对于发布内容的订阅次数以及后续要求；错误提醒包括了发布内容未通过和***/网络出错，反馈给发布者相关信息及处理方法。
3.2)作为优化方案，发布中间件流程如图4所示：
步骤一：发布者在发布注册管理器进行注册；
步骤二：发布者在发布客户端进行事件或者主题的发布；
步骤三：发布的内容通过发布管理器传送到数据库；
步骤四：数据库存储发布内容。
作为优化方案，发布者注册管理器首先提供发布者进行注册。注册后可以进行存储、 检索、查找REST服务接口以及注销服务，还接受来自订阅客户端的查询；发布客户端是发布者的开发并传送结果的平台：不仅包括了电脑操作***如Windows、Linux、MacOS，还包括了各类android软件平台、APPStore以及运营商的自建平台；发布管理器存储发布内容并转化为与数据库相容的格式，还提供了REST发布服务接口用以管理来自发布客户端的通知发布请求信息；传送过程中***会对发布内容与已发布的内容进行比较，删除重复或者无用的内容，保存有价值的发布内容等待订阅条件的匹配。数据库中还记录发布内容存在于***的时间，并设定最长保存时长T3，在T3间无任何订阅情况会删除此条发布内容，发布者权限越高，T3的值越大。
3.3)本发明实施例的中间件中节点间消息传递机制，如图3所示，其特征在于：
作为优化方案，本发明采用了RESTful标识类型对每一个节点的位置进行标识。
作为优化方案，节点的位置信息由RESTful标识进行统一编码。
作为优化方案，节点位于每个功能模块中间，帮助消息在其中相互传递；相比于SOAP中节点只能单向传输，REST中的节点能够达到双向传输：可以从上一级接收消息发送到下一级，也可以从下一级接收消息返回上一级，减少节点数量，简化***。
进一步，由于传输载体不同，节点中位置信息的还应该包含有各类REST传输网络协议以配合节点间的传输，若需要进行保密或者防止恶意软件增加***负荷，可以添加验证码等附加信息。
进一步，节点是消息传递机制中的最小逻辑组成，它的内部环境以及构成与外部环境甚至其他节点都没有必然联系，每个节点相互独立。
进一步，消息传递时，节点根据消息命令，进行一个或者多个节点间传递。
作为优化方案，节点由三个部分组成：接收器、传输***、发送器。
进一步，消息传递机制的特征在于，包括以下三个步骤：步骤一：接受器在收到命令消息时，判断需要使用的节点，将用户需求信息(订阅条件)发送给对应一个或者都过节点的传输***；步骤二：传输***经过一定的处理传送到发送器；步骤三：发送器根据输出命令信息将用户需求信息发送到目的节点。
进一步，需要注意的是，信息转发过后在一定的时间范围内会缓存在节点中，如果其他节点收到命令转发相同信息，就会被舍弃，从以前的节点开始转发，这样可以避免不必要的转发。
4)发布/订阅中间件容错机制
作为优化方案，发布/订阅中间件容错机制由三个方面组成：硬件容错机制、软件容错机 制及传输容错机制。
4.1)硬件容错机制：状态评估***对于硬件检测有较好的效果。其特征在于：中间件在使用时并不只是处于被动(静态)模式，一旦一些较为复杂的软件或者过多的软件在其中运行时可能会出现硬件故障。当出现这种情况，就立即进行收集并评估状态反馈给管理人员。同时***会根据当时使用情况调用备用服务器或者流量控制，保证***正常运行。
作为优化方案，状态评估***在C/S模式下通过心跳机制实现，步骤如下：
步骤一：将服务端驻留在各类硬件中，收集工作状态，存储在心跳信号中；
步骤二：根据服务器繁忙或空闲状态，设定较长或较短的间隔时间，将心跳信号通过节点发送到管理人员的客户端；
步骤三：如果在一定时间内没有收到心跳信号，表示硬件已经出现问题(断线或损坏)，管理人员应立即进行检查修复，并且修复完成后保证心跳信号恢复运行。
4.2)软件容错机制：日志***适于用软件错误机制。其特征在于：软件运行日志主要用于开发调试阶段和软件交付使用阶段提供快速跟踪、定位错误位置的工具，为调试、排故提供了有效手段。日志***中的信息包括了进入退出信息、软件运行状态、其它重要信息(例如，本节点发布、订阅的主题名，订阅方的IP、端口等)以及错误信息；通过设定信息输出的级别控制来决定要输出的信息种类与数量：A所有信息、B软件运行状态状态及错误信息、C错误信息；软件出现错误时根据历史记录传送最少的信息到控制台进行解决，如果没有出现过的错误按照C→B→A的顺序进行信息传输，信息越少传输速度越快，有利于问题快速解决。
4.3)传输容错机制：在大多数情况下，只有经过必要的中间节点进行处理后，发送信息才能够到达指定位置。传送过程中如果出现了错误，就不能够传送到目标位置时。如图3所示，解决方案：选择把消息先传送到后备处理节点，或暂存到规定的缓存队列中，等待继续传送的命令消息。情况1)判断出是错误信息就直接丢弃；情况2)需要继续传送，就选择最短的一条链路。如果必须经过某些节点，就进行多次选择。
最后说明的是，以上优选实施例仅用以说明本发明的技术方案而非限制，尽管通过上述优选实施例已经对本发明进行了详细的描述，但本领域技术人员应当理解，可以在形式上和细节上对其作出各种各样的改变，而不偏离本发明权利要求书所限定的范围。
Claims (6)
1.一种基于RESTful的泛在网发布订阅中间件模型的方法，其特征在于：包括以下几个组成部分：发布/订阅中间件基础模型；订阅中间件中的消息格式、流程和订阅条件过滤器；发布中间件中的消息格式、流程和节点间消息传递机制；用于处理发布/订阅中间件错误信息的容错机制；
所述基础模型由以下几个部分组成：1）发布/订阅中间件模型中的成员；2）发布/订阅中间件模型的主要活动角色；3）发布/订阅中间件模型管理单元；
所述模型中的成员主要是事件主题，事件主题可以由参与者中的发布者进行发布，也可以能由参与者中的订阅者提出；
所述模型的主要活动角色是发布者与订阅者，两者的关系是相对于事件主题而言的，发布者和订阅者的注册方式通过泛在网统一的标识方式进行规范化管理；
所述中间件模型管理单元，包含了主要的通信特征，并封装了REST传输协议、REST消息编码、REST通信模式、可靠性、安全性、事务管理及互操作性等主要元素，定义各类REST传输协议的抽象接口，包括回调接口和服务绑定；
所述订阅中间件中的消息格式由以下几个部分构成：订阅中间件消息类型、订阅ID、订阅命令、订阅消息传输位置、订阅消息优先级、订阅时间戳和反馈消息；
所述订阅ID指与订阅者一一对应；订阅中间件消息类型包括了订阅客户端中登录、注册、注销消息以及***中的订阅和响应消息；订阅命令指判断是否发送订阅条件以及订阅者对订阅条件的更新、取消；订阅消息传输位置与功能模块或中间节点对应，并对传输路径缓存记录；订阅消息优先级是指在超出服务器负载情况下，消息传递需要有先后顺序；订阅时间戳用于记录订阅消息存在于***的时间，时间过长会被删除；反馈消息由匹配到的发布内容和***返回的错误提醒组成，错误提醒包括了订阅条件出错和***/网络出错。
2.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型的方法，其特征在于： 所述订阅中间件流程，通过以下四个步骤进行：步骤一：订阅者进行注册，由此进入订阅客户端；步骤二：用户在客户端中提出订阅条件并发送给订阅管理器；步骤三：订阅管理器将订阅条件发送到数据库，在其中匹配订阅条件；步骤四：数据库在匹配过后将结果经由订阅管理器传送到订阅客户端；
订阅客户端是指用户查找订阅信息时的操作平台；订阅管理器的功能是存储和检索订阅条件，将订阅条件转化为与数据库相容的REST数据，并提供REST服务接口进行订阅或退订服务；数据库中包含有订阅条件过滤器，用以提高匹配效率。
3.根据权利要求2所述的一种基于RESTful的泛在网发布订阅中间件模型的方法，其特征在于：所述订阅条件过滤器用于对经泛在网统一的标识方式标识后的主题进行筛选；所述订阅条件过滤器的主要功能为匹配订阅条件，筛选时就订阅条件进行拆分，区分订阅条件中名词与名词之间的重要性程度，以更重要的名词作为条件进行筛选，筛选结果排在次要名词筛选的结果之前，或者建立多级过滤器，由订阅者自行选择，进一步减少筛选次数；
所述的订阅条件过滤器在具体设计时还应考虑筛选时间、筛选空间以及事件数据本身的更新，筛选时间就是订阅者在输入订阅条件以后得到结果的时间，空间是指数据存储的空间，事件数据更新就是指发布者新发布的数据和订阅者增加或者取消的订阅。
4.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型的方法，其特征在于：所述发布中间件消息格式采用REST风格，由发布消息头和发布消息体构成；其中发布消息头包括了发布ID、发布中间件消息类型、发布命令、发布消息传输位置、权限和发布时间戳；发布消息体包括了发布内容和反馈信息；
发布ID指与发布者一一对应；发布中间件消息类型包括了发布客户端中登录、注册、注销消息、***中的发布、响应消息以及发布者控制和发布内容是否为公共信息；发布命令指判断是否发送发布内容以及发布者对发布内容的更新、取消；发布消息传输位置与功能模块或中间节点对应，并对传输路径缓存记录；权限是指在分为发布者权限与发布内容权限；发布者权限高低与发布内容被订阅次数多少挂钩，发布内容权限指发布者对发布内容可见性的限定；发布时间戳用于记录发布消息存在于***的时间，时间过长会被删除；反馈消息由订阅情况和***返回的错误提醒组成，订阅情况指订阅者对于发布内容的订阅次数以及后续要求，错误提醒包括了发布内容出错和***/网络出错。
5.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型的方法，其特征在于： 所述发布中间件流程包括以下四个步骤：步骤一：发布者在发布注册管理器进行注册；步骤二：发布者在发布客户端进行事件或者主题的发布；步骤三：发布的内容通过发布管理器传送到数据库；步骤四：数据库存储发布内容；所述发布注册管理器首先提供发布者进行注册；发布客户端是发布者的开发并传送结果的平台，发布管理器存储发布内容并转化为与数据库相容的格式，提供REST发布服务接口用以管理来自发布客户端的通知发布请求信息；数据库保存有价值的发布内容等待订阅条件的匹配。
6.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型的方法，其特征在于：所述的基于RESTful的泛在网发布/订阅中间件消息传递机制，采用RESTful标识类型对每一个节点的位置进行标识；并包含有各类REST传输网络协议，并可以添加验证码保证安全性；节点位于每个功能模块中间，帮助消息在其中相互传递；所述发布/订阅中间件消息传递机制中的节点是消息传递机制中的最小逻辑组成，且每个节点相互独立，消息传递时，节点根据消息命令，进行一个或者多个节点间传递；所述节点由三个部分组成：接收器、传输***、发送器；接收器接收命令消息并将订阅信息发送给传输***；传输***通过命令消息进行判断如何进行下一步传送，并将命令消息发送给发送器。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410205763.XA CN103944924B (zh) | 2014-05-15 | 2014-05-15 | 一种基于RESTful的泛在网发布订阅中间件模型的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410205763.XA CN103944924B (zh) | 2014-05-15 | 2014-05-15 | 一种基于RESTful的泛在网发布订阅中间件模型的方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103944924A CN103944924A (zh) | 2014-07-23 |
| CN103944924B true CN103944924B (zh) | 2017-04-19 |
Family
ID=51192408
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410205763.XA Active CN103944924B (zh) | 2014-05-15 | 2014-05-15 | 一种基于RESTful的泛在网发布订阅中间件模型的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103944924B (zh) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105656959A (zh) * | 2014-11-13 | 2016-06-08 | 中国科学院沈阳计算技术研究所有限公司 | 基于路由机制的多终端pub/sub消息同步方法 |
| CN104617666A (zh) * | 2015-01-14 | 2015-05-13 | 国家电网公司 | 一种采用发布订阅通讯模型的配电网数据传输方法 |
| CN104899277B (zh) * | 2015-05-29 | 2018-08-10 | 北京京东尚科信息技术有限公司 | 一种消息分发方法和装置 |
| US10230696B2 (en) * | 2015-06-09 | 2019-03-12 | Intel Corporation | System, apparatus and method for managing lifecycle of secure publish-subscribe system |
| KR101889159B1 (ko) * | 2015-10-21 | 2018-08-17 | 주식회사 포스코 | 철강 공정 미들웨어의 이벤트 서비스 방법 및 프레임워크 시스템 |
| CN105472042B (zh) * | 2016-01-15 | 2018-09-21 | 中煤电气有限公司 | Web端控制的消息中间件***及其数据传送方法 |
| CN105577533A (zh) * | 2016-03-18 | 2016-05-11 | 微梦创科网络科技（中国）有限公司 | 一种分布式的消息投放***和方法 |
| WO2017214804A1 (zh) * | 2016-06-13 | 2017-12-21 | 深圳天珑无线科技有限公司 | 分布式网络的消息处理方法及节点 |
| CN106302817A (zh) * | 2016-09-29 | 2017-01-04 | 南京中新赛克科技有限责任公司 | 一种基于分布式消息队列的数据总线实现方法和装置 |
| CN106357799B (zh) * | 2016-10-20 | 2020-03-27 | 杭州东方通信软件技术有限公司 | 服务总线中间件***及其调用方法 |
| CN106790402B (zh) * | 2016-11-29 | 2020-10-23 | 苏州浪潮智能科技有限公司 | 信息化体系结构中间件数据并行分发方法及*** |
| CN107592351B (zh) * | 2017-09-06 | 2021-01-12 | 北京锐安科技有限公司 | 一种基于Redis的多用户发布订阅方法及*** |
| CN107580061A (zh) * | 2017-09-15 | 2018-01-12 | 无锡南理工科技发展有限公司 | 多流实时管理无线中间件的框架*** |
| CN107729161B (zh) * | 2017-09-28 | 2020-08-11 | 平安普惠企业管理有限公司 | 信息通知方法、***、设备及计算机可读存储介质 |
| CN107809475B (zh) * | 2017-10-19 | 2020-12-04 | 中国科学院电工研究所 | 一种能源互联网物理信息***的多源信息交互方法 |
| CN107920116B (zh) * | 2017-11-17 | 2020-12-08 | 中国航空工业集团公司西安航空计算技术研究所 | 一种可动态扩展的机载网络服务数据通信方法 |
| CN108595483B (zh) * | 2018-03-13 | 2020-11-24 | 腾讯科技（深圳）有限公司 | 数据处理方法及相关装置 |
| CN108875086B (zh) * | 2018-07-18 | 2023-03-28 | 山东中创软件商用中间件股份有限公司 | 一种uri路径资源的匹配方法及*** |
| CN109284482B (zh) * | 2018-10-25 | 2024-06-07 | 百度在线网络技术（北京）有限公司 | 写作平台***及用于写作平台的文章发布方法 |
| CN111221659B (zh) * | 2018-11-23 | 2023-10-03 | 北京图森智途科技有限公司 | 一种多机器人操作***环境的订阅性能追踪*** |
| CN109656726B (zh) * | 2018-11-28 | 2020-10-23 | 中国船舶重工集团公司第七一九研究所 | 一种适用于数据中心的工业信息交互***及方法 |
| CN109677465B (zh) * | 2018-12-29 | 2024-07-16 | 卡斯柯信号有限公司 | 用于轨道交通综合监控***的分布式实时***架构 |
| CN112995266B (zh) * | 2019-12-18 | 2022-07-26 | 深圳云天励飞技术有限公司 | 一种信息推送方法及相关设备 |
| CN111124428A (zh) * | 2019-12-18 | 2020-05-08 | 广东电网有限责任公司 | 一种基于中创中间件的应用自动化发布方法和相关装置 |
| CN111371621A (zh) * | 2020-03-12 | 2020-07-03 | 浪潮通用软件有限公司 | 基于混合云的数据交换方法、装置及计算机可读介质 |
| CN112328404B (zh) * | 2020-11-26 | 2023-08-08 | 北京百度网讯科技有限公司 | 负载均衡方法及装置、电子设备、计算机可读介质 |
| CN112437162A (zh) * | 2020-12-03 | 2021-03-02 | 中国船舶工业***工程研究院 | 基于订阅与发布机制的无人艇信息交互方法、***及终端 |
| CN112689020B (zh) * | 2020-12-30 | 2023-08-04 | 北京锐安科技有限公司 | 一种消息传输方法、消息中间件、电子设备及存储介质 |
| CN113079087B (zh) * | 2021-03-31 | 2022-11-22 | 上海天旦网络科技发展有限公司 | 互联数据网关、基于互联数据网关的数据处理***和方法 |
| CN113641139B (zh) * | 2021-08-05 | 2022-11-25 | 珠海格力电器股份有限公司 | 可实现异步编程的***、控制器、控制***、存储介质 |
| CN113709250B (zh) * | 2021-08-31 | 2023-09-15 | 中国电子科技集团公司第二十八研究所 | 一种基于订阅发送模式的跨域用户数据同步方法 |
| CN114629904B (zh) * | 2022-02-15 | 2024-05-24 | 广州伊智信息科技有限公司 | 一种分布式事件的处理方法、***、设备及介质 |
| CN115190164B (zh) * | 2022-06-24 | 2023-11-03 | 弥费科技(上海)股份有限公司 | 网络通信方法、装置、计算机设备和存储介质 |
| CN115514609B (zh) * | 2022-08-31 | 2024-05-03 | 北京控制工程研究所 | 一种Socket链路受限的发布订阅***及方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101930656A (zh) * | 2010-07-30 | 2010-12-29 | 武汉虹信通信技术有限责任公司 | 平安城市视频监控***告警消息处理方法 |
| CN103154944A (zh) * | 2010-09-29 | 2013-06-12 | 国际商业机器公司 | 适应性基于内容的发行/订阅消息传递 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101594377A (zh) * | 2008-05-28 | 2009-12-02 | 国际商业机器公司 | 用于管理Feed数据的***和方法 |
| CN101388027A (zh) * | 2008-10-09 | 2009-03-18 | 浙江大学 | 一种基于语义的数据服务糅合方法 |
| CN101854338B (zh) * | 2009-03-31 | 2014-02-26 | 国际商业机器公司 | 订户设备及其订阅管理方法、实时通信方法和*** |
| CN102255934B (zh) * | 2010-05-20 | 2015-10-21 | 中兴通讯股份有限公司 | 云服务发布方法及云服务中介 |
| CN102629939B (zh) * | 2012-03-14 | 2014-11-19 | 广东电网公司电力科学研究院 | 电力企业服务总线实现方法及装置 |
| CN103795689A (zh) * | 2012-10-29 | 2014-05-14 | 中兴通讯股份有限公司 | 资源订阅方法及装置 |
-
2014
- 2014-05-15 CN CN201410205763.XA patent/CN103944924B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101930656A (zh) * | 2010-07-30 | 2010-12-29 | 武汉虹信通信技术有限责任公司 | 平安城市视频监控***告警消息处理方法 |
| CN103154944A (zh) * | 2010-09-29 | 2013-06-12 | 国际商业机器公司 | 适应性基于内容的发行/订阅消息传递 |
Non-Patent Citations (2)
| Title |
|---|
| A Publish/Subscribe Middleware for Dependable and Real-time Resource Monitoring in the Cloud;Kyoungho An et al;《SDMCMM 12 Proceedings of the workshop on secure and dependable middleware for cloud monitoring and management》;20121205;全文 * |
| Publish/Subscribe Middleware for Energy-Eff cient Mobile Crowdsensing;Ivana Podnar ˇZarko et al;《UbiComp 13 Adjunct Proceedings of the 2013 ACM conference on Pervasive and ubiquitous computing adjunct publication》;20130912;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN103944924A (zh) | 2014-07-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103944924B (zh) | 一种基于RESTful的泛在网发布订阅中间件模型的方法 | |
| CN101371237B (zh) | 在网络元件中代表应用执行消息有效载荷处理功能 | |
| CN102938731B (zh) | 一种基于代理缓存适配模型的交换集成装置及方法 | |
| US7995519B2 (en) | Centralised management for a set of network nodes | |
| CN101365119B (zh) | 用于网络视频监控***所使用的录像负载均衡方法 | |
| US20140324473A1 (en) | System and Method for Providing Patient Record Synchronization in a Healthcare Setting | |
| CN110266783B (zh) | 一种基于dds的铁路ctc***通信平台 | |
| CN106210099B (zh) | 数据处理***及方法 | |
| CN101854351A (zh) | 用于基于标准的消息传输的***和/或方法 | |
| CN101268450B (zh) | 用于部署ems供给服务的方法和装置 | |
| JP2005517234A (ja) | 自動メッセージ処理システムとプロセス | |
| CN104168333A (zh) | Proxzone服务平台的工作方法 | |
| EP2487870B1 (en) | Method for naming sensor devices in a local network, service gateway and remote management server | |
| CN101854348B (zh) | Soa在******访问核心支撑***的实现方法 | |
| CN101420391A (zh) | 由触发器子***提供专用及基于标准触发器的***和方法 | |
| CN109150858A (zh) | 数据交互总线的请求处理方法、设备、***及存储介质 | |
| CN1941771B (zh) | 用于面向服务的体系结构应用的Web服务信息管理方法和*** | |
| CN101360129A (zh) | 网络视频监控***手机短信发送方法 | |
| CN109413040A (zh) | 消息鉴权方法、设备、***及计算机可读存储介质 | |
| WO2013126430A1 (en) | Systems and methods involving virtual machine host isolation over a network | |
| CN101277212A (zh) | 资源管理平台及资源管理方法 | |
| US20180191858A1 (en) | System for managing data of user devices | |
| CN104410556A (zh) | 一种基于iec61970标准的双向互动终端集成架构 | |
| CN105959385A (zh) | 一种信息通信方法、装置及*** | |
| CN102916830A (zh) | 一种资源服务优化配置容错管理实现*** |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |