跨数据库交互服务平台的制作方法

文档序号:15455574发布日期:2018-09-15 01:00阅读:206来源:国知局

本申请涉及网络技术领域,特别是涉及一种跨数据库交互服务平台。



背景技术:

网络环境下的应用软件开发,可以采用传统的软件开发的模式。但是传统技术中,软件和网络是两个不同的领域,比较少有交集,软件开发主要针对应用功能实现,网络则主要研究系统之间的通信。

随着互联网的发展,使得这两个领域高度融合,如何开发在互联网复杂的环境中高效使用软件和分布式环境下的数据库,是亟待解决的技术问题,对分布式环境下的数据库集成既是实现数据分布式应用的基础,也是互联网技术实施的关键。然而现有企业信息系统业务平台的集成技术大多为基于功能定义模式,即针对特定的环境、功能或需求提供紧耦合的服务,一旦内部需求变更或增加,就难以有效重用已有资源而需重复开发新的数据服务,可重用性和适用性差,在面对某些应用服务时甚至无能为力,难以形成灵活配置和可扩展的体系架构。



技术实现要素:

基于此,有必要针对数据访问服务不够灵活的技术问题,提供一种可灵活配置的跨数据库交互服务平台。

一种跨数据库的交互服务平台,包括提供数据库数据信息的数据层、携带restful(representationalstatetransfer,表现层状态转移)api(applicationprogramminginterface,应用程序编程接口)的服务层、携带轻量级服务总线的总线层、以及应用层;

所述数据层将所述数据信息发送至所述服务层,所述应用层接收访问请求信号,并将所述访问请求信号发送至所述总线层,所述总线层的轻量级服务总线,按照所述访问请求信号,对所述总线层预设的服务信息以及所述服务层接收的数据信息进行编排管理,得到编排结果,并将所述编排结果输出至所述应用层,得到访问结果。

在其中一个实施例中,所述总线层包括服务容器模块、消息路由模块以及流程编排模块;

所述服务容器模块进行子服务注册,并将注册的子服务信息发送至所述消息路由模块,所述消息路由根据所述子服务信息确定获取的所述数据信息的传递路线与规则,并按照所述传递路线与规则将获取的所述数据信息传递至所述服务容器模块,所述流程编排模块按照所述访问请求信号,对所述服务容器模块注册的所述子服务与接收的所述数据信息进行编排,得到编排结果。

在其中一个实施例中,所述服务容器模块包括服务列表单元;

所述子服务信息注册于所述服务列表单元,所述服务列表单元对所述子服务进行管理,当所述访问请求信号对应的访问服务发生变更或增加时,通过对服务列表进行修改或添加注册所述子服务完成访问。

在其中一个实施例中,所述服务容器模块包括访问服务注册单元、子服务确定单元以及数据信息确定单元;

所述访问服务注册单元按照所述访问请求信号注册对应的访问服务,所述子服务确定单元根据所述访问服务,对子服务进行查找和选择,确定所需的子服务,数据信息确定单元确定与所述所需的子服务对应的数据信息,所述流程编排模块对所述所需的子服务以及所述所需的子服务对应的数据信息进行编排,得到编排结果。

在其中一个实施例中,所述总线层还包括消息机制确定模块;

所述消息机制确定模块确定数据信息处理机制,并按照所述数据信息处理机制,将所述编排结果输出至所述应用层。

在其中一个实施例中,所述数据层提供多个数据库,并将所述多个数据库分别封装为可独立调用的数据单元。

在其中一个实施例中,所述服务层的restfulapi包括标识单元和访问单元;

所述标识单元使所述数据单元携带uri(uniformresourceidentifier,统一资源标识)标识,所述访问单元根据所述访问请求信号,访问所述携带uri标识的数据单元,得到目标数据信息。

在其中一个实施例中,所述服务层的restfulapi包括操作单元;

所述操作单元对所述目标数据信息进行增加、读取、修改以及删除中的至少一种操作。

在其中一个实施例中,所述数据库包括mysql、oracle、cachedb、documentdb以及mongodb中的至少一种类型。

在其中一个实施例中,所述应用层实现数据服务,应用服务和展示服务中的至少一种服务。

上述跨数据库的交互服务平台,通过数据层提供数据库的数据信息,服务层采用restfulapi实现对数据信息的访问,使得规范性、安全性、灵活性得到提高,总线层通过利用轻量级服务总线可提供对系统的松耦合集成的特点,实现对服务层的服务流程与数据信息的编排管理,使得各服务组件与数据库之间的访问更为便捷高效,避免了服务需求变化时需重复开发新的数据服务的使用弊端,并通过应用层接收访问请求信号并提供服务应用,从而实现多种不同类型的数据库之间高效、规范、安全的数据交互访问服务,满足业务的快速部署与灵活配置,具备良好的适用性。

附图说明

图1为本申请一个实施例中跨数据库的交互服务平台的结构框图;

图2为本申请另一个实施例中跨数据库的交互服务平台的结构框图;

图3为本申请另一个实施例中跨数据库的交互服务平台的结构框图;

图4为本申请一个应用实例中跨数据库的交互服务平台的结构框图;

图5为本申请一个应用实例中总线层的轻量级服务总线的结构框图;

图6为本申请一个应用实例中服务层对数据信息进行操作的流程示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。

由于传统的soap(simpleobjectaccessprotocol,简单对象访问协议)方法要遵循大量的协议和标准,这种复杂、效率低下且难以变更的重量级服务已不能满足敏捷业务系统某些功能的开发需求。经过深入研究,设计了一种基于restfulapi设计理论的可配置式跨数据库交互服务平台,高效、规范、安全地在复杂的互联网或分布式网络环境下,实现多种不同类型的数据库之间数据交互访问。

如图1所示,一种跨数据库的交互服务平台,包括提供数据库数据信息的数据层100、携带restfulapi220的服务层200、携带轻量级服务总线310的总线层300、以及应用层400;

数据层100将数据信息发送至服务层200,应用层400接收访问请求信号,并将访问请求信号发送至总线层300,总线层300的轻量级服务总线310,按照访问请求信号,对总线层300预设的服务信息以及服务层200接收的数据信息进行编排管理,得到编排结果,并将编排结果输出至应用层400,得到访问结果。

交互服务平台架构自下而上依次分为数据层100、服务层200、总线层300和应用层400。数据层100是作为整个平台架构的底层基础,提供分散于各应用子系统中的数据信息。服务层200通过创建restful服务,使用restfulapi220来实现对数据层100分布数据源的访问,其中rest即指一组架构的约束条件和原则,满足这些约束条件和原则的应用程序或设计就是restful,restfulapi220是互联网应用程序的api设计理论,restful服务通过标准的语法对资源进行统一表述从而简化了系统架构,对多源动态分布特性的资源的抽象获取非常适合。总线层300的轻量级服务总线310是指具有对系统的松耦合集成的特点的服务总线,是构建数据库交互服务平台的关键部分,总线层300按照访问请求信号通过组合调用实现对服务流程的编排、管理和监控,可满足分布式环境中的集成需求。作为顶层的应用层400接收访问请求信号并根据总线层300的提供结果,可提供的数据查询、数据展示与智能应用等服务应用。

上述跨数据库的交互服务平台,通过数据层100提供数据库的数据信息,服务层200采用restfulapi220实现对数据信息的访问,使得规范性、安全性、灵活性得到提高,总线层300通过利用轻量级服务总线310可提供对系统的松耦合集成的特点,实现对服务层200的服务流程与数据信息的编排管理,使得各服务组件与数据库之间的访问更为便捷高效,避免了服务需求变化时需重复开发新的数据服务的使用弊端,并通过应用层400接收访问请求信号并提供服务应用,从而实现多种不同类型的数据库之间高效、规范、安全的数据交互访问服务,满足业务的快速部署与灵活配置,具备良好的适用性。

如图2所示,在其中一个实施例中,总线层300的轻量级服务总线310包括服务容器模块320、消息路由模块340以及流程编排模块360,服务容器模块320进行子服务注册,并将注册的子服务信息发送至消息路由模块340,消息路由模块340根据子服务信息确定获取的数据信息的传递路线与规则,并按照传递路线与规则将获取的数据信息传递至服务容器模块320,流程编排模块360按照访问请求信号,对服务容器模块320注册的子服务与接收的数据信息进行编排,得到编排结果。

作为信息集成平台的核心组成部分,总线层300承上启下,是整个平台的业务处理中枢。轻量级服务总线310提供了一组丰富的功能以启用管理和监控应用程序之间的交互,集成在应用系统的应用层及服务层之间,通过多种通信协议连接并集成不同系统上的组件将其映射为服务,完成服务间的互操作。服务容器模块320是指提供高性能可伸缩的容器应用管理服务的模块,用于进行子服务的注册与管理,是服务总线的重要构件之一,可封装用户应用软件和自身基础服务。消息路由模块340是指针对命令消息,进行传递路径选择和消息发送的处理模块。流程编排模块360是指对数据信息和应用服务按照访问请求进行重新编排的模块。在交互服务平台中,各子服务依据相应的功能应用被注册在服务容器内,当总线接收到来自应用层400的访问请求时,服务容器模块320发现请求并依照列表选择相应的子服务。消息路由模块340接收数据层100的数据信息,并注册的子服务信息分析服务传递的步骤并建立数据信息的传递线路和规则,最终实现消息的传递过程,流程编排模块360对数据与服务等的组合、重用和编排,达到最终的业务整合。

如图3所示,在一个实施例中,服务容器模块320包括服务列表单元322,子服务信息注册于服务列表单元322,服务列表单元322对子服务进行管理,当访问请求信号对应的访问服务发生变更或增加时,通过对服务列表进行修改或添加注册子服务完成访问。

服务列表单元322是指集成了注册的众多子服务的单元,通过建立服务列表,实现了对子服务的优化管理。访问请求信号存在对应的访问服务,当访问请求信号对应的访问服务发生变更或增加时,通过对服务列表进行修改或添加注册子服务即可完成,简化了操作流程。系统的业务逻辑、流程及高级应用均被定义和分解封装为服务,在实现某一具体的应用时,总线层300依据流程编排引擎过对数据服务等的组合、重用和编排以达到最终的业务整合,实现应用层的高级应用,以及实现restfulapi的配置管理,当系统的业务发生变更或增加时,通过对服务列表修改或添加注册新的服务即可满足业务需求,系统灵活、可扩展。

在一个实施例中,服务容器模块320包括访问服务注册单元324、子服务确定单元326以及数据信息确定单元328,访问服务注册单元324按照访问请求信号注册对应的访问服务,子服务确定单元326根据访问服务,对子服务进行查找和选择,确定所需的子服务,数据信息确定单元328确定与所需的子服务对应的数据信息,流程编排模块360对所需的子服务以及所需的子服务对应的数据信息进行编排,得到编排结果。

访问服务注册单元324是指当检测到当前的访问请求信号没有对应的服务信息时,对当前的访问请求信号进行服务注册的单元,以便完成当前的访问服务,而且当下一次出现同样的访问请求信号时,可直接对获取到对应的服务信息,节省了操作时间,使用更为便捷。访问请求信号的存在多样性,但完成访问一般是通过多个子服务的结合来实现的,子服务确定单元326可以按照访问服务,对服务列表中的子服务进行查找和选择,确定所需的子服务,子服务对应需要数据信息,通过数据信息确定单元328确定与所需的子服务对应的数据信息,流程编排模块360可以通过流程编排引擎对所需的子服务以及所需的子服务对应的数据信息进行编排,得到编排结果来实现访问。

在一个实施例中,总线层300的轻量级服务总线310还包括消息机制确定模块380,消息机制确定模块380确定数据信息处理机制,并按照数据信息处理机制,将编排结果输出至应用层400。

交互访问平台提供了订阅或发布,以及请求或回复2组消息处理机制,订阅或发布是指根据订阅请求,按照预设的时间或周期,发布对应的消息的处理机制,具有规律性,请求或回复是指以一问一答的形式,根据请求服务内容,回复对应的消息的处理机制,具有随机性。消息机制确定模块380确定数据信息处理机制,并按照数据信息处理机制,将编排结果输出至应用层400,向用户展示访问结果。

在一个实施例中,数据层100提供多个数据库,并将多个数据库分别封装为可独立调用的数据单元。

由于不同格式数据的处理机制不同,为降低服务间的耦合关系并提供标准的调用接口,通过数据层100将数据库业务逻辑封装为离散的、可独立调用的功能单元,以便在分布式环境中构建松散耦合的数据服务。

在其中一个实施例中,数据库包括mysql、oracle、cachedb、documentdb以及mongodb中的至少一种类型。

通过不同类型的数据库,扩大了交互访问的范围,提高了访问便捷度,满足了多种访问需求,对跨数据库的交互访问进行了优化。

在一个实施例中,服务层200的restfulapi220包括标识单元222和访问单元224,标识单元222使数据单元携带uri标识,访问单元224根据访问请求信号,访问携带uri标识的数据单元,得到目标数据信息。

restful服务将数据层100数据单元中需要操作的事物、关系和业务流程抽象为资源,同时为每个资源赋予唯一的资源标识符(uri),通过超文本传输协议(http)处理和传输资源状态。标识单元222通过标准的语法对资源进行统一表述,再通过访问单元224进行访问,简化了系统架构,对多源动态分布特性的资源的抽象获取非常适合,服务层200通过创建restful服务来实现对底层分布数据源的访问,restful服务简捷灵活,可通过uri直接识别定位资源,避免了访问资源时繁琐的响应过程,在需要使用有限带宽提供更多连接时更具效率,使系统具有可寻址性、连通性,降低了与其他分布式组件的耦合性,具有高伸缩性和灵活性,适合构造松散组合的系统,实现快速响应。

在一个实施例中,服务层200的restfulapi220包括操作单元226,操作单元226对目标数据信息进行增加、读取、修改以及删除中的至少一种操作。

根据访问请求的实际需要,对目标数据信息进行增加、读取、修改或者删除操作,可以对数据进行进一步筛选,提高了访问服务的精确性。在对数据进行增加、读取、修改、删除等操作时,请求数据置于http(hypertexttransferprotocol,超文本传输协议)文档主体,通过uri向服务器发送请求,服务器依据方法参数处理完毕后,将结果以超文本标记语言html或xml或json等格式(javascriptobjectnotation,js对象标记),通过uri传回应用层。restfulapi服务简捷高效、低耦合,特别适于平台中对数据的访问,一旦数据源发生变更或增加,只需对uri进行简单的修改即可,可实现服务的快速响应。

在一个实施例中,应用层400实现数据服务,应用服务和展示服务中的至少一种服务。

数据服务是指对数据的提取与查询服务,应用服务是指对数据信息进行操作的服务,展示服务是指将数据信息呈现的服务。根据实际需求,选择不同的服务类型,满足多种交互访问需求,提升了用户使用感。

如图4所示,在一个应用实例中,交互访问平台架构适用于企业数据库,交互访问平台自下而上依次分为数据层、服务层、总线层和应用层,数据层提供企业数据库包括mysql、oracle、cachedb、documentdb、mongodb等,并将各数据库封装为离散的、可独立调用的功能单元,在数据库操作时对数据进行必要的解析与数据转换,与数据层连接的服务层设置有restfulapi,可提供restful服务,可以理解,还可以同时设置soap/swdl服务,结合两种服务类型,更好的实现交互访问,restful通过uri直接识别定位封装的功能单元,总线层包括轻量级服务总线,轻量级服务总线是构建数据库交互服务平台的关键部分,它提供消息路由、粗粒度应用服务以及与其他组件之间的互操作,通过对各子服务的组合调用实现对服务流程的编排、管理和监控,可满足分布式环境中的集成需求。具体来说提供流程管理和总线服务两类,其中流程管理包括流程编排、流程引擎、流程监控、服务管理以及集成功能,总线服务包括动态路由、消息服务、访问控制、事件服务、消息转换以及日志服务。如图5所示,具体地,可以通过获取消息机制确定使用订阅/发布,还是请求/回复的处理方式,消息路由可以通过restfulapi获取数据库中的数据信息,服务容器是服务总线的构件之一,可封装用户应用软件和自身基础服务。服务列表依据相应的功能应用而事先被注册在服务容器内,当总线层接收到来自应用层的访问请求信号时,服务容器根据访问请求信号对服务列表进行查询,具体可以通过对服务列表中的子服务的发现和选择来进行查询,当没有对应的服务时,可通过注册来实现补充,而各子服务可以预先注册于服务列表,且服务列表可以对子服务进行管理,根据查询选择出的子服务,会对应需要查找数据库中的数据信息,消息路由可以根据选择的子服务,制定数据消息的传递路线与规则,将对应的数据信息传递至服务容器,流程管理对选择的子服务和对应的数据信息按访问要求进行编排和监控,并将编排结果输出至应用层,实现访问过程。如图6所示,更进一步的,服务层可以根据应用层获取到的服务请求者的访问请求需要,实现对数据信息的增加、读取、修改以及删除操作,在对数据进行增加、读取、修改、删除等操作时,请求数据置于http(hypertexttransferprotocol,超文本传输协议)文档主体,通过uri向服务器发送请求,服务器依据方法参数处理完毕后,将结果以超文本标记语言html(hypertextmarkuplanguage,超级文本标记语言)或xml(extensiblemarkuplanguage,可扩展标记语言)或json等格式(javascriptobjectnotation,js对象标记),并通过uri传回应用层,实现访问过程。

以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。

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