WO2008015398A1

WO2008015398A1 - Method and system for web service selection

Info

Publication number: WO2008015398A1
Application number: PCT/GB2007/002869
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 service selection are described. Web service selection includes receiving a request (38). The request (38) is compared to a plurality of cases stored in a library (44), and a relevancy is determined for respective ones of the cases. Relevant ones of the cases are prioritised, and a web service corresponding to a prioritised case is retrieved from a data pool (46).

Description

Method and System for Web Service Selection

Technical Field

The present invention relates to web service selection, and more particularly to a method and system for web service selection.

Background to the Invention and Prior Art

The current trend in software architecture is towards building platform-independent software components called web services that are available in the distributed environment of the Internet. Applications can be assembled from a set of appropriate web services and thus no longer need to be manually written out. In this regard, seamless web service selection holds out great potential to streamline enterprise application integration. For this reason, web service selection has recently emerged as an area of research interest. Several approaches have been proposed in this area. However, these essentially involve low-level programming details, making the process of selecting web services difficult for naive or non-expert end users. For example, end users need to identify the interactions of service operations, and have knowledge of how the services are invoked and how messages (e.g. input/output parameters of service operations) are mapped to one another.

In view of the foregoing, it would be desirable to have a method and system for web service selection 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 method and system for web service selection that does not require much, if any, user input. Further, by applying a Case-Based Reasoning (CBR) approach to the web service selection process, computational time for web service selection can be reduced with the present invention.

From a first aspect there is provided a method for web service selection, the method comprising: receiving a request; comparing the request to a plurality of cases stored in a library; determining a relevancy for respective ones of the cases; prioritising relevant ones of the cases; and retrieving a web service corresponding to a prioritised case from a data pool, wherein the step of determining a relevancy for respective ones of the cases preferably includes matching a plurality of attributes in the request and respective ones of the cases to determine a number of pairs of comparable attributes therein. Embodiments of the invention according to the first aspect provide the advantages set out above.

Preferably, the step of determining a relevancy for respective ones of the cases further includes expressing the number of pairs of comparable attributes as a proportion of a total number of different attributes in the request and respective ones of the cases. Preferably, the attributes in the request and the cases stored in the library are categorised according to whether the respective attributes are role-specific. Advantageously, role-based classification of the attributes in the request and the cases speeds up the web service selection process as only cases in the library having one or more roles similar to the request are compared. Comparisons with cases having dissimilar roles are not made. Preferably, the attributes in the request and the cases stored in the library are of a fixed semantics based on a predefined taxonomy. This ensures that one or more attributes in the request are accurately matched to one or more attributes in respective ones of the cases stored in the library.

The step of prioritising relevant ones of the cases preferably includes determining a priority value for respective ones of the relevant cases based on a difference value between the respective pairs of comparable attributes. Preferably, the difference value between the respective pairs of comparable attributes is normalised. Normalisation of the difference value prevents bias values resulting^' from the different scales of measurement. Preferably, a weight is assigned to the respective pairs of comparable attributes. Advantageously, the weight assigned to the respective pairs of comparable attributes accounts for differing levels of importance or influence amongst the attributes.

Preferably, a check is performed to determine if the web service is available before retrieving the web service from the data pool. This ensures that the web service is available and ready for selection and invocation before being retrieved from the data pool.

Preferably, the request is converted into a predetermined format. Advantageously, this provides flexibility in implementing embodiments of the invention as various input formats can be accepted.

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.

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 web service selection, the system comprising: selection means configured to receive a request, the selection means further comprising: comparison means configured to compare the request to a plurality of cases stored in a library and to determine a relevancy for respective ones of the cases, and prioritisation means configured to prioritise relevant ones of the cases; and analysing means configured to retrieve a web service corresponding to a prioritised case from a data pool.

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 diagram of a high-level framework for web service selection 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 3A is a schematic representation of a scenario-based request in accordance with an embodiment of the present invention;

Figure 3B is a schematic representation of a service-based request in accordance with another embodiment of the present invention; Figure 3C is a schematic representation of a specific request in accordance with yet another embodiment of the present invention;

Figure 4 is a schematic diagram of a conversion means for converting a request into a predetermined format in accordance with one embodiment of the present invention;

Figure 5 is a schematic diagram illustrating how attributes in a requested case and a targeted case are matched in accordance with an embodiment of the present invention; and

Figure 6 is a schematic flow diagram illustrating a web service selection method in accordance with another embodiment of the present invention.

Detailed Description of the Preferred Embodiments

A system and method for web service selection 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.

Conceptually, a web service may be regarded as an object to perform certain tasks (e.g. ticket booking). Web services are offered by service providers (e.g.' a cinema online service agency). Service providers are responsible for describing and assigning values to web services. Web services are invoked by consumers. Consumers may be end users or other services that invoke web services.

Web services are typically described in Web Service Description Language (WSDL). In particular, WSDL is used to describe the syntax associated with the invocation and response of a web service. However, even though WSDL describes functional information of web services, it provides little semantic description; WSDL mainly describes web services from a syntactical point of view. Accordingly, in order to provide semantic-enabled web service descriptions to realise automatic reasoning capabilities for web service selection, additional properties are added to WSDL descriptions of web services in embodiments of the present invention to extend WSDL with semantic capabilities. Nonetheless, it should be understood that the present invention is not limited by the language or derivation of the web service descriptions. In embodiments of the present invention, web services are classified according to their respective rotes or purposes. Role-based classification of the web services provides groundwork for the reasoning of the selection process. Advantageously, role-based classification of web services speeds up the web service selection process as only web services with similar roles are compared. Comparisons with non-similar services are not made. Accordingly, descriptions of web services in embodiments of the present invention may be represented by a functional role-based classification schema such as that described below with reference to Figure 1.

Referring now to Figure 1 , a schematic representation of a web service description 10 is shown. In Figure 1 , the node defined by dashed-lines represents attributes extended from WSDL concepts (e.g. operation, name, binding, etc.), while the nodes defined by solid lines represent additional properties added to augment the semantic capabilities of WSDL. Edges, defined by arrows in Figure 1 , represent the relationships between the nodes.

The web service description 10 describes a web service 12. The web service 12 is described by a plurality of functional attributes 14 and one or more non-functional attributes 16. The functional attributes 14 include a plurality of WSDL attributes 18 and may further include one or more non-WSDL attributes 20. The non-functional attributes 16 include one or more of one or more role-specific attributes 22 and one or more non-role specific attributes 64.

The functional attributes 14 provide information necessary for web service invocation. The functional attributes 14 are not role-specific. The WSDL attributes 18 describe the syntax associated with the invocation and response of the web service 12. Examples of WSDL attributes 18 include a web service name, web service operations and binding protocol information. Such attributes are known by those of skill in the art and therefore, further explanation is not necessary for a complete understanding of the invention. The non-WSDL attributes 20 extend the WSDL description of the web service 12 to enable semantic capability, thereby providing the groundwork for understanding and selecting the web service 12. A precondition attribute is an example of a non-WSDL attribute 20. The precondition attribute specifies a logical condition that must be satisfied before an operation of the web service 12 can be invoked. For example, a web service 12 may provide a log-in operation with an "IsLogin" precondition. The log-in operation only executes when a user is not already logged in (i.e. when the "IsLogin" precondition has a logical value of "FALSE").

The non-functional attributes 16 provide additional information about the web service 12. The information provided by the non-functional attributes 16 is not essential for web service invocation. As shown in Figure 2, the non-functional attributes 16 are classified according to whether the respective non-functional attributes 16 are role-specific.

The role-specific attributes 22 describe non-functional role-related attributes of the web service 12. In embodiments of the present invention, each role-specific attribute 22 is defined as follows:

{Category _op , Channel _op) ( 1 )

where Category _op describes a role or function performed by the web service 12, and Channel_op represents one or more mediums by which the role or function described in the Category _op property operates. The Channeh_p >s defined as follows:

Channelop ^e %β\, ei, —, en) \ ei ≠ ei ≠ ... ≠ e_n\ (2)

where e represents a medium by which the role or function described in the Category ₀ property operates, and n represents a positive integer. Examples of role- specific attributes 22 include (delivery provider. Short Message Service (SMS)), (delivery provider. Multimedia Message Service (MMS)), (payment provider. Visa) and (payment provider, MasterCard). The Channel_op values e are of a fixed semantics based on a predefined taxonomy. In one embodiment, the RosettaNet business dictionary consisting of a common vocabulary is used to describe the predefined taxonomy.

The non-role-specific attributes 24 describe qualitative properties of the web service 12; the non-role-specific attributes 24 are independent of the role or function performed by the web service 12 and provide non-functional information about the web service 12. Examples of non-role-specific attributes 24 include Quality of Service (QoS) information such as reliability of the web service 12, availability of the web service 12 (e.g. an up-time, a time period for invocation of the web service 12, a location of the web service 12, etc.) and performance measures for the web service 12, contextual information about the service provider and service provider preferences. The functional role-based web service attribute classification schema described above provides the groundwork for web service selection in accordance with embodiments of the present invention. Based on the functional role-based classification schema, the web service 12 may be represented as follows:

Φ <≡ {(αi , fl2 a») such that

≠ a₂ ^≠ - ^≠ a_n] (3) where Φ represents the web service 12, a represents an attribute of the web service 12, and n represents a positive integer.

Referring now to Figure 2, a system 30 for web service selection is shown. The system includes conversion means 32, selection means 34 and analysing means 36. The conversion means 32 is configured to convert a request 38 into a predetermined format for the selection means 34. The selection means 34 is configured to receive the request 38, and includes comparison means 40 and prioritisation means 42. The comparison means 40 is configured to compare the request 38 to a plurality of cases stored in a library 44 and to determine a relevancy for respective ones of the cases, while the prioritisation means 42 is configured to prioritise relevant ones of the cases. The analysing means 36 is configured to retrieve a web service corresponding to a prioritised case from a data pool 46. In the present embodiment, the analysing means 36 includes checking means 48 configured to check that the web service is available before retrieving the web service from the data pool 46.

The request 38 may be made by an end user via any electronic device with networking capabilities (i.e. any device capable of transmitting the request across a network), for example, a mobile phone, a laptop computer, a desktop computer or a Personal Digital Assistant (PDA), or by another service that invokes the web service.

The request 38 specifies one or more attributes of a requested case R . In the present embodiment, the attributes in the request 38 are categorised according to whether the respective attributes are role-specific and may be represented as follows:

A

ai> α^ K

(4) where A_R represents one or more attributes in the request, ^R U_RS represents a set of role-specific attributes in the request, and ^R CI_NRS represents a set of non-role-specific attributes in the request.

The request 38 may be a scenario-based input (e.g. a short text message), a service-based input (e.g. a business process) or a specific input (e.g. a functional description). Examples of these input formats of the request 38 are described below with reference to Figures 3A through 3C.

Referring first to Figure 3A, a schematic representation of a scenario-based request 60 is shown. In this example, the scenario-based request 60 is a short text message specifying one or more business activities of a user. The short text message is enciphered into a machine-readable language via a syntactical processing method to determine the business processes involved. The input format shown in Figure 3A may be submitted by the user via an SMS from a mobile device.

Referring next to Figure 3B, a schematic representation of a service-based request 70 is shown. The service-based request 70 specifies the business processes involved in a transaction. In the present example, the service-based request 70 specifies three (3) business processes: making flight and hotel reservations 72, obtaining confirmation 74 on the reservations and executing a purchase 76.

Referring now to Figure 3C, a schematic representation of a specific request 80 is shown. The specific request 80 specifies a particular operational task that is to be performed by the web service, in this instance, purchasing a flight ticket.

Referring again to Figure 2, in embodiments where the request 38 is in the form of a scenario-based input, a service-based input, a specific input or other inappropriate formats, the request 38 is converted by the conversion means 32 into the format shown in equation (4) for the selection means 34. Advantageously, this provides flexibility in implementing embodiments of the invention as various input formats can be accepted. An example of the conversion performed by the conversion means 32 is described below with reference to Figure 4.

Referring now to Figure 4, a schematic diagram of a conversion means 100 is shown. The conversion means 100 includes a text processor 102 and a memory 104. The conversion means 100 converts a request 106 into a predetermined format 108.

In this example, the request 106 is a scenario-based request. The scenario- based request 106 may be transmitted to the conversion means 100 via an SMS. The request 106 is enciphered by the conversion means 100. More particularly, the text processor 102 extracts web service attributes (i.e. mode of travel, travel period, seat class, carrier) and the corresponding attribute values (i.e. air, 12 to 17 December, business class, Malaysian Airlines) from the scenario-based request 106 based on a predefined taxonomy of attributes and values stored in the memory 104. Subsequent to the extraction, the extracted attributes and values are converted into the predetermined format 108.

Referring again to Figure 2, the selection means 34 employs CBR — a problem solving approach in which new problems are solved based on solutions of similar past problems. In the present context, the request 38 is the new problem which is solved by returning the solution (i.e. web service) of the most similar past query. The past queries and their respective solutions (i.e. web services returned in response to the respective past queries) are stored as targeted cases T j_n the library 44. In the present embodiment, the cases stored in the library 44 are systematically categorised for efficient retrieval.

The comparison means 40 identifies the relevant cases (i.e. the cases that contain the requested business process) by examining the number of attributes in each of the targeted cases T in the library 44 that are relevant to the request 38. Each of the targeted cases T stored in the library 44 may be represented as follows:

A —

^'■> ClNRS ⁼ L^l ' #2 ? fl3 > «4? K CtN]J (5)

where Ar represents one or more attributes in a targeted case T , ^τ cms represents a set of role-specific attributes in the targeted case T , and ^τ C_INRS represents a set of non-role- specific attributes in the targeted case T . Because business practices vary from organisation to organisation, the number of attributes in the requested case R may differ from that in respective ones of the targeted cases T . For example, a request for a payment service may specify a combination of attributes from a pool of attributes comprising booking number, order number, payment mode, booking validity, etc, while a web service providing payment services may specify another combination of attributes. Accordingly, the comparison means 40 is configured to match a plurality of attributes in the request 38 and respective ones of the cases stored in the library 44 to determine a number of pairs of comparable attributes in the request 38 and respective ones of the cases. Matching of the attributes in the request 38 and respective ones of the cases stored in the library 44 is described in greater detail below with reference to Figure 5. To ensure accurate matching, the attributes in the request 38 and the cases stored in the library 44 are of a fixed semantics based on a predefined taxonomy.

Referring now to Figure 5, a schematic diagram illustrating how attributes in a requested case A_R and a targeted case A_T are matched is shown. Each of the requested and targeted cases A_R and A_T includes a set of role-specific attributes ^RU_RS and ^τ U_RS ^ar|d a set of non-role-specific attributes ^RQ_NRS and ^τ _CI_NRS ■ The attributes in the requested case A_R are matched to those in the targeted case A_T ■ A pair of attributes is deemed to match if the two attributes in the pair are comparable. In Figure 5, each pair of comparable attributes is indicated by a double-headed arrow, while a single-headed arrow indicates that an attribute in either the requested case A_R or the targeted case A_T is unmatched. As can be seen, the attributes in the requested case and the targeted case are categorised according to whether the respective attributes are role-specific. Advantageously, role- based classification of the attributes in the requested case and the targeted cases speeds up the web service selection process as only cases in the library having one or more roles similar to the requested case are compared. Comparisons between cases with dissimilar roles are not made.

Referring again to Figure 2, the number of pairs of comparable attributes determined from matching the attributes in the request 38 and respective ones of the cases stored in the library 44 provide an indication of the relevancies of the targeted cases T stored in the library 44 to the request 38. In the present embodiment, the comparison means 40 is configured to express the number of pairs of comparable attributes as a proportion of a total number of different attributes in the request 38 and respective ones of the cases. The relevancy MR of each targeted case T stored in the library 44 to the request 38 may be computed with the following equation:

where Ξ(a, β) = ' , M represents a number of different role-specific

attributes, and N represents a number of different non-role-specific attributes. Advantageously, as seen from equation (6), embodiments of the present invention are capable of handling multivariate attributes.

The relevant cases identified by the comparison means 40 are further examined by the prioritisation means 42 to deduce a unique selection based on prioritised key attributes. In one embodiment, the first fifty (50) cases ranked in order of relevancy values MR axe deemed relevant. However, it should be understood that the present invention is not limited to a particular definition for the relevant cases as the cut-off value for the relevant cases varies depending on the problem domain and implementation. The prioritisation means 42 is configured to determine a priority value for respective ones of the relevant cases based on a difference value between the respective pairs of comparable attributes. The difference value between two attributes in a pair of comparable attributes may be computed by subtracting one from the other. Where the values of the attributes in the pair are non- numerical, the difference value may be computed using a taxonomy tree: objects residing under different parental nodes are assigned a greater difference value than objects under the same parent node. The methods for computing the difference values described herein are merely exemplary; it should be understood that the present invention is not limited to a particular method of computing the difference values.

Because the number of different attributes M and N are not known a priori, the prioritisation means 42 in the present embodiment is configured to determine the priority value for respective ones of the relevant cases based on a normalised difference value between the respective pairs of comparable attributes. Normalisation of the difference values prevents bias values resulting from the different scales of measurement.

Additionally, because certain attributes may be more important or influential than others, the prioritisation means 42 in the present embodiment is configured to determine the priority value for respective ones of the relevant cases based on a weighted difference value between the respective pairs of comparable attributes. A weight is assigned to respective ones of the different attributes in the computation of the priority value to account for differing levels of importance or influence amongst the attributes. The weights assigned to the attributes may be manually or automatically determined; a weight is manually determined if the attribute is unknown and automatically determined when prior knowledge of the attribute type and level of influence is available. Default values may be assigned to unknown attributes. To maintain a standard of measurement, the weights in the present embodiment are within a prescribed range, for example, zero to one [0, 1] or ten to a hundred [10, 100], the wider prescribed range having a greater significance on the priority value. Nonetheless, it should be understood that the present invention is not limited to weights within a prescribed range.

Accordingly, the priority value PF of a targeted case in the present embodiment may be computed with the following equation:

where δ represents a difference value between a pair of comparable attributes, and ω represents a weight assigned to an attribute. Advantageously, the number of different attributes M and N need not be the same. This provides flexibility as the number of syntactical attributes and semantic attributes to be compared are not always identical.

The analysing means 36 understands and identifies web services stored in the data pool 46 by identifying the attributes of the web services defined according to the functional role-based classification schema. The checking means 48 serves to ensure that a web service is available and ready for selection and invocation before retrieving the web service from the data pool 46.

The system 30 may be implemented on one or more computers. For example, the system 30 may be implemented on a server or a network of computers. Further, it should be understood that the invention is not limited by the architecture of the system 30. The modular components shown in Figure 2 and described herein are intended to illustrate aspects of the present invention and not to limit the present invention to any particular configuration.

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 2 and 6.

Figure 6 is a schematic flow diagram illustrating a method 150 for web service selection. In a first step 152, the selection means 34 receives a request 38 from a service consumer. The request 38 specifies one or more attributes of a requested case. As previously mentioned, the request 38 may be in the form of a scenario-based input, a service-based input or a specific input. In such embodiments, the request 38 is converted into a predetermined format by the conversion means 32. Advantageously, this provides flexibility in implementing embodiments of the invention as various input formats can be accepted. The service consumer may be any electronic device with networking capabilities (i.e. any device capable of transmitting the request across a network), for example, a mobile phone, a laptop computer, a desktop computer or a PDA, or another service invoking a web service.

The request 38 is compared to a plurality of cases stored in the library 44 by the comparison means 40 at step 154. More particularly, the comparison means 40 matches a plurality of attributes in the request 38 and respective ones of the cases stored in the library 44. In the present embodiment, the attributes in the request 38 and the cases stored in the library 44 are categorised according to whether the respective attributes are role-specific. Advantageously, role-based classification of the attributes in the request 38 and the cases speeds up the web service selection process as only cases in the library 44 having one or more roles similar to the requested case specified in the request 38 are compared. Comparisons between cases with dissimilar roles are not made. Further, to ensure accurate matching, the attributes in the request 38 and the cases stored in the library 44 are of a fixed semantics based on a predefined taxonomy in the present embodiment.

At step 156, the comparison means 40 determines a relevancy for respective ones of the cases. More particularly, the comparison means 40 determines a number of pairs of comparable attributes in the request and respective ones of the cases and expresses the number of pairs of comparable attributes as a proportion of a total number of different attributes in the request and respective ones of the cases.

Relevant ones of the cases are prioritised by the prioritisation means 42 at step 158. More particularly, the prioritisation means 42 determines a priority value for respective ones of the relevant cases based on a difference value between the respective pairs of comparable attributes. In the present embodiment, the difference value between the respective pairs of comparable attributes is normalised and a weight is assigned to the respective pairs of comparable attributes. Normalisation of the difference value prevents bias values resulting from the different scales of measurement, while the weight assigned to the respective pairs of comparable attributes accounts for differing levels of importance or influence amongst the attributes.

At step 160, a web service corresponding to a prioritised case is retrieved by the analysing means 36 from the data pool 46. More particularly, the analysing means 36 retrieves the web service corresponding to the case with the highest priority value calculated by the prioritisation means 42 from the data pool 46. In the present embodiment, the checking means 48 checks that the web service is available before retrieving the web service from the data pool 46. This ensures that the web service is available and ready for selection and invocation before being retrieved from the data pool.

The retrieved web service is returned to the service consumer by the selection means 34 at step 162.

The method 150 for web service selection 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 service selection method 150, main memory for storing the program, a mass storage device for storing the data collection, and either further storage for the data pool 46, or/and an interface to a network of networked computers on which the data pool 46 is implemented.

As is evident from the foregoing discussion, the present invention provides a substantially automated system and method for web service selection that does not require much, if any, user intervention. By automating the web service selection process, the otherwise tedious process of web service selection can be performed quickly and easily with the present invention. In addition, by applying the CBR approach to the web service selection process, computational time for web service selection is reduced with 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 method for web service selection, comprising: receiving a request; comparing the request to a plurality of cases stored in a library; determining a relevancy for respective ones of the cases; prioritising relevant ones of the cases; and retrieving a web service corresponding to a prioritised case from a data pool, wherein the step of determining a relevancy for respective ones of the cases comprises matching a plurality of attributes in the request and respective ones of the cases to determine a number of pairs of comparable attributes therein.

2. A method according to claim 1 , wherein the attributes in the request and the cases stored in the library are categorised according to whether the respective attributes are role-specific.

3. A method according to claim 1 or 2, wherein the attributes in the request and the cases stored in the library are of a fixed semantics based on a predefined taxonomy.

4. A method according to any one of the preceding claims, wherein the step of determining a relevancy for respective ones of the cases further comprises expressing the number of pairs of comparable attributes as a proportion of a total number of different attributes in the request and respective ones of the cases.

5. A method according to claim 4, wherein the step of prioritising relevant ones of the cases comprises determining a priority value for respective ones of the relevant cases based on a difference value between the respective pairs of comparable attributes.

6. A method according to claim 5, wherein the difference value between the respective pairs of comparable attributes is normalised.

7. A method according to claim 5 or 6, wherein a weight is assigned to the respective pairs of comparable attributes.

8. A method according to any one of the preceding claims, further comprising checking that the web service is available before retrieving the web service from the data pool.

9. A method according to any one of the preceding claims, further comprising converting the request into a predetermined format.

10. 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.

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

12. A system of apparatus for web service selection, comprising: selection means configured to receive a request, the selection means further comprising: comparison means configured to compare the request to a plurality of cases stored in a library and to determine a relevancy for respective ones of the cases, and prioritisation means configured to prioritise relevant ones of the cases; and analysing means configured to retrieve a web service corresponding to a prioritised case from a data pool, wherein the comparison means is configured to match a plurality of attributes in the request and respective ones of the cases stored in the library to determine a number of pairs of comparable attributes therein.

13. A system of apparatus according to claim 12, wherein the comparison means is configured to match the attributes in the request and respective ones of the cases stored in the library, the attributes in the request and the cases stored in the library being categorised according to whether the respective attributes are role-specific.

14. A system of apparatus according to claim 12 or 13, wherein the comparison means is configured to match the attributes in the request and respective ones of the cases stored in the library, the attributes in the request and the cases stored in the library being of a fixed semantics based on a predefined taxonomy.

15. A system of apparatus according to any one of claims 12 to 14, wherein the comparison means is configured to express the number of pairs of comparable attributes as a proportion of a total number of different attributes in the request and respective ones of the cases.

16. A system of apparatus according to claim 15, wherein the prioritisation means is configured to determine a priority value for respective ones of the relevant cases based on a difference value between the respective pairs of comparable attributes.

17. A system of apparatus according to claim 16, wherein the prioritisation means is configured to determine the priority value for respective ones of the relevant cases based on a normalised difference value between the respective pairs of comparable attributes.

18. A system of apparatus according to claim 16 or 17, wherein the prioritisation means is configured to determine the priority value for respective ones of the relevant cases based on a weighted difference value between the respective pairs of comparable attributes.

19. A system of apparatus according to any one of claims 13 to 18, further comprising checking means configured to check that the web service is available before retrieving the web service from the data pool.

20. The system for web service selection according to any one of claims 12 to 19, further comprising conversion means configured to convert the request into a predetermined format for the selection means.