一种服务调用方法和提供服务调用的装置制造方法
【专利摘要】本发明公开了一种服务调用方法和提供服务调用的装置，涉及软件开发领域，以自动化的方式实现应用软件系统之间的兼容，从而降低成本，提高效率。本发明的方法主要包括：接收第一外部系统发送的应用调用命令，所述应用调用命令中包含目标服务的业务需求参数和服务标识；根据服务标识在预先配置的脚本库中查找所述目标服务对应的内置脚本；执行所述内置脚本，所述内置脚本用于依据所述业务需求参数进行所述目标服务的公共逻辑处理，并调用所述目标服务相关的扩展脚本；执行所述扩展脚本，所述扩展脚本用于进行所述目标服务的非公共逻辑处理。本发明主要用于多个应用软件系统之间相互协作的过程中。
【专利说明】一种服务调用方法和提供服务调用的装置
【技术领域】
[0001]本发明涉及软件开发领域，尤其涉及一种服务调用方法和提供服务调用的装置。【背景技术】
[0002]随着网络的普及，应用类软件进入了高速发展期，应用软件系统之间的关联关系也逐渐紧密，使得多个应用软件系统之间可以通过相互协助为用户提供更为丰富功能。但是，由于应用软件的种类多样并且各应用软件一般都是独立开发的，导致多个应用软件系统之间的交互会出现不兼容的问题。因此，如何解决应用软件系统之间的兼容性问题，使得多个应用软件系统之间可以相互配合成为了关键的问题。
[0003]现有技术中，针对不同应用软件系统之间的兼容性问题处理，通常的方式是做代码上的兼容处理。针对不同的应用软件系统采用本软件系统的开发语言进行编码改进，增加兼容性编码，然后重新编译得到改进后的应用软件，并重新发布新版本应用软件来做到兼容性的支撑。
[0004]但是，这种方式固然解决了兼容性问题，却随之引入了新的问题。目前市面上已发布的应用软件大多数没有考虑与其他应用软件进行兼容的问题，对已有应用软件的开发语言进行兼容性编码并重新编译，需要耗费大量人力和物资，并且开发周期长，效率较低。
【发明内容】
[0005]本发明的实施例提供一种服务调用方法和提供服务调用的装置，以自动化的方式实现应用软件系统之间的兼容，从而降低成本，提高效率。
[0006]为达到上述目的，本发明的实施例采用如下技术方案:
[0007]本发明的一方面提供一种服务调用方法，包括:
[0008]接收第一外部系统发送的应用调用命令，所述应用调用命令中包含目标服务的业务需求参数和服务标识；
[0009]根据所述服务标识在预先配置的脚本库中查找所述目标服务对应的内置脚本；
[0010]执行所述内置脚本，所述内置脚本用于依据所述业务需求参数进行所述目标服务的公共逻辑处理，并调用所述目标服务相关的扩展脚本；
[0011]执行所述扩展脚本，所述扩展脚本用于进行所述目标服务的非公共逻辑处理。
[0012]本发明的另一方面提供一种提供服务调用的装置，包括:
[0013]接收单元，用于接收第一外部系统发送的应用调用命令，所述应用调用命令中包含目标服务的业务需求参数和服务标识；
[0014]查询单元，用于根据所述接收单元接收的服务标识在预先配置的脚本库中查找所述目标服务对应的内置脚本；
[0015]执行单元，用于执行所述内置脚本，所述内置脚本用于依据所述业务需求参数进行所述目标服务的公共逻辑处理，并调用所述目标服务相关的扩展脚本；执行所述扩展脚本，所述扩展脚本用于进行所述目标服务的非公共逻辑处理。[0016]本发明实施例提供的服务调用方法和提供服务调用的装置，在接收到外部系统发送的应用调用命令后，首先调用目标服务的内置脚本，该内置脚本用于处理不同应用软件系统通用的公共逻辑，再调用扩展脚本以处理应用软件系统之间不兼容的非公共逻辑，从而以自动化的方式实现应用软件系统之间的服务兼容，从而降低了多系统协作服务的成本，提高了多系统协作服务的效率。
【专利附图】
【附图说明】
[0017]为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0018]图1为本发明实施例1中的一种服务调用方法流程图；
[0019]图2为本发明实施例2中的一种服务调用方法流程图；
[0020]图3为本发明实施例2中的一种自动化脚本引擎框架示意图；
[0021]图4为本发明实施例3中的一种提供服务调用的装置的组成示意图。
【具体实施方式】
[0022]下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0023]实施例1
[0024]本发明实施例提供一种服务调用方法，如图1所示，包括:
[0025]101、接收第一外部系统发送的应用调用命令，所述应用调用命令中包含目标服务的业务需求参数和服务标识。
[0026]其中，第一外部系统是需要借助提供服务调用的装置得到协作服务的软件系统，第一外部系统可以客户端运行的软件系统，也可以是服务器运行的软件的系统。
[0027]102、根据所述服务标识在预先配置的脚本库中查找所述目标服务对应的内置脚本。
[0028]其中，在提供服务调用之前，在提供服务调用的装置中可以预先配置脚本库，脚本库中包含每个服务的内置脚本，也包含每个服务所需的扩展脚本。一个内置脚本负责一项服务的核心流程，进行公共逻辑处理，也就是说内置脚本的处理对于不同的应用软件系统都是相同的。而不同的应用软件系统之间可能会需求同一项服务，因此一项服务对不同的应用软件系统可以预先配置有不同的扩展脚本。当应用软件系统A需求一项服务时，该项服务的内置脚本可以调用与当前应用软件系统A对应的扩展脚本，以实现与当前应用软件系统A的兼容。
[0029]103、执行所述内置脚本，所述内置脚本用于依据所述业务需求参数进行所述目标服务的公共逻辑处理，并调用所述目标服务相关的扩展脚本。
[0030]其中，业务需求参数由服务调用请求所请求的服务以及发起服务调用请求的应用软件系统决定。不同的应用软件系统发送的业务需求参数的数据结构可能不同，但是提供服务调用的装置并不关心业务需求参数的内部结构，例如所分配的字段个数或所采用的分隔符种类等。只要外部应用软件系统提供的业务需求数据满足预定形式，例如字符串形式或数据表形式等，提供服务调用的装置便可以将业务需求数据透传到内置脚本进行逻辑处理。
[0031]104、执行所述扩展脚本，所述扩展脚本用于进行所述目标服务的非公共逻辑处理。
[0032]其中，由于不同的应用软件系统可以采用各自的开发语言进行开发编译，其逻辑处理的具体过程也会存在差异，这些差异的逻辑处理就是非公共逻辑处理，在本实施例中通过扩展脚本来实现。目标服务的一个非公共逻辑处理可以预先配置多个版本的扩展脚本，分别服务于不同的应用软件系统，当某一应用软件系统发起服务调用请求时，内置脚本可以选择该应用软件系统所需的扩展脚本进行非公共逻辑处理。
[0033]需要说明的是，在内置脚本和扩展脚本的执行过程中，由于脚本的运行需要可以通过与第二外部系统的通信通道与第二外部系统通信，获取第二外部系统的数据，或向第二外部系统发送数据。通过内置脚本和扩展脚本的执行，最终得到处理结果，根据第一外部系统所请求服务的要求不同，内置脚本最终会将处理结果返回给第一外部系统，或发送给第二外部系统，或者发送给其他外部系统，本实施例对此不做限定。
[0034]本发明实施例提供的服务调用方法，在接收到外部系统发送的应用调用命令后，首先调用目标服务的内置脚本，该内置脚本用于处理不同应用软件系统通用的公共逻辑，再调用扩展脚本以处理应用软件系统之间不兼容的非公共逻辑，从而以自动化的方式实现应用软件系统之间的服务兼容，从而降低了多系统协作服务的成本，提高了多系统协作服务的效率。
[0035]实施例2
[0036]本发明实施例提供一种服务调用方法，如图2所示，包括:
[0037]201、接收第一外部系统发送的应用调用命令，所述应用调用命令中包含目标服务的业务需求参数和服务标识。
[0038]其中，服务标识可以为目标服务的名称，或目标服务的ID等，本实施例对服务标识的具体形式不做限定。
[0039]202、获取每个服务的服务标识与其在脚本库中的内置脚本的映射关系；其中，所述脚本库中预先存储有多个服务及每个服务对应的内置脚本和扩展脚本。
[0040]在本实施例中，在脚本库预先配置内置脚本和扩展脚本时，便可以记录内置脚本与服务标识的映射关系，还可以配置一个内置脚本对应的多个扩展脚本的索引。提供服务调用的装置可以在启动时便读取各个服务的服务标识与其内置脚本的映射关系，加载到内存中，以便在接收到应用调用命令后迅速调用应用调用命令所请求的服务对应的内置脚本。
[0041]可以理解的是，内置脚本和扩展脚本统称为脚本库，而脚本库可以存储在提供服务调用的装置的内部存储器中，也可以存储在外部存储设备中，还可以将内置脚本存储在内部存储器中，将扩展脚本存储在外部存储设备中，本实施例对此不做限定。
[0042]203、根据所述服务标识查询所述映射关系，得到所述目标服务对应的内置脚本。[0043]其中，所述内置脚本与服务标识的映射关系可以包含提供服务调用的装置所能提供的每个服务的服务标识，以及每个服务的内置脚本的存储路径。通过查找映射关系可以确定目标服务的内置脚本的存储地址，从而调用内置脚本。
[0044]204、执行所述内置脚本，所述内置脚本用于依据所述业务需求参数进行所述目标服务的公共逻辑处理。
[0045]其中，内置脚本除了进行公共逻辑处理之外，还有一个重要作用就是调用扩展脚本。因此，可以在内置脚本中以脚本代码的形式预先写入所需调用的扩展脚本的地址，该地址可以是相对地址也可以是绝对地址。或者，也可以记录内置脚本与扩展脚本的映射关系，或服务标识与扩展脚本的映射关系，以便内置脚本根据当前请求服务调用的应用软件系统或提供服务的应用软件系统，查找预设的映射关系得到其所需要调用的扩展脚本。
[0046]205、调用所述目标服务相关的扩展脚本，所述扩展脚本用于进行所述目标服务的非公共逻辑处理。
[0047]206、通过功能接口与第二外部系统进行数据交互，以辅助内置脚本或扩展脚本的处理。
[0048]例如，第一外部系统为聊天软件A，请求通过云存储服务器B的备份功能将聊天软件A的联系人信息进行备份，此时云存储服务器B为第二外部系统。聊天软件A发送的业务需求参数包含其联系人信息，调用备份服务对应的内置脚本I后，该内置脚本I会查找到能够将聊天软件A与云存储服务器B之间进行兼容处理的扩展脚本2，从而运行扩展脚本2完成备份到云存储服务器B。
[0049]207、将所述扩展脚本的执行结果返回给所述内置脚本，以便所述内置脚本将所述执行结果进行整体处理。
[0050]208、将整体处理后的最终执行结果按照调用顺序返回给所述第一外部系统。
[0051]例如，若聊天软件A所请求的是以其账户信息查找另一个社交网站C的聊天记录，则聊天软件A发送的业务需求参数包含其账户信息，调用聊天记录拉取服务的内置脚本I’后，该内置脚本I’会超找到能够将聊天软件A与社交网站C之间进行兼容的扩展脚本3，从而运行扩展脚本3得到聊天记录并转换成聊天软件A能识别的数据，再由内置脚本I’完成将最终结果返回给聊天软件A。
[0052]为便于本领域技术人员理解本发明实施例的实现方式，下面以图3为例对提供服务调用的装置的软件(也可称为自动化脚本引擎)的框架结构进行举例说明，在实际应用中不限于图3中表不的方式。第一外部系统发送的指令基于HTTP协议(超文本传输协议)，自动化脚本引擎通过通信接口，例如JsonRPCOverHttp接口(Json为一种轻量级数据转换格式)，可以解析得到应用调用命令的内容。自动化脚本引擎框架为每个服务准备独立的js脚本运行环境(JS，即JavaScript，一种计算机脚本语言)，并分配脚本执行实例号，并将内置脚本与服务名称的映射关系加载到内存中。根据应用调用命令中的服务名称查找到对应的内置脚本，由js执行引擎执行该内置脚本，执行过程中可以调用相关的扩展脚本。内置脚本通过自动化引擎功能接口层，获取第二外部系统提供的数据；自动化引擎功能接口层查找与第二外部系统进行交互的通道，并通过找到的通道与第二外部系统进行交互获取数据；图中例举的通道分别为Telnet协议通道(Telnet协议是TCP/IP协议族中的一员)、SSH协议通道(Secure Shell，建立在应用层和传输层的基础上的安全协议)、TFTP/FTP协议通道(TFTP和FTP均为文件传输协议)。通过第二外部系统交互通道从外部系统获取数据，并返回给自动化引擎功能接口层；内置脚本接收到自动化引擎功能接口层返回的第二外部系统的数据，并进行处理，其中其核心业务逻辑需要变化的部分，即不同系统之间需要做兼容处理的数据则转交给扩展脚本进行处理，并且由扩展脚本将处理结果返回给内置脚本，并由内置脚本处理后，将最终结果按调用顺序返回给第一外部系统。
[0053]需要说明的是，本实施例中部分步骤的具体描述可以参考实施例1中的对应内容，本实施例这里不再重复赘述。
[0054]本发明实施例提供的服务调用方法，在接收到外部系统发送的应用调用命令后，首先调用目标服务的内置脚本，该内置脚本用于处理不同应用软件系统通用的公共逻辑，再调用扩展脚本以处理应用软件系统之间不兼容的非公共逻辑，从而以自动化的方式实现应用软件系统之间的服务兼容，从而降低了多系统协作服务的成本，提高了多系统协作服务的效率。
[0055]实施例3
[0056]本发明实施例提供一种提供服务调用的装置，如图4所示，包括:
[0057]接收单元31，用于接收第一外部系统发送的应用调用命令，所述应用调用命令中包含目标服务的业务需求参数和服务标识；
[0058]查询单元32，用于根据所述接收单元31接收的服务标识在预先配置的脚本库中查找所述目标服务对应的内置脚本；
[0059]执行单元33，用于执行所述查询单元32查询到的内置脚本，所述内置脚本用于依据所述业务需求参数进行所述目标服务的公共逻辑处理，并调用所述目标服务相关的扩展脚本；执行所述扩展脚本，所述扩展脚本用于进行所述目标服务的非公共逻辑处理。
[0060]进一步的,所述查询单元32包括:
[0061]获取子单元321，用于获取每个服务的服务标识与其在脚本库中的内置脚本的映射关系；其中，所述脚本库中预先存储有多个服务及每个服务对应的内置脚本和扩展脚本；
[0062]查询子单元322，用于根据所述接收单元31接收的服务标识查询所述获取子单元321获取的映射关系，得到所述目标服务对应的内置脚本。
[0063]进一步的，所述执行单元33，还用于在所述内置脚本或扩展脚本的执行过程中，通过功能接口与第二外部系统进行数据交互。
[0064]进一步的，所述执行单元33还用于:在执行所述扩展脚本之后，将所述扩展脚本的执行结果返回给所述内置脚本，以便所述内置脚本将所述执行结果进行整体处理。
[0065]进一步的，所述提供服务调用的装置还可以包括:
[0066]发送单元34，用于将所述执行单元33整体处理后的最终执行结果按照调用顺序返回给所述第一外部系统。
[0067]需要说明的是，本实施例中的部分功能单元的具体描述可以参考实施例1和实施例2中的对应内容，本实施例这里不在重复赘述。
[0068]本发明实施例提供的提供服务调用的装置，在接收到外部系统发送的应用调用命令后，首先调用目标服务的内置脚本，该内置脚本用于处理不同应用软件系统通用的公共逻辑，再调用扩展脚本以处理应用软件系统之间不兼容的非公共逻辑，从而以自动化的方式实现应用软件系统之间的服务兼容，从而降低了多系统协作服务的成本，提高了多系统协作服务的效率。
[0069]所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0070]在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0071]所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0072]另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0073]所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM, Read-Only Memory)、随机存取存储器(RAM, Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0074]以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。
【权利要求】
1.一种服务调用方法，其特征在于，包括: 接收第一外部系统发送的应用调用命令，所述应用调用命令中包含目标服务的业务需求参数和服务标识； 根据所述服务标识在预先配置的脚本库中查找所述目标服务对应的内置脚本； 执行所述内置脚本，所述内置脚本用于依据所述业务需求参数进行所述目标服务的公共逻辑处理，并调用所述目标服务相关的扩展脚本； 执行所述扩展脚本，所述扩展脚本用于进行所述目标服务的非公共逻辑处理。
2.根据权利要求1所述的服务调用方法，其特征在于，所述根据所述服务标识在预先配置的脚本库中查找所述目标服务对应的内置脚本，包括: 获取每个服务的服务标识与其在脚本库中的内置脚本的映射关系；其中，所述脚本库中预先存储有多个服务及每个服务对应的内置脚本和扩展脚本； 根据所述服务标识查询所述映射关系，得到所述目标服务对应的内置脚本。
3.根据权利要求1或2所述的服务调用方法，其特征在于，在所述内置脚本或扩展脚本的执行过程中，还包括:通过功能接口与第二外部系统进行数据交互。
4.根据权利要求3所述的服务调用方法，其特征在于，在执行所述扩展脚本之后，还包括: 将所述扩展脚本的执行结果返 回给所述内置脚本，以便所述内置脚本将所述执行结果进行整体处理。
5.根据权利要求4所述的服务调用方法，其特征在于，所述内置脚本还用于:将整体处理后的最终执行结果按照调用顺序返回给所述第一外部系统。
6.一种提供服务调用的装置，其特征在于，包括: 接收单元，用于接收第一外部系统发送的应用调用命令，所述应用调用命令中包含目标服务的业务需求参数和服务标识； 查询单元，用于根据所述接收单元接收的服务标识在预先配置的脚本库中查找所述目标服务对应的内置脚本； 执行单元，用于执行所述查询单元查询到的内置脚本，所述内置脚本用于依据所述业务需求参数进行所述目标服务的公共逻辑处理，并调用所述目标服务相关的扩展脚本；执行所述扩展脚本，所述扩展脚本用于进行所述目标服务的非公共逻辑处理。
7.根据权利要求6所述的提供服务调用的装置，其特征在于，所述查询单元包括: 获取子单元，用于获取每个服务的服务标识与其在脚本库中的内置脚本的映射关系；其中，所述脚本库中预先存储有多个服务及每个服务对应的内置脚本和扩展脚本； 查询子单元，用于根据所述接收单元接收的服务标识查询所述获取子单元获取的映射关系，得到所述目标服务对应的内置脚本。
8.根据权利要求6或7所述的提供服务调用的装置，其特征在于，所述执行单元，还用于在所述内置脚本或扩展脚本的执行过程中，通过功能接口与第二外部系统进行数据交互。
9.根据权利要求8所述的提供服务调用的装置，其特征在于，所述执行单元还用于:在执行所述扩展脚本之后，将所述扩展脚本的执行结果返回给所述内置脚本，以便所述内置脚本将所述执行结果进行整体处理。
10.根据权利要求9所述的提供服务调用的装置，其特征在于，还包括: 发送单元，用于将所述执行单元整体处理后的最终执行结果按照调用顺序返回给所述第一外部系统。`
【文档编号】G06F9/44GK103500102SQ201310483332
【公开日】2014年1月8日 申请日期:2013年10月16日 优先权日:2013年10月16日
【发明者】杨斌 申请人:迈普通信技术股份有限公司