A Component Service Recommendation Method for Mashup Service Requirements

Abstract

The present invention proposes a component service recommendation method for Mashup service requirements, including: constructing a candidate component Web API set for Mashup service requirements; generating potential application scenario feature words for the service requirements and Web APIs in the candidate component set; generating a scenario semantically enhanced Mashup service requirement vector and a service function vector; generating a heterogeneous association vector integrating multi-dimensional association features for the Web API; establishing a component service recommendation model for Mashup service requirements with grouped mashup optimization, and solving the recommended components. The present invention can better prioritize the extraction of feature words with high fit with the service application scenario. The proposed method for generating a service function vector with application scenario semantic enhancement can greatly improve the accuracy of matching Mashup service requirements with Web API functions. The Web API heterogeneous association compatibility determination method integrating four association features greatly improves the compatibility of recommended component services. The established grouped mashup optimization recommendation model makes the diversity of recommended component services better and the recommendation quality higher.

Description

Technical Field

[0001] The invention belongs to the field of cloud computing, and in particular relates to a component service recommendation method for Mashup service requirements. Background Art

[0002] WebAPI is an application program interface that is called over the network and can be used to build various business systems. To facilitate calling, the functional granularity of WebAPI is usually small, and a single WebAPI is difficult to meet complex business needs. Mashup services mix and match multiple WebAPIs to form new value-added services, which can integrate more data resources and provide rich business functions. Therefore, they are also called mashup services. The Web API included in the Mashup service is called a component service (or component Web API). The component service recommendation for Mashup service requirements refers to finding suitable component services for Mashup service requirements in existing Web APIs.

[0003] The existing component service recommendation technology for Mashup service requirements is mainly based on the functional matching of services, and then uses collaborative association to improve the compatibility of the recommended component services. The existing technology mainly has the following problems:

[0004] (1) The recommended component services have a low functional match with the Mashup service requirements.

[0005] Whether in the Mashup service requirements or in the functional description provided when the WebAPI is released, the application scenario information that can be provided is very limited. This makes the application scenario features in the functional vectors corresponding to the WebAPI and Mashup service requirements generated by various models very sparse, resulting in low accuracy of functional matching between the Mashup service requirements and the WebAPI in the component service recommendation process of the Mashup service requirements, which reduces the quality of the candidate WebAPI set generated in the recommendation process.

[0006] (2) The recommended component services have poor compatibility.

[0007] The component service recommendations of existing Mashup services mostly improve the recommendation quality through collaborative associations between WebAPIs, but lack consideration of other association features, such as functional associations, service provider associations, user associations, etc., resulting in functional duplication or redundancy among the recommended WebAPIs. Some recommended WebAPIs have poor interactive compatibility, and the compatibility of recommendation results needs to be improved.

[0008] (3) The diversity of recommended component services is poor.

[0009] Existing methods mostly calculate the functional matching degree between a single candidate WebAPI and the Mashup service requirements, as well as the compatibility with other candidate WebAPIs, and recommend WebAPIs according to the functional matching and compatibility scores. The functional matching and compatibility between component services in the recommendation results are not comprehensively considered, resulting in the functional homogeneity of component services at the front of the recommendation list, and the diversity of recommendations needs to be improved. Summary of the invention

[0010] In view of the problems that the existing component service recommendation method for Mashup service requirements has poor compatibility, poor diversity and low functional matching accuracy between the recommended component service and the Mashup service, the present invention proposes the following technical solution:

[0011] A component service recommendation method for Mashup service requirements, characterized by comprising:

[0012] Step A: Construct the candidate component WebAPI set Cw(mr) of the Mashup service requirement mr;

[0013] Step B: Generate potential application scenario feature words for the service requirement mr and the WebAPI in the candidate component set Cw(mr);

[0014] Step B1, constructing a service description feature word extraction model SYAKE that incorporates scenario fit;

[0015] Step B2: Generate potential application scenario feature words for the service requirement mr and WebAPI in the candidate component set Cw(mr);

[0016] Step C, generating a Mashup service demand vector and a service function vector enhanced by scenario semantics;

[0017] Step C1, generating a scenario semantics enhanced demand vector for the Mashup service demand mr;

[0018] Step C2, generating a scene semantics enhanced service function vector for the service s in Cw(mr);

[0019] Step D, generating a heterogeneous correlation vector integrating multi-dimensional correlation features for WebAPI;

[0020] Step D1, mining multi-dimensional correlation features between WebAPIs;

[0021] Step D2, establishing a heterogeneous association graph;

[0022] Step D3, based on the heterogeneous association graph, using the HGPROMPT model based on prompt learning to generate an association vector vc(s) for the service s corresponding to the node v in the heterogeneous association graph;

[0023] Step E: Establish a component service recommendation model for grouped mashup service requirements and solve for the recommended components.

[0024] Furthermore, the comprehensive weight formula of the words included in the service description in step B1 is as follows:

[0025]

[0026] Among them, W case is the word form weight, W pos is the position weight, W rel is the word co-occurrence weight, W dif is the sentence frequency weight, W con is the context weight, W scen Adapt weights to the scene;

[0027] In step B2, a characteristic word set is formed for each WebAPI in Cw(mr) using formula SYAKE(w);

[0028] In this feature word set, the following formula is used to calculate the degree of fit between each feature word and the label:

[0029]

[0030] The following formula is used to select the top-n words with the highest adaptability for each tag of mr, forming the potential application scenario feature word Law(mr) of mr;

[0031]

[0032] The following formula is used to recommend potential application scenario feature words Law(s) for each service s in Cw(mr):

[0033]

[0034] Furthermore, in step C1, Word2vec is used to generate word vectors for the potential application scenario feature word Law(mr) of mr, and the mean of these word vectors is used as the potential application scenario feature word vector of mr and h mr The vector formed by splicing is used as the demand vector of mr, denoted as vf(mr), and the symbol “||” represents vector splicing.

[0035]

[0036] In step C2, SimCSE is used to generate a function vector h s , concatenate it with the mean of the potential application scenario feature word vector, and the resulting vector is used as the service function vector of s, denoted as vf(s):

[0037]

[0038] Furthermore, in step D3, the HGPROMPT model is used to generate an association vector vc(s) for the service s corresponding to the node v in the heterogeneous association graph, as follows:

[0039] (1) Through the graph template, the WebAPI heterogeneous association graph is decomposed into four homogeneous subgraphs and one homogeneous overall graph that removes heterogeneity and only retains the topological structure of the original graph;

[0040] (2) In each graph, a breadth-first traversal random walk is used to extract a subgraph centered on each node, and a feature hint vector is trained to aggregate the subgraph vector as the embedding of the node in the current homogeneous graph;

[0041] (3) Train the heterogeneity hint vector to achieve heterogeneous aggregation of nodes embedded in all homogeneous graphs and obtain their WebAPI heterogeneous association vectors.

[0042] Further, in the step E,

[0043] Cluster the services in Cw(mr) into k service clusters G1, G2, …, G k Each service cluster corresponds to a set of candidate WebAPIs. Each time, the recommended component services are k, from G1 to G k The service in is represented by The scoring formula for the recommended set of services is as follows:

[0044]

[0045] Based on this scoring formula, the mathematical model of Mashup service demand mr component service recommendation is: Z = max(p(RS,mr)).

[0046] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0047] (1) Compared with the original YAKE model, the service description feature word extraction model SYAKE that incorporates scene fit has increased context weight and scene adaptation weight when extracting keywords, thereby improving the fit between the screening feature words and the text context and application scenarios, and can better prioritize the extraction of feature words that have a high fit with the service application scenario.

[0048] (2) The method for generating a service function vector with enhanced application scenario semantics proposed in the present invention can improve the matching accuracy between Mashup service requirements and WebAPI functions by supplementing application scenario feature words for Mashup service requirements or Web API function descriptions, constructing a scenario feature word vector, and concatenating the scenario feature word vector with the function vector to form a service function vector with enhanced scenario semantics.

[0049] (3) The candidate component set of Mashup service requirements including second-order similar WebAPIs designed by the present invention adds the WebAPI that best matches the Mashup service requirements to the candidate component set with the help of the idea of ​​collaborative filtering. At the same time, the method can well include cold-start WebAPIs in the candidate component set, thereby significantly improving the quality of the candidate component service set.

[0050] (4) The WebAPI heterogeneous association compatibility determination method established by the present invention integrates four types of association features. It is a fusion of multi-dimensional association features. Compared with the traditional method of using only one association method to determine the compatibility of recommendation results, the heterogeneous association in the scheme of the present invention considers the dependencies between component services more comprehensively. Therefore, the compatibility of recommended component services can be greatly improved.

[0051] (5) The constructed Mashup service requirement component service recommendation model based on group mashup optimization recommends a group of component services of Mashup service requirements each time, and calculates the overall matching and compatibility between the services in the group and the Mashup service requirements. Compared with the existing technology that only calculates the matching and compatibility between a single component service and the Mashup service requirements, this method recommends a better diversity of component services and a higher quality of recommendation. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 A flow chart of a component service recommendation method for Mashup service requirements of the present invention;

[0053] Figure 2 This is an example of a WebAPI heterogeneous association graph that integrates multi-dimensional association features in the present invention. DETAILED DESCRIPTION

[0054] The embodiments are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used for explanation and are not to be construed as limiting thereof. Figure 1 The present invention proposes a component service recommendation method for Mashup service requirements, which is as follows:

[0055] 1. Crawl WebAPI (component service) and Mashup service in the service registration platform. Clean the data of the above services and build the Mashup service set MS and WebAPI set WS used in the study. Use the cosine distance function sim(h i ,h j )=h i *h j / ||h i ||*||h j ||Calculate the similarity of the vectors, where mr is the Mashup service requirement of the component service to be recommended.

[0056] Referring to the Web service example in Table 1, the WebAPI in the present invention is represented as a triple s=(n, L, d), where n is the name of the WebAPI, L is the tag set of the WebAPI, and d is the description information of the WebAPI.

[0057] Table 1 is a WebAPI example

[0058]

[0059]

[0060] Referring to the Mashup service example in Table 2, the Mashup service in the present invention is represented by a four-tuple m=(n, L, d, S), where n is the name of the Mashup service, L is the label set of the Mashup service, d is the description information of the Mashup service, and S is the component Web API set.

[0061] Table 2 shows an example of a Mashup service.

[0062]

[0063] Mashup service requirements are represented by a tuple mr = (d, L), where d is the description information of the mashup service requirements and L is the category label set of the mashup service requirements.

[0064] 2. Obtain the candidate component WebAPI set of Mashup service requirements mr from the functional level:

[0065] 2.1 Find the top-X mashup services with the highest similarity for mr, and construct the set Nm(mr) as shown in formula (1), where MS is the existing mashup service set.

[0066] Nm(mr)={m|Top-X(sim(h mr ,h m ))∧m∈MS} (1)

[0067] 2.2 Obtain the component WebAPI of each Mashup service in Nm(mr) and construct the first-order candidate component service set Cw-1(mr) of mr as shown in formula (2):

[0068]

[0069] 2.3 For each WebAPI in Cw-1(mr), select Y similar WebAPIs as the second-order potential component service set Cw-2(mr) of mr, see formula (3):

[0070]

[0071] 2.4 Construct the candidate component set Cw(mr)=Cw-1(mr)∪Cw-2(mr) of the Mashup service requirement mr. The above X and Y are set according to the data set parameters.

[0072] 3 Generate potential application scenario feature words for the service requirement mr and the WebAPI in the candidate component set Cw(mr).

[0073] 3.1 Constructing the service description feature word extraction model SYAKE that incorporates scenario fit

[0074] SYAKE integrates the scene fit into the original YAKE model and retains the four existing weight indicators of the YAKE model: word form weight W case (words with capital letters are more important than lowercase words), position weight W pos (The more important the word is, the closer it is to the front), the weight of the word co-occurrence W rel (The more different words on both sides, the lower the word importance) and sentence frequency weight W dif (The more words appear in sentences, the higher their importance).

[0075] On this basis, contextual weights and scene adaptation weights (collectively referred to as scene fit) were designed to improve the fit between the screened feature words and the text context and application scenarios.

[0076] D is a set of service descriptions, Ld is the set of labels corresponding to the services in the service description set D, w is a word contained in the service description d∈D, MeanSemSim(w,d) is the mean of the semantic similarity between w and the words in d, TF-IDF(w,d,D) is the TF-IDF frequency of word w, the context weight calculation method of word w is shown in formula (4), and the scene adaptation weight is shown in formula (5).

[0077] W Con=MeanSemSim(w,d)·(TF-IDF(w,d,D)) (4)

[0078]

[0079] dL is the label set of service description d, h w With h l are the word vectors corresponding to w and l, respectively, obtained by Word2vec training. In SYAKE, the comprehensive weight of word w in service description d is obtained based on the above 6 feature weights as shown in formula (6). The lower the weight value, the higher the importance of word w in service description d.

[0080]

[0081] 3.2 Generate potential application scenario feature words for WebAPI in mr and Cw(mr).

[0082] SYAKE is used to extract the functional feature words of the service description in Nm(mr) and Cw(mr), and potential application scenario feature words are generated for mr and candidate component services through label adaptation, see formulas (7)-(9):

[0083]

[0084]

[0085]

[0086] The degree of fit F(w,l) between word w and its label l in the functional description d of service s is shown in formula (7). Label fit consists of two parts: the similarity between word w and label l, and the inverse of the similarity between word w and the labels in the label group except l. The larger the value of F(w,l), the more the functional scenario of the current service represented by word w and label l is matched.

[0087] Formula (8) is used to generate potential application scenario feature words for mr. First, the SYAKE model is used to extract feature words for each WebAPI in Cw(mr) to form a feature word set. In this feature word set, the label fitness is used to select the top-n words with the highest fitness for each label of mr to form the potential application scenario feature words Law(mr) of mr. Similarly, formula (9) is used to recommend potential application scenario feature words Law(s) for each service s in Cw(mr). The number of feature words n here needs to be set according to the data set parameter adjustment.

[0088] In order to improve the accuracy of function matching, there is also a method of extracting feature words, but the current method is to extract nouns related to the function, and the extracted feature words are all from the Mashup service requirements or the functional description of the WebAPI itself. This method of using functional feature words to supplement the function vector is a "local function + global function" method, which has very limited improvement in the accuracy of function matching.

[0089] The present invention no longer extracts feature words that represent functions, but instead extracts feature words related to application scenarios, and uses the method of "application scenario features + functional features" to improve the accuracy of functional matching. In addition, the extraction source of application scenario feature words is no longer limited to the functional description of the application scenario itself, but is extended to the functional description of similar services or requirements. The present invention splices the vectors corresponding to the potential application scenario feature words with the Mashup service requirements and WebAPI functional vectors, solves the problem of insufficient application scenario features faced by the functional description of Mashup service requirements and WebAPI, improves the functional matching accuracy of Mashup service requirements and WebAPI, and facilitates finding a WebAPI with a higher degree of functional fit for Mashup service requirements.

[0090] 4. Generate Mashup service demand vector and service function vector enhanced by scenario semantics

[0091] 4.1 Generate scenario semantics enhanced demand vector for Mashup service demand mr

[0092] h mr The function vector generated by SimCSE for the requirement mr. Word2vec is used to generate the word vector for the potential application scenario feature word Law(mr). The mean of these word vectors is used as the potential application scenario feature word vector of mr and h mr The vector formed by splicing is used as the demand vector of mr, denoted as vf(mr), see formula (10), where the symbol || represents vector splicing.

[0093]

[0094] 4.2 Generate a scenario semantics enhanced service function vector for service s in Cw(mr)

[0095] For service s in Cw(mr), use SimCSE to generate a function vector h for it s It is concatenated with the mean of the potential application scenario feature word vectors to form a vector as the service function vector of s, denoted as vf(s), see formula (11).

[0096]

[0097] 5. Generate heterogeneous correlation vectors for WebAPI that integrate multidimensional correlation features

[0098] 5.1 Mining multi-dimensional correlation features between WebAPIs:

[0099] (1) Two services i and j If there is a common label, the two have a functional association, denoted as f(s i ,s j ).

[0100] (2) Two services i and j Participate in the construction of Mashup service together, then the two have a collaborative relationship, denoted as c(s i ,s j ).

[0101] (3) Two services i and j If they are provided by the same service provider, then they have a service provider association, denoted as p(s i ,s j ).

[0102] (4) Two services i and j If they have been used by the same user, then the two have a user association, denoted as u(s i ,s j ).

[0103] 5.2 Establish a heterogeneous association graph. The heterogeneous association graph is formally described as follows:

[0104] The WebAPI heterogeneous association graph is an undirected weighted graph HAG = (V, E, W), where:

[0105] (1) V = {v1, v2, …, v n} is a node set, node v i Represents WebAPIs i ;

[0106] (2) E = {Ef, Ec, Ep, Eu}, where Ef, Ec, Ep and Eu are the function-related edge set, the collaboration-related edge set, the service provider-related edge set and the user-related edge set, respectively.

[0107] 1)e=(v i ,v j )∈Ef i With v j The corresponding s i and j Satisfy f(s i ,sj ).

[0108] 2)e=(v i ,v j )∈Ec i With v j The corresponding s i and j Satisfy c(s i ,s j ).

[0109] 3)e=(v i ,v j )∈Ep i With v j The corresponding s i and j Satisfy p(s i ,s j ).

[0110] 4)e=(v i ,v j )∈Eu i With v j The corresponding s i and j Satisfy u(s i ,s j ).

[0111] (3)W={w ij} is the edge weight set, w ij =Nl(s i ,s j ); w ij =Nc(s i ,s j ); w ij =Np(s i ,s j ); w ij = Nu(s i ,s j );

[0112] Nl(s i ,s j )、Nc(s i ,s j )、Np(s i ,s j ) and Nu(s i ,s j ) represent si and j The number of common tags, the number of participating Mashup services, the number of service providers (value is 1), and the number of common users.

[0113] 5.3 Reference Figure 2 , based on the constructed Web API heterogeneous association graph HAG that integrates multi-dimensional association features. The HGPROMPT model based on prompt learning is used to generate the association vector vc(s) for the service s corresponding to the node v in the heterogeneous association graph.

[0114] (1) Through the graph template, the WebAPI heterogeneous association graph is decomposed into four homogeneous subgraphs and one homogeneous overall graph that removes heterogeneity and only retains the topological structure of the original graph.

[0115] (2) In each graph, a breadth-first traversal random walk is used to extract a subgraph centered on each node, and a feature hint vector is trained to aggregate the subgraph vector as the embedding of the node in the current homogeneous graph.

[0116] (3) Train the heterogeneity hint vector to achieve heterogeneous aggregation of nodes embedded in all homogeneous graphs and obtain their WebAPI heterogeneous association vectors.

[0117] The present invention overcomes the shortcomings of the prior art that all improve compatibility from a single perspective, that is, either positive feedback or negative feedback, ignoring the substantial improvement of compatibility by integrating positive and negative feedback. The present invention explores four association features of WebAPI tag association, collaboration association, service provider association, and user association, constructs a heterogeneous association integrating the above four association features, and designs a heterogeneous association modeling and quantification method integrating multi-dimensional association features. The heterogeneous association integrating multi-dimensional association features is used to determine whether the WebAPI is compatible, so as to improve the compatibility of component services recommended by Mashup service requirements.

[0118] The present invention integrates different types of association features into a heterogeneous association. These association features improve the compatibility of the recommended WebAPI. Collaboration association and user association improve compatibility from a positive feedback perspective, while label association and service provider association improve compatibility from a negative feedback perspective.

[0119] 6. Establish a component service recommendation model for grouped mashup service requirements and solve for the recommended components.

[0120] 6.1 Establishing a component service recommendation model for grouped mashup service requirements

[0121] According to the average number of Web APIs of Mashup services in Nm(mr), determine the number of groups k. Cluster the services in Cw(mr) into k service clusters G1, G2, …, Gk Each service cluster corresponds to a set of candidate WebAPIs. Each time, the recommended component services are k, from G1 to G k The service in is represented by The score of the recommended set of services is shown in formula (12):

[0122]

[0123] 6.2 Optimization of Mashup Service Demand Component Services

[0124] Based on the above scoring model, the mathematical model for Mashup service requirement mr component service recommendation is: Z = max(p(RS,mr)). When the number of candidate WebAPIs in the group and in the group is small, the model can take G1, G2, ..., G k Substitute the WebAPIs in the permutation and combination into Z, and make recommendations according to the scores. Considering the efficiency of solving, when there are a large number of candidate WebAPIs in a group or within a group, a swarm intelligence algorithm such as an artificial bee colony algorithm can be used to solve.

[0125] In the existing technical solutions, component services are recommended from the perspective of matching the functions and compatibility of a single WebAPI with the Mashup service requirements, resulting in a high degree of matching between the recommended single service and the Mashup requirements. However, when selecting a group of services, the functions of various services are homogenized, and the diversity of recommendations is poor. In addition, when recommending component services for Mashup service requirements, the existing technical solutions all adopt the Top-k recommendation method to promote the WebAPI that best meets the conditions. The existing technical solutions are all committed to improving the matching degree between the recommended single service and the Mashup service requirements, ignoring the matching and functional complementary relationship between the recommended WebAPIs, resulting in the inability to consider grouping and group recommendation during the recommendation process. Therefore, the organizational form of the recommendation results of the existing technical solutions limits the possibility of grouping candidate services when building the recommendation model, which in turn affects the diversity of recommendations.

[0126] The present invention uses the collaborative filtering concept to determine the number of WebAPIs required for Mashup service requirements, groups candidate WebAPIs according to the number, and establishes a recommendation model that integrates functions and compatible matching to optimize group mashup. The model recommends a group of component services for Mashup service requirements each time, calculates the overall matching and compatibility between the services in the group and the Mashup service requirements, and increases the diversity of recommendation results, thereby improving the quality of recommendation.

[0127] Experimental verification:

[0128] 1 Recommended effect comparison, comparing the following six technical solutions

[0129] (1) R-NGCF: This technology builds a call graph between Mashup services and WebAPIs, and proposes a WebAPI recommendation method based on neural graph collaborative filtering. This method focuses on the embedding propagation of node relationships and recommends component WebAPIs for Mashup services by mining high-order interaction information between Mashup services and WebAPIs.

[0130] (2) SRMG: This technology uses BERT to generate description vectors for new requirements and historical Mashup services, and obtains the neighboring Mashup services of the requirements through similarity calculation. It builds a historical call graph of Mashup services and WebAPIs, uses GraphGAN to generate embedded representations of Mashup services and WebAPIs, obtains Mashup service preferences, and uses the call preferences of the neighboring Mashup services of the new requirements to recommend component WebAPIs.

[0131] (3) MISR: This technology constructs a deep neural network that merges three types of interactive information between WebAPIs and Mashup services. It learns to extract the hidden structures and features between requirements and neighboring Mashup services, requirements and candidate WebAPIs, and candidate WebAPIs, and scores each candidate WebAPI for Mashup service requirements to achieve WebAPI recommendation.

[0132] (4) DySR: This technology models the mashup creation problem as a WebAPI set recommendation task to ensure the diversity among candidate WebAPIs. A dynamic graph neural network-based model is proposed to construct a semantic difference measurement method to reasonably calculate the functional matching degree between requirements and candidate Web APIs.

[0133] (5) LightGCL: This technology builds a heterogeneous graph based on the calling relationship between Mashup services and component WebAPIs, obtains an enhanced graph through approximate singular value decomposition, uses GCN to learn the feature representation of service nodes, uses contrast loss function to optimize node features, and optimizes recommended objects based on labeled data and pairwise loss function.

[0134] (6) DLOAR: This technology clusters existing Mashup services, calculates the similarity between Mashup service demand keywords and cluster keywords, and obtains the most similar service cluster set. It calculates similarity based on service descriptions, obtains the most similar Mashup services from the cluster, and then obtains the most similar WebAPIs in the component services they call to complete the recommendation.

[0135] 2 Evaluation indicators The following indicators commonly used in recommendation systems are used:

[0136] Recall, Precision, Normalized Discounted Cumulative Gain (NDCG), Diversity (ILS)

[0137] 3 Experimental results

[0138] The Mashup services and WebAPIs used were crawled from the ProgrammableWeb website. After deleting Mashup services with too short descriptions or duplicate registrations, the data set contained 5,305 Mashup services and 19,240 WebAPIs. Among them, the average number of WebAPI calls for each Mashup service is 2.8, and the average number of words in each service description is 27. All service description texts were processed by word segmentation, stop word removal, and stemming for recommendation experiments. The ten-fold cross-validation method was used, and the average value of all experimental data was taken as the final experimental result. In the implementation of this example, the parameters X and Y in the technical solution when constructing the candidate component set were set to 4, 5, and the number of application scenario feature words was set to 6.

[0139] Using the technical solution in the present invention, we verified the recommendation results of the Top-3 groups for each service. Since other technical solutions are not grouped, when compared, the selection quantity requirements for component services launched by other technical solutions are consistent with the number of component services corresponding to the Top-k batches in the solution of the present invention.

[0140] Table 3 is a comparison of the recommendation quality of the technology of the present invention and the popular component WebAPI recommendation technology

[0141]

[0142] From the comparison data in Table 3 above, it can be seen that the scheme of the present invention outperforms the comparative technologies in various indicators under different numbers of recommendation results. The recommended Recall, Precision and NDCG are all higher than those of the comparative technical solutions. Compared with the average performance of each comparative technical solution, the technical solution of the present invention has improved Recall, Precision and NDCG by 14.3%, 16.1% and 15.1% respectively. Obviously, the recommended component services of the scheme of the present invention are not only comprehensive and accurate, but also the accuracy of the component services at the front of the recommended results is significantly higher than that of the comparative technical solutions.

[0143] In addition, the ILS index is significantly lower than that of other technical solutions, with a decrease of about 18.2%. ILS is a diversity index. The lower the ILS, the better the diversity of recommendations. This shows that the diversity recommended by the solution of the present invention is significantly higher than that of other technical solutions, which verifies that the grouping and mixing recommendation model in the present invention is very effective in improving diversity. The comparative data in the above cases show that the present invention has well solved the problems of accurate function matching, compatibility and diversity of recommendations.

[0144] The above-described embodiments of the present invention do not constitute a limitation on the protection scope of the present invention. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the claims of the present invention.

Claims

1. A component service recommendation method for Mashup service requirements, characterized in that: include: Step A: Build Mashup service requirements mr A collection of candidate components for Web API C ( mr ); Step B: Service requirements mr and the candidate component set C ( mr ) generates potential application scenario feature words using the Web API; Step B1: Construct a service description feature word extraction model SYAKE that incorporates scene fit. Compared with the original YAKE model, SYAKE adds context weight and scene adaptation weight when extracting keywords; Step B2: Service requirements mr and the candidate component set C ( mr ) in which Web API generates characteristic words for potential application scenarios; Step C, generating a Mashup service demand vector and a service function vector enhanced by scenario semantics; Step C1: Serving Mashup Service Requirements mr Generate a demand vector for scene semantic enhancement; Step C2: C ( mr ) s Generate a service function vector enhanced by scene semantics; Step D: generating a heterogeneous correlation vector integrating multi-dimensional correlation features for the Web API; Step D1, mining multi-dimensional correlation features between Web APIs; Step D2, establishing a heterogeneous association graph; Step D3: Based on the heterogeneous correlation graph, use the HGPROMPT model to v Corresponding services s Generate association vector vc ( s ); Step E: Establish a component service recommendation model for grouped mashup service requirements and solve for the recommended components; Will C ( mr ) is clustered as k Service Cluster G 1, G 2, …, G k Each service cluster corresponds to a set of candidate WebAPIs, and the recommended component service each time is k , respectively from G 1 to G k The service in is represented by , the scoring formula for a set of recommended services is as follows: ； in, vf ( mr )for mr The demand vector of vf ( s i ) is the node v i Corresponding services s i The service function vector; vc ( s i ) is the node v i Corresponding services s i Generate a correlation vector; vc ( s j ) is the node v j Corresponding services s j Generate an association vector; Based on the above scoring formula, Mashup service demand mr The mathematical model recommended by component services is: Z=max ( p ( RS , mr ); When there are not many candidate Web APIs in a group or in a group, the model takes G 1, G 2, …, G k Web API in the permutation and combination method Z , recommendations are made based on the scores.

2. The component service recommendation method for Mashup service requirements according to claim 1, characterized in that: The comprehensive weight formula of the words included in the service description in step B1 is as follows: ； in, W case is the word form weight, W pos is the position weight, W rel is the word co-occurrence weight, W dif is the sentence frequency weight, W con is the context weight, W scen Adapt weights to the scene; In step B2, the formula SYAKE(w) is used as C ( mr ) Each Web API forms a feature word set; In this feature word set, the following formula is used to calculate the degree of fit between each feature word and the label: ； The following formula is used mr Each tag selects the top-n words with the highest adaptability, forming mr Potential application scenario feature words Law ( mr ) ; ； The following formula is used C ( mr ) s Recommend potential application scenario feature words Law ( s ): 。 3. The component service recommendation method for Mashup service requirements according to claim 1, characterized in that: In step C1, Word2vec is used as mr Potential application scenario feature words Law ( mr ) to generate word vectors and use the mean of these word vectors as mr Potential application scenarios of feature word vectors and h mr The vector formed by concatenation is mr The demand vector of vf ( mr ), the symbol "||" indicates vector concatenation, h mr To adopt SimCSE as a requirement mr The resulting feature vector; ； In step C2, SimCSE is used to generate a function vector h s , concatenating it with the mean vector of the potential application scenario feature word, and the resulting vector is used as s The service function vector is denoted as vf ( s ): 。 4. The component service recommendation method for Mashup service requirements according to claim 1, characterized in that: In step D3, the HGPROMPT model is used to define nodes in the heterogeneous association graph. v Corresponding services s Generate association vector vc ( s ), as follows: (1) Using graph templates, the Web API heterogeneous association graph is decomposed into four homogeneous subgraphs and a homogeneous overall graph that removes heterogeneity and only retains the topological structure of the original graph; (2) In each graph, a breadth-first traversal random walk is used to extract a subgraph centered on each node, and a feature hint vector is trained to aggregate the subgraph vector as the embedding of the node in the current homogeneous graph; (3) Train the heterogeneous hint vector to achieve heterogeneous aggregation of nodes embedded in all homogeneous graphs and obtain the Web API heterogeneous association vector.

Images