一种服务方法、装置、系统以及电子设备与流程

文档序号:16262903发布日期:2018-12-14 21:43阅读:175来源:国知局
一种服务方法、装置、系统以及电子设备与流程

本申请涉及计算机软件技术领域,尤其涉及一种服务方法、装置、系统以及电子设备。

背景技术

面向服务架构(serviceorientedarchitecture,soa)是目前企业软件的一种主流架构,soa是一种分布式的架构,它将业务逻辑提炼成分布式的服务,这些服务之间一般可以通过webservice通信。

图1为现有技术中的soa分布式架构下的web系统的一种架构示意图。在图1中,web系统整合后端服务系统的数据获取和操作等服务,并为客户端提供相应的数据接口以便于客户端请求获取服务。

在现有技术中,上述web系统主要有两种服务整合方案。第一种,为每个web页面需要的业务整合远程过程调用协议(remoteprocedurecallprotocol,rpc)服务,并在web系统中包装一个超文本传输协议(hypertexttransferprotocol,http)的数据接口,这是目前web系统中为客户端的页面(可以称为页面端)提供数据获取和操作服务典型的实现方案;第二种,使用restful风格的请求为页面端提供数据获取和操作接口,这种方案在web系统中集成一些restful的框架,通过在框架内集成rpc服务,将rpc服务以restful风格的接口提供给客户端。

但是,对于第一种方案,需要为每一个数据接口提供一个http请求,每提供一个新请求都要做一定量的硬编码,带来的问题包括:请求不规范,统一资源定位符(uniformresourcelocator,url)名称、参数格式等都基于开发人员的约定,增加了沟通和调试成本;每暴露一个rpc服务请求都需要编码,工作量大,容易出错。第二种方案在第一种方案的基础上做了改进,对url规范在编程风格和框架层面做了支持,但是,依然要为每一个数据接口进行对应的硬编码。

由此可见,现有技术中请求不规范以及硬编码会导致易出错,服务效率低等问题。



技术实现要素:

本申请实施例提供一种服务方法、装置、系统以及电子设备,用以解决如下技术问题:现有技术中的soa分布式架构下的web系统中,请求不规范以及一些硬编码会导致易出错,服务效率低等问题。

为解决上述技术问题,本申请实施例是这样实现的:

本申请实施例提供的一种服务方法,包括:

接收客户端发送的基于通用领域专用语言(domainspecificlanguage,dsl)协议的服务请求;

对所述服务请求进行解析,得到所述客户端所请求服务的标识和参数;

根据所述所请求服务的标识和参数,通过服务集成层调用对应的服务执行引擎以执行所述所请求服务;

其中,所述服务集成层用于管理可提供的各服务的注册信息。

本申请实施例提供的一种服务装置,包括:

接收模块,接收客户端发送的基于通用dsl协议的服务请求;

解析模块,对所述服务请求进行解析,得到所述客户端所请求服务的标识和参数;

服务模块,根据所述所请求服务的标识和参数,通过服务集成层调用对应的服务执行引擎以执行所述所请求服务;

其中,所述服务集成层用于管理可提供的各服务的注册信息。

本申请实施例提供的一种服务系统,包括:统一网关、dsl引擎、服务集成层、一个或多个服务执行引擎;

所述统一网关接收客户端发送的基于通用dsl协议的服务请求;

所述统一网关将所述服务请求传递给所述dsl引擎;

所述dsl引擎对所述服务请求进行解析,得到所述客户端所请求服务的标识和参数,以调用所述服务集成层;

所述服务集成层根据其管理的可提供的各服务的注册信息,以及所述dsl引擎调用时传递的所述所请求服务的标识和参数,调用对应的服务执行引擎以执行所述所请求服务;

其中,所述各服务的注册信息包括:元数据,和/或包含对多项服务的逻辑编排信息的脚本。

本申请实施例提供的一种电子设备,包括:

至少一个处理器;以及,

与所述至少一个处理器通信连接的存储器;其中,

所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够:

接收客户端发送的基于通用dsl协议的服务请求;

对所述服务请求进行解析,得到所述客户端所请求服务的标识和参数;

根据所述所请求服务的标识和参数,通过服务集成层调用对应的服务执行引擎以执行所述所请求服务;

其中,所述服务集成层用于管理可提供的各服务的注册信息。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:可以基于通用dsl协议将请求规范化,以及通过服务集成层统一管理各服务的注册信息,以有效地实现服务整合,可以减少上述的硬编码,因此,有利于减少出错以及提高服务效率,可以部分或全部地解决现有技术中的问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。

图1为现有技术中的soa分布式架构下的web系统的一种架构示意图;

图2为本申请实施例提供的一种服务方法的流程示意图;

图3为本申请实施例提供的soa分布式架构下的web系统的一种架构示意图;

图4为本申请实施例提供的对应于图2的一种服务系统的结构示意图;

图5为本申请实施例提供的对应于图2的一种服务装置的结构示意图。

具体实施方式

本申请实施例提供一种服务方法、装置、系统以及电子设备。

为了使本技术领域的人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。

为了便于理解,对本申请的方案的核心思想进行说明:可以基于通用dsl协议,将现有技术中的请求规范化,以及可以对web服务端的架构进行调整,增加服务集成层,由服务集成层管理可提供的各服务的注册信息,以高效地实现服务整合。

需要说明的是,本申请的方案不仅适用于soa分布式架构下的web系统,同样也适用于其他具有服务需求方(可以是客户端或者另一服务端)和服务端的系统。

基于以上核心思想,下面对本申请的方案进行详细说明。

图2为本申请实施例提供的一种服务方法的流程示意图。从程序角度而言,该流程的执行主体可以是服务器上或者终端上的程序,比如,web服务端、终端上的应用等。从设备角度而言,该流程的执行主体包括但不限于可作为服务器或者终端的以下至少一种设备:个人计算机、中型计算机、计算机集群、手机、平板电脑、智能可穿戴设备、车机等。

图2中的流程可以包括以下步骤:

s201:接收客户端发送的基于通用dsl协议的服务请求。

在本申请实施例中,可以由为web服务端和客户端预先定义统一的一种dsl协议,作为所述通用dsl协议,web服务端与客户端则基于该通用dsl协议进行数据交互,所述数据交互包括但不限于:客户端向web服务端请求获取服务、web服务端向客户端发布服务等。服务请求中包含所请求服务的标识和参数,其中,所述参数也可以为空。

例如,一个基于通用dsl协议的服务请求比如可以是如下格式:

“getuser(id:123456){userid,username,email,address}”

该服务请求包含的所请求服务的标识为“getuser”,参数为“id=123456”,该服务请求用于请求获取id=123456的用户,所请求服务属于数据获取服务。

s202:对所述服务请求进行解析,得到所述客户端所请求服务的标识和参数。

在本申请实施例中,可以相应地基于该通用dsl协议,对接收到的服务请求进行解析,得到所请求服务的标识和参数。

s203:根据所述所请求服务的标识和参数,通过服务集成层调用对应的服务执行引擎以执行所述所请求服务;其中,所述服务集成层用于管理可提供的各服务的注册信息。

在本申请实施例中,所述服务可以是本地服务,也可以是远程服务。一般地,在soa分布式架构下的web系统中,所述服务具体是rpc服务。

可以通过将配置的服务相关信息在服务集成层进行注册,作为服务的注册信息,以实现服务集成,服务相关信息可以是人工配置的,也可以是机器通过一定的策略自动生成并配置的。

服务相关信息可以包括服务的元数据,和/或包含对多项服务的逻辑编排信息的脚本。所述元数据用于统一地描述服务;所述脚本用于组装和编排多项服务,以形成一项合成服务,有利于支持更复杂的业务场景,在脚本中比如可以指定多项服务的逻辑顺序,可以指定多项服务的元数据的信息等;另外,为了可以灵活地编排以形成各式各样的合成服务,所述多项服务可以是粒度较细的服务,比如,原子服务等。

服务相关信息还可以包含服务执行引擎或者其信息,所述元数据或者脚本与服务执行引擎可以有对应关系,在这种情况下,不同元数据对应的服务可能由不同的服务执行引擎获取,元数据对应的服务与脚本对应的服务可能由不同的服务执行引擎获取。

在实际应用中,服务集成层也可以直接集成服务执行引擎的功能,那么服务集成层可以直接调用所请求服务以提供给客户端。

所请求服务具体可以通过远程调用或者本地调用而执行。

在本申请实施例中,可以将服务的注册信息向客户端进行发布,则客户端可以知晓能够从web服务端获取到的服务。

图2所涉及的动作的执行主体可以是同一设备或同一程序,也可以是不同设备或不同程序。比如,步骤s201~s203的执行主体均为某web服务端;又比如,步骤s201的执行主体为某网关设备,而步骤s202~s203的执行主体均为连接该网关设备的某服务器;等等。

通过图2的方法,可以基于通用dsl协议将请求规范化,以及通过服务集成层统一管理各服务的注册信息,以有效地实现服务整合,可以减少上述的硬编码,因此,有利于减少出错以及提高服务效率,可以部分或全部地解决现有技术中的问题。

不仅如此,相比于现有技术中的硬编码,本申请的方案可以基于服务的元数据或者脚本集成以及发布服务,不仅简单,而且支持动态集成和发布,有利于提高系统的开发和运维效率。

基于图2的方法,本申请实施例还提供了该方法的一些具体实施方案,以及扩展方案,下面进行说明。

为了实施图2的方法,需要对现有技术中的系统进行相应的改进,一种具体的改进方案的示例请参照图3。

图3为本申请实施例提供的soa分布式架构下的web系统的一种架构示意图,可以在图3的系统中实施图2的方法。

相比于图1,图3的主要变化在于web服务端。图3中的web服务端主要包括:统一网关、dsl引擎、服务集成层、服务执行引擎、服务的元数据、服务对应的脚本,其中,后面两项可以动态配置,有可能没有。下面结合一些实施例,对这几项的用途进行说明。

在本申请实施例中,对于步骤s201,所述接收客户端发送的基于通用dsl协议的服务请求,具体可以包括:通过统一网关接收客户端发送的基于通用dsl协议的服务请求,所述通用dsl协议可以由所述统一网关定义。

各客户端与web服务端之间的数据交互均可以通过该统一网关进行,可以通过该统一网关向各客户端发布服务。

在本申请实施例中,对于步骤s202,所述对所述服务请求进行解析,具体可以包括:通过dsl引擎对所述服务请求进行解析。dsl引擎解析请求后,可以根据解析得到的服务的标识和参数,调用由服务集成层统一描述的服务。

在本申请实施例中,服务集成层负责定义和管理可提供的各服务。具体地,可以将各服务在服务集成层进行注册,服务集成层根据各注册信息,直接或者间接地调用对应的服务。

以服务集成层间接调用服务的情况为例,对于步骤s203,所述根据所述所请求服务的标识和参数,通过服务集成层调用对应的服务执行引擎,具体可以包括:

将所述所请求服务的标识和参数发送给服务集成层;比如,可以由dsl引擎将解析出的所述标识和参数发送给服务集成层,或者,可以由统一网关解析服务请求,并将解析出的所述标识和参数发送给服务集成层;等等;

所述服务集成层根据所述所请求服务的标识和参数,在其管理的可提供的各服务的注册信息中确定所述所请求服务的注册信息,根据所述所请求服务的注册信息,通过传递所述所请求服务的标识和参数,调用对应的服务执行引擎。

在一个更具体的实例中,上述的元数据或者脚本可以保存在容器中,容器可以将元数据或者脚本,以及对应的服务执行引擎或者其信息包装在一起,在服务集成层注册为一个数据获取器;进而,服务集成层在接收到所请求服务的标识和参数后,可以根据该标识直接定位到对应的数据获取器,然后,再由该数据获取器对应的服务执行引擎执行服务。

在本申请实施例中,所述对应的服务执行引擎可以为:可调用原子服务的服务调用器(serviceinvoker),和/或可通过脚本嵌套调用所述服务调用器的脚本引擎(scriptengine)。当然,若服务调用器也具有脚本解析的功能,则未必要将所述脚本引擎作为服务执行引擎。

在本申请实施例中,对于原子服务,一般可以由服务调用器直接执行,而对于由多项原子服务合成的合成服务,一般可以由脚本引擎先解析对应的脚本,确定该合成服务由哪些原子服务组成,以及各原子服务的逻辑顺序,然后,再调用服务调用器执行各原子服务(相当于执行该合成服务)。

在本申请实施例中,对于步骤s203,所述注册信息包括元数据;当所述对应的服务执行引擎为可调用原子服务的服务调用器时,所述执行所述所请求服务,具体可以包括:

所述服务调用器获得所述所请求服务的元数据,以及所述服务集成层调用时传递的所述所请求服务的标识和参数;所述服务调用器根据所述所请求服务的元数据,以及所述所请求服务的标识和参数,调用所述所请求服务。

服务调用器所使用的元数据可以由服务调用器自行从容器中获取,也可以由服务集成层传递。

在本申请实施例中,对于步骤s203,所述各服务的注册信息包括:包含对多项服务的逻辑编排信息的脚本;当所述对应的服务执行引擎为可通过脚本嵌套调用所述服务调用器的脚本引擎时,所述服务执行引擎执行所述所请求服务,具体可以包括:

所述脚本引擎获得所述所请求服务对应的所述脚本,以及所述服务集成层调用时传递的所述所请求服务的标识和参数;所述脚本引擎通过执行所述脚本,调用所述服务调用器;所述服务调用器基于所述脚本引擎的调用,按照所述逻辑编排信息,调用作为所述所请求服务的所述多项服务。

在本申请实施例中,由于元数据和脚本的可以动态配置,相应地,可以实现动态地注册以及发布新的原子服务或者合成服务。

仍以图3中的架构为例,对于新的原子服务,可以在容器中配置相应的元数据,并在服务集成层进行注册,对于新的合成服务,可以在容器中配置相应的元数据,以及用于编排得到该合成服务的脚本,并在服务集成层进行注册。进而,向统一网关发布对应的服务,以便于所述客户端能够请求所述对应的服务。

结合上面的说明,对本申请的方案的主要特点和效果总结如下:

通过统一网关和基于通用dsl协议的请求定义,规范了前后端交互的标准,请求内容更加语义化和标准化,可以减少web系统开发时沟通和联调成本;

可以基于在服务集成注册的元数据向统一网关发布原子服务,对于只要将原子服务发布到客户端的场景,配置元数据而不是硬编码使得发布服务更加简单并且减少出错几率,开发配置数据而不是代码的形式也带来了动态发布的能力,可以提高了开发效率;

通过编写脚本对原子服务进行组装和编排,使得不仅可以支持单项原子服务的业务场景,也可以支持基于多项原子服务组装编排出的更复杂的业务场景,有利于提高对业务场景支持的完备性。

另外,需要说明的是,上面很多实施例是基于图3中的架构进行说明的,而在实际应用中,图3中的架构并非唯一能够实施本申请的方案的架构,仅是一种示例性的架构。比如,图3中的统一网关、dsl引擎、服务集成层、服务执行引擎等部分的功能也可以重新进行组合或者分拆,从而形成另一种可以能够实施本申请的方案的架构,而且该架构也未必是soa分布式架构下的web系统的架构。

基于同样的发明思路,本申请实施例还提供了一种实际应用场景下,对应于图2的一种服务系统的结构示意图,如图4所示。

图4中的系统包括:统一网关401、dsl引擎402、服务集成层403、一个或多个服务执行引擎404;

所述统一网关401接收客户端发送的基于通用dsl协议的服务请求;

所述统一网关401将所述服务请求传递给所述dsl引擎402;

所述dsl引擎402对所述服务请求进行解析,得到所述客户端所请求服务的标识和参数,以调用所述服务集成层403;

所述服务集成层403根据其管理的可提供的各服务的注册信息,以及所述dsl引擎402调用时传递的所述所请求服务的标识和参数,调用对应的服务执行引擎404以执行所述所请求服务;

其中,所述各服务的注册信息包括:元数据,和/或包含对多项服务的逻辑编排信息的脚本。

基于同样的发明思路,本申请实施例还提供了图2中的方法对应的装置,如图5所示。

图5为本申请实施例提供的对应于图2的一种服务装置的结构示意图,虚线方框表示可选的模块,该装置可以位于图2中流程的执行主体上,包括:

接收模块501,接收客户端发送的基于通用dsl协议的服务请求;

解析模块502,对所述服务请求进行解析,得到所述客户端所请求服务的标识和参数;

服务模块503,根据所述所请求服务的标识和参数,通过服务集成层调用对应的服务执行引擎以执行所述所请求服务;

其中,所述服务集成层用于管理可提供的各服务的注册信息。

可选地,所述接收模块501包含统一网关,所述接收模块501接收客户端发送的基于通用dsl协议的服务请求,具体包括:

所述统一网关接收客户端发送的基于通用dsl协议的服务请求,所述通用dsl协议由所述统一网关定义。

可选地,所述解析模块502包含dsl引擎,所述解析模块502对所述服务请求进行解析,具体包括:

所述dsl引擎对所述服务请求进行解析。

可选地,所述对应的服务执行引擎为:可调用原子服务的服务调用器,和/或可通过脚本嵌套调用所述服务调用器的脚本引擎。

可选地,所述服务模块503包含服务集成层、服务执行引擎,所述服务模块503根据所述所请求服务的标识和参数,通过服务集成层调用对应的服务执行引擎,具体包括:

所述接收模块501将所述所请求服务的标识和参数发送给所述服务集成层;

所述服务集成层根据所述所请求服务的标识和参数,在其管理的可提供的各服务的注册信息中确定所述所请求服务的注册信息,根据所述所请求服务的注册信息,通过传递所述所请求服务的标识和参数,调用对应的服务执行引擎。

可选地,所述注册信息包括元数据;

当所述对应的所述服务执行引擎为可调用原子服务的服务调用器时,所述服务模块503执行所述所请求服务,具体包括:

所述服务调用器获得所述所请求服务的元数据,以及所述服务集成层调用时传递的所述所请求服务的标识和参数;

所述服务调用器根据所述所请求服务的元数据,以及所述所请求服务的标识和参数,调用所述所请求服务。

可选地,所述各服务的注册信息包括:包含对多项服务的逻辑编排信息的脚本;

当所述对应的所述服务执行引擎为可通过脚本嵌套调用所述服务调用器的脚本引擎时,所述服务执行引擎执行所述所请求服务,具体包括:

所述脚本引擎获得所述所请求服务对应的所述脚本,以及所述服务集成层调用时传递的所述所请求服务的标识和参数;

所述脚本引擎通过执行所述脚本,调用所述服务调用器;

所述服务调用器基于所述脚本引擎的调用,按照所述逻辑编排信息,调用作为所述所请求服务的所述多项服务。

可选地,所述装置还包括:

注册发布模块504,将服务的元数据和/或包含对多项服务的逻辑编排信息的脚本在所述服务集成层注册,并向所述统一网关发布对应的服务。

可选地,所述服务为rpc服务。

基于同样的发明思路,本申请实施例还提供了对应的一种电子设备,包括:

至少一个处理器;以及,

与所述至少一个处理器通信连接的存储器;其中,

所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够:

接收客户端发送的基于通用dsl协议的服务请求;

对所述服务请求进行解析,得到所述客户端所请求服务的标识和参数;

根据所述所请求服务的标识和参数,通过服务集成层调用对应的服务执行引擎以执行所述所请求服务;

其中,所述服务集成层用于管理可提供的各服务的注册信息。

基于同样的发明思路,本申请实施例还提供了对应的一种非易失性计算机存储介质,存储有计算机可执行指令,所述计算机可执行指令设置为:

接收客户端发送的基于通用dsl协议的服务请求;

对所述服务请求进行解析,得到所述客户端所请求服务的标识和参数;

根据所述所请求服务的标识和参数,通过服务集成层调用对应的服务执行引擎以执行所述所请求服务;

其中,所述服务集成层用于管理可提供的各服务的注册信息。

本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置、系统、电子设备、非易失性计算机存储介质实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。

本申请实施例提供的装置、系统、电子设备、非易失性计算机存储介质与方法是对应的,因此,装置、系统、电子设备、非易失性计算机存储介质也具有与对应方法类似的有益技术效果,由于上面已经对方法的有益技术效果进行了详细说明,因此,这里不再赘述对应装置、系统、电子设备、非易失性计算机存储介质的有益技术效果。

在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray,fpga))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(hardwaredescriptionlanguage,hdl),而hdl也并非仅有一种,而是有许多种,如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等,目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit,asic)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中,计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(ram)和/或非易失性内存等形式,如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitorymedia),如调制的数据信号和载波。

还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。

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