一种网络应用节点的集成系统和方法与流程

文档序号:14574543发布日期:2018-06-02 01:11阅读:135来源:国知局
一种网络应用节点的集成系统和方法与流程

本发明涉及计算机系统领域,更具体的,涉及在以开放性网络应用架构中,用于在接入该网络的应用对象之间按照本系统的功能应用编程接口(以下简称API)元数据定义进行互操作的方法。



背景技术:

在现有技术中,为了实现互联网的应用软件或者物联网的应用设备的耦合,当前普遍使用基于API耦合的开发方法。在美国发明说明书US200301058887 A1中公开了一种用于软件应用集成的方法和系统,具有预定义低级API的功能,其API的定义与实现完全分离,调用过程与执行过程相分离,很好的实现了对应用程序的解耦。在这种系统与方法中,对低阶API的抽象难以实现统一的API参数验证,会在传输不合法的API调用对象(网络应用节点)即网络应用节点上浪费网络资源;对服务器端应用之间的API调用采用消息转发的形式,且未采用分布式进程相关技术构建,使得中心节点的数据吞吐和计算压力过大。

专利WO2013123445A1是一个典型的物联网设备平台,试图提供对连接(connectivity)、内容(content)、感知(cognitive)、上下文(context)、云服务(cloud)与协作(collaboration)的所谓”6C”对物联网进行服务能力整合,并针对物联网应用场景提供了服务支撑。但该系统过于强调“6C”,对“6C”物联网应用场景之外的既有软件应用整合能力不够,难以实现对复杂服务器系统/智能计算设备软件/既有软件业务系统等既有应用的有效整合。



技术实现要素:

本发明的目的是提供一种网络软件和设备应用的集成系统,和利用该系统实现网络应用节点间的调用方法;本系统通过建立各种应用设备和功能软件模块的一站式业务访问入口,实现软硬件应用节点的相互调用;通过建立对连接对象的业务状态反馈和关注通知机制,让开发者可以更加高效统一的实现对象状态维护的相关功能,不必自行设计复杂的数据结构和相关机制,更不必关注由此带来的一致性、性能等问题。

为实现以上发明的目的,本发明提供一种网络应用节点的集成系统,主要包括N个应用节点管理中心、M个前端服务模块,其中,M≥N≥1,所述各前端服务模块设有应用节点服务单元,各前端服务模块通过其应用节点服务单元与对应应用节点管理中心连接;其中,

所述各前端服务模块用于接入至少一个网络应用节点;

所述各应用节点管理中心用于统一定义并储存各网络应用节点的API元信息和/或状态元信息,其通过各应用节点服务单元间接管理由前端服务模块连接的各网络应用节点的调用信息与状态信息,实现对基于IP网络的各网络应用节点的统一管理;所述应用节点管理中心监控应用节点服务单元的在线状态,并在所述应用节点服务单元离线时修改其所连接的网络应用节点的连接状态;

所述各应用节点管理中心通过应用节点服务单元实现各应用节点管理中心、各应用节点服务单元、各网络应用节点中一种或多种之间的相互调用和/或交叉调用。

由于应用节点管理中心统一定义网络应用节点的API元信息,为接入的网络应用节点提供一站式的访问入口,使得网络应用节点不需要自行提供接口的授权和认证机制,实现了接入的网络应用节点对其他接入的网络应用节点的调用;

由于应用节点管理中心统一了接入的网络应用节点的状态元信息,为软硬件应用节点提供了统一、可靠、带有参数的对象连接和业务状态的带参数反馈和关注通知机制,让开发者可以更加高效统一的实现对象状态维护的相关功能,不必自行设计复杂的数据结构和相关机制,更不必关注由此带来的一致性、性能等问题,

为解决应用节点中心管理负载过重问题,本系统中应用节点管理中心对网络应用节点提供粗粒度状态管理,即应用节点管理中心只负责监控嵌入应用节点服务单元的前端服务模块存在状态,在前端服务模块因故离线后做出善后处理;每一级节点只负责接入和监测其直接下游级别节点的状态,使得系统在接入海量网络应用该节点时系统各结构负载不至于过重。当所述的某个前端应用服务模块失联异常时,所述应用节点服务单元将向上游汇报更新所有与该前端应用服务模块相关的网络应用节点的状态,确保系统中各级所管理的应用节点状态保持一致。

进一步地,为解决系统对接入的网络应用节点的状态信息获取与监控,所采用的技术是所述各应用节点服务单元封装了对应用节点管理中心的远程调用、对其他应用节点服务单元所连接网络应用节点的远程调用过程和对网络应用节点状态的监控逻辑,运行在相应前端服务模块内部,并被前端服务模块调用,应用节点服务单元监测连接到前端服务模块中网络应用节点的状态信息,并汇报给应用节点管理中心,应用管理中心根据相应的状态信息,指令应用节点服务单元执行相应的处理过程。通过此技术手段,令应用节点管理中心与网络应用节点关系更为紧密。

为解决系统接入网络应用节点数量上有限制的问题,进一步地,根据权利要求1所述的网络应用节点的集成系统,所采用的技术手段为,所述应用节点管理中心、前端服务模块、应用节点服务单元采用可扩展的分布式结构以实现服务能力的可扩展性,所述应用节点管理中心数量及前端服务模块数量根据所需接入该集成系统的网络应用节点数量确定;所述各网络应用节点包括至少一个应用实例。当网络应用节点为一个本系统账号在一个服务器端应用程序中所拥有的资源时,在具体实施例中可以理解为,一个服务平台的客户端在同一个人不同设备上的集合,每一个设备上的客户端都是一个实例(比如同一个人的微信客户端,在手机,平板,笔记本电脑的集合就属于一个网络应用节点)。在该技术方案中,由于系统各结构采用可扩展的分布式结构,可实现对海量、异构现有客户端/服务器软件应用和硬件应用的集成。

进一步地,所述的各应用节点服务单元通过中间件注册服务的方式向对应前端服务模块提供网络应用节点的元信息和/或状态信息的查询与变更通知服务,以实现应用节点管理中心通过分布式部署实现服务能力扩展。

在所有的上述技术中,所述的网络应用节点包括:嵌入式网络应用设备,分布式网络应用程序,聚合服务器客户端,客户端软件,硬件设备的中间件,一个本系统账号在一个服务器端应用程序中所拥有的资源。

所述的前端服务模块包括服务器端应用程序服务模块(service bus)、设备服务模块(device bus)、以及线下应用服务模块(page bus)等不类型的服务模块。不同类型的网络应用节点接入对应类型的前端服务模块中。

在上述所有的技术中,所述的各网络应用节点的状态元信息包括其接入认证信息、连接状态信息、所包含业务状态的列表、包含业务状态的状态机构成信息及其当前所处状态、所实现的API列表、API访问授权信息中的一种或多种。

在网络应用节点业务状态更新时,为了保证系统对更新的业务状态的同步,系统提供了网络应用节点业务状态的更新机制。

1.具体包括:由网络应用节点发起业务状态更新请求,传入参数包括:网络应用节点ID、所需更新的目标业务状态机ID(stateMachineID)、目标状态识别号(stateGroupID、stateID)、目标状态相关参数值;

2.由前端服务模块中的应用节点服务单元检查网络应用节点ID的连接状态是否为连接(ACTIVE),若不是则抛出规则异常;

3.由前端服务模块中的应用节点服务单元根据目标状态识别号(state GroupID、state ID)获取状态元信息,若无法获取则抛出规则异常;

4.由前端服务模块中的应用节点服务单元根据所获取的状态元信息检查目标业务状态在目标业务状态机中是否存在,若不存在则抛出规则异常;

5.由前端服务模块中的应用节点服务单元根据所获取的状态元信息检查目标业务状态相关参数的存在性(必要参数必须指定)、正确性,若不正确则抛出规则异常;

6.由前端服务模块中的应用节点服务单元访问应用节点管理中心更新业务状态,若更新失败则抛出数据系统异常。

为实现以上发明的目的,本发明还提供一种网络应用节点集成方法包括:

1)建立集成系统

建立不少于一个应用节点管理中心,其统一定义API元信息或/和状态元信息用于提供对基于IP网络的终端应用节点的统一元信息与状态信息管理服务;

建立不少于一个前端服务模块,用于接入网络应用节点,

建立应用节点管理中心面向不同前端服务模块的应用节点服务单元,其中封装了对网络应用节点管理中心的远程调用、对其他应用节点服务单元的远程调用和对连接的网络应用节点状态的监控逻辑,运行在前端服务模块内部,并可被前端服务模块调用,应用服务单元包用于监测连接到前端服务端口中的网络应用节点状态信息,并汇报给应用节点管理中心,应用管理中心根据相应的状态数据,指令下游做出相应的行为,

将应用节点管理中心与应用服务单元包建立连接,

所述的应用节点管理中心对待接入的网络应用节点提供粗粒度状态管理,即若一个应用节点服务单元中存在同一个网络应用节点的一个以上的实例的状态,在应用节点管理中心中则仅保存一条状态记录,既一个网络应用节点在一个应用节点服务单元中的状态;

2)向系统接入网络应用节点:

网络应用节点接入前端服务模块,应用服务单元包通过前端服务模块与网络应用节点建立连接,

3)网络应用节点间的调用:

接入的网络应用节点发起向其他网络应用节点的调用请求,应用节点服务单元根据应用节点管理中心中的状态数据执行点对点的消息分发,基于应用节点中心统一定义网络应用节点的API元信息,实现网络应用节点间的调用。

所述的网络应用节点包括但不限于:嵌入式网络应用设备,分布式网络应用程序,聚合服务器客户端,客户端软件,硬件设备的中间件,

所述的前端服务接口包括服务器端应用程序服务模块(service bus)、设备服务模块(device bus)、以及线下应用服务模块(page bus)等,不同类型的网络应用节点接入对应类型的前端服务模块中。

作为对上述方法中的进一步改进,为解决网络应用节点间调用过程中的安全性,调用对象的合法性的问题,采用的技术措施为调用流程分为如下步骤:

1.由起始网络应用节点发起调用请求,指明所需调用的网络应用节点,以及被调用的API及其输入参数值;

2.由前端服务模块中的应用节点服务单元检查API及其入参的数量与数据格式合法性;

3.由前端服务模块中的应用节点服务单元检查目标网络应用节点是否可被调用(状态检查);

4.由前端服务模块中的应用节点服务单元调用应用节点管理中心或依据前端服务模块本地缓存检查目标网络应用节点是否已实现目标API;

5.由前端服务模块调用应用节点管理中心或依据前端服务模块本地缓存检查目标网络应用节点与源网络应用节点是否归属于同一个所有者:

6.归属于同一所有者:继续执行调用;

7.归属于不同所有者:由应用节点服务单元调用应用节点管理中心,根据该API所属的权限类型,获取该网络应用节点针对该权限所授权的账号分组,并检查该分组中是否有源网络应用节点所有者的账号;若有,则继续执行调用;若没有,则抛出权限拒绝的异常。

执行调用操作;若调用成功,返回结果;若调用失败,抛出异常。

附图说明

图1为本申请所提供的一种网络应用节点的集成系统结构示意图

图2为系统承载分布式结构服务器统一会话机制示意图

图3为接入设备的父子节点树状管理示意图

图4为所述父节点状态机示意图

图5为所述子节点状态机示意图

图6为所述前端服务模块状态机示意图

图7为父节点状态更新的流程示意图

图8为网络应用该节点注册认证流程示意图

图9为接入系统的网络应用节点调用流程示意图

图10为前端服务模块失联异常处理的流程示意图

图11为本发明第一种实施例结构示意图

图12为传统企业集成模式与本发明第二种实施例集成模式的对比图

具体实施方式

以下结合附图对本申请进行进一步的说明。

一种网络应用节点的集成系统如图1所示,包括应用节点管理中心、应用节点服务单元、前端服务模块,

所述的前端服务模块用于接入网络应用节点,所述的应用节点服务单元一端连接应用节点管理中心,同时被前端服务模块包含;

所述的应用节点管理中心、应用该节点服务模块、前端服务模块采用可扩展的分布式结构,外接的每个网络应用节点可以包括1个以上的应用实例;

所述的应用节点管理中心通过所述的前端服务模块间接管理连接网络应用节点,应用节点管理中心用于提供对基于IP网络的终端应用节点的统一管理服务统一定义应用节点的API元信息和状态机元信息;所述的应用节点服务单元封装了对网络应用节点管理中心的远程调用、对其他应用节点服务单元的远程调用和对应用节点状态的监控逻辑,运行在前端服务模块内部,并被前端服务模块调用,应用服务管理模块监测连接到前端服务模块中网络应用节点的状态信息,并汇报给应用节点管理中心,应用管理中心根据相应的状态数据,指令应用节点服务单元做出相应的行为;所述的应用节点管理中心对网络应用节点提供粗粒度状态管理,即若一个应用节点服务单元中存在同一个网络应用节点的一个以上的实例,在应用节点管理中心中则仅保存一条状态记录,既一个网络应用节点在一个应用节点服务单元中的状态,而具体到每个实例的状态信息由前端服务模块管理。

如图2所示,所述的服务器端应用程序可以由1个以上的应用服务器承载,这些服务器被允许连接在1个以上的服务器端应用程序服务模块实例上;而本系统中服务器端应用程序所对应的网络应用节点的定义是:一个本系统账号在一个服务器端应用程序中所拥有的资源,因此一个服务器端应用程序网络应用节点可能同时具有多个实例,并且每个实例分别具有自己的连接状态,但这些实例共享一组业务状态机所描述的状态。即使这些服务于同一个逻辑应用节点的不同应用服务器连接在不同的服务器端应用程序服务模块节点上,其会话状态同样可以由本系统确保同步。这些实例在分布式环境下的会话一致性问题和状态同步由本系统提供支持,因此服务器端应用程序的开发者只需关注自身应用程序业务而不需要关注分布式开发所带来的会话一致性和API调用同步性问题,本系统的这个设计减低了开发者的开发难度和工作量。

如图3所示,接入的网络应用可采用设备应用父子节点的树状连接流程和管理方法,所述的父节点是继承自网络应用节点的实体,通过网络连接至前端服务模块的应用节点,可能以物理或逻辑方式连接并管理一个或多个子应用节点;所述的子节点是继承自网络应用节点的实体,以物理或逻辑方式连接至父节点的子应用节点接入的设备

如图4所示,所谓的状态机指管理网络应用节点业务状态的一套机制。一个网络应用节点可以拥有多个业务状态机实例,每个业务状态机可以拥有一个或多个具有有向转换关系的业务状态,但每个业务状态机实例在一个时刻只能处于一个特定状态、具有一个或多个特定的参数值。

网络应用节点(包括父节点和子节点)的权威状态信息保存在Redis或其他类似的分布式缓存中间件中,并由应用节点服务单元在前端服务模块内存中做带有权威状态信息监听的本地高速缓存副本用于调用判断,确保数据的一致性。

父节点状态机设置如下:

1.父节点注册完成后,其到前端服务模块的连接被创建,状态管理工作由应用节点管理中心接管,应用节点管理中心中的状态即是父节点的权威状态;

2.当父节点自身连接主动断开(正常/意外),抑或其所连接的前端服务模块中的特定服务模块主动下线(正常/意外)时,系统监听到该动作后更新父节点及控制子节点的状态。

3.当父节点因主动下线、所连接前端服务模块下线等原因处于离线状态时,父节点对某一前端服务模块发起连接/重连时应执行连接流程,成功后方可完成连接。

如图5所示,子节点状态机设置如下:

1.子节点完成与父节点的配对后,方可在应用节点管理中心注册并被执行状态汇报;子节点的状态信息由父节点感知、管理并汇报;

2.子节点可经由父节点执行连接断开操作,可能造成连接断开的情形有:子节点主动断开连接或失去连接,父节点主动断开或失去与前端服务模块的连接,抑或父节点所连接的前端服务模块主机失去连接;

3.子节点在应用节点管理中心标识的离线状态下,可能经由以下情形恢复连接:子节点与父节点连接未断,父节点恢复链接,其状态被父节点一并更新为已连接;抑或子节点主动恢复与父节点的连接,由父节点向平台更新其状态为已连接。

如图6所示,以应用节点服务单元为访问代理组件的前端服务模块的上线、下线影响着其所负责的父节点状态信息,前端服务模块突然离线后需要对相应父节点的状态进行及时更新。

前端服务模块状态机机制如下:

1.前端服务模块的应用节点服务单元与应用节点管理中心连接并在分布式集群管理中间(例如ZooKeeper)中创建标记后,该标记将接受应用节点管理中心的监听;前端服务模块此后将向应用节点管理中心汇报当前所管理网络应用节点(包括其下属的父节点和子节点)状态。

2.当前端服务模块的应用节点服务单元失联/下线后,分布式集群管理中间件中的标记将消失,此时应用节点管理中心监听到该行为,将更新所有该前端服务模块相关父节点/子节点的状态,确保全局记录中不再出现该前端服务模块相关的数据;

3.由于前端服务模块机器的状态信息不在应用节点管理中心系统中做永久留存,故前端服务模块失连状态不可转换为前端服务模块连接状态。

如图7所示,业务状态更新作为状态更新的过程如下所示:

7.由网络应用节点发起业务状态更新请求,传入参数包括:网络应用节点ID、所需更新的目标业务状态机ID(state MachineID)、目标状态识别号(state GroupID、state ID)、目标状态相关参数值;

8.由前端服务模块中的应用节点服务单元检查网络应用节点ID的连接状态是否为连接(ACTIVE),若不是则抛出规则异常;

9.由前端服务模块中的应用节点服务单元根据目标状态识别号(state GroupID、state ID)获取状态元信息,若无法获取则抛出规则异常;

10.由前端服务模块中的应用节点服务单元根据所获取的状态元信息检查目标业务状态在目标业务状态机中是否存在,若不存在则抛出规则异常;

11.由前端服务模块中的应用节点服务单元根据所获取的状态元信息检查目标业务状态相关参数的存在性(必要参数必须指定)、正确性,若不正确则抛出规则异常;

12.由前端服务模块中的应用节点服务单元访问应用节点管理中心更新业务状态,若更新失败则抛出数据系统异常。

如图8所示,作为本发明的进一步改进,所述的网络应用节点通过注册与认证与系统构成连接,并享有唯一的账号。

其具体的注册认证流程如下:

网络应用节点注册流程:

1.网络应用节点向前端服务模块提供唯一识别码(UiID)(通常由特定前端服务模块模块授予或本身具有全球唯一码的保证机制:如应用软件可直接由服务前端服务模块授予,硬件设备可使用MAC地址与本厂内部唯一编号的组合);

2.若网络应用节点提供了网络应用节点ID、授权码与时间戳(ts),则转向网络应用节点认证流程;

3.检查唯一识别码((UiID)):

3.1.若唯一识别码((UiID)已注册过:检查是否绑定用户,若已绑定用户则直接判定为注册失败,若未绑定则进入下一流程;该步骤可以防止已经有属主、被盗取的网络应用节点被复位后重新连接到平台上被其他帐号使用,若原有属主需要转移网络应用节点资产,需要先行释放对该网络应用节点的所有权。

3.2.若唯一识别码(UiID)没有注册过,则分配新的网络应用节点ID。

4.应用节点管理中心生成并分配新令牌(token)(如果之前有token则直接覆盖,若没有则直接写入);

5.注册流程结束,转入认证流程。

网络应用节点认证过程:

1.网络应用节点与应用节点管理中心通过前端服务模块同步服务器-客户端时间戳;

2.网络应用节点根据当前时间戳(ts)、令牌(token),用HMAC(timestamp,token)的方式计算授权码,

3.网络应用节点向前端服务模块提供网络应用节点ID、授权码、当前时间戳ts(上一流程中已同步),由应用节点服务单元验证参数完整性;

4.应用节点服务单元验证时间戳(ts)的正确性(是否在允许时间差范围内,视部署情况可调整所容忍时间差的长短,如统一广播域内可设定为0.5s,同一国家范围内可设定为2s,洲际通信可设定为数秒等),若时间戳不在允许的时间差范围内则拒绝认证;该步骤可防止验证消息意外被第三方拦截并破解后永久性使用某次访问的授权码值访问服务器,让即使在用于传输授权码的加密传输通道被拦截并且破解的最差情况下依然可以让拦截者所获得授权码在短时间内失效,保证所建立通道的安全合法;

5.根据网络应用节点ID、令牌token、已验证时间戳(ts),使用与网络应用节点客户端一致的算法验算授权码;该授权码必须使用当前已被验证的时间戳ts、以及不经过通道传输的令牌token计算才能得到与请求中授权码一致的结果,以防通过修改时间戳使之通过时间戳认证的情形发生,进一步确保连接通道构建过程的安全;

6.连接通道构建完成。

如图9所示,网络应用节点调用过程自一侧的父节点或子节点发起,经父节点、前端服务模块中的应用节点服务单元,抵达另一侧的(应用节点服务单元)前端服务模块、网络应用节点最终抵达目标父节点或子节点,其具体流程如下所示:

1.由起始网络应用节点发起调用请求,指明所需调用的网络应用节点,以及被调用的API及其输入参数值;

2.由前端服务模块中的应用节点服务单元检查API及其入参的数量与数据格式合法性;

3.由前端服务模块中的应用节点服务单元检查目标网络应用节点是否可被调用(状态检查);

4.由前端服务模块中的应用节点服务单元调用应用节点管理中心或依据前端服务模块本地缓存检查目标网络应用节点是否已实现目标API;

5.由前端服务模块调用应用节点管理中心或依据前端服务模块本地缓存检查目标网络应用节点与源网络应用节点是否归属于同一个所有者:

6.归属于同一所有者:继续执行调用;

7.归属于不同所有者:由应用节点服务单元调用应用节点管理中心,根据该API所属的权限类型,获取该网络应用节点针对该权限所授权的账号分组,并检查该分组中是否有源网络应用节点所有者的账号;若有,则继续执行调用;若没有,则抛出权限拒绝的异常。

8.执行调用操作;若调用成功,返回结果;若调用失败,抛出异常。

如图10所示,应用节点管理中心对前端服务模块失联异常处理程序如下:

1.前端服务模块中的应用节点服务单元进程终止或网络断开,应用节点管理中心的若干主机进程监听到是否失联;

2.应用节点管理中心若干主机进程试图在分布式协调中间件(如ZooKeeper)中创建分布式事务节点和执行节点,以及在当前应用节点管理中心进程结束后会自动删除的临时节点,最终只有一个进程可以创建成功,以此体现本操作的单一性(在同一时刻只有一个进程可以执行操作);

3.抢占成功的应用节点管理中心进程检查当前事务的状态,若为“空(NULL)”、“就绪(STANDBY)”或“执行中(PROCESSING)”则继续执行下一步,若为“已完成(COMPLETED)”则直接结束并释放该临时节点;

4.抢占成功的应用节点管理中心进程将该事务的状态标注为“执行中(PROCESSING)”,没有抢占成功的进程监听所创建的临时节点;

5.抢占成功的应用节点管理中心进程开始清理失联前端服务模块节点相关网络应用节点的状态,清理结束后将该事务的状态标注为“已完成(COMPLETED)”。

图11是本发明第一种实施例的结构示意图,智能家居应用的用户数量大且分布地域广,需要接入支持的设备种类繁多且普遍具有分层连接的特性,是本系统适用的典型场景之一。

应用本发明申请的智能家居应用集成系统实现方法包括:

1)连接ZigBee网关(IP设备),使之通过ZigBee低功耗短距无线组网协议接入子级设备,包括:开关面板、电动窗帘、智能门锁、新风系统、空调等家用设备;接入门窗磁感应器(一种感知门窗开关的感应装置)、人体传感器、人体生物特征识别器(指纹、虹膜、红外阵列传感器等)等生活用状态感知设备;接入光照度传感器、可燃气体传感器、空气传感器等环境传感设备,感知环境的状态以便根据控制策略对受控设备进行调整。

2)进一步的为了保证接入设备的安全,接入本系统的设备必须通过注册认证流程(既图8所示的流程),比如智能家居网关设备在接入本智能家居系统时,必须提供其MAC地址与出厂内部唯一编号组合进行认证,若不能提供该数据,说明此智能家居网关设备非经正规厂商出厂,平台对该设备将不予接入。系统在建立与该设备间的授信连接之前会根据用户提交的设备ID与密码进行合法性验证;若设备连接时未提供设备ID与密码的组合或验证不通过,则检查该数据组合是否已经绑定过用户,若未绑定,则为该智能家居网关设备分配新的ID。

3)父级/子级设备、智能家居应用程序通过实现本系统所定义的API,可无缝获得上层控制应用程序以及周边应用设备,如开关面板、电动窗帘、智能门锁、新风系统、空调等家用设备等所分发的控制指令和状态信息,并执行相应操作。例如当空调设备或智能家居网关设备通过获取环境传感器、人体传感器的状态数据,监测到室内有人且温度过低,可以开启空调的暖风模式;同样的,当服务器端智能家居应用程序监控到温度过低后,也可以根据软件内的控制策略调用空调设备的API以将室温提升至所设定的可接受水平。

4)通过状态机接受上述设备实时推送的业务状态,感知使用者对设备的操控行为,如开灯/关灯时,开关面板状态的改变将被实时同步至本系统的状态机并通知周边设备,以便智能家居应用软件学习使用者行为模式,进而构建智能化的反馈和控制策略。如:对于“RGB灯泡”而言,其状态包括“电源开(PowerOn)”与“电源关(PowerOff)”,其中“电源开”状态还包含两个参数:“亮度(brightness)”参数,其取值范围为[0,1],为单精度浮点类型;“颜色(color)”参数,其取值是一个长度为3的byte数组(24个二进制位,分别代表R、G、B值)。该设备的该业务状态机可在“PowerOn”和“PowerOff”之间切换,在切换到“PowerOn”状态时需要为其两个参数赋值,否则将使用默认参数。RGB灯泡的业务状态发生改变时,其在本系统中所对应的业务状态机也会随之发生改变,不论其来源是平台端API调用、其自行改变业务状态抑或透过平台外其他方式控制其改变。

5)智能家居应用软件可以制定对具体设备API的调用策略(定时触发/条件触发,以有向无环图描述多个设备API的调用先后顺序及其调用参数)并执行。例如,当服务器端智能家居应用软件通过本系统监听到房门的门磁传感器的状态变为“打开”且人体传感器的状态变为“有人”后,可通过调用电热水壶的“煮水”API,并在室温高于所设定的舒适阈值(如30摄氏度)或低于所设定的舒适阀值(如20度)时调用空调设备的“启动并设定温度”API并设定期望温度参数(如25度)。

6)智能家居系统是服务器端应用系统,具有多台前端服务模块,并且允许同一个用户的多个不同客户端接入,且这些不同的客户端有可能是连接至不同的前端服务模块,因此需要使用本系统所提供的分布式会话同步机制。

7)用户1仅将门锁的执行权限在指定时间范围内分享给用户2,用户2仅将某开关面板状态信息的读权限分享给用户1等,从而可实现多用户间的设备带权限共享。

智能家居应用的服务器和多个用户的设备可分别接入本系统。如图11中所表示的两个用户的多个客户端,即有可能接入相同的应用前端服务模块也有可能接入不同的服务器。同一用户的客户端即使接入不同的应用服务器,也可以由本系统保证分布式会话的同步性。本系统实现了对两个用户的父设备(ZigBee网关)和所连接子设备的连接状态管理以及业务状态管理,设备的持有者和被共享者可以获得设备状态更新的相关通知;例如,若用户1将所持有的设备共享给用户2,则用户2一样可以在他的智能家居应用客户端上看到被共享的设备,并进行权限允许范围内的操作。在接入本系统的设备和其他网络应用节点中,一切实现了智能家居应用所需API的应用节点都可以被呈现在客户端上。

在复杂企业应用系统集成场景中,对多系统的打通往往伴随着复杂的系统间API适配开发和来自多个不同系统的数据同步与按照新的业务要求重新整合存储的问题,新的数据一致性问题对系统未来的运维工作造成更多的压力。多个系统整合时,更加错综复杂的权限依赖关系为系统集成工作带来了复杂性,也具有为集成后的业务系统带来新的安全隐患的风险。为了高效、安全的集成众多异构的企业应用系统模块,本发明的第二种实施例中为企业业务集成系统,具体包括:

1)可扩展的统一API定义:将本组织业务所涉及的API统一定义在本系统中,以供不同的业务模块实现或调用;不同业务模块只需关注其他模块可以提供的功能和资源(以实现某些API的形式体现)即可直接在权限允许的情况下使用,而不必关注模块本身的技术细节,更不必考虑对异构数据的适配问题(已经在实现统一API时解决)。

2)统一的权限管理机制:用读、写、执行分类服务器端应用程序节点(用户在某一服务器端应用程序中的实例,及其所对应的资源)或设备的客户权限,用用户组管理被授予特定权限用户的列表,以此扁平化的结构管理复杂的企业应用授权关系,实现安全集成。

图12a描述了传统企业业务系统集成的基本方式:对于同一个(些)业务模块,不同的第三方模块需要分别对这些业务模块的API分别进行适配,最终获取数据或调用功能。由于不同的业务模块开发者不一样,其格式、参数校验规则、权限准入规则迥异,对接口的适配需要先后经过沟通获取开发文档、申请使用权限、联调等繁琐的过程;不同业务模块之间庞杂的依赖关系,也让业务模块间以来关系的管理成为组织内信息系统维护的巨大挑战。

图12b描述了基于本系统的应用聚合方式。尽管面向企业采购的既有商业应用软件模块(如ERP、CRM等)编写面向本系统的API发布适配组件依然是无法避免的工作,但只需进行一次即可,之后其他业务系统也可以通过本系统访问这些既有应用软件模块所提供的API。新开发的企业数据集成平台不再需要向既有应用模块的负责人申请API使用权限、获取开发文档,只需面向本系统所提供的API访问授权规则开发即可直接访问企业的财务和资源管理系统ERP、客户关系管理系统CRM等应用模块所提供的数据和功能。同时,新开发的应用模块可以将自身所提供的API发布到本系统上供其他业务系统调用。

在本实施例中,企业内部分别建设了业务繁多、各自不能相互兼容的IT系统,采购的来源也不尽相同。企业的财务和资源管理系统(ERP)、客户关系管理系统(CRM)、各类不同的业务流程系统(BPM)完全相互孤立,大大降低了公司员工的工作效率:普通员工需要登入专用账号才能在ERP系统中查询自己的工资详情和绩效考核状态、提交及查询报销信息状态,需要登入日常工单系统的专用账号才能获取并处理日常工作事务,需要登入CRM的专用账号才能管理客户信息并处理客户相关工作事务。缺乏统一身份认证系统及员工账号权限管理系统,各类业务系统的账号管理和权限管理孤立,各级领导和关键业务角色审批人的审批权限管理混乱。员工无法在一个统一的“仪表盘”页面中及时获取和自己相关的公司基础事务流程、客户业务流程、工作事务流程的相关通知和处理状态,也无法对与自己相关的工作进展一目了然。更重要的,企业的管理者无法通过统一的入口获取到日常审计数据,企业在以周、月、季度、半年、年等粒度进行业务和财务审计时需要通过查询并拷贝名目繁多的业务系统、业务系统背后的数据库甚至使用提取银行交易流水、访谈、邮件追踪等手段才能完成。

实施上所述的方案达到了以下效果,1)基于本系统的统一身份认证机制、统一权限管理机制开发用于管理组织结构和审批权限关系和业务流程通知的业务流程管理应用组件(BPM),提供规范的审批业务流程基础组件;2)对企业内各系统的业务API进行统一适配并在本系统中注册;3)将各业务流程系统接入企业统一权限管理平台,让各项财务审批和日常工作业务审批流程具有统一的权限管控入口,减低权限混乱所带来的业务与财务风险的可能,降低业务流程系统的开发工作量;4)基于已经将功能API、身份认证与权限管理机制、业务流程管理功能接入本系统的本企业关键业务组件,利用本系统所提供的统一API访问入口与访问控制机制开发企业数据集成平台,为员工提供可直接看到与自己相关各业务和财务流程提醒和状态进展的仪表盘页面;5)基于已注册的各业务系统API开发可以直接获取企业日常审计数据与周期审计数据的企业管理者页面,并可根据审计需求持续迭代开发;6)各企业应用组件可通过平台在权限管控下获取周边的数据,调用周边系统的功能,以实现原本各自孤立系统的协同,如ERP系统可直接监听CRM客户业务流程相关状态机以获取状态数据,以实时同步应收账款/实收账款的状态信息。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1