Behavioral Queries for Service Selection
Automatic service discovery and selection is the key aspect for composing Web services dynamically in service-oriented computing (SOC). Current approaches attempting to automate discovery and selection make use of only structural and functional aspects of the Web services. We believe that behavioral selection of Web services should be used to provide more precise results. Service behavior is difficult to specify prior to service execution and instead is better described based on experience with the service execution.
We are exploring a novel approach to service selection and maintenance—inspired by agile software development techniques—that is based on behavioral queries specified as test cases. Behavior is evaluated through the analysis of execution values of functional and non-functional parameters.
Formal Model for Expressing Expected Behavior
We have developed a formal model for expressing the expected behavior of a Web service. For this model, we define a Web service WS as a tuple:
<I, FP, NFP, scenario, constraints>, where:
  • I is the set of input parameters
  • FP is the set of functional parameters (the Web service outputs)
  • NFP is the set of non-functional parameters (e.g., response time and availability)
  • scenario is an assignment of values to the input parameters
  • constraints is a conjunction of restrictions or  behavioral constraints, B1 ^ B2 ^ … ^ Bn, that must hold under the scenario.
Each constraint Bi is a tuple containing the following elements {parameter, expectedRange, relevance}, where:
  • parameter is an element of either FP or NFP
  • expectedRange is also a pair of values (min and max)
  • relevance is an indicator of the importance of the constraint.
I and FP are used for semantic matchmaking in a UDDI-based repository of available services. Scenario and constraints are used to test the behavior of the WS.
 
An Example Application
Consider the stock quoting domain. Suppose that using current selection techniques you find a list of candidate Web services, including URLs pointing to their WSDL files.  Each WSDL file specified the data types for the inputs to its corresponding Web service and the outputs it would generate.  In this case, the inputs were a string identifying the stock and an integer specifying the number of units, and the output was a real specifying the price.  However, what if one of the services provided a quote for purchasing livestock (cattle and pigs), and the string input identified the type of livestock?
WSDL-S attempts to deal with this problem by providing a reference from each input and output parameter to a mutually agreed upon ontology.  But this requires the existence of such an ontology, or a way to reconcile the independently developed ontologies of the service requestor and the service provider, neither of which is currently available.
Moreover, if you invoke the service for a particular stock (e.g., “IBM”) for which you wish to know its price, you would expect the result to be in a certain range (e.g., between 80.0 and 120.0), while the price for livestock is in a different range (the price for a cow, for example, is greater than 300 US dollars). Ontologies rarely include such constraints.

A particular instance of WS for our stockPurchase service example is:
I = {stockName, numberOfUnits}
FP = {price}
NFP = {availability, responseTime}
scenario = {stockName=”IBM”, numberOfUnits=1}
and constraints = {B1, B2}, where
B1 = {price, (60, 110), 1}
B2 = {responseTime, (0, 5000), 1}.

Using current selection techniques we find a list of candidate Web services which are available at:
Then, we used our behavioral selection approach to rank these candidate services and find the most appropriate one. We used JUnit for the implementation of the unit cases, and Apache Axis WSDL2Java for the automatic generation of client stubs to invoke the Web services.
We captured the behavioral information in an XML file to pass them as input to the unit test. The behavioral constraints are expressed as assertions in the unit test. The source code of the unit test in JUnit. The source code for the service requester class (which is the one tested by the unit test) in Java.