1 Introduction

Web service is a modular application program over the network and it can provide a set of relatively independent functions. As a key technology in service computing [1], it can be described, published, discovered and invoked. Service composition becomes an important path to realize complex function and form complex application in service computing area. How to composite services quickly and accurately to realize service composition according to users’ requests is a key issue to be solved in the area of service-oriented software engineering [2].

At present, some researchers at home and abroad have carried out extensive research around Web service composition technology, and they have proposed a lot of theories and methods about it. These research approaches can be roughly classified as the following categories. The first one is the user-centric service composition method. This method realizes service composition using different mechanisms to meet users’ requirement, such as the literature [3,4,5,6,7,8,9]. The second one is the formal-based method. It uses the Petri nets and description logics to discuss service composition, such as literature [10,11,12,13,14]. The third one is QoS-based method. It mainly selects services to be composited to meet the user’s QoS requirements, and thus to improve users’ satisfaction, such as literature [15,16,17]. In addition, there exists some other approaches. such as ontology-based approach in literature [18, 19], backward tree based method in literature [20] and so on. The above research work discusses Web service composition approaches from different aspects and using different mechanisms. But there is a lot of Web services available on the internet, using above research methods to find and thus to composite services is time-consuming. The efficiency will be relatively low. In addition, some approaches do not support semantic matching calculation, and this will affect service composition accuracy. In order to solve above problems, Kwon et al. in [21, 22] have proposed a scalable and efficient Web services composition method based on relational database. This approach stores Web service information, the service execution relations and service execution path. It mainly considers the service interface information, and finds composite services directly from service execution path table according to users’ request. This approach stores the service composition path information in advance, it will lead to affect service composition flexibility. And this method does not consider the service capability and other information. When to determine the composition relations through service interface information, this approach only involves one parameter and this is not consistent with the actual situation.

In order to solve above problems, this paper proposes a Web service composition method based on join operation in relational database. It stores the information of Web service and ontology, and uses ontology concepts and concept status path to express Web service interface and capability. According to the users’ requests, it uses join operation in RDB to connect the related tables, and thus the composite service execution path can be constructed dynamically and flexibly. The services are composited from the aspects of interface and capability, and the semantic relationships between concepts are also considered. This approach can enhance service composition efficiency and accuracy. In addition, we use experiments to do the validation and analysis.

Web service definition and storage in RDB will be elaborated in Sect. 2. In Sect. 3, we discuss the algorithms of how to use join operation in RDB to composite Web services dynamically according to users’ requests. The concrete cases study is used to do the illustration. In Sect. 4, the experiments are used to validate the proposed approaches. Finally, the conclusion and next step work are given.

2 Web Service Definition and Storage

2.1 Web Service Definition

Definition 1.

Web Service(ws): ws = {WSName, Interface, Capability}.

WSName represents the name of ws.

Interface = {Input, Output}, and Input = {In i , In i  ∈ Class, i = 0,1,…,inum}, Output = {Out o , Out o  ∈ Class, o = 0,1,…,onum}.

Capability = {Precondition, Effect}, Precondition = {Prec p , p = 0,1,…pnum}, Prec p  = {c p :s p , c p  ∈ Class, s p  ∈ hsm(c p )}. Effect = {Eff e , e = 0,1,…,enum}, Eff e = {c e :rt e → ot e ,c e  ∈ Class, rt e ,ot e  ∈ hsm (c e ), e = 0,1,…,enum}.

In above definition, Class denotes the concept set of ontology and hsm(c p ) denotes the status set of c p [23]. The Input, Output, Precondition and Effect are called as IOPE. The following Table 1 shows the IOPE information of Web services (ws1–ws8).

Table 1. Web service examples
Full size table

2.2 Web Service and Ontology Storage

We use tables to store IOPE information of services. Input(i_id, pid, ws_id) is used to store the information of Input. Output(o_id, pid, ws_id) is used to store the information of Output. Precondition(pr_id, pid, tid, ws_id) is used to store the information of Precondition. Effect(e_id, pid, tid_s, tid_e, ws_id) is used to store the information of Effect. Para(pid, pname, cid) is used to store the information of different parameters.

As shown in Definition 1, we use concepts and their status to express the interface and capability of Web services. We use ontology concepts to denote the IOPE of ws1-ws8, and design correspondent tables. Class(cid, cname) is used to store the information of concepts. Relation(rid, rname) is used to store the relation types between concepts. Axiom(aid, cid_1, cid_2, rid) is used to the relationships between concepts. State(tid, tname) is used to store the status information. ClassState(cs_id, cid, sid) is used to store the status of particular concept. StatePath(sp_id, tid_1, tid_2) is used to store the information of state transition. We mainly consider the following five kinds of semantic relationships: Exact, Plugin, Subsume, Intersect and Fail. They denote the relationships of equivelantOf, subClassOf, superClassOf, intersection and fail respectively. The semantic reasoning relationship between concepts can be got using ontology reasoner, such as Jena, Pellet, etc. The ontology information of Web services in Table 1 is shown in Fig. 1.

Fig. 1.
figure 1

The relationship of ontology concepts

Full size image

On the basis of status path and semantic relationships of ontology concepts, the execution relationships between services(ws1–ws8) are shown in Fig. 2.

Fig. 2.
figure 2

Service execution relationship

Full size image

3 Web Service Composition and Case Study

3.1 Web Service Composition

Definition 2.

Request(RE): RE = {ReInput, ReOutput, ReCapa}, ReInput = {Rin i ,Rin i  ∈ Class,i = 1,2,…,rinum}, ReOutput = {Rout o , Rout o  ∈ Class,o = 1, 2,…,ronum}, ReCapa = {Reff c ,c = 1, 2,…,efnum}, Reff c  = {Re c :Rst c → Ret c , Re c  ∈ Class, Rst c , Ret c  ∈ hsm(Re c )}.

On the basis of users’ specific requests, the following Algorithm 1 gives the process of how to use join operation on the tables in RDB, and thus to realize Web service composition dynamically.

figure a

VisitPath in input of the above Algorithm 1 is the status path table which is formed through StatePath, and it stores the concept status path information. The match() in step 5 and 30 is used to compute the matching degree of specific pid. The matchstate(step 31) is used to calculate the matching degree between two status of specific concept. The structure of Table IO in step 19 is Table IO (o_id, pid_o, ws_id_o, i_id, pid_i, ws_id_i). The o_id, pid_o, ws_id_o are the columns in TOutput be joined, and i_id, pid_i, ws_id_i are the columns in Input. The structure of Table CA in step 22 is Table CA (e_id, pid_e, tid_s, tid_e, ws_id_e, pr_id, pid_i, tid, ws_id_p). Similarly, all the columns of Table CA are constructed by the columns of TEffect and Precondition.

In Algorithm 1, it finds the tuples in Input which can match with the elements in RE.ReInput, and stores the elements into TInput, as seen in step 2–7. Then it gets TOutput through TInput with the same ws_id. TOutput and Input are joined looply to get the service execution path of ReOutput. The service execution path will be inserted into cws. Firstly, the tuples tu in TInput are judged looply, the output and effect of tu will be found and inserted into TOutput and TEffect separately, as seen in step 9–12. Then it judges whether the elements in TOutput contains the element in ReOutput. If it contains, the corresponding service execution path will be added into cws, and ReOutput will be updated, as seen in step 13–17. TOutput and Input will be joined and TInput will be updated, as seen in step 18–20. When TEffect! = Null, TEffect and Precondition will be joined. The service execution path will be added into cws, and TInput will be updated, as seen in step 21–25. In step 28–36, it selects services that can meet RE.ReCapa, and adds them into cws. The corresponding Effect and Precondition will be joined to select composite sevices. At last, return cws. In the step 19 of Algorithm 1, TOutput.pid@Input.pid denotes there exists certain semantic relationships between the concept of TOutput.pid and Input.pid.

3.2 Case Study

Supposing RE.ReInput = {p14, p32} and RE.ReOutput = {p21, p24, p29, p30}, the concrete calculation process of getting composite service cws to meet RE is shown as follows.

In the step 2–7 of Algorithm 1, when Rin 1  = p14, pidnum ← getpid(p14, Table{Class, Para})⇒pidnum = 14, match(14, ws 1 .pid, Table{Para, Relation, Axiom}) = 1.0. Similarly, when Rin 2 = p32, we can get match(32, ws 1 .pid, Table{Para, Relation, Axiom}) = 1.0. TInput is shown in Table 2.

Table 2. TInput
Full size table
  1. (1)

    The first loop: TOutput can be got using TOutput.insert(σws_id=1(Output)) in step 11. It is shown in Table 3. Using TEffect.insert(σws_id=1(Effect)) in step 12, we get TEffect = NULL.

    Table 3. TOutput of the first loop
    Full size table

    In step 13, TOutput! = Null, and we get num ← π ws_id (σws_id=1(Output)⇒num = 1, then ws 1 .Output ⊄ RE.ReOutput. TOutput and Input are joined using step 19. TOutput.pid@Input.pid denotes there exists a kind of semantic relationships(equivelantOf, subClassOf, superClassOf, intersection) between pid. For example, when TOutput.pid = 5 and Input.pid = 10, there exists superClassOf relationship between TOutput.pid and Input.pid. Table IO can be got using above method, as shown in Table 4.

    Table 4. TableIO of the first loop
    Full size table

    TInput can be updated using step 20. TInput is formed through getting the columns of i_id, pid_i and ws_id_i in Table IO , as shown in Table 5.

    Table 5. TInput of the first loop
    Full size table
  2. (2)

    The second loop: TOutput can be got using step 11, as shown in Table 6. Through step 12, we can get TEffect = NULL.

    Table 6. TOutput of the second loop
    Full size table

    Table IO can be got using step 19, and it is shown in Table 7.

    Table 7. TableIO of the second loop
    Full size table

    Then using step 20 to update TInput, as shown in Table 8.

    Table 8. TInput of the second loop
    Full size table
  3. (3)

    The third loop: using step 11 we can get TOutput, as shown in Table 9. Through TEffect.insert(σws_id=4(Effect)) of step 12, we can get TEffect and it is shown in Table 10.

    Table 9. TOutput of the third loop
    Full size table
    Table 10. TEffect of the third loop
    Full size table

Through step 15–17, (ws 6 .Output = p30) && p30 ⊆ {p21, p24, p29, p30}⇒cws ← cws + ws 6 ⇒cws = {<ws 1 , ws 3 ,ws 6 >}, RE.ReOutput = RE.ReOutput-ws 6 .Output⇒RE.ReOutput = {p21, p24, p29}.

Based on Table 9, Table IO can be got using step 19, and it is shown in Table 11.

Table 11. TableIO of the third loop
Full size table

Using step 20 to update TInput, and it is shown in Table 12.

Table 12. TInput of the third loop
Full size table

As shown in Table 10, we can get TEffect! = Null in step 21. TEffect and Precondition will be joined. TEffect.pid@Precondition.pid denotes there exists a kind of semantic relationships(equivelantOf, subClassOf, superClassOf, intersection) between pid. TEffect.tid_e#Precondition.tid denotes TEffect.tid_e and Precondition.tid are equal. For example, for ws_id = 4 in TEffect, the service whose ws_id is 8 can be joined with this service in Precondition. Table CA can be got using step 22, as shown in Table 13.

Table 13. TableCA of the third loop
Full size table

Through step 23–25, (ws 8 .Output = p29) && p29 ⊆ {p21, p24, p29}⇒cws ← cws + ws 8 ⇒cws = {<ws 1 , ws 3 , ws 6 > , <ws 1 , ws 3 , ws 4 , ws 8 >}, RE.ReOutput = RE.ReOutput-ws 8 .Output⇒RE.ReOutput = {p21, p24}, TInput = NULL.

The fourth loop: TOutput can be got through step 11 on the basis of TInput of Table 12, as shown in Table 14.

Table 14. TOutput of the fourth loop
Full size table

Through step 15–17, (ws 5 .Output = {p21, p24}) && {p21, p24} ⊆ {p21, p24}⇒cws ← cws + ws 5 ⇒cws = {<ws 1 , ws 3 ,ws 6 > , <ws 1 , ws 3 , ws 4 , ws 8 > , <ws 1 , ws 3 , ws 4 , ws 5 >}, RE.ReOutput = RE.ReOutput-ws 5 .Output⇒RE.ReOutput = NULL.

4 Experiment

4.1 Experiment Environment

Software Environment: Windows XP, MyEclipse 8.5 M2, Mindswap OWL-S API (http://www.mindswap.org/2004/owl-s/api/), xampp (http://www.apachefriends.org/en/xampp.html).

Hardware Environment: CPU: double Intel (R) Core (TM) 2 Duo CPU P8400@ 2.26 GHz, memory: 2G.

Dataset: OWLS-TC (http://projects.semwebcentral.org/projects/owls-tc/). This dataset include 1083 services and it covers 9 areas: education, medical care, food, travel, communication, economy, weapons, geography and simulation. This dataset includes 5 subdirectories: services, queries, ontology, domains and wsdl. Services in different areas are in the directory of services, and ontology set are in the directory of ontology. The interface elements of services are annotated by the ontology concepts.

4.2 Experiment Comparison and Analysis

This paper proposes a kind of Web service composition method using the join operation in RDB. We compare the composition service finding efficiency and recall rate with other approaches. We mainly compare the following three methods.

RCWSR: it uses the proposed Web service composition method based on join operation in RDB. It mainly uses the concept semantic relationship to do the calculation, and thus to realize Web service composition.

FORIO: it stores the service information into RDB and uses the concept semantic relations to do calculation. The tuples are judged looply in Input and Output to select services for composition.

STRWS: it uses the join operation in RDB to composite Web services. The string matching method is used to do calculation and join related tables.

We extract some part of data in OWL-TC to do experiment. In experiment 1 and 2, we mainly use the ontology of books.owl. There are 180 concepts and 205 concept semantic relations in this ontology. We generate the Input and Output of 50 services randomly. The experiment is mainly done on the Input and Output of services.

Experiment 1.

Comparison of composite service finding efficiency and recall rate.

This experiment is mainly to compare the composite service finding time and recall rate of RCWSR, FORIO and STRCWS according to users’ request. The experiment is taken in the following services request numbers: 5, 10, 15, 20, 25, 30, 35, 40, 45 and 50 separately. The composite service finding time of the above approaches is shown in Fig. 3.

Fig. 3.
figure 3

Comparison of composite service finding time

Full size image

For a specific method in Fig. 3, the composite service finding time increases dramatically as the number of service request becomes larger. For the certain number of service requests, we can see the composite service finding time is largely different of the three methods. The time of STRCWS is the least of all, FORIO method is the most, and the RCWSR is followed by FORIO. This is because STRCWS method uses the string matching method, and it only considers the equivalence relationship between concepts. It does not use the semantic reasoning relationship to do join operation on tables, and the time of this method is the least of all. While FORIO needs to judge all the tuples in Output and Input looply, and it uses the concept semantic reasoning relationship to do calculation. This will consume a lot of time and the time of this approach is the most of all. The RCWSR in this work uses the join operation in RDB. It finds the tuples with matching relationship in Output and Input directly to do join operation, and the time will be saved. This method also uses the concept semantic relationship to do calculation. The time of this method is less than FORIO, but more than STRCWS method.

The composite service finding recall rate of RCWSR, FORIO and STRCWS are shown in Fig. 4. For the specific number of users’ requests, the composite service finding recall rate of RCWSR and FORIO is 1.0, which is more than the recall rate of STRCWS method. This is because STRCWS only uses the string matching method, and it does not consider the concept semantic reasoning relationship. It will influence the matching calculation accuracy, and thus the accuracy of joining tables will be affected. The services which have semantic matching relationships between them can not be composited, and it will affect the recall rate of service composition. Because the methods of RCWSR and FORIO do the calculation in the consideration of the concept semantic reasoning relationships, they can find the comprehensive composite services for different requests.

Fig. 4.
figure 4

Comparison of composite service finding recall rate

Full size image

In all, the composite service finding time of STRCWS method is the least of all, but its recall rate is the lowest. The recall rate of RCWSR and FORIO are all equal to 1.0, but the time of FORIO is far more than the other two approaches. Although the efficiency of our RCWSR method is slightly lower than STRCWS, but it can greatly improve the composite service finding recall rate.

Experiment 2.

Comparison of composite service finding number using different methods.

According to the 50 service requests, this experiment compares and analyzes the composite service numbers to be found using STRCWS, RCWSR and RCWSUB. The experiment result is shown in Table 15. RCWSUB is the method which uses the join operation in RDB to composite services. It only uses the semantic relationships of equivalentOf and subClassOf between concepts, and it does not consider the relationships of superClassOf and intersection.

Table 15. Comparison of composite service finding number using different methods
Full size table

In Table 15, for the certain total service numbers, the composite services number using STRCWS method is least of all. RCWSR is the most and RCWSUB is in the middle. This is due to STRCWS does not consider the semantic reasoning relationship between concepts. While RCWSR uses the relationship of equivelantOf, subClassOf, superClassOf and Intersection between concepts. It helps to find services to meet requests accurately and comprehensively. But RCWSUB only uses the relationships of equivelantOf and subClassOf. This will affect the accuracy of finding composite services. The composite service number of this method will be less than RCWSR.

Experiment 3.

Comparison of finding composite services using different ontologies.

This experiment compares the related results of finding composite services using different ontologies, such as messemodul.owl, books.owl, SUMO.owl, core-plus-office.owl and Mid-level-ontology.owl. The experiment result is shown in Fig. 5.

Fig. 5.
figure 5

Comparison of finding composite services using different ontology

Full size image

In the abscissa of Fig. 5, 1 represents the time of getting concepts from different ontologies. 2 represents the concept numbers. 3 means the time used to get the concept relationships. 4 represents the number of concept relationships and 5 represents the time of finding composite services. We can see the time of getting concepts and finding composite services is becoming more as the more number of concepts. This is mainly related to the concept number in different ontologies.

5 Conclusion

Web service composition is a key problem to be solved in the area of service computing. On the basis of storing Web service and ontology information in RDB, this paper uses the join operation in RDB on the IOPE tables of services according to users’ specific requests. The tuples with matching relationships are selected directly and the matching time can be reduced. It composites services dynamically and does the calculation from the semantic level. Thus, it can enhance Web service composition efficiency and accuracy. The case study and experiments are used to validate the effectiveness of the proposed approach. The next step research work includes: considering the QoS information of users’ requests, and considering the relationships between service operations and interface to composite services dynamically. Therefore, the users’ personal requirements can be met better.