WO2017117876A1 - 基于tosca的服务调用方法及装置 - Google Patents

基于tosca的服务调用方法及装置 Download PDF

Info

Publication number
WO2017117876A1
WO2017117876A1 PCT/CN2016/078695 CN2016078695W WO2017117876A1 WO 2017117876 A1 WO2017117876 A1 WO 2017117876A1 CN 2016078695 W CN2016078695 W CN 2016078695W WO 2017117876 A1 WO2017117876 A1 WO 2017117876A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
node
information
calling
call
Prior art date
Application number
PCT/CN2016/078695
Other languages
English (en)
French (fr)
Inventor
王淼
吕波
孟照星
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2017117876A1 publication Critical patent/WO2017117876A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/566—Grouping or aggregating service requests, e.g. for unified processing

Definitions

  • the present invention relates to the field of communications, and in particular, to a service invocation method and apparatus based on a Topology and Orchestration Specification for Cloud Applications (TOSCA).
  • TOSCA Topology and Orchestration Specification for Cloud Applications
  • the TOSCA is proposed by the Organization For The Advancement Of Structured Information Standards (OASIS).
  • OASIS Organization For The Advancement Of Structured Information Standards
  • the specification mainly includes two parts: the network topology, describing the composition of the cloud application and the services that each node can provide; the programming information is mainly a collection of services provided by each node in the topology, and is presented as a planned Plan workflow.
  • the structure of the topology template and the services provided by each node are defined in the TOSCA specification.
  • the specification supports existing standard workflows, such as Business Process Execution Language (BPEL) 2.0 or Business Process Modeling Notation (BPMN) 2.0, and also supports customization. Workflow.
  • BPEL Business Process Execution Language
  • BPMN Business Process Modeling Notation
  • the TOSCA specification does not explain how the nodes and corresponding services in the template definition should be reflected in the process, nor how the services should be called by the process.
  • the services provided by each device may be various, such as the application WebService service, etc., that is, the services provided by the devices of the same manufacturer may also be different. If you want to call different types of services in the process, then Plan will need to provide support for various service calls, and the development and modification of Plan will become very difficult.
  • the present invention provides a TOSCA-based service invocation method and apparatus to at least solve the problem in the related art that the development and modification of the Plan is difficult due to the invocation of different types of services in the TOSCA specification.
  • a TOSCA-based service invocation method including:
  • the middle layer acquires service deployment information of the node according to the cloud service template CSAR file
  • the middle layer receives the calling service information initiated by the planned workflow Plane through the unified calling interface
  • the obtaining, by the intermediate layer, the node service deployment information according to the cloud service template CSAR file includes: decompressing the CSAR file, generating a temporary file, and acquiring node definition information from the temporary file, according to the node definition
  • the node service definition in the information gets the service deployment information of the node.
  • the method further includes: deleting the temporary file.
  • the service deployment information includes a service type and a service call address.
  • a TOSCA based service invocation method including
  • the planned workflow Plan initiates a service call to the middle layer according to the input parameter of the user, wherein the input parameter is used to indicate a node to be called by the user and a method of the node;
  • the Plan acquires a result of calling the middle layer to the service call.
  • a TOSCA based service call apparatus applied to an intermediate layer, comprising:
  • the first obtaining module is configured to acquire service deployment information of the node according to the cloud service template CSAR file;
  • a receiving module configured to receive, by using a unified calling interface of the middle layer, call service information initiated by the planned workflow Plan;
  • a second obtaining module configured to acquire service deployment information of the method of the node and the node according to the method of calling the node and the node in the calling service information
  • Calling a module configured to initiate a call to the service indicated by the invoked service information according to the service deployment information
  • the feedback module is configured to obtain the service call result of the call, and feed back the service call result to the Plan.
  • the first acquiring module includes:
  • Decompressing unit configured to decompress the CSAR file to generate a temporary file
  • An obtaining unit configured to obtain node definition information from the temporary file
  • An obtaining unit is configured to obtain service deployment information of the node according to a node service definition in the node definition information.
  • the first obtaining module further includes:
  • Delete the unit set to delete the temporary file.
  • the service deployment information includes a service type and a service call address.
  • a TOSCA based service call apparatus applied to a TOSCA template, comprising:
  • Calling a module configured to indicate that the planned workflow Plan initiates a service call to the middle layer according to the input parameter of the user, wherein the input parameter is used to indicate a node to be called by the user and a method of the node;
  • Obtaining a result module configured to instruct the Plan to obtain a result of calling the middle layer to the service call.
  • the middle layer acquires the service deployment information of the node according to the cloud service template CSAR file, and the middle layer receives the calling service information initiated by the planned workflow Flow through the unified calling interface, according to the node and the node that are required to be invoked in the calling service information.
  • the method, the service deployment information of the node and the method of the node is obtained, the call of the service indicated by the call service information is initiated according to the service deployment information, the service call result of the call is obtained, and the service call result is fed back to the method Plan, solves the problem that the development and modification of the Plane is difficult due to the absence of the call method of different types of services in the TOSCA specification, which greatly facilitates the development and modification of the Plan.
  • FIG. 1 is a flowchart 1 of a TOSCA-based service invocation method according to an embodiment of the present invention
  • FIG. 2 is a second flowchart of a TOSCA-based service invocation method according to an embodiment of the present invention
  • FIG. 3 is a structural block diagram 1 of an apparatus for calling a service based on TOSCA according to an embodiment of the present invention
  • FIG. 4 is a structural block diagram 2 of an apparatus for calling a service based on TOSCA according to an embodiment of the present invention
  • FIG. 5 is a structural block diagram 3 of an apparatus for calling a TOSCA based service according to an embodiment of the present invention
  • FIG. 6 is a structural block diagram 4 of an apparatus for calling a service based on TOSCA according to an embodiment of the present invention
  • FIG. 7 is a structural diagram of a service template of a TOSCA in an OASIS standard according to a preferred embodiment of the present invention.
  • FIG. 8 is a flow chart of an intermediate layer acquisition method for deploying CSAR and node services according to a preferred embodiment of the present invention
  • FIG. 9 is a flow diagram of a Plan call node service method in accordance with a preferred embodiment of the present invention.
  • FIG. 1 is a flowchart 1 of a TOSCA-based service invocation method according to an embodiment of the present invention. As shown in FIG. 1, the process includes the following steps:
  • Step S102 The middle layer acquires service deployment information of the node according to the cloud service template CSAR file.
  • Step S104 the middle layer receives the calling service information initiated by the planned workflow Plane through the unified calling interface
  • Step S106 obtaining service deployment information of the node and the method of the node according to the calling node and the method of the node in the calling service information;
  • Step S108 initiating a call to the service indicated by the calling service information according to the service deployment information
  • Step S110 Acquire a service call result of the call, and feed back the service call result to the Plan.
  • the middle layer obtains the service deployment information of the node according to the cloud service template CSAR file, and the middle layer receives the call service information initiated by the planned workflow flow through the unified calling interface, according to the node and the node that are required to be invoked in the call service information.
  • the method, the service deployment information of the node and the method of the node is obtained, the call of the service indicated by the call service information is initiated according to the service deployment information, the service call result of the call is obtained, and the service call result is fed back to the method Plan, solves the problem that the development and modification of the Plane is difficult due to the absence of the call method of different types of services in the TOSCA specification, which greatly facilitates the development and modification of the Plan.
  • the middle Tier also known as the "application service layer or application service layer," is the logical layer between the user interface or the web client and the database.
  • the obtaining, by the intermediate layer, the node service deployment information according to the cloud service template CSAR file includes: decompressing the CSAR file, generating a temporary file, and acquiring node definition information from the temporary file, according to the node service definition in the node definition information. Get the service deployment information of the node.
  • the temporary file is deleted, which saves the storage space of the middle layer.
  • the service deployment information includes a service type and a service call address.
  • FIG. 2 is a flowchart 2 of a TOSCA-based service invocation method according to an embodiment of the present invention. As shown in FIG. 2, the process includes the following steps. :
  • Step S202 the planned workflow Plan initiates a service call to the middle layer according to the input parameter of the user, where the input parameter is used to indicate the node to be called by the user and the method of the node;
  • Step S204 the Plan obtains a result of calling the middle layer to the service call.
  • the planned workflow Plan initiates a service call to the middle layer according to the input parameter of the user, wherein the input parameter is used to indicate the node to be called by the user and the method of the node, and the Plan obtains the middle layer to the service.
  • the call result of the call, Plan only needs to interact with the middle layer to obtain the service call result of each node, which greatly facilitates the development and modification of the Plan.
  • module may implement a combination of software and/or hardware of a predetermined function.
  • apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
  • FIG. 3 is a structural block diagram 1 of a device for invoking a service call based on a TOSCA according to an embodiment of the present invention, applied to an intermediate layer, as shown in FIG. 3, the device includes:
  • the first obtaining module 32 is configured to acquire service deployment information of the node according to the cloud service template CSAR file;
  • the receiving module 34 is connected to the first obtaining module 32, and is configured to receive the calling service information initiated by the planned workflow Plane through the unified calling interface of the intermediate layer;
  • the second obtaining module 36 is connected to the receiving module 34, and configured to acquire service deployment information of the node and the method of the node according to the node that is required to be invoked in the calling service information and the method of the node;
  • the calling module 38 is connected to the second obtaining module 36, and is configured to initiate a call to the service indicated by the calling service information according to the service deployment information;
  • the feedback module 40 is connected to the calling module 38, and is configured to obtain a service call result of the call, and feed back the service call result to the Plan.
  • the first obtaining module 32 acquires the service deployment information of the node according to the cloud service template CSAR file, and the receiving module 34 receives the calling service information initiated by the planned workflow Plane through the unified calling interface, and the second obtaining module 36 according to the calling service information
  • the calling node and the method of the node are requested to obtain service deployment information of the node and the method of the node, and the calling module 38 is configured to initiate a call of the service indicated by the calling service information according to the service deployment information, and the feedback module 40 Obtaining the result of the service call of the call, and feeding back the result of the service call to the Plan, and solving the problem that the development and modification of the Plan is difficult due to the absence of the call mode of different types of services in the TOSCA specification, which greatly facilitates the development of the Plan and modify.
  • FIG. 4 is a structural block diagram 2 of an apparatus for invoking a service call based on a TOSCA according to an embodiment of the present invention.
  • the first obtaining module 32 includes:
  • the decompressing unit 42 is configured to decompress the CSAR file to generate a temporary file
  • the obtaining unit 44 is connected to the decompression unit 42 and configured to acquire node definition information from the temporary file;
  • the obtaining unit 46 is connected to the obtaining unit 44, and is configured to obtain service deployment information of the node according to the node service definition in the node definition information.
  • FIG. 5 is a structural block diagram 3 of an apparatus for invoking a service call based on a TOSCA according to an embodiment of the present invention.
  • the first obtaining module 32 includes:
  • the deleting unit 52 is connected to the obtaining unit 46 and is arranged to delete the temporary file.
  • the service deployment information includes a service type and a service call address.
  • FIG. 6 is a structural block diagram 4 of an apparatus for invoking a service call based on a TOSCA according to an embodiment of the present invention. The method is applied to a TOSCA template. As shown in FIG. 6, the apparatus includes:
  • the calling module 62 is configured to instruct the planned workflow Plan to initiate a service call to the middle layer according to the input parameter of the user, wherein the input parameter is used to indicate the node to be called by the user and the method of the node;
  • the result module 64 is connected to the calling module 62 and is set to instruct the Plan to obtain the result of the call of the middle layer to the service call.
  • the calling module 62 is set to instruct the planned workflow Plan to initiate a service call to the middle layer according to the input parameter of the user, wherein the input parameter is used to indicate the node to be called by the user and the method of the node, and obtain the result module.
  • 64 is set to instruct the Plan to obtain the result of the call of the middle layer to the service call, and the Plan only needs to interact with the middle layer to obtain the service call result of each node, which greatly facilitates the development and modification of the Plan.
  • each of the above modules may be implemented by software or hardware.
  • the foregoing may be implemented by, but not limited to, the foregoing modules are all located in the same processor; or, the modules are located in multiple In the processor.
  • FIG. 7 is a service template structure diagram of the TOSCA in the OASIS standard according to a preferred embodiment of the present invention.
  • the service provided by the designated node is invoked and how to pass Define the middle layer to simplify the difficulty of Plan calls to services.
  • the interactive communication between the Network Orchestration Center and the Virtual Infrastructure Management (VIM) is cross-vendor.
  • the services provided by different vendors may be different.
  • the middle layer is responsible for providing a standard interface to the Plan and handling the adaptation of the service modes required by different devices. Plan only interacts with the middle layer, and initiates a call to the node service through a standard interface.
  • the processing method is simple and single.
  • different services are distinguished by defining the services in the TOSCA template and corresponding deployment information, and forwarding calls are made to different services. In this way, support for different services is transferred to the middle layer for unified processing, shielding the direct association between the Plan and the specific service.
  • the Plan in the TOSCA template refers to the process and workflow for orchestrating the service; the corresponding archive format of the TOSCA model file is called the Cloud Service Archive (CSAR).
  • CRC Cloud Service Archive
  • the preferred embodiment provides a method for the intermediate layer to parse the CSAR to obtain the corresponding service information of the node, and the steps of the method include:
  • the first step extract the CSAR file and generate a temporary file
  • the second step obtaining node definition information and saving the node service definition
  • the third step according to the service definition, find the corresponding service implementation and deploy it;
  • Step 4 Record service deployment information (service type, call address, etc.);
  • Step 5 Delete the temporary file
  • Step 6 Provide a unified call interface and wait for the Plan call.
  • the preferred embodiment provides a method for calling a service provided by a node, and the steps of the method include:
  • the first step the user indicates the node to be called and its method
  • Step 2 Plan sends the service to the middle layer service through the unified interface
  • the third step the middle layer obtains the service type and service address according to the node and its method
  • Step 4 The middle layer initiates a call to the service
  • Step 5 The middle layer returns the result of the service call
  • Step 6 Plan gets the result of the service call.
  • FIG. 8 is a flowchart of an intermediate layer acquiring a method for deploying a CSAR and a node service according to a preferred embodiment of the present invention. As shown in FIG. 8, the method includes the following steps:
  • Step 801 Decompress the imported CSAR file to generate a temporary file.
  • Step 802 Search for CSAR definition information, and obtain a service definition corresponding to the node.
  • Step 803 according to the service definition, find a location corresponding to the service implementation, and deploy the service;
  • Step 804 recording service related deployment information (service type, service deployment address, etc.);
  • Step 805 deleting the temporary file
  • Step 806 start the service, provide a unified interface to the outside, and wait for the Plan to call.
  • FIG. 9 is a flowchart of a Plan call node service method according to a preferred embodiment of the present invention. As shown in FIG. 9, the method includes the following steps:
  • Step 901 The user specifies, by using an input parameter, a node and a method to be called;
  • Step 902 the Plan initiates a call to the middle layer
  • step 903 the middle layer is connected to the Plan application
  • Step 904 The middle layer acquires a service definition according to the node and the method.
  • Step 905 the middle layer initiates a call to the service
  • Step 906 the middle layer obtains a service call result
  • step 907 the Plan obtains the result of the service call.
  • the technical solution of the present invention which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk,
  • a storage medium such as ROM/RAM, disk,
  • the optical disc includes a number of instructions for causing a terminal device (which may be a cell phone, a computer, a server, or a network device, etc.) to perform the methods described in various embodiments of the present invention.
  • Embodiments of the present invention also provide a storage medium.
  • the storage medium may be configured to store program code for performing the method steps of the above embodiment:
  • the storage medium is further arranged to store program code for performing the method steps of the above-described embodiments:
  • the foregoing storage medium may include, but not limited to, a USB flash drive, a Read-Only Memory (ROM), a Random Access Memory (RAM), a mobile hard disk, and a magnetic memory.
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • a mobile hard disk e.g., a hard disk
  • magnetic memory e.g., a hard disk
  • the processor performs the method steps of the foregoing embodiments according to the stored program code in the storage medium.
  • modules or steps of the present invention described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein.
  • the steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated as a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.
  • the middle layer acquires the service deployment information of the node according to the cloud service template CSAR file, and the middle layer receives the call service information initiated by the planned workflow flow through the unified calling interface, according to the invoked service information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本发明提供了一种基于TOSCA的服务调用方法及装置，其中，该方法包括：中间层根据云服务模板CSAR文件获取节点的服务部署信息，该中间层通过统一调用接口接收计划工作流Plan发起的调用服务信息，依据该调用服务信息中要求调用的节点及该节点的方法，获取该节点及该节点的方法的服务部署信息，依据该服务部署信息发起对该调用服务信息所指示的服务的调用，获取该调用的服务调用结果，将该服务调用结果反馈给该Plan。采用上述技术方案，解决了由于TOSCA规范中没有规定对不同类型服务的调用方式导致Plan开发及修改困难的问题，极大的方便了Plan开发及修改。

Description

基于TOSCA的服务调用方法及装置 技术领域
本发明涉及通信领域，具体而言，涉及一种基于云应用的拓扑和业务流程规范(Topology and Orchestration Specification for Cloud Applications，简称为TOSCA)的服务调用方法及装置。
背景技术
近年来，云计算、虚拟化技术发展迅速，带来了很多创新，同时也给运营商带来很大的压力，运营商面临寻找新的收入增长点，以抵消开放互联网的视频服务Over the Top,简称为OTT)业务带来的影响，同时降低企业的管理支出(Operating Expense，简称为OPEX)，快速开展业务。
TOSCA由结构化标准促进组织(Organization For The Advancement Of Structured Information Standards，简称为OASIS)提出。该规范主要包含两部分的内容：网络拓扑，描述云应用的构成及其各节点可提供的服务；编排信息，主要是对拓扑结构中各个节点提供服务的集合，呈现为计划Plan工作流方式。
TOSCA规范中定义了拓扑模板的结构和各节点提供的服务。规范支持现有的标准工作流，如业务流程执行语言(Business Process Execution Language，简称为BPEL)2.0或业务流程建模与标注(Business Process Modeling Notation，简称为BPMN)2.0等，同时也支持自定义的工作流。但是，TOSCA规范即没有说明在模板定义中的各节点和对应的服务应该如何在流程中得到体现，也没有说明各服务应该用何种方式被流程调用。对于不同厂商的设备，各设备提供服务的方式可能多种多样，如应用程序WebService服务等，就是同一厂商的设备提供的服务也可能有区别。如果要在流程中对各种不同类型的服务进行调用，那么Plan将需要提供对各种服务调用进行支持，Plan的开发及修改将变得非常困难。
针对相关技术中，由于TOSCA规范中Plan开发及修改困难的问题，目前还没有解决方案。
发明内容
本发明提供了一种基于TOSCA的服务调用方法及装置，以至少解决相关技术中由于TOSCA规范中没有规定对不同类型服务的调用方式导致Plan开发及修改困难的问题。
根据本发明的一个实施例，提供了一种基于TOSCA的服务调用方法，包括：
中间层根据云服务模板CSAR文件获取节点的服务部署信息；
所述中间层通过统一调用接口接收计划工作流Plan发起的调用服务信息；
依据所述调用服务信息中要求调用的节点及所述节点的方法，获取所述节点及所述节点的方法的服务部署信息；
依据所述服务部署信息发起对所述调用服务信息所指示的服务的调用；
获取所述调用的服务调用结果，将所述服务调用结果反馈给所述Plan。
在本发明的实施例中，所述中间层根据云服务模板CSAR文件获取节点服务部署信息包括：解压所述CSAR文件，生成临时文件，从所述临时文件获取节点定义信息，依据所述节点定义信息中的节点服务定义得到所述节点的服务部署信息。
在本发明的实施例中，在依据所述节点服务定义得到服务部署信息之后，所述方法还包括：删除所述临时文件。
在本发明的实施例中，所述服务部署信息包括服务类型和服务调用地址。
根据本发明的一个实施例，还提供了一种基于TOSCA的服务调用方法，包括
计划工作流Plan依据用户的输入参数发起对中间层的服务调用，其中，所述输入参数用于指示所述用户要调用的节点及所述节点的方法；
所述Plan获取所述中间层对所述服务调用的调用结果。
根据本发明的另一实施例，提供了一种基于TOSCA的服务调用的装置，应用于中间层，包括：
第一获取模块，设置为根据云服务模板CSAR文件获取节点的服务部署信息；
接收模块，设置为通过所述中间层的统一调用接口接收计划工作流Plan发起的调用服务信息；
第二获取模块，设置为依据所述调用服务信息中要求调用的节点及所述节点的方法，获取所述节点及所述节点的方法的服务部署信息；
调用模块，设置为依据所述服务部署信息发起对所述调用服务信息所指示的服务的调用；
反馈模块，设置为获取所述调用的服务调用结果，将所述服务调用结果反馈给所述Plan。
在本发明的实施例中，所述第一获取模块包括：
解压单元，设置为解压所述CSAR文件，生成临时文件；
获取单元，设置为从所述临时文件获取节点定义信息；
获得单元，设置为依据所述节点定义信息中的节点服务定义得到所述节点的服务部署信息。
在本发明的实施例中，所述第一获取模块还包括：
删除单元，设置为删除所述临时文件。
在本发明的实施例中，所述服务部署信息包括服务类型和服务调用地址。
根据本发明的另一实施例，提供了一种基于TOSCA的服务调用的装置，应用于TOSCA模板，包括：
调用模块，设置为指示计划工作流Plan依据用户的输入参数发起对中间层的服务调用，其中，所述输入参数用于指示所述用户要调用的节点及所述节点的方法；
获取结果模块，设置为指示所述Plan获取所述中间层对所述服务调用的调用结果。
通过本发明，中间层根据云服务模板CSAR文件获取节点的服务部署信息，该中间层通过统一调用接口接收计划工作流Plan发起的调用服务信息，依据该调用服务信息中要求调用的节点及该节点的方法，获取该节点及该节点的方法的服务部署信息，依据该服务部署信息发起对该调用服务信息所指示的服务的调用，获取该调用的服务调用结果，将该服务调用结果反馈给该Plan，解决了由于TOSCA规范中没有规定对不同类型服务的调用方式导致Plan开发及修改困难的问题，极大的方便了Plan开发及修改。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例的一种基于TOSCA的服务调用方法的流程图一；
图2是根据本发明实施例的一种基于TOSCA的服务调用方法的流程图二；
图3是根据本发明实施例的一种基于TOSCA的服务调用的装置的结构框图一；
图4是根据本发明实施例的一种基于TOSCA的服务调用的装置的结构框图二；
图5是根据本发明实施例的一种基于TOSCA的服务调用的装置的结构框图三；
图6是根据本发明实施例的一种基于TOSCA的服务调用的装置的结构框图四；
图7是根据本发明优选实施例的OASIS标准中TOSCA的服务模板结构图；
图8是根据本发明优选实施例的中间层获取部署CSAR和节点服务方法的流程图；
图9是根据本发明优选实施例的Plan调用节点服务方法的流程图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
在本实施例中提供了一种基于TOSCA的服务调用方法，图1是根据本发明实施例的一种基于TOSCA的服务调用方法的流程图一，如图1所示，该流程包括如下步骤：
步骤S102，中间层根据云服务模板CSAR文件获取节点的服务部署信息；
步骤S104，该中间层通过统一调用接口接收计划工作流Plan发起的调用服务信息；
步骤S106，依据该调用服务信息中要求调用的节点及该节点的方法，获取该节点及该节点的方法的服务部署信息；
步骤S108，依据该服务部署信息发起对该调用服务信息所指示的服务的调用；
步骤S110，获取该调用的服务调用结果，将该服务调用结果反馈给该Plan。
通过上述步骤，中间层根据云服务模板CSAR文件获取节点的服务部署信息，该中间层通过统一调用接口接收计划工作流Plan发起的调用服务信息，依据该调用服务信息中要求调用的节点及该节点的方法，获取该节点及该节点的方法的服务部署信息，依据该服务部署信息发起对该调用服务信息所指示的服务的调用，获取该调用的服务调用结果，将该服务调用结果反馈给该Plan，解决了由于TOSCA规范中没有规定对不同类型服务的调用方式导致Plan开发及修改困难的问题，极大的方便了Plan开发及修改。中间层(middle Tier)也称作“应用程序服务层或应用服务层”，是用户接口或Web客户端与数据库之间的逻辑层。
在本实施例中，该中间层根据云服务模板CSAR文件获取节点服务部署信息包括：解压该CSAR文件，生成临时文件，从该临时文件获取节点定义信息，依据该节点定义信息中的节点服务定义得到该节点的服务部署信息。
在本实施例中，在依据该节点服务定义得到服务部署信息之后，删除该临时文件，节省了中间层的存储空间。
在上述实施例中，该服务部署信息包括服务类型和服务调用地址。
在本实施例中还提供了一种基于TOSCA的服务调用方法，图2是根据本发明实施例的一种基于TOSCA的服务调用方法的流程图二，如图2所示，该流程包括如下步骤：
步骤S202，计划工作流Plan依据用户的输入参数发起对中间层的服务调用，其中，该输入参数用于指示该用户要调用的节点及该节点的方法；
步骤S204，该Plan获取该中间层对该服务调用的调用结果。
通过上述步骤，计划工作流Plan依据用户的输入参数发起对中间层的服务调用，其中，该输入参数用于指示该用户要调用的节点及该节点的方法，该Plan获取该中间层对该服务调用的调用结果，Plan只需与中间层进行交互即可获取各个节点的服务调用结果，极大的方便了Plan的开发及修改。
在本实施例中还提供了两种基于TOSCA的服务调用的装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图3是根据本发明实施例的一种基于TOSCA的服务调用的装置的结构框图一，应用于中间层，如图3所示，该装置包括：
第一获取模块32，设置为根据云服务模板CSAR文件获取节点的服务部署信息；
接收模块34，与所述第一获取模块32连接，设置为通过该中间层的统一调用接口接收计划工作流Plan发起的调用服务信息；
第二获取模块36，与所述接收模块34连接，设置为依据该调用服务信息中要求调用的节点及该节点的方法，获取该节点及该节点的方法的服务部署信息；
调用模块38与所述第二获取模块36连接，设置为依据该服务部署信息发起对该调用服务信息所指示的服务的调用；
反馈模块40与所述调用模块38连接，设置为获取该调用的服务调用结果，将该服务调用结果反馈给该Plan。
通过上述步骤，第一获取模块32根据云服务模板CSAR文件获取节点的服务部署信息，接收模块34通过统一调用接口接收计划工作流Plan发起的调用服务信息，第二获取模块36依据该调用服务信息中要求调用的节点及该节点的方法，获取该节点及该节点的方法的服务部署信息，调用模块38设置为依据该服务部署信息发起对该调用服务信息所指示的服务的调用，反馈模块40获取该调用的服务调用结果，将该服务调用结果反馈给该Plan，解决了由于TOSCA规范中没有规定对不同类型服务的调用方式导致Plan开发及修改困难的问题，极大的方便了Plan开发及修改。
图4是根据本发明实施例的一种基于TOSCA的服务调用的装置的结构框图二，如图4所示，该第一获取模块32包括：
解压单元42，设置为解压该CSAR文件，生成临时文件；
获取单元44与所述解压单元42连接，设置为从该临时文件获取节点定义信息；
获得单元46与所述获取单元44连接，设置为依据该节点定义信息中的节点服务定义得到该节点的服务部署信息。
图5是根据本发明实施例的一种基于TOSCA的服务调用的装置的结构框图三，如图5所示，该第一获取模块32包括：
删除单元52与所述获得单元46连接，设置为删除该临时文件。
在本发明的实施例中，该服务部署信息包括服务类型和服务调用地址。
图6是根据本发明实施例的一种基于TOSCA的服务调用的装置的结构框图四，应用于TOSCA模板，如图6所示，该装置包括：
调用模块62，设置为指示计划工作流Plan依据用户的输入参数发起对中间层的服务调用，其中，该输入参数用于指示该用户要调用的节点及该节点的方法；
获取结果模块64，与调用模块62连接，设置为指示该Plan获取该中间层对该服务调用的调用结果。
通过上述步骤，调用模块62设置为指示计划工作流Plan依据用户的输入参数发起对中间层的服务调用，其中，该输入参数用于指示该用户要调用的节点及该节点的方法，获取结果模块64设置为指示该Plan获取该中间层对该服务调用的调用结果，Plan只需与中间层进行交互即可获取各个节点的服务调用结果，极大的方便了Plan的开发及修改。
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述模块分别位于多个处理器中。
下面结合优选实施例和实施方式对本发明进行详细说明。
本发明优选实施例公开实现了一种实现虚拟化场景下基于TOSCA规范的服务调用方式。该方法指明了Plan中应该如何结合TOSCA定义模板，图7是根据本发明优选实施例的OASIS标准中TOSCA的服务模板结构图，如图7所示，对指定节点提供的服务进行调用以及如何通过定义中间层的方式来简化Plan对服务调用的难度。在虚拟化场景下，网络编排中心和不同虚拟基础设施管理器(Virtualised Infrastructure Manage，简称为VIM)的交互通信是跨厂商的，不同厂商提供的服务可能各不相同，通过定义中间层转发，来简化具体Plan的调用方式。中间层负责提供对Plan的标准接口，并处理不同设备需要的服务方式的适配。Plan只与中间层进行交互，通过标准接口发起对节点服务的调用，处理方式简单单一。在中间层通过对TOSCA模板中服务的定义及相应的部署信息来区分不同的服务，并对不同的服务进行转发调用。这样，将对不同服务的支持转移到中间层进行统一处理，屏蔽了Plan和具体服务间的直接关联。
在本发明优选实施例中，TOSCA模板中的Plan是指对服务进行编排的流程及工作流；TOSCA模型文件相应的归档格式称为云服务模板(Cloud Service Archive，简称为CSAR)。
本优选实施例提供了中间层解析CSAR获取节点对应服务信息的方法，该方法的步骤包括：
第一步：解压CSAR文件，生成临时文件；
第二步：获取节点定义信息，保存节点服务定义；
第三步：根据服务定义，找到对应服务实现，并进行部署；
第四步：记录服务部署信息(服务类型，调用地址等)；
第五步：删除临时文件；
第六步：提供统一调用接口，等待Plan调用。
本优选实施例提供了Plan调用节点提供的服务的方法，该方法的步骤包括：
第一步：用户指明要调用的节点及其方法；
第二步：Plan通过统一接口发送服务给中间层服务；
第三步：中间层根据节点及其方法获取服务类型及服务地址；
第四步：中间层发起对服务的调用；
第五步：中间层返回服务调用结果；
第六步：Plan获取到服务调用结果。
图8是根据本发明优选实施例的中间层获取部署CSAR和节点服务方法的流程图，如图8所示，该方法包括如下步骤：
步骤801，解压导入的CSAR文件，生成临时文件；
步骤802，查找CSAR定义信息，获取节点对应的服务定义；
步骤803，根据服务定义，找到对应服务实现的位置，部署服务；
步骤804，记录服务相关的部署信息(服务类型、服务部署地址等)；
步骤805，删除临时文件；
步骤806，启动服务，对外提供统一的接口，等待Plan进行调用。
图9是根据本发明优选实施例的Plan调用节点服务方法的流程图，如图9所示，该方法包括如下步骤：
步骤901，用户在通过输入参数指定要调用节点及方法；
步骤902，Plan发起对中间层的调用；
步骤903，中间层接到Plan申请；
步骤904，中间层根据节点及方法获取服务定义；
步骤905，中间层发起对服务的调用；
步骤906，中间层获取服务调用结果；
步骤907，Plan获取到服务调用结果。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方 法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行上述实施例的方法步骤的程序代码：
可选地，存储介质还被设置为存储用于执行上述实施例的方法步骤的程序代码：
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行上述实施例的方法步骤。
可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
工业实用性
基于本发明实施例提供的上述技术方案，中间层根据云服务模板CSAR文件获取节点的服务部署信息，该中间层通过统一调用接口接收计划工作流Plan发起的调用服务信息，依据该调用服务信息中要求调用的节点及该节点的方法，获取该节点及该节点的方法的服务部署信息，依据该服务部署信息发起对该调用服务信息所指示的服务的调用，获取该调用的服务调用结果，将该服务调用结果反馈给该Plan，解决了由于TOSCA规范中没有规定对不同类型服务的调用方式导致Plan开发及修改困难的问题，极大的方便了Plan开发及修改。

Claims (10)

  1. 一种基于云应用的拓扑和业务流程规范TOSCA的服务调用方法，包括：
    中间层根据云服务模板CSAR文件获取节点的服务部署信息；
    所述中间层通过统一调用接口接收计划工作流Plan发起的调用服务信息；
    依据所述调用服务信息中要求调用的节点及所述节点的方法，获取所述节点及所述节点的方法的服务部署信息；
    依据所述服务部署信息发起对所述调用服务信息所指示的服务的调用；
    获取所述调用的服务调用结果，将所述服务调用结果反馈给所述Plan。
  2. 根据权利要求1所述的方法，其中，所述中间层根据云服务模板CSAR文件获取节点的服务部署信息包括：
    解压所述CSAR文件，生成临时文件；
    从所述临时文件获取节点定义信息；
    依据所述节点定义信息中的节点服务定义得到所述节点的服务部署信息。
  3. 根据权利要求2所述的方法，其中，在依据所述节点服务定义得到服务部署信息之后，所述方法还包括：
    删除所述临时文件。
  4. 根据权利要求1至3任一项所述的方法，其中，所述服务部署信息包括服务类型和服务调用地址。
  5. 一种基于云应用的拓扑和业务流程规范TOSCA的服务调用方法，包括：
    计划工作流Plan依据用户的输入参数发起对中间层的服务调用，其中，所述输入参数用于指示所述用户要调用的节点及所述节点的方法；
    所述Plan获取所述中间层对所述服务调用的调用结果。
  6. 一种基于云应用的拓扑和业务流程规范TOSCA的服务调用装置，应用于中间层，包括：
    第一获取模块，设置为根据云服务模板CSAR文件获取节点的服务部署信息；
    接收模块，设置为通过所述中间层的统一调用接口接收计划工作流Plan发起的调用服务信息；
    第二获取模块，设置为依据所述调用服务信息中要求调用的节点及所述节点的方法，获取所述节点及所述节点的方法的服务部署信息；
    调用模块，设置为依据所述服务部署信息发起对所述调用服务信息所指示的服务的 调用；
    反馈模块，设置为获取所述调用的服务调用结果，将所述服务调用结果反馈给所述Plan。
  7. 根据权利要求6所述的装置，其中，所述第一获取模块包括：
    解压单元，设置为解压所述CSAR文件，生成临时文件；
    获取单元，设置为从所述临时文件获取节点定义信息；
    获得单元，设置为依据所述节点定义信息中的节点服务定义得到所述节点的服务部署信息。
  8. 根据权利要求7所述的装置，其中，所述第一获取模块还包括：
    删除单元，设置为删除所述临时文件。
  9. 根据权利要求6至8任一项所述的装置，其中，所述服务部署信息包括服务类型和服务调用地址。
  10. 一种基于云应用的拓扑和业务流程规范TOSCA的服务调用装置，应用于TOSCA模板，包括：
    调用模块，设置为指示计划工作流Plan依据用户的输入参数发起对中间层的服务调用，其中，所述输入参数用于指示所述用户要调用的节点及所述节点的方法；
    获取结果模块，设置为指示所述Plan获取所述中间层对所述服务调用的调用结果。
PCT/CN2016/078695 2016-01-08 2016-04-07 基于tosca的服务调用方法及装置 WO2017117876A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610013378.4A CN106961453A (zh) 2016-01-08 2016-01-08 基于tosca的服务调用方法及装置
CN201610013378.4 2016-01-08

Publications (1)

Publication Number Publication Date
WO2017117876A1 true WO2017117876A1 (zh) 2017-07-13

Family

ID=59273526

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/078695 WO2017117876A1 (zh) 2016-01-08 2016-04-07 基于tosca的服务调用方法及装置

Country Status (2)

Country Link
CN (1) CN106961453A (zh)
WO (1) WO2017117876A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11805002B2 (en) 2021-11-19 2023-10-31 Hewlett Packard Enterprise Development Lp Retrieving and provisioning entities based on inheritance

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110609675B (zh) * 2018-06-14 2023-08-08 中兴通讯股份有限公司 一种工作流建模方法、装置和计算机可读存储介质
CN110891239B (zh) * 2018-09-06 2021-01-15 ***通信有限公司研究院 Pnf配置及pnfd tosca实现方法和装置
CN112948152B (zh) * 2021-04-16 2022-10-18 深圳市今天国际物流技术股份有限公司 一种编排数据处理与接口服务调用方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101609415A (zh) * 2009-07-17 2009-12-23 武汉大学 基于中间件的通用服务调用***及方法
WO2014088543A1 (en) * 2012-12-03 2014-06-12 Hewlett-Packard Development Company, L.P. Cloud object
WO2014190544A1 (zh) * 2013-05-31 2014-12-04 华为技术有限公司 应用部署方法和设备
CN104508627A (zh) * 2012-10-08 2015-04-08 惠普发展公司，有限责任合伙企业 混合云环境

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101609415A (zh) * 2009-07-17 2009-12-23 武汉大学 基于中间件的通用服务调用***及方法
CN104508627A (zh) * 2012-10-08 2015-04-08 惠普发展公司，有限责任合伙企业 混合云环境
WO2014088543A1 (en) * 2012-12-03 2014-06-12 Hewlett-Packard Development Company, L.P. Cloud object
WO2014190544A1 (zh) * 2013-05-31 2014-12-04 华为技术有限公司 应用部署方法和设备

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11805002B2 (en) 2021-11-19 2023-10-31 Hewlett Packard Enterprise Development Lp Retrieving and provisioning entities based on inheritance

Also Published As

Publication number Publication date
CN106961453A (zh) 2017-07-18

Similar Documents

Publication Publication Date Title
US10033597B2 (en) Type-to-type analysis for cloud computing technical components with translation scripts
US8612406B1 (en) Sharing business data across networked applications
US20190387064A1 (en) Capturing a virtual configuration from cloud-provisioning data
US9672140B1 (en) Processing special requests at dedicated application containers
US8954952B2 (en) Portable business process deployment model across different application servers
CN113342478B (zh) 资源管理方法、设备、网络***及存储介质
WO2018036342A1 (zh) 基于csar的模型文件的可视化设计方法及装置
US20190196793A1 (en) Building enterprise mobile applications
US10324701B1 (en) Rapid deployment of computing instances
US10270650B2 (en) Data defined infrastructure
WO2017117876A1 (zh) 基于tosca的服务调用方法及装置
US20120303654A1 (en) Methods and systems to automatically extract and transport data associated with workload migrations to cloud networks
WO2023130978A1 (zh) 一种企业数字中台中资源服务应用的调用***和方法
US9888050B2 (en) Method and apparatus for integrating various network elements and providing media processing services
CN115525396A (zh) 基于云原生的应用管理方法及装置
US20210263641A1 (en) Context-driven group pill in a user interface
US11438459B2 (en) Dynamically modifying call flow management using a common data model interface for automated call distribution systems
CN114666388B (zh) 一种面向组织业务的微服务开发方法、装置及存储介质
CN115242871B (zh) 业务网关的服务方法及装置、存储介质及电子设备
WO2016087640A1 (en) Type-to-type analysis for cloud computing technical components
CN116048466A (zh) 业务实现方法、***和装置
CN114116111A (zh) 配置流程节点和数据处理的方法、装置、设备及介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16883020

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16883020

Country of ref document: EP

Kind code of ref document: A1