A service call interface reconstruction method based on semantic annotation

Abstract

Current service development lacks a unified calling interface standard specification. Each service provider has its own proprietary application programming interface to implement and manage services. As a result, application software developers who call these services are locked into the service platform of a specific service provider and cannot easily port their applications or data to the service platforms of other service providers. The present invention proposes a method for reconstructing application service calling interfaces based on semantic annotation. First, the heterogeneous platform service calling interfaces are analyzed, and then the service interfaces are annotated. The ontology filling technology is used to generate semantic instances to establish an ontology library and generate specific adapters for the universal service calling interfaces. Developers can use standard platform as a service application programming interfaces to implement universal applications, which can be deployed on heterogeneous service platforms without re-modifying the source code.

Description

Technical Field

[0001] The invention relates to a service call interface reconstruction method based on semantic annotation, and belongs to the field of software technology. Background Art

[0002] Current service development lacks a unified calling interface standard specification, and each service provider has its own proprietary application programming interface to implement and manage services. As a result, application software developers who call these services are locked into the service platform of a specific service provider and cannot easily port their applications or data to the service platform of another service provider. However, the portability of applications or data may be necessary, such as when a service platform has a high downtime rate, the resources used become expensive, the service quality degrades and cannot meet application requirements, or the service provider stops providing services. Since each service provider's basic services (such as storage, messaging, authentication, and mail services) have specific service calling interfaces, in order to port applications between different service platforms, it may be necessary to change the source code of the application.

[0003] To support application portability to overcome the problem of lock-in to a specific service vendor, current approaches focus on providing a common service call interface for applications to be deployed and managed. The literature (E. Hossny, S. Khattab, F. Omara, and H. Hassan, “Implementing Generic PaaS Deployment API: Repackaging and Deploying Applications on Heterogeneous PaaS Platforms,” International Journal of Big Data Intelligence, vol. 3, no. 4, pp. 257–269, 2016.) developed a generic open source application programming interface to support the deployment and management of applications on OpenShift and Cloud Foundry service platforms; the literature (S. Kolb and C. Rock, “Unified cloud application management,” in 2016 IEEE World Congress on Services. IEEE, 2016, pp. 1–8.) provides a unified service call interface for application deployment and management between cloud service platforms; the literature (N.Bassiliades, M. Symeonidis, G. Meditskos, E. Kontopoulos, P. Gouvas, and I.Vlahavas, “A semantic recommendation algorithm for the PaaSport platform-as-a-service marketplace,” Expert Systems with Applications, vol. 67, pp. 203–227, 2017.) Through a lightweight and non-intrusive cloud agent, annotated with a unified OWL ontology semantic model, cloud applications can be seamlessly migrated on demand to achieve interoperability of applications on different cloud platform services. The above method manually implements the adapter of the general service call interface, so any update in the service-specific application programming interface will make its corresponding adapter unavailable. For example, when the parameters of a specific method in a specific application programming interface change, all references to the method need to be manually updated in the adapter code. Summary of the invention

[0004] The purpose of the present invention is to develop an adapter for each of the multiple general application programming interfaces so as to coordinate between the general application programming interface call and the specific application programming interface call. In addition, when the specific application programming interface changes, the adapters of all general application programming interfaces need to be adjusted. In order to deal with the above problems, the present invention does not need to adjust multiple adapters, but only needs to mark the specific service call interface once each time it is changed.

[0005] Principle of the invention: This paper proposes a semantically-annotated application service call interface reconstruction method, which generates a specific adapter based on a service-based general service call interface for a target service platform based on automated semantic annotation. Developers can use standard platform-as-a-service application program interfaces to implement general applications that can be deployed on heterogeneous service platforms without re-modifying the source code. The automatically generated adapter has a service-based general service call interface, and the work of semantically annotating general and specific application programming interfaces is much less than the work of manually implementing and adjusting the adapter code.

[0006] The technical solution of the present invention is a service call interface reconstruction method based on semantic annotation, such as Figure 1 As shown, its characteristics are that the implementation steps are as follows:

[0007] (1) Service interface parsing: The service provider provides a set of service-based specific application programming interfaces, and uses the reflection mechanism to parse the specific service interface to obtain the relevant service interface class, the methods of each class, and the I / O parameters of each method, and annotate the specific, general, and practical application programming interfaces based on the service;

[0008] (2) Service interface semantic population: Parse all these application programming interfaces (specific, general, and practical), insert the data retrieved by automatic parsing into the ontology as a set of instances, and semantically annotate the newly inserted instances.

[0009] (3) Service call adapter generation: Automatically search the ontology to generate the source code of a specific adapter for the target service. Taking the ontology and the target service as input, the source code of the specific adapter is generated for the target service through an automatic code generation algorithm. The specific adapter maps the general methods defined in the ontology to its corresponding specific service interface call.

[0010] (4) Service exception handling: When a specific adapter cannot be generated, it notifies the developer of the list of methods that cannot be generated. Adapter generation will fail only if the target cloud service platform does not have the corresponding annotation. Examples of changes that can be handled include adding new methods, changing method names, adding new parameters to existing methods, changing the data type of the I / O parameters of existing methods, merging a group of methods, or splitting a method into a group of methods.

[0011] (5) Service call interface refactoring: In order to generate the code for the generic method, a SPARQL query statement is automatically generated to retrieve a path (i.e., a list of specific methods) starting from the semantic concept of one of the generic method input parameters and terminating at the generic method output semantic concept. This query is executed on the ontology. If no result is returned, another SPARQL query will continue to be automatically generated. This new query is generated by increasing the path depth of the previous query until the generated query succeeds, i.e., the correct path is detected, or the path depth reaches its maximum limit. Whenever the correct path is detected, the specific method of the path is called to represent the generated code for the given generic method. Whenever the path depth reaches the maximum limit, it means that it is impossible to establish a link between the semantics of one of the generic method input parameters and the semantics of the generic method output parameter. In this case, the SPARQL query is initialized again to detect the path starting from another input parameter of the generic method. If it is impossible to link between the semantics of the generic method input parameter and the semantics of the generic method output parameter, the list of generic methods that cannot be generated is returned to the developer.

[0012] Compared with the prior art, the present invention has the following advantages:

[0013] The existing method is to manually implement the adapter of the general service call interface in the application. When the parameters of a specific method in a specific application programming interface change, all references to the method need to be manually updated in the adapter code. In contrast, a semantic annotation-based application service call interface refactoring method is proposed. Based on automated semantic annotation, a specific adapter of the service-based general service call interface is generated for the target service platform. The application can be deployed on a heterogeneous service platform and the general service call interface is automatically generated without re-modifying the source code. The work of semantic annotation of a specific application programming interface is much less than the workload of manually implementing and adjusting the adapter code. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 Refactor the method execution flow chart for the service call interface. DETAILED DESCRIPTION

[0015] The present invention takes the generation of a general service call method createContainer by a specific service interface ServiceX as an example to illustrate the process of service call interface code reconstruction. The method flow of the embodiment of the present invention is as follows:

[0016] First, the service call interface is parsed. According to a set of service-based specific application programming service interfaces provided by the service provider, the specific service interface is parsed using the reflection mechanism, and then semantic annotation is performed. The input parameters of the annotation include the storage account, container name, Container object name, content type, and Container access rights. The output of the parsing is an object with semantic annotations as a new Container object.

[0017] Then, the service adapter is generated. Taking the ontology and the target service as input, the ontology is searched to generate the source code of the specific adapter for the target service, and the generic methods defined in the ontology of the specific adapter are mapped to their corresponding specific service call interface. In order to generate the generic method code createContainer of the service call ServiceX, a SPARQL query is automatically generated to search for methods with semantic input storage account, semantic output new business line, and belonging to the service utility ServiceX.

[0018] Then, handle the exceptions generated by the adapter. When the createContainerClient method has a semantic input storageAccount, but it does not have a semantic output newContainer, the previous SPARQL query execution fails and is updated by another method that automatically increases its path depth. The new SPARQL query searches for two methods, the first method has a semantic input of storageAccount and a semantic output of semaContainer; the second method has a semantic input of semaContainer and a semantic output of newContainer. The search results found that the first method createCloudContainerClient has a semantic input storageAccount and a semantic output ContainerClient, and the second method getContainerReference has a semantic input ContainerClient but no semantic output newContainer. Therefore, the process of automatically generating SPARQL queries will continue until it succeeds when the path depth is equal to 9.

[0019] Finally, the service interface refactoring code is generated. Based on the above query results, SPARQL query statements are automatically generated to retrieve the path starting from the input parameters of the general method and ending at the semantic concept of the general method output, and then a list of specific methods is obtained, and the specific methods of the path are called to represent the generated code of the given general method.

Claims

1. A service call interface reconstruction method based on semantic annotation, characterized in that: The implementation steps are as follows: (1) Service interface parsing: Based on a set of service-based specific application programming interfaces provided by the service provider, the specific service interface is parsed using the reflection mechanism, and the relevant service interface classes, methods of each class, and I / O parameters of each method are annotated; (2) Service interface semantic filling: parse specific, general, and practical application programming interfaces, and insert the parsed and annotated service call interface information into the ontology as a set of instances; (3) Service adapter generation: taking the ontology and target service as input, searching the ontology to generate the source code of a specific adapter for the target service, and mapping the general methods defined in the ontology of the specific adapter to its corresponding specific service call interface; (4) Service exception handling: If the target service does not have a corresponding annotation and a specific adapter cannot be generated, the instance content is changed, including adding a new method, changing the method name, adding a new parameter to an existing method, changing the data type of the I / O parameter of an existing method, merging a group of methods, or splitting a method into a group of methods; (5) Service interface reconstruction: Automatically generate SPARQL query statements to retrieve the path starting from the input parameters of the general method and ending at the semantic concept of the general method output, and then obtain a list of specific methods, and call the specific method of the path to represent the generated code of the given general method.

Images