一种基于RESTful的泛在网发布订阅中间件模型的制作方法
【专利摘要】本发明公开了一种基于RESTful的泛在网发布订阅中间件模型，属于通信【技术领域】，该发布订阅中间件模型包括以下几个组成部分：发布/订阅中间件基础模型；订阅中间件中的消息格式、流程和订阅条件过滤器；发布中间件中的消息格式、流程和节点间消息传递机制；用于处理发布/订阅中间件错误信息的容错机制。与现有技术相比，本发明基于REST架构，相比于SOAP和WDSL，使用双向节点，减少功能模块数量，同时，通过对泛在网中的信息的生产者和消费者之间设置一个中间件来进行交互，在实现泛在网中多对多的通信方式的同时，信息消费者能够通过中间件，及时、可靠地得到发布的感兴趣消息，使得消息的生产者和订阅者在时间、空间上完全解耦。
【专利说明】—种基于RESTfuI的泛在网发布订阅中间件模型
【技术领域】
[0001]本发明属于通信【技术领域】，涉及一种基于RESTful的泛在网发布订阅中间件模型。
【背景技术】
[0002]传统的通信模式(如客户机/服务器，RPC调用，消息队列等)，发送消息然后等待响应，使得消息的请求者和发送者在时间上，空间上存在着紧耦合的关系，面对大规模的分布式系统显得力不从心。通过使用发布订阅的中间件模型，可以让消息的生产者和订阅者在时间，空间上完全解耦，实现多对多的通信方式。而REST作为一种设计Web服务的方法，其对专有中间件(例如某个应用程序服务器)的依赖比基于SOAP和WSDL的方法更少。将这REST和中间件结合起来可以得到更好的订阅/发布模型。
【发明内容】
[0003]有鉴于此，本发明的目的在于提供一种基于RESTful的泛在网发布订阅中间件模型。
[0004]为达到上述目的，本发明提供如下技术方案:
[0005]一种基于RESTful的泛在网发布订阅中间件模型，包括以下几个组成部分:发布/订阅中间件基础模型；订阅中间件中的消息格式、流程和订阅条件过滤器；发布中间件中的消息格式、流程和节点间消息传递机制；用于处理发布/订阅中间件错误信息的的容错机制。
[0006]进一步，所述基础模型由以下几个部分组成:1)发布/订阅中间件模型中的成员；2)发布/订阅中间件模型的主要活动角色；3)发布/订阅中间件模型管理单元；
[0007]所述模型中的成员主要是事件主题，事件主题可以由参与者中的发布者进行发布，也可以能由参与者中的订阅者提出；
[0008]所述模型的主要活动角色是发布者与订阅者，两者的关系是相对于事件主题而言的，发布者和订阅者的注册方式通过泛在网统一的标识方式进行规范化管理；
[0009]所述中间件模型管理单元，包含了主要的通信特征，并封装了 REST传输协议、REST消息编码、REST通信模式、可靠性、安全性、事务管理及互操作性等主要元素，定义各类REST传输协议的抽象接口，包括回调接口和服务绑定。
[0010]进一步，所述订阅中间件中的消息格式由以下几个部分构成:订阅中间件消息类型、订阅ID、订阅命令、订阅消息传输位置、订阅消息优先级、订阅时间戳和反馈消息；
[0011]所述订阅ID指与订阅者一一对应；订阅中间件消息类型包括了订阅客户端中登录、注册、注销消息以及系统中的订阅和响应消息；订阅命令指判断是否发送订阅条件以及订阅者对订阅条件的更新、取消；订阅消息传输位置与功能模块或中间节点对应，并对传输路径缓存记录；订阅消息优先级是指在超出服务器负载情况下，消息传递需要有先后顺序，可以用收费的方式实现；订阅时间戳用于记录订阅消息存在于系统的时间，时间过长会被删除；反馈消息由匹配到的发布内容和系统返回的错误提醒组成，错误提醒包括了订阅条件出错和系统/网络出错。
[0012]进一步，所述订阅中间件流程，通过以下四个步骤进行:步骤一:订阅者进行注册，由此进入订阅客户端；步骤二:用户在客户端中提出订阅条件并发送给订阅管理器；步骤三:订阅管理器将订阅条件发送到数据库，在其中匹配订阅条件；步骤四:数据库在匹配过后将结果经由订阅管理器传送到订阅客户端；
[0013]订阅客户端是指用户查找订阅信息时的操作平台；订阅管理器的功能是存储和检索订阅条件，将订阅条件转化为与数据库相容的REST数据，并提供REST服务接口进行订阅或退订服务；数据库中包含有订阅条件过滤器，用以提高匹配效率。
[0014]进一步，所述订阅条件过滤器用于对经泛在网统一的标识方式标识后的主题进行筛选；所述订阅条件过滤器的主要功能为匹配订阅条件，筛选时就订阅条件进行拆分，区分订阅条件中名词与名词之间的重要性程度，以更重要的名词作为条件进行筛选，筛选结果排在次要名词筛选的结果之前，或者建立多级过滤器，由订阅者自行选择，进一步减少筛选次数；
[0015]所述的订阅条件过滤器在具体设计时还应考虑筛选时间、筛选空间以及事件数据本身的更新，筛选时间就是订阅者在输入订阅条件以后得到结果的时间，空间是指数据存储的空间，事件数据更新就是指发布者新发布的数据和订阅者增加或者取消的订阅。
[0016]进一步，所述发布中间件消息格式采用REST风格，由发布消息头和发布消息体构成；其中发布消息头包括了发布ID、发布中间件消息类型、发布命令、发布消息传输位置、权限和发布时间戳；发布消息体包括了发布内容和反馈信息；
[0017]发布ID指与发布者一一对应；发布中间件消息类型包括了发布客户端中登录、注册、注销消息、系统中的发布、响应消息以及发布者控制和发布内容是否为公共信息；发布命令指判断是否发送发布内容以及发布者对发布内容的更新、取消；发布消息传输位置与功能模块或中间节点对应，并对传输路径缓存记录；权限是指在分为发布者权限与发布内容权限；发布者权限高低与发布内容被订阅次数多少挂钩，发布内容权限指发布者对发布内容可见性的限定；发布时间戳用于记录发布消息存在于系统的时间，时间过长会被删除；反馈消息由订阅情况和系统返回的错误提醒组成，订阅情况指订阅者对于发布内容的订阅次数以及后续要求，错误提醒包括了发布内容出错和系统/网络出错。
[0018]进一步，所述发布中间件流程包括以下四个步骤:步骤一:发布者在发布注册管理器进行注册；步骤二:发布者在发布客户端进行事件或者主题的发布；步骤三:发布的内容通过发布管理器传送到数据库；步骤四:数据库存储发布内容；
[0019]所述发布注册管理器首先提供发布者进行注册；发布客户端是发布者的开发并传送结果的平台，发布管理器存储发布内容并转化为与数据库相容的格式，提供REST发布服务接口用以管理来自发布客户端的通知发布请求信息；数据库保存有价值的发布内容等待订阅条件的匹配。
[0020]进一步，所述的基于RESTful的泛在网发布/订阅中间件消息传递机制，采用RESTful标识类型对每一个节点的位置进行标识；并包含有各类REST传输网络协议，并可以添加验证码保证安全性；节点位于每个功能模块中间，帮助消息在其中相互传递；相比于SOAP中节点只能单向传输，REST中的节点能够达到双向传输:可以从上一级接收消息发送到下一级，也可以从下一级接收消息返回上一级，减少节点数量，简化系统。
[0021]所述发布/订阅中间件消息传递机制中的节点是消息传递机制中的最小逻辑组成，且每个节点相互独立，消息传递时，节点根据消息命令，进行一个或者多个节点间传递;
[0022]所述节点由三个部分组成:接收器、传输系统、发送器；接收器接收命令消息并将订阅信息发送给传输系统；传输系统通过命令消息进行判断如何进行下一步传送，并将命令消息发送给接收器。
[0023]传送原则就是信息传送方式以及传送路径，多数情况下需经过一些中间节点的处理，发送信息才能够到达指定节点；传送原则也包含了当出现了错误，不能够传送到目的节点时的解决方案:可选择把消息先传送到后备处理节点，或者暂存到规定的缓存队列中，等待继续传送的命令消息。
[0024]进一步，所述的泛在网发布/订阅中间件容错机制由三个方面组成:硬件容错机制、软件容错机制及传输容错机制；
[0025]所述的硬件容错机制采用状态评估系统，中间件在运行时可能会出现硬件故障，通过在C/S模式下运用心跳信号机制实现对系统的维护；
[0026]所述的软件容错机制采用日志系统，软件运行日志主要用于开发调试阶段和软件交付使用阶段提供快速跟踪、定位错误位置的工具，为调试、排故提供了有效手段，通过将日志信息分级，出现错误时从最低级信息开始发送给管理人员，不能解决就传送较高的信息，实现快速解决问题；
[0027]所述的传输容错机制，传送过程中如果出现了异常，判断出是错误信息就直接丢弃，判断出需要继续传送，就选择最短的一条链路，如果必须经过某些节点，就进行多次选择。
[0028]本发明的有益效果在于:本发明提供了一种基于RESTful的泛在网发布订阅中间件模型，与现有技术相比，本发明基于REST架构，相比于SOAP和WDSL，使用双向节点，减少功能模块数量，同时，通过对泛在网中的信息的生产者和消费者之间设置一个中间件来进行交互，在实现泛在网中多对多的通信方式的同时，信息消费者能够通过中间件，及时、可靠地得到发布的感兴趣消息，使得消息的生产者和订阅者在时间、空间上完全解耦。
【专利附图】
【附图说明】
[0029]为了使本发明的目的、技术方案和有益效果更加清楚，本发明提供如下附图进行说明:
[0030]图1为泛在网发布/订阅中间件关系图；
[0031]图2为泛在网发布/订阅中间件订阅条件过滤器示意图；
[0032]图3为泛在网发布/订阅中间件节点及路由机制示意图；
[0033]图4为泛在网发布/订阅中间件流程示意图。
【具体实施方式】
[0034]下面将结合附图，对本发明的优选实施例进行详细的描述。
[0035]本发明实施例的一种基于RESTful的泛在网发布/订阅中间件模型，该基于RESTful的泛在网发布与订阅中间件由以下几部分组成:
[0036]发布/订阅中间件基础模型；
[0037]订阅中间件中的消息格式、流程和订阅条件过滤器；
[0038]发布中间件中的消息格式、流程和节点间消息传递机制；
[0039]用于处理发布/订阅中间件错误信息的的容错机制。
[0040]基于RESTful的“发布/订阅”模式不仅能够在同一时间提供一对多、多对一以及多对多的异步通信模式，而且它能解除泛在网中用户在时间和空间上的限制，即松耦合，这正是大规模分布式网络系统所要求的。
[0041]I)本发明实施例的发布/订阅中间件基础模型中成员关系如图1所示:
[0042]1.1)发布/订阅中间件模型中成员包括参与者、管理单元和主题等，其中主题是主要对象，由参与者创建或者关注主题可以有多个。
[0043]1.2)模型的主要活动角色为参与者，其可创建任何自己关注的主题。其中一部分的人作为发布者通过数据发送模块，发布自己能够提供的信息或者能力；另一部分作为订阅者在这其中选择自己感兴趣的信息或能力。
[0044]作为优化方案，发布者、订阅者的注册方式可以通过泛在网统一标识方式进行规范化管理，方便两者的查询和联系，提供更大的合作空间。
[0045]1.3)管理单元:包含了主要的通信特征；封装了 REST传输协议:不仅包括了 SOAP和WSLD包括的HTTP和XML，还有HTML、URI等；封装了 REST消息编码、REST通信模式、可靠性、安全性、事务管理及互操作性等主要元素；定义各类REST传输协议的抽象接口，包括回调接口、服务绑定等，实现与多种应用系统之间的互操作，使得发布/订阅系统能在泛在网的任意网络类型里面使用。
[0046]2)订阅中间件消息格式、订阅中间件流程及订阅条件过滤器
[0047]2.1)作为优化方案，订阅中间件消息格式运用了 REST风格，由以下订阅消息头和订阅消息体构成；其中消息头包括了订阅ID、订阅消息类型、订阅命令、消息传输位置、订阅消息优先级和订阅时间戳；消息体包括了订阅条件和反馈信息。
[0048]2.1.1)订阅消息头
[0049]SubID (订阅ID):8字节，与订阅者注册账号——对应；
[0050]SubMSGType (订阅消息类型):3字节，001表示登录，010表示注册，011表示注销，100表示订阅，101表示响应。
[0051]SubOrder (订阅命令):2字节，00表示发送订阅条件，01表示不发送订阅条件:订阅者在登陆状态下进行发送，订阅者注销或退出时不发送，并删除此时的订阅命令；10表示对订阅条件的更新，11表示订阅者取消订阅。
[0052]SubMSGPosition (订阅消息传输位置):4字节，与订阅客户端、订阅管理器以及它们的中间节点对应，并对传输路径缓存记录。
[0053]SubMSGPriority (订阅消息优先级):2字节，在超出服务器负载或负载大的情况下，消息传递需要有先后顺序。
[0054]作为优化方案，上述优先级的处理可以通过收费的方式实现:在服务器忙碌时收费用户的优先级高于未收费的用户:00表示免费用户，01表示初级会员，10表示中级会员，11表示高级会员，等级依次提高；具体来说:收费用户不仅优先级高，还可以拥有更多的订阅缓存空间，会对提高在服务器上订阅请求保存的时间，并且如果处于离线状态，系统会保存相应的通知或者匹配到的内容，再次上线时，系统自动取出该消息并发送给收费用户。
[0055]SubTimestamp (订阅时间戳)'2字节,用于记录订阅消息存在于系统的时间，并设定最高保存时长Tl与之相比较，大于Tl会丢弃消息，订阅者等级越高，Tl的值越大。
[0056]2.1.2)订阅消息体
[0057]SubRequirement (订阅条件):订阅者提出的订阅条件保存其中；
[0058]FeedbackMSG (反馈信息):由匹配到的发布内容和系统返回的错误提醒组成；匹配到的发布内容指与订阅条件基本相符的内容；错误提醒包括了订阅条件出错和系统/网络出错，反馈给订阅者相关信息及处理方法。
[0059]2.2)作为优化方案，订阅中间件流程如图4所示:
[0060]步骤一:订阅者进行注册，由此进入订阅客户端；
[0061]步骤二:用户在客户端中提出订阅条件并发送给订阅管理器；
[0062]步骤三:订阅管理器将订阅条件发送到数据库，在其中匹配订阅条件；
[0063]步骤四:数据库在匹配过后将结果经由订阅管理器传送到订阅客户端。
[0064]作为优化方案，整个消息传输过程中使用REST协议进行传输。订阅客户端是指用户查找订阅信息时的操作平台；订阅管理器的功能是存储和检索订阅条件，将订阅条件转化为与数据库相容的REST数据，并提供REST服务接口进行订阅或退订服务。数据库中包含有订阅条件过滤器，用以提高匹配效率。
[0065]2.3)作为优化方案，如图2，订阅条件过滤器的性能主要体现在对订阅者提出的订阅条件的内容匹配，主要应考虑以下几点:
[0066]I)筛选对订阅条件进行拆分；2)区分订阅条件中名词与名词之间的重要性程度，以更重要的名词作为条件进行筛选，筛选结果排在次要名词筛选的结果之前；3)筛选时同样的内容只需过滤一次，主要内容大多在名词上有了体现，所以可以排除很多不必要的内容，从而减少筛选次数；4)建立多级过滤器，可以在拆分后的名词搜索结果中继续检索，或者订阅者可以每次对一个关键词进行搜索，这样可以进一步减少筛选次数。
[0067]作为优化方案，设计订阅条件过滤器主要考虑的因素还有筛选时间、筛选空间以及事件数据更新。
[0068]进一步，需要筛选的时间就是订阅者在输入订阅条件以后得到结果的时间；空间是指数据存储的空间；事件数据更新指发布者新发布的数据和订阅者增加或取消的订阅。
[0069]进一步，可利用泛在网的大量数据和RESTful的各类标记语言(例如URI)作为基础，进行数据分块整理，根据历史检索记录把信息进行分类，这样不仅能获得最大化的数据存储，也为筛选时提供更精确的导向。
[0070]3)发布中间件消息格式、发布中间件流程和中间件中节点间消息传递机制
[0071]3.1)作为优化方案，发布中间件消息格式运用了 REST风格，由以下发布消息头和发布消息体构成；其中发布消息头包括了发布ID、发布消息类型、发布命令、消息传输位置、权限和发布时间戳；发布消息体包括了发布内容和反馈信息。
[0072]3.1.1)发布消息头
[0073]PubID (发布ID):8字节,与发布者注册账号 对应；
[0074]PubMSGType (发布消息类型):3字节，001表示登录，010表示注册，011表示注销，100表不订阅，101表不响应，110表不发布者对发布内容的修改的控制信息，111表不发布者发出的所有用户可见的公共信息。
[0075]PubOrder (发布命令):2字节，00表示发送发布内容，01表示不发送发布内容:发布通过审核且检查后没有重复的内容，不符合条件的不进行发布；10表示对发布内容的更新，11表示发布者取消发布。
[0076]PubMSGPosition (发布消息传输位置):4字节，与功能模块或中间节点对应，并对传输路径缓存记录。
[0077]Permission (权限):4字节，分为发布者权限与发布内容权限；发布者权限高地与发布内容被订阅次数多少挂钩，发布者权限高会在审核发布内容时获得快速通道，减少过程耗时并尽早发布；发布内容权限指发布者对发布内容可见性的限定:可以设定为只有收费用户甚至中、高级订阅者才能订阅，也可以设定为所有订阅者可见。
[0078]PubTimestamp (发布时间戳):2字节,用于记录发布消息存在于系统的时间，并设定最长保存时长T2与之相比较，在T2间无任何响应会删除发布消息，发布者权限越高，T2的值越大。
[0079]3.1.2)发布消息体
[0080]PubContent (发布内容):发布者的发布内容保存其中；
[0081]FeedbackMessage (反馈信息):由订阅情况和系统返回的错误提醒组成；订阅情况指订阅者对于发布内容的订阅次数以及后续要求；错误提醒包括了发布内容未通过和系统/网络出错，反馈给发布者相关信息及处理方法。
[0082]3.2)作为优化方案，发布中间件流程如图4所示:
[0083]步骤一:发布者在发布注册管理器进行注册；
[0084]步骤二:发布者在发布客户端进行事件或者主题的发布；
[0085]步骤三:发布的内容通过发布管理器传送到数据库；
[0086]步骤四:数据库存储发布内容。
[0087]作为优化方案，发布者注册管理器首先提供发布者进行注册。注册后可以进行存储、检索、查找REST服务接口以及注销服务，还接受来自订阅客户端的查询；发布客户端是发布者的开发并传送结果的平台:不仅包括了电脑操作系统如Windows、Linux、MacOS,还包括了各类android软件平台、APPStore以及运营商的自建平台；发布管理器存储发布内容并转化为与数据库相容的格式，还提供了 REST发布服务接口用以管理来自发布客户端的通知发布请求信息；传送过程中系统会对发布内容与已发布的内容进行比较，删除重复或者无用的内容，保存有价值的发布内容等待订阅条件的匹配。数据库中还记录发布内容存在于系统的时间，并设定最长保存时长T3，在T3间无任何订阅情况会删除此条发布内容，发布者权限越高，T3的值越大。
[0088]3.3)本发明实施例的中间件中节点间消息传递机制，如图3所示，其特征在于:
[0089]作为优化方案，本发明采用了 RESTful标识类型对每一个节点的位置进行标识。
[0090]作为优化方案，节点的位置信息由RESTful标识进行统一编码。
[0091]作为优化方案，节点位于每个功能模块中间，帮助消息在其中相互传递；相比于SOAP中节点只能单向传输，REST中的节点能够达到双向传输:可以从上一级接收消息发送到下一级，也可以从下一级接收消息返回上一级，减少节点数量，简化系统。[0092]进一步，由于传输载体不同，节点中位置信息的还应该包含有各类REST传输网络协议以配合节点间的传输，若需要进行保密或者防止恶意软件增加系统负荷，可以添加验证码等附加信息。
[0093]进一步，节点是消息传递机制中的最小逻辑组成，它的内部环境以及构成与外部环境甚至其他节点都没有必然联系，每个节点相互独立。
[0094]进一步,消息传递时,节点根据消息命令，进行一个或者多个节点间传递。
[0095]作为优化方案，节点由三个部分组成:接收器、传输系统、发送器。
[0096]进一步，消息传递机制的特征在于，包括以下三个步骤:步骤一:接受器在收到命令消息时，判断需要使用的节点，将用户需求信息(订阅条件)发送给对应一个或者都过节点的传输系统；步骤二:传输系统经过一定的处理传送到发送器；步骤三:发送器根据输出命令信息将用户需求信息发送到目的节点。
[0097]进一步，需要注意的是，信息转发过后在一定的时间范围内会缓存在节点中，如果其他节点收到命令转发相同信息，就会被舍弃，从以前的节点开始转发，这样可以避免不必要的转发。
[0098]4)发布/订阅中间件容错机制
[0099]作为优化方案，发布/订阅中间件容错机制由三个方面组成:硬件容错机制、软件容错机制及传输容错机制。
[0100]4.1)硬件容错机制:状态评估系统对于硬件检测有较好的效果。其特征在于:中间件在使用时并不只是处于被动(静态)模式，一旦一些较为复杂的软件或者过多的软件在其中运行时可能会出现硬件故障。当出现这种情况，就立即进行收集并评估状态反馈给管理人员。同时系统会根据当时使用情况调用备用服务器或者流量控制，保证系统正常运行。
[0101]作为优化方案，状态评估系统在C/S模式下通过心跳机制实现，步骤如下:
[0102]步骤一:将服务端驻留在各类硬件中，收集工作状态，存储在心跳信号中；
[0103]步骤二:根据服务器繁忙或空闲状态，设定较长或较短的间隔时间，将心跳信号通过节点发送到管理人员的客户端；
[0104]步骤三:如果在一定时间内没有收到心跳信号，表示硬件已经出现问题(断线或损坏)，管理人员应立即进行检查修复，并且修复完成后保证心跳信号恢复运行。
[0105]4.2)软件容错机制:日志系统适于用软件错误机制。其特征在于:软件运行日志主要用于开发调试阶段和软件交付使用阶段提供快速跟踪、定位错误位置的工具，为调试、排故提供了有效手段。日志系统中的信息包括了进入退出信息、软件运行状态、其它重要信息(例如，本节点发布、订阅的主题名，订阅方的IP、端口等)以及错误信息；通过设定信息输出的级别控制来决定要输出的信息种类与数量:A所有信息、B软件运行状态状态及错误信息、C错误信息；软件出现错误时根据历史记录传送最少的信息到控制台进行解决，如果没有出现过的错误按照C — B — A的顺序进行信息传输，信息越少传输速度越快，有利于问题快速解决。
[0106]4.3)传输容错机制:在大多数情况下，只有经过必要的中间节点进行处理后，发送信息才能够到达指定位置。传送过程中如果出现了错误，就不能够传送到目标位置时。如图3所示，解决方案:选择把消息先传送到后备处理节点，或暂存到规定的缓存队列中，等待继续传送的命令消息。情况I)判断出是错误信息就直接丢弃；情况2)需要继续传送，就选择最短的一条链路。如果必须经过某些节点，就进行多次选择。
[0107]最后说明的是，以上优选实施例仅用以说明本发明的技术方案而非限制，尽管通过上述优选实施例已经对本发明进行了详细的描述，但本领域技术人员应当理解，可以在形式上和细节上对其作出各种各样的改变，而不偏离本发明权利要求书所限定的范围。
【权利要求】
1.一种基于RESTful的泛在网发布订阅中间件模型，其特征在于:包括以下几个组成部分:发布/订阅中间件基础模型；订阅中间件中的消息格式、流程和订阅条件过滤器；发布中间件中的消息格式、流程和节点间消息传递机制；用于处理发布/订阅中间件错误信息的的容错机制。
2.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型，其特征在于:所述基础模型由以下几个部分组成:1)发布/订阅中间件模型中的成员；2)发布/订阅中间件模型的主要活动角色；3)发布/订阅中间件模型管理单元； 所述模型中的成员主要是事件主题，事件主题可以由参与者中的发布者进行发布，也可以能由参与者中的订阅者提出； 所述模型的主要活动角色是发布者与订阅者，两者的关系是相对于事件主题而言的，发布者和订阅者的注册方式通过泛在网统一的标识方式进行规范化管理； 所述中间件模型管理单元，包含了主要的通信特征，并封装了 REST传输协议、REST消息编码、REST通信模式、可靠性、安全性、事务管理及互操作性等主要元素，定义各类REST传输协议的抽象接口，包括回调接口和服务绑定。
3.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型，其特征在于:所述订阅中间件中的消息格式由以下几个部分构成:订阅中间件消息类型、订阅ID、订阅命令、订阅消息传输位置、订阅消息优先级、订阅时间戳和反馈消息； 所述订阅ID指与订阅者一一对应；订阅中间件消息类型包括了订阅客户端中登录、注册、注销消息以及系统中的订阅和响应消息；订阅命令指判断是否发送订阅条件以及订阅者对订阅条件的更新、取 消；订阅消息传输位置与功能模块或中间节点对应，并对传输路径缓存记录；订阅消息优先级是指在超出服务器负载情况下，消息传递需要有先后顺序；订阅时间戳用于记录订阅消息存在于系统的时间，时间过长会被删除；反馈消息由匹配到的发布内容和系统返回的错误提醒组成，错误提醒包括了订阅条件出错和系统/网络出错。
4.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型，其特征在于:所述订阅中间件流程，通过以下四个步骤进行:步骤一:订阅者进行注册，由此进入订阅客户端；步骤二:用户在客户端中提出订阅条件并发送给订阅管理器；步骤三:订阅管理器将订阅条件发送到数据库，在其中匹配订阅条件；步骤四:数据库在匹配过后将结果经由订阅管理器传送到订阅客户端； 订阅客户端是指用户查找订阅信息时的操作平台；订阅管理器的功能是存储和检索订阅条件，将订阅条件转化为与数据库相容的REST数据，并提供REST服务接口进行订阅或退订服务；数据库中包含有订阅条件过滤器，用以提高匹配效率。
5.根据权利要求4所述的一种基于RESTful的泛在网发布订阅中间件模型，其特征在于:所述订阅条件过滤器用于对经泛在网统一的标识方式标识后的主题进行筛选；所述订阅条件过滤器的主要功能为匹配订阅条件，筛选时就订阅条件进行拆分，区分订阅条件中名词与名词之间的重要性程度，以更重要的名词作为条件进行筛选，筛选结果排在次要名词筛选的结果之前，或者建立多级过滤器，由订阅者自行选择，进一步减少筛选次数； 所述的订阅条件过滤器在具体设计时还应考虑筛选时间、筛选空间以及事件数据本身的更新，筛选时间就是订阅者在输入订阅条件以后得到结果的时间，空间是指数据存储的空间，事件数据更新就是指发布者新发布的数据和订阅者增加或者取消的订阅。
6.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型，其特征在于:所述发布中间件消息格式采用REST风格，由发布消息头和发布消息体构成；其中发布消息头包括了发布ID、发布中间件消息类型、发布命令、发布消息传输位置、权限和发布时间戳；发布消息体包括了发布内容和反馈信息； 发布ID指与发布 者一一对应；发布中间件消息类型包括了发布客户端中登录、注册、注销消息、系统中的发布、响应消息以及发布者控制和发布内容是否为公共信息；发布命令指判断是否发送发布内容以及发布者对发布内容的更新、取消；发布消息传输位置与功能模块或中间节点对应，并对传输路径缓存记录；权限是指在分为发布者权限与发布内容权限；发布者权限高低与发布内容被订阅次数多少挂钩，发布内容权限指发布者对发布内容可见性的限定；发布时间戳用于记录发布消息存在于系统的时间，时间过长会被删除；反馈消息由订阅情况和系统返回的错误提醒组成，订阅情况指订阅者对于发布内容的订阅次数以及后续要求，错误提醒包括了发布内容出错和系统/网络出错。
7.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型，其特征在于:所述发布中间件流程包括以下四个步骤:步骤一:发布者在发布注册管理器进行注册；步骤二:发布者在发布客户端进行事件或者主题的发布；步骤三:发布的内容通过发布管理器传送到数据库；步骤四:数据库存储发布内容； 所述发布注册管理器首先提供发布者进行注册；发布客户端是发布者的开发并传送结果的平台，发布管理器存储发布内容并转化为与数据库相容的格式，提供REST发布服务接口用以管理来自发布客户端的通知发布请求信息；数据库保存有价值的发布内容等待订阅条件的匹配。
8.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型，其特征在于:所述的基于RESTful的泛在网发布/订阅中间件消息传递机制，采用RESTful标识类型对每一个节点的位置进行标识；并包含有各类REST传输网络协议，并可以添加验证码保证安全性；节点位于每个功能模块中间，帮助消息在其中相互传递； 所述发布/订阅中间件消息传递机制中的节点是消息传递机制中的最小逻辑组成，且每个节点相互独立，消息传递时，节点根据消息命令，进行一个或者多个节点间传递； 所述节点由三个部分组成:接收器、传输系统、发送器；接收器接收命令消息并将订阅信息发送给传输系统；传输系统通过命令消息进行判断如何进行下一步传送，并将命令消息发送给接收器。
9.根据权利要求1所述的一种基于RESTful的泛在网发布订阅中间件模型，其特征在于:所述的泛在网发布/订阅中间件容错机制由三个方面组成:硬件容错机制、软件容错机制及传输容错机制； 所述的硬件容错机制采用状态评估系统，中间件在运行时可能会出现硬件故障，通过在C/S模式下运用心跳信号机制实现对系统的维护； 所述的软件容错机制采用日志系统，软件运行日志主要用于开发调试阶段和软件交付使用阶段提供快速跟踪、定位错误位置的工具，为调试、排故提供了有效手段，通过将日志信息分级，出现错误时从最低级信息开始发送给管理人员，不能解决就传送较高的信息，实现快速解决问题； 所述的传输容错机制，传送过程中如果出现了异常，判断出是错误信息就直接丢弃，判断出需要继续传送， 就选择最短的一条链路，如果必须经过某些节点，就进行多次选择。
【文档编号】H04L29/08GK103944924SQ201410205763
【公开日】2014年7月23日 申请日期:2014年5月15日 优先权日:2014年5月15日
【发明者】张鹏, 程方, 蒋明浪, 卢毓岑, 朱建虎, 史涛, 张瑞 申请人:重庆邮电大学