WO2008015417A1

WO2008015417A1 - Automatic composition of web services based on syntactiv and semantic rules

Info

Publication number: WO2008015417A1
Application number: PCT/GB2007/002910
Authority: WO
Inventors: Hui Na Chua
Original assignee: British Telecommunications Public Limited Company
Priority date: 2006-07-31
Filing date: 2007-07-31
Publication date: 2008-02-07

Abstract

A system and method for web services composition are described. Web services composition includes receiving a request from a service consumer (16) and matching a plurality of web service descriptions stored in a data pool (12) to the request according to one or more semantic rules (202). The matched web service descriptions are filtered according to one or more syntactic rules (204). One or more composition plans are generated based on the filtered web service descriptions. A composite web service description is generated based on one of the one or more composition plans and delivered to the service consumer (16).

Description

AUTOMATIC COMPOSITION OF WEB SERVICES BASED ON SYNTACTIV AND SEMANTIC RULES

Technical Field

The present invention relates to web services composition, and more particularly to a web services composition system and method.

Background to the Invention and Prior Art

A web service is a set of related functionalities that can be programmatically accessed through the World Wide Web (or the Internet as it is commonly known). A software application uses the web service simply by invoking the web service across a network without having to integrate the service. Because the web service is not integrated into the, software application, application development and testing times, maintenance costs and overall errors are reduced. Given the enormous potential of web services, web services composition, that is, the process of combining several web services to provide a value- added composite service, is generating much research interest. To this end, several approaches have been proposed in the area of web services composition. However, many of these approaches typically require dealing with low level programming details, making the process of composing a composite service difficult for non-expert end users. Web services can of course be deployed and used not only on the Internet, but also on intranets and other networks which are compliant with the relevant Internet Protocols. For the sake of brevity, this patent application refers simply to web services, but it is to be understood that use of the public Internet proper is not assumed. That is, embodiments of the invention find equal application on intranets, the Internet, and other networks compliant with the requisite protocols.

In view of the foregoing, it would be desirable to have a web services composition system and method that does not require much, if any, user intervention.

Summary of embodiments of the Invention

In order to meet the above, embodiments of the present invention provide a substantially automated system and method for web services composition that does not require much, if any, user input. From a first aspect there is provided a web services composition method, the method comprising: receiving a request from a service consumer; matching a plurality of web service descriptions stored in a data pool to the request according to one or more semantic rules; filtering the matched web service descriptions according to one or more syntactic rules; generating one or more composition plans based on the filtered web service descriptions; generating a composite web service description based on one of the one or more composition plans; and delivering the composite web service description to the service consumer.

Embodiments of the invention according to the first aspect provide the advantages set out above.

Preferably, the step of matching the web service descriptions to the request includes performing a determination of whether one or more operation categories specified in the request is within one or more corresponding operation category domains specified in respective ones of the web service descriptions, performing a determination of whether one or more function semantics specified in the request is within one or more corresponding function synonyms specified in respective ones of the web service descriptions, and/or performing a determination of whether each of one or more operation parameters specified in- the request satisfy one or more corresponding property attributes specified in respective ones of the web service descriptions.

Preferably, the step of matching the web service descriptions to the request includes performing a determination of whether one or more output parameters specified in the request are compatible with one or more corresponding input parameters specified in respective ones of the web service descriptions. The step of determining whether the one or more output parameters and the one or more corresponding input parameters are compatible preferably includes performing a determination of whether the one or more output parameters and the one or more corresponding input parameters are of a compatible data type, performing a determination of whether all of the one or more input parameters specified in respective ones of the web service descriptions are within the one or more output parameters specified in the request, performing a determination of whether the one or more output parameters and the one or more corresponding input parameters are of a compatible measurement, and/or performing a determination of whether the one or more output parameters and the one or more corresponding input parameters are of a compatible language. Preferably, the step of matching the web service descriptions to the request includes performing a determination of whether one or more preconditions specified in respective ones of the web service descriptions are satisfied by the service consumer.

Preferably, the step of matching the web service descriptions to the request includes performing a determination of whether one or more non-functional constraints specified in respective ones of the web service descriptions are satisfied. The step of determining whether the one or more non-functional constraints are satisfied preferably includes performing a determination of whether an invocation time specified in the request satisfies a corresponding time constraint specified in respective ones of the web service descriptions, performing a determination of whether one or more of one or more service locations and one or more service request locations specified in the request satisfies a corresponding location constraint specified in respective ones of the web service descriptions, performing a determination of whether one or more payment preferences specified in the request satisfies one or more corresponding payment constraints specified in respective ones of the web service descriptions, and/or performing a determination of whether one or more security mechanisms specified in the request are compatible with one or more corresponding security constraints specified in respective ones of the web service descriptions.

Preferably, one or more business rules are applied to the matching of the web service descriptions to the request.

Preferably, the step of filtering the matched web service descriptions comprises performing a determination of whether the matched web service descriptions specify at least one compatible binding, and/or performing a determination of whether corresponding operations described in the matched web service descriptions and the request specify at least one compatible service operation route.

By applying a tight set of rules to the web service descriptions during the selection of participant services, the present invention returns a substantially accurate result which corresponds closely to user specifications in the request.

The one or more generated composition plans may be stored in the data pool.

In a preferred embodiment, a selection is made from a plurality of composition plans according to at least one contextual rule when more than one composition plan is generated. Preferably, the step of selecting from the plurality of composition plans comprises performing a determination of whether one or more contextual properties of the service consumer are compatible with a service provider profile specified in respective ones of the web service descriptions. In a further preferred embodiment, one of the one or more semantic rules is applied to the selection of the composition plan. Preferably, the step of applying one of the one or more semantic rules to the selection of the composition plan comprises performing a determination of whether a service quality measurement specified in respective ones of the web service descriptions satisfies a service quality requirement specified in the request.

In yet another preferred embodiment, a determination of whether the request corresponds to an earlier request is performed. Preferably, the composition plan for the earlier request is retrieved from the data pool when the request is determined to correspond to an earlier request. The retrieval and use of the archived composition plan for the generation of the composite web service description reduces the computational time of the present invention.

Preferably, the web service descriptions stored in the data pool are derived from Web Service Description Language (WSDL) descriptions of web services extended with one or more additional properties. This facilitates the provision of automatic reasoning capabilities for web service selection and composition in the present invention.

The web service descriptions stored in the data pool preferably are described with vocabulary from one or more predefined taxonomies. This facilitates accurate interpretation of the semantics of the web service descriptions of the present invention.

From a second aspect, the present invention further provides a computer program or suite of programs so arranged such that when executed by a computer system it/they cause/s the system to perform the process of any of the preceding claims. The computer program or programs may be embodied by a modulated carrier signal incorporating data corresponding to the computer program or at least one of the suite of programs, for example a signal being carried over a network such as the Internet.

Additionally, from a third aspect the invention also provides a computer readable storage medium storing a computer program or at least one of suite of computer programs according to the second aspect. The computer readable storage medium may be any magnetic, optical, magneto-optical, solid-state, or other storage medium capable of being read by a computer.

From a fourth aspect, the present invention further provides a system for composing a composite web service from web service descriptions stored in a data pool, the system comprising: a matching module configured to receive a request from a service consumer, the matching module being further configured to match web service descriptions stored in the data pool to the request according to one or more semantic rules; a composition module configured to filter the matched web service descriptions according to one or more syntactic rules, the composition module being further configured to generate one or more composition plans based on the filtered web service descriptions; and a generation module configured to generate a composite web service description based on one of the one or more composition plans, the generation module being further configured to deliver the composite web service description to the service consumer.

In the fourth aspect, corresponding advantages are obtained as previously described in respect of the first aspect. Moreover, corresponding further features as described above in respect of the first aspect may also be employed.

Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.

Brief Description of the Drawings

The following detailed description of preferred embodiments of the invention will be better understood when read in conjunction with the appended drawings. The present ' invention is illustrated by way of example and is not limited by the accompanying figures, in which like references indicate similar elements.

Figure 1 is a schematic overview of an architecture for web services composition in accordance with an embodiment of the present invention;

Figure 2 is a schematic representation of a web service description in accordance with an embodiment of the present invention;

Figure 3 is a schematic representation of a composition rules model for web services composition in accordance with an embodiment of the present invention; and Figure 4 is a schematic flow diagram illustrating a web services composition method in accordance with an embodiment of the present invention.

Detailed Description of the Preferred Embodiments

A web services composition system and method are provided. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be understood, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.

Referring now to Figure 1 , an architecture 10 for web services composition is shown.

The architecture 10 includes a data pool 12 for storing a plurality of web service descriptions and a web services composition system 14 for composing a composite web service from the web service descriptions stored in the data pool 12 on receiving a request from a service consumer 16. The web services composition system 14 includes a matching module 18, a composition module 20, a selection module 22 and a generation module 24. The matching module 18 is configured to receive the request from the service consumer 16, to perform a determination of whether the request corresponds to an earlier request, and to match the web service descriptions stored in the data pool 12 to the request according to one or more semantic rules. The composition module 20 is configured to filter the matched web service descriptions according to one or more syntactic rules and to generate one or more composition plans based on the filtered web service descriptions. The selection module 22 is configured to make a selection from a plurality of composition plans according to at least one contextual rule where more than one composition plan is generated by the composition module 20. The generation module 24 is configured to generate a composite web service description based on one of the one or more composition plans, and to deliver the composite web service description to the service consumer 16.

The data pool 12 may reside in one or more locations, for example, on a server or a network of computers. The data pool 12 serves as a service registry for web services, providing a searchable repository of web service descriptions. Accordingly, one or more service providers, that is, parties that offer one or more web services, may define descriptions of the web services and publish the web service descriptions in the data pool 12. The web service descriptions may be input into the data pool 12 via one or more administration portals 28. Such portals 28 are known by those of skill in the art and therefore, further explanation is not necessary for a complete understanding of the invention.

Web services are typically described by WSDL documents. WSDL documents describe the syntax associated with the invocation and response of web services, but provide little semantic description. Thus, in the present embodiment of the invention, the web service descriptions stored in the data pool 12 are derived from WSDL descriptions 26 of web services extended with one or more additional properties to augment the semantic capabilities of the WSDL descriptions 26. The additional properties added to the WSDL descriptions 26 facilitate the provision of automatic reasoning capabilities for web service selection and composition. Nonetheless, it should be understood that the present invention is not limited by the language or derivation of the web service descriptions. To facilitate accurate interpretation of the semantics of the web service descriptions, the web service descriptions stored in the data pool 12 are described with vocabulary from one or more predefined taxonomies.

Each of the web service descriptions stored in the data pool 12 may be represented by a tree-based model. Referring now to Figure 2, a tree-based schematic representation of a description 100 of a web service 102 is shown. The nodes defined by dashed-lines represent WSDL concepts, while the nodes defined by solid lines represent the additional properties added to the WSDL description of the web service 102 to augment the semantic capabilities of the web service description 100. The edges defined by the arrows in Figure 2 represent the relationships between the nodes, while the ratios corresponding to the edges represent the cardinality of the respective relationships, that is, the number of child nodes originating from respective ones of the parent nodes.

As shown in Figure 2, the web service 102 is described by a web service name 104, a service provider profile 106, one or more bindings 108, and one or more operations 110.

The service provider profile 106 is described by contextual properties of the service provider. As can be seen from Figure 2, the service provider profile 106 includes a service provider name 112, one or more service provider contact details 114, and payment account information 116. Each of the one or more bindings 108 includes a binding name 118 and a binding style 120. Such bindings 108 are known by those of skill in the art and therefore, further explanation is not necessary for a complete understanding of the invention.

As shown in Figure 2, each of the one or more operations 110 is further described by an operation name 122, one or more functional attributes 124, and one or more nonfunctional attributes 126. The one or more functional attributes 124 include one or more of a service operation route 128, an input message 130, an output message 132, one or more preconditions 134, and one or more exceptions 136. The one or more non-functional attributes 126 include one or more of one or more categories 138 and one or more non- functional constraints. The functional attributes 124 provide information necessary for web service invocation, while the non-functional attributes 126 provide additional information which is non-essential to web service invocation. The additional information provided by the non-functional attributes 126 is used to analyse and select web services 102 when there are multiple web services 102 with identical operational functionalities.

Turning first to the functional attributes 124, the service operation route 128 specifies a transmission primitive supported, by an operation 110 of the web service 102. Examples of transmission primitives include notification, one-way, solicit-response, and request- response. Such transmission primitives are known by those of skill in the art and therefore, further explanation is not necessary for a complete understanding of the invention. It follows therefore that the service operation route 128 determines whether an operation 110 of the web service 102 receives only an input message 130 (i.e. when a one-way primitive is specified), sends only an output message 132 (i.e. when a notification primitive is specified), or receives an input message 130 and sends out an output message 132 (i.e. when either a solicit-response or request-response primitive is specified). Consequently, as seen from the ratios provided next to the input and output nodes 130 and 132, each operation 110 can have either zero (0) or one (1) input message 130 and either zero (0) or one (1) output message 132.

Each of the input and output messages 130 and 132 is further described by one or more parameters 140: a parameter name 142, a measurement 144, a language 146, and a data type 148. The measurement parameter 144 specifies a numerical value of respective ones of the input and output messages 130 and 132, for example, a date, a weight or a length. The measurement parameter 144 is left empty or assigned a zero (0) value when respective ones of the input and output messages 130 and 132 is non-numerical. The language parameter 146 specifies, a language of respective ones of the input and output messages 130 and 132. For example, in one embodiment, the language parameter 146 may specify that an input message 130 is to be in English.

The data type 148 specifies a data type of respective ones of the input and output messages 130 and 132. Build-in data types defined in the World Wide Web Consortium

(W3C) XML Schema may be used to describe the data type 148 of respective ones of the input and output messages 130 and 132 to standardise the description of the data type 148.

Nonetheless, it should be understood that the present invention is not limited to a particular typing system. In one embodiment, each of the parameter name 142, the measurement 144, the language 146, and the data type 148 is described with vocabulary from a predefined taxonomy such as, for example, the RosettaNet business dictionary to prevent conflicting semantics. Nonetheless, it should be understood that the present invention is

^• not limited to a particular taxonomy. In alternative embodiments, multiple taxonomies may be used concurrently to provide greater flexibility in describing the parameters 140.

Each of the one or more preconditions 134 specifies a logical condition that must be satisfied before an operation 110 of the web service 102 can be executed. For example, the web service 102 may provide a log-in operation 110 with an "IsLogin" precondition 134. The log-in operation 110 only executes when the user is not already logged in (i.e. when the "IsLogin" precondition 134 has a logical value of "FALSE").

Each of the one or more exceptions 136 specifies a possible exception that may occur during the execution of an operation 110 and a corresponding action that is to be taken when such an exception occurs. For example, the exception 136 may specify that a payment service is not to be executed if a user is not logged in.

Turning now to the non-functional attributes 126, each of the one or more categories describes a role or function performed by the operation 110. Accordingly, each of the one or more operations 110 may be classified into one or more categories 138 according to the one or more roles or functions performed by the operation 110. Examples of the categories

138 which an operation 110 may be classified into include: a payment services category for operations 110 that perform payment related transactions such as, for example, payments, refunds, and checking of payment transaction details and statuses; a delivery services category for operations 110 that perform delivery services, for example, Short Message

Service (SMS) and email; a content services category for operations 110 that provide requested content or services; and a value-added services category for operations 110 that perform value-added functions, for example, translations, currency conversions, transcoding of markup languages (e.g. Hyper Text Markup Language (HTML) to Wireless Markup Language (WML)), and trusted party services for federated ID or login authorisation.

As can be seen from Figure 2, each of the one or more operation categories 138 is described by a domain 150 and one or more functions 152. The domain 150 specifies an area or related areas of interest of an operation category 138, while each of the one or more functions 152 specifies a function of the operation category 138. Each of the one or more functions 152 is described by one or more properties 154 and a synonym 156, and each of the one or more properties 154 is further described by one or more attributes 158. In the present embodiment, the domain 150 and the one or more attributes 158 are defined using vocabulary from one or more predefined taxonomies. For example, the domain may be described with vocabulary from the Universal Standard Products and Services Classification (UNSPSC), while the one or more attributes 158 may be defined using vocabulary from the RosettaNet dictionary. An example of the domains 150, the functions 152, the properties 154 and the attributes 158 of various operation categories 138 of a web service 102 is shown in Table 1 below.

Table 1

In the example shown in Table 1 , the "Content Services" category 138 is described by a "Ticketing" function 152 in a "Request for movie" domain 150 and a "Downloads" function 152 in a "Request for music" domain 150, while the "Value-added Services" category 138 is described by a "Conversion" function 152 in a "Utility" domain 150. Each of the "Ticketing", "Downloads" and "Conversion" functions 152 are described by a plurality of properties 154, each of which is further described by a corresponding attribute 158.

The synonym 156 specifies similar or alternative function names for each of the one or more category functions 152. For example, a "Transformation" function 152 having a "Conversion" synonym 156 is capable of performing both object conversion and transformation by providing the required properties 154 and attributes 158. Turning now to the non-functional constraints, the non-functional constraints are described by one or more of a time constraint 160, one or more payment constraints 162, a location constraint 164, one or more security constraints 166, and a service quality measurement 168. The non-functional constraints specify additional conditions that have to be met before the web service 102 can execute.

The time constraint 160 specifies a particular time period or duration of time during which the web service 102 is available for invocation.

The one or more payment constraints 162 specify payment related information such as, for example, the charges for using the web service 102, information on how the charges are computed (e.g. by volume, time or length, or per service requested), a currency for payment and a payment mode (e.g._. payment before delivery or delivery before payment).

The location constraint 164 specifies one or more service locations and one or more service request locations which the web service 102 responds to.

The one or more security constraints 166 specify one or more security mechanisms, for example, non-repudiation and encryption, supported by the web service 102.

The service quality measurement 168 specifies a measure of service consumer perception of service quality. The service quality of the web service 102 may be measured using SERVQUAL — an instrument for measuring consumer perceptions of service quality. However, it should be understood that the present invention is not limited to a particular instrument for measuring service quality. The service quality measurement 168 may be updated with results from a survey on consumer satisfaction or by performing pattern analysis on "return-consumer" historical access logs.

Referring again to Figure 1 , one or more elements of the web service description 100 shown in Figure 2 are furnished by the service provider during a registration phase and stored in the data pool 12. In one embodiment, a checking algorithm is automatically and periodically performed to ensure that the WSDL elements in the web service descriptions stored in the data pool 12 are consistent with the corresponding elements in the WSDL web service descriptions 26 from which the former are derived. If an inconsistency is identified, web services composition is suspended. Web services composition is only resumed after updates of the web service descriptions stored in the data pool 12 are made via the one or more administration portals 28. The data pool 12 in the present embodiment is also configured to store a plurality of composition rules 30 (i.e. the one or more semantic rules, the one or more syntactic rules and the at least one contextual rule employed by the web services composition system 14 during web services composition) and one or more business rules 32, for example, a ranking of the service providers in accordance with service consumer preferences. The composition rules 30 and the one or more business rules 32 may be input into the data pool 12 by an administrator (not shown) during a rule setting phase based on service provider requirements and the requirements of the web services composition system 14. The administrator may specify whether a particular rule is optional or compulsory.

The composition rules 30 stored in the data pool 12 may be represented by a composition rules model. Referring now to Figure 3, a schematic representation of a composition rules model 200 for web services composition is shown. The composition rules model 200 includes a plurality of semantic rules 202, a plurality of syntactic rules 204, and a contextual rule 206.^' The semantic rules 202 include a message parameters rule 208, a precondition rule 210, a function semantics rule 212, and a plurality of non-functional constraints rules 214. The syntactic rules 204 include a binding rule 216 and an operation route rule 218.

The message parameters rule 208, the precondition rule 210, the binding rule 216 and the operation route rule 218 operate on the functional attributes of the web service descriptions and are therefore classified as functional level rules. The function semantics rule 212 and the non-functional constraints rules 214 operate on the non-functional attributes of the web service descriptions and are therefore classified as non-functional level rules. The functional level rules are compulsory. One or more of the non-functional level rules may be optional. .

Referring first to the semantic rules 202, the message parameters rule 208 checks that the message parameters expected by the web services are compatible with the message parameters to be received by the service consumer by performing a determination of whether one or more output parameters specified in the request are compatible with one or more corresponding input parameters (i.e. data types, measurements and/or languages) specified in respective ones of the web service descriptions. More particularly, the message parameters rule 208 performs a determination of whether the one or more output parameters and the one or more corresponding input parameters are of a compatible data type, a determination of whether each of the one or more input parameters specified in respective ones of the web service descriptions is within the one or more output parameters specified in the request, and a determination of whether the one or more output parameters and the one or more corresponding input parameters are of a compatible measurement and language. The determination of whether the message parameters are compatible is made by mapping the one or more output parameters specified in the request to the one or more corresponding input parameters specified in a web service description. The message parameters rule 208 may be expressed as follows:

[d_r! ςz d_pJ) Λ [VI_pj e O_n. ] Λ [M(I_pJ) = M(O_ri)] Λ [L(I_pj) =L(O_ri) ] (1 )

where O_n. represents the one or more output message parameters specified in the request, I_pj represents the one or more input message parameters specified in the web service description, d_ri represents a data type of an output message specified in the request, d_pj represents a data type of an input message specified in the web service description, M(O_n) represents a measurement parameter of an output message specified in the request, M(I_pj) represents a measurement parameter of an input message specified in the web service description, L{O_ri) represents a language parameter of an output message specified in the request, and L(I _pJ) represents a language parameter of an input message specified in the web service description. Messages are exchangeable between a web service and the service consumer when the data type d_ri of the output message specified in the request is a subset of or equal to the data type d_pj of the input message specified in the web service description (e.g. a short data type is a subset of an integer data type), all of the one or more input message parameters I_pj specified in the web service description are within the one or more output message parameters O_n. specified in the request, the measurement parameter M(O_n) of the output message specified in the request is similar to the measurement parameter M(I_pj) of the input message specified in the web service description, and the language parameter L(O _ri) of the output message specified in the request matches the language parameter L(I _pJ) of the input message specified in the web service description. Before a web service can be requested, each of the one or more preconditions specified in the web service description must first be met. Accordingly, the precondition rule 210 performs a determination of whether one or more preconditions specified in respective ones of the web service descriptions are satisfied by the service consumer by mapping one or more logical conditions of the service consumer specified in the request to the one or more preconditions specified in respective ones of the web service descriptions. The precondition rule 210 may be expressed as follows:

Pr = (Oϊθft). ^β. ). (Z₂U)^₂) (/„(*_,),«., )) (2)

where f_{(χ_t) represents the one or more preconditions (or, more particularly, the /-th logical function performing a specific task x. , i being an integer having a value from 1 to m) specified in a web service description, f_t(x,) e {θ, i} (i.e. f_t{χ) having a value of either zero "0" or one "1") where "0" represents a logical value TRUE and "1" represents a logical value FALSE, and a_t represents a logical value (i.e. TRUE or FALSE) that satisfies the precondition /)(*;), a_t e {θ, 1} (i.e. a₍ having a value of either zero "0" or one "1") where "0" represents the logical value TRUE and "1" represents the logical value FALSE. A web service is deemed suitable for composition if it is determined that each of the one or more preconditions f_{(χ,) specified in the web service description is of the same value as the corresponding logical value a_t .

At the non-functional level, the function semantics rule 212 checks that the request and the web service descriptions are of compatible function semantics to ensure that corresponding operations specified in the request and the web service descriptions are functionally compatible and that the semantics of the corresponding operations are correctly interpreted. More particularly, the function semantics rule 212 performs a determination of whether one or more operation categories specified in the request is within one or more corresponding operation category domains specified in respective ones of the web service descriptions, a determination of whether one or more function semantics specified in the request is within one or more corresponding function synonyms specified in respective ones of the web service descriptions, and a determination of whether each of one or more operation parameters specified in the request satisfy one or more corresponding property attributes specified in respective ones of the web service descriptions. These determinations are made by mapping one or more operation semantics specified in the request to one or more corresponding operation semantics specified in respective ones of the web service descriptions. The function semantics rule 212 may be expressed as follows:

[c_r e c_p] Λ [s_r e s_p] Λ [VO_r ς: a_p ] (3)

where c_r represents one or more operation categories specified in the request, c_p represents one or more operation category domains specified in a web service description, s_r represents one or more function semantics specified in the request, s_p represents one or more corresponding function synonyms of the one or more operation categories specified in the web service description, O₇. represents one or more operation parameters specified in the request, and a_p represents one or more function property attributes of the one or more operation categories specified in the web service description. A web service description is deemed to have compatible function semantics with the request if the one or more operation categories c_r specified in the request exists in the one or more corresponding operation category domains c_p specified in the web service description, the one or more function semantics s_r specified in the request exists in the one or more corresponding function synonyms s_p specified in the web service description, and the one or more operation parameters O_r specified in the request are a subset of or equal to the one or more corresponding property attributes a_p specified in the web service description (although not all the property attributes a_p of an operation of a web service need to be satisfied by the one or more output parameters O_r specified in the request, for example, a web service with a function for booking a one-way ticket requires specification of fewer output parameters compared to that required to invoke a return-ticket booking function). Because, as previously mentioned, the web service descriptions are described with vocabulary from one or more predefined taxonomies, a semantics gap or problems arising from differing interpretations of different taxonomy terms will not arise when the function semantics rule 212 is applied.

The non-functional constraints rules 214 include a time constraint rule, a location constraint rule, a payment constraint rule, a security constraint rule and a service quality rule. The non-functional constraints rules 214 check the qualitative properties of the corresponding operations specified in the web service descriptions and the request. More particularly, the non-functional constraints rules 214 perform a determination of whether one or more non-functional constraints specified in respective ones of the web service descriptions are satisfied by mapping the non-functional constraints and service properties specified in respective ones of the web service descriptions^' to one or more corresponding properties specified in the request. A web service is deemed suitable for composition if the non-functional constraints rules 214 are satisfied.

As previously mentioned, a web service may only be available for invocation at a particular time period or duration of time. Accordingly, the time constraint rule performs a determination of whether an invocation time specified in the request satisfies a corresponding time constraint specified in respective ones of the web service descriptions.

The time constraint rule may be expressed as follows:

If t_p ≠ 0, then t_r c t_p (4)

where t_p represents a time period or duration of time during which a web service is available for invocation specified in a web service description, and t_r represents an invocation time (i.e. time when the web service is invoked by the service consumer) specified in the request. A web service is available for invocation when, where a time constraint is specified in the web service description, the invocation time t_r specified in the request is a subset of or equal to the time period or duration of time t_p specified in the web service description.

Similarly, a web service may be offered only at one or more service locations and/or respond only to a request from one or more service request locations. Accordingly, the location constraint rule performs a determination of whether one or more of one or more service locations and one or more service request locations specified in the request satisfy a corresponding location constraint specified in respective ones of the web service descriptions. The location constraint rule may be expressed as follows:

lf (/l, ≠ 0) A ( 12_P ≠ 0), then (/l_r e /l, )Λ {12 _r e I2_p ); or

If (Zl ≠ 0) Λ (/2 = 0), then (/l_r 6 /1 ); or If (Zl,= 0) Λ (12 _p ≠ 0), then (l2_r e l2_p). (5)

where l\_p represents one or more service locations specified in a web service description, 12 _p represents one or more service request locations which the web service responds to specified in the web service description, ll_r represents one or more service locations specified in the request, and I2_r represents one or more service request locations specified in the request. The web service is deemed suitable for composition when, where one or more service locations l\_p are specified in the web service description, the one or more service locations l\_r specified in the request is within the one or more service locations l\_p specified in the web service description, and when, where one or more service request locations 12 _p are specified in the web service description, the one or more service request locations I2_r specified in the request is within the one or more service request locations 12 _p specified in the web service description.

The payment constraint rule performs a determination of whether one or more payment preferences specified in the request satisfies one or more corresponding payment constraints specified in respective ones of the web service descriptions. For example, a service consumer may specify delivery-before-payment and payment via credit card in the request. The payment constraint rule checks whether the service provider accepts the payment preferences of the service consumer. The payment constraint rule may be expressed as follows:

Vp_r c: p_p (6)

where p_r represents the one or more payment preferences specified in the request, and p_p represents one or more payment constraints specified in a web service description. A web service is deemed suitable for composition if all of the one or more payment preferences p_r specified in the request are a subset of or equal to the one or more payment constraints p_p specified in the web service description.

The security constraint rule performs a determination of whether one or more security mechanisms specified in the request are compatible with one or more corresponding security constraints specified in respective ones of the web service descriptions, thereby ensuring that preferred security mechanisms of the service provider are used in the exchange of functional messages. The security constraint rule may be expressed as follows:

If e_p ≠ 0, then e_r f] e_p ≠ 0; and

If e_r ≠ 0, then e_p ≥ e_r (7)

where e_p represents the one or more security constraints specified in a web service description, and e_r represents the one or more security mechanisms specified in the request. A web service is deemed suitable for composition if when one or more security constraints e_p are specified in the web service description, the request and the web service description specify at least one common security mechanism (i.e. e_r and e_p intersect), and when one or more security mechanisms e_r are specified in the request, the one or more security mechanisms e_r specified in the request. A web service is deemed suitable for composition when, where one or more security constraints e_p are specified in the web service description, the request and the web service description specify at least one common security mechanism (i.e. e_r and e_p intersect), and, where one or more security mechanisms e_r are specified in the request, the one or more security constraints e_p specified in the web service description support the one or more security mechanisms e_r specified in the request (i.e. e_p is greater than or equal to e_r ).

The service quality rule performs a determination of whether a service quality measurement specified in ^respective ones of the web service descriptions satisfies a service quality requirement specified in the request. The service quality rule may be expressed as follows:

If q_r ≠ 0, q_p > q_r (8)

where q_r represents the service quality requirement specified in the request, and q_p represents the service quality measurement specified in a web service description. Where a service quality requirement q_r is specified in the request, the service quality of a web service is deemed to meet the service quality requirement q_r specified in the request if the service quality measurement q_p specified in the web service description is larger than or equal to the service quality requirement q_r .

Turning now to the syntactic rules 204, because web services may bind to different protocols and message formats, for example, Simple Object Access Protocol (SOAP), Multipurpose Internet Mail Extensions (MIME) and Hyper Text Transfer Protocol (HTTP), the binding rule 216 performs a determination of whether the web service descriptions specify at least one compatible binding to ensure that the web services are able to communicate with one other. The binding rule 216 performs this determination by mapping one or more bindings specified in a first web service description to one or more bindings specified in a second web description. The binding rule 216 may be expressed as follows:

b_p (I b_r ≠ 0 (9)

where b_p represents the one or more bindings specified in a first web service description, and b_r represents one or more bindings specified in a second web service description. The first and second web services composable if the web service descriptions of the first and second web services specify at least one common binding (i.e. b_p and b_r intersect).

For a web service to interact with other web services and to be invoked by the service consumer, corresponding operations specified in respective ones of the web service descriptions and in the request must have at least one compatible service operation route. For example, if a web service operation is described by a notification service operation route, the corresponding operation specified in another web service or the request must be described by a receiver service operation route. Similarly, an operation described by a solicit-response service operation route must be matched with another operation described by a request-response service operation route. Accordingly, the operation route rule 218 performs a determination of whether corresponding operations described in the web service descriptions and the request have at least one compatible service operation route by mapping the service operation routes specified in the web service descriptions and the request. The operation route rule 218 may be expressed as follows: [(r, =n)Λ (r_r=o)] v [(r_p =o)Λ ( .r_r=n)]v [(r_p = s)Λ (r_r = q)]v [(r_p =q)Λ (r_r=s)] (10)

where r_p represents a service operation route specified in a web service description, and r_r represents a corresponding service operation route specified in another web service description or the request, n represents a nptification service operation route, o represents a receiver service operation route, s represents a solicit-response service operation route, and q represents a request-response service operation route. As can be seen from equation (10), the notification n and the receiver o service operation route are compatible, while the solicit-response service operation route s is compatible with the request-response service operation route q. Web services may be composable with other web services and invoked by the service consumer if the web service descriptions and the request specify at least one compatible service operation route.

Referring now to the contextual rule 206, the contextual rule 206 performs a determination of whether one or more contextual properties of the service consumer are compatible with a service provider profile specified in respective ones of the web service descriptions. The contextual properties of the service consumer include service consumer preferences and/or constraints (e.g. network and device capabilities). The service consumer may specify whether a particular contextual property is optional or compulsory. The contextual composition rules 206 may be expressed as follows:

Vx_re c x_{p .} (11)

where x_rc represents one or more compulsory contextual properties of the service consumer specified in the request, and x_p represents one or more contextual properties of the service provider specified in a web service description. A web service is determined to be contextually compatible with the request if all of the one or more compulsory contextual properties of the service consumer are a subset of or equal to the one or more contextual properties of the service provider specified in the web service description.

Referring again to Figure 1 , the web services composition system 14 functions as an intermediary in the architecture 10 and may be implemented as a proxy such as, for example, a server or a software agent between the data pool 12 and the service consumer 16. The service consumer 16 may be any electronic device with networking capabilities (i.e. any device capable of transmitting the service composition request across a network), for example, a mobile phone, a laptop computer, a desktop computer or a personal digital assistant (PDA). In one embodiment, a profile of the service consumer 16 is stored in the data pool 12. In such an embodiment, the profile of the service consumer 16 may be captured by the data pool 12 during the registration phase via the one or more administration portals 28.

Having described the various system modules in an embodiment of the present invention, the operation of these modules in a composition phase will now be described in greater detail below with reference to Figures 1 , 3 and 4.

Figure 4 is a schematic flow diagram illustrating a web services composition method 250. In a first step 252, the matching module 18 receives a request from the service consumer 16. The request specifies one or more operations to be performed, service ' consumer requirements, and service consumer preferences.

At step 254, the matching module 18 analyses the request received from the service consumer 16 at step 252 and performs a determination of whether the request corresponds to an earlier request. In particular, the matching module 18 checks whether an earlier request shares the same pattern of query (i.e. specifies the same operation(s) to be performed and the same service consumer requirements) as the current request from the service consumer 16.

If the matching module 18 determines at step 254 that no corresponding earlier request exists, the matching module 18 matches the web service descriptions stored in the data pool 12 to the request according to one or more semantic rules 202 at step 256. More particularly, the matching module 18 applies- one or more of a message parameters rule 208, a precondition rule 210, a function semantics rule 212 and one or more non-functional constraints rules 214 (i.e. a time constraint rule, a location constraint rule, a payment constraint rule and/or a security constraint rule) to the web service descriptions stored in the data pool 12 to locate at step 256 the web service descriptions that match the request. In a further embodiment, the matching module 18 also applies one or more business rules to the matching of the web service descriptions to the request at step 256.

The matched web service descriptions are then filtered by the composition module 20 according to one or more syntactic rules 204 at step 258. More particularly, the composition module 20 applies one or more of a binding rule 216 and an operation route rule 218 to the matched web service descriptions to identify composable web service descriptions at step 258.

At step 260, the composition module 20 generates one or more composition plans based on the filtered web service descriptions (i.e. the composable web service descriptions identified by the composition module 20 in step 258). The one or more composition plans generated by the composition module 20 may be stored in the data pool 12. Each of the one or more composition plans includes a list of participant services and information on the interaction between these services (e.g. the mappings between the messages exchanged). The application of the one or more semantic rules 202 at step 256 and the one or more syntactic rules 204 at step 258 ensures that the one or more composition plans conform to service consumer and service provider requirements and specifications.

When more than one composition plan is generated by the composition module 20 at step 260, the selection module 22 makes a selection from a plurality of composition plans according to at least one contextual rule 206 at step 262. More particularly, the selection module 22 performs a determination of whether one or more contextual properties of the service consumer 16 are compatible with a service provider profile specified in respective ones of the web service descriptions at step 262. In a further embodiment, the selection module 22 also applies one of the one or more semantic rules 202, in particular, the service quality rule, to the selection of the composition plan at step 262.

At step 264, the generation module 24 generates a composite web service description based on one of the one or more composition plans. In the case where more than one composition plan is generated by the composition module 20 at step 260, the composite web service description is generated by the generation module 24 at step 264 based on the composition plan selected by the selection module 22 at step 262. The composite web service description includes a list of the participant services, a sequence in which the participant services are executed, details of how the participant services are interconnected and the mappings between their messages. In one embodiment, the composite web service description is described in Business Process Execution Language for Web Services (WS-BPEL).

Referring again to step 254, if the matching module 18 determines at step 254 that the request corresponds to an earlier request, the composition module 20 retrieves the composition plan for the earlier request from the data pool 12 and the generation module 24 generates at step 264 the composite web service description based on the retrieved

, composition plan. As can be seen, the matching of the request to an archived composition plan speeds up the web services composition process by eliminating computational time required for composition planning (i.e. steps 258 and 260) and selection (i.e. step 262).

The composite web service description generated at step 264 is delivered by the generation module 24 to the service consumer 16 at step 268.

The web services composition method 250 may be run on a data processing device or a similar hardware device specifically built for the process. Generally, a device such as a personal computer or a midrange data processing device may be used. Such devices generally include a processing unit for running a program which implements the web services composition method 250, main memory for storing the program, a mass storage device for storing the data collection, and either further storage for the data pool 12, or/and an interface to a network of networked computers on which the data pool 12 is implemented.

As is evident from the foregoing discussion, the present invention provides a substantially automated web services composition system and method that does not require much, if any, user intervention. A user only needs to specify the operations to be performed. The process of composing the composite web service (i.e. identifying suitable web services for composition, plugging their operations, etc.) is transparent to the user. By automating the web services composition process, the otherwise tedious process of web services composition can be performed quickly and easily with the present invention. In addition, because the composite web service description can be generated based on an archived composition plan, the computational time of the present invention can be further reduced. By applying a tight set of rules to the web service descriptions stored in the data pool during the selection of participant services, the present invention returns a substantially accurate result which corresponds closely to user specifications. Further, because the web service descriptions stored in the data pool are described with vocabulary from one or more predefined taxonomies, the semantics of the web service descriptions can be accurately interpreted in the present invention.

While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art without departing from the spirit and scope of the invention as described in the claims.

Further, unless the context dearly requires otherwise, throughout the description and the claims, the words "comprise", "comprising" and the like are to be construed in an inclusive as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to".

Claims

1. A web services composition method, comprising: . receiving a request from a service consumer; matching a plurality of web service descriptions stored in a data pool to the request according to one or more semantic rules; filtering the. matched web service descriptions according to one or more syntactic rules; generating one or more composition plans based on the filtered web service descriptions; generating a composite web service description based on one of the one or more composition plans; and delivering the composite web service description to the service consumer.

• 2. A web services composition method according to claim 1 , wherein the step of matching the web service descriptions to the request comprises performing one or more of the following determinations of:

(i) whether one or more operation categories specified in the request is within one or more corresponding operation category domains specified in respective ones of the web service descriptions;

(ii) whether one or more function semantics specified in the request is within one or more corresponding function synonyms specified in respective ones of the web service descriptions;

(iii) whether each of one or more operation parameters specified in the request satisfy one or more corresponding property attributes specified in respective ones of the web service descriptions;

(iv) one or more output parameters specified in the request are compatible with one or more corresponding input parameters specified in respective ones of the web service descriptions.

3. A web services composition method according to claim 2, wherein the determining step (iv) is performed and comprises performing one or more of the following determinations of:

(v) whether the one or more output parameters and the one or more corresponding input parameters are of a compatible data type; (vi) whether all of the one or more input parameters specified in respective ones of the web service descriptions are within the one or more output parameters specified in the request:

(vii) whether the one or more output parameters and the one or more corresponding input parameters are of a compatible measurement:

(viii) whether the one or more output parameters and the one or more corresponding input parameters are of a compatible language.

4. A web services composition method according to any one of the preceding claims, wherein the step of matching the web service descriptions to the request comprises performing a determination of whether one or more preconditions specified in respective ones of the web service descriptions are satisfied by the service consumer.

5. A web services composition method according to any one of the preceding claims, wherein the step of matching the web service descriptions to the request comprises performing a determination of whether one or more non-functional constraints specified^" in respective ones of the web service descriptions are satisfied.

6. A web services composition method according to claim 5, wherein the step of determining whether the one or more non-functional constraints are satisfied comprises performing a determination of whether an invocation time specified in the request satisfies a corresponding time constraint specified in respective ones of the web service descriptions.

7. A web services composition method according to claim 5 or 6, wherein the step of determining whether the one or more non-functional constraints are satisfied comprises performing a determination of whether one or more of one or more service locations and one or more service request locations specified in the request satisfies a corresponding location constraint specified in respective ones of the web service descriptions.

8. A web services composition method according to any one of claims 5 to 7, wherein the step of determining whether the one or more non-functional constraints are satisfied comprises performing a determination of whether one or more payment preferences specified in the request satisfies one or more corresponding payment constraints specified in respective ones of the web service descriptions.

9. A web services composition method according to any one of claims 5 to 8, wherein the step of determining whether the one or more non-functional constraints are satisfied comprises performing a determination of whether one or more security mechanisms specified in the request are compatible with one or more corresponding security constraints specified in respective ones of the web service descriptions.

10. A web services composition method according to any one of the preceding claims, wherein the step of filtering the matched web service descriptions comprises performing a determination of whether the matched web service descriptions specify at least one compatible binding.

11. A web services composition method according to any one of the preceding claims, wherein the step of filtering the matched web service descriptions comprises performing a determination of whether corresponding operations described in the matched web service descriptions and the request specify at least one compatible service operation route.

12. A web services composition method according to any one of the preceding claims, further comprising making a selection from a plurality of composition plans according to at least one contextual rule when more than one composition plan is generated.

13.A web services composition method according to claim 12, wherein the step of selecting from the plurality of composition plans comprises performing a determination of whether one or more contextual properties of the service consumer are compatible with a service provider profile specified in respective ones of the web service descriptions.

14. A web services composition method according to claim 12 or 13, further comprising applying one of the one or more semantic rules to the selection of the composition plan.

15.A web services composition method according to claim 14, wherein the step, of applying one of the one or more semantic rules to the selection of the composition plan comprises performing a determination of whether a service quality measurement specified in respective ones of the web service descriptions satisfies a service quality requirement specified in the request.

16.A web services composition method according to any one of the preceding claims, further comprising storing the one or more generated composition plans in the data pool.

17.A web services composition method according to claim any one of the preceding claims, further comprising performing a determination of whether the request corresponds to an earlier request.

18. A web services composition method according to claim 17, further comprising retrieving the composition plan for the earlier request from the data pool when the request is determined to correspond to an earlier request.

19.A web services composition method according to any one of the preceding claims, wherein the web service descriptions stored in the data pool are derived from WSDL descriptions of web services extended with one or more additional properties.

20.A web services composition method according to any one of the preceding claims, wherein the web service descriptions stored in the data pool are described with vocabulary from one or more predefined taxonomies.

21. A computer program or suite of computer programs executable by a computer system to cause the computer system to perform the method of any one of the preceding claims.

22.A modulated carrier signal incorporating data corresponding to the computer program or at least one of the suite of programs of claim 21.

23.A computer readable storage medium storing a computer program or any one or more of a suite of computer programs according to claim 21.

24.A system of apparatus for composing a composite web service from web service descriptions stored in a data pool, the system comprising: a matching module configured to receive a request from a service consumer, the matching module being further configured to match web service descriptions stored in the data pool to the request according to one or more semantic rules; a composition module configured to filter the matched web service descriptions according to one or more syntactic rules, the composition module being further configured to generate one or more composition plans based on the filtered web service descriptions; and a generation module configured to generate a composite web service description based on one of the one or more composition plans, the generation module being further configured to deliver the composite web service description to the service consumer.

25.A system of apparatus for composing a composite web service from web service descriptions stored in a data pool according to claim 24, wherein the matching module is further configured to perform one or more of the following determinations of:

(x) whether one or more operation categories specified in the request is within one or more corresponding operation category domains specified in respective ones of the web service descriptions;

(xi) whether one or more function semantics specified in the request is within one or more corresponding function synonyms specified in respective ones of the web service descriptions;

(xii) whether each of one or more operation parameters specified in the request satisfy one or more corresponding property attributes specified in respective ones of the web service descriptions: (xiii) whether one or more output parameters specified in the request are compatible with one or more corresponding input parameters specified in respective ones of the web service descriptions.

26.A system for composing a composite web service from web service descriptions stored in a data pool according to claim 25, wherein the matching module is configured to perform determination (xiii) and further to perform a determination of whether the one or more output parameters and the one or more corresponding input parameters are of a compatible data type.

27. A system for composing a composite web service from web service descriptions stored in a data pool according to claim 25 or 26, wherein the matching module is configured to perform determination (xiii) and further to perform one or more of the following determinations of: (xiv) whether all of the one or more input parameters specified in respective ones of the web service descriptions are within the one or more output parameters specified in the request; (xv) whether the one or more output parameters and the one or more corresponding input parameters are of a compatible measurement:

(xvi) whether the one or more output parameters and the one or more corresponding input parameters are of a compatible language.

28. A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 24 to 27, wherein the matching module is further configured to perform a determination of whether one or more preconditions specified in respective ones of the web service descriptions are satisfied by the service consumer.

29. A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 24 to 28, wherein the matching module is further configured to perform a determination of whether one or more non-functional constraints specified in respective ones of the web service descriptions are satisfied.

30. A system for composing a composite web service from web service descriptions stored in a data pool according to claim 29, wherein the matching module is further configured to perform a determination of whether an invocation time specified in the request satisfies a corresponding time constraint specified in respective ones of the web service descriptions.

31. A system for composing a composite web service from web service descriptions stored in a data pool according to claim 29 or 30, wherein the matching module is further configured to perform a determination of whether one or more of one or more service locations and one or more service request locations specified in the request satisfies a corresponding location constraint specified in respective ones of the web service descriptions.

32. A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 29 to 31 , wherein the matching module is further configured to perform a determination of whether one or more payment preferences specified in the request satisfies one or more corresponding payment constraints specified in respective ones of the web service descriptions.

33. A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 29 to 32, wherein the matching module is further configured to perform a determination of whether one or more security mechanisms specified in the request are compatible with one or more corresponding security constraints specified in respective ones of the web service descriptions.

34. A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 29 to 33, wherein the composition module is further configured to perform a determination of whether the matched web service descriptions specify at least one compatible binding.

35. A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 24 to 34, wherein the composition module is further configured to perform a determination of whether corresponding operations described in the matched web service descriptions and the request specify at least one compatible service operation route.

36. A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 24 to 25, further comprising a selection module configured to make a selection from a plurality of composition plans according to at least one contextual rule when more than one composition plan is generated by the composition module.

37. A system for composing a composite web service from web service descriptions stored in a data pool according to claim 36, wherein the selection module is further configured to perform a determination of whether one or more contextual properties of the service consumer are compatible with a service provider profile specified in respective ones of the web service descriptions.

38. A system for composing a composite web service from web service descriptions stored in a data pool according to claim 36 or 37, wherein the selection module is further configured to apply one of the one or more semantic rules to the selection of the composition plan.

39. A system for composing a composite web service from web service descriptions stored in a data pool according to claim 38, wherein the selection module is further configured to perform a determination of whether a service quality measurement specified in respective ones of the web service descriptions satisfies a service quality requirement specified in the request.

40. A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 24 to 39, wherein the data pool is further configured to store the one or more generated composition plans.

41. A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 24 to 40, wherein the matching module is further configured to perform a determination of whether the request corresponds to an earlier request.

42. A system for composing a composite web service from web service descriptions stored in a data pool according to claim 41, wherein the composition module is further configured to retrieve the composition plan for the earlier request from the data pool when the request is determined to correspond to an earlier request.

43. A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 24 to 42, wherein the data pool is further configured to store the web service descriptions derived from WSDL descriptions of web services extended with one or more additional properties.

44.A system for composing a composite web service from web service descriptions stored in a data pool according to any one of claims 24 to 43, wherein the data pool is further configured to store the web service descriptions described with vocabulary from one or more predefined taxonomies.