Service Offer Discovery Using Genetic Algorithms - IEEE Xplore

2011 Ninth IEEE European Conference on Web Services

Service Offer Discovery Using Genetic Algorithms Maciej Zaremba Digital Enterprise Research Institute National University of Ireland, Galway [email protected]

Tomas Vitvar Web Engineering Group Faculty of Information Technologies Czech Technical University in Prague [email protected]

Sami Bhiri Digital Enterprise Research Institute National University of Ireland, Galway [email protected]

Manfred Hauswirth Digital Enterprise Research Institute National University of Ireland, Galway [email protected]

Abstract

formed. We believe that a similar understanding of offers should be applied to services and therefore we distinguish between services and service offers. Service offers are quantifiable artifacts suitable for objective ranking and making services truly comparable. The majority of service discovery approaches (e.g., [12, 11, 6]) operate on abstract service descriptions that contain information on service categorisation, and pre- and postconditions expressed in terms of concepts and datatypes, but not in terms of attribute values. On the other hand, QoS-based service selection approaches (e.g., [15, 4]) operate on concrete values of service QoS parameters (e.g., price, delivery time), but assume that QoS values are statically available in service description. Assumption that parameters like service price are statically available in service description is unrealistic in the case of highly configurable services. Available service descriptions are abstract due to: (1) large number of possible service offers, (2) privacy concerns – providers might not want to disclose details of their business (e.g., how is the service price calculated), and (3) maintaining business advantage – providers may use marketing terms in their service descriptions (e.g., by describing a service as the cheapest service). Service offers are generated with parameters provided by a service consumer. However, service consumer might specify a flexible search request where parameters required by a service are defined in terms of ranges (e.g., package weight: 8–12 kg), alternatives (e.g., target address: home address or office address). Fixed values (e.g., package weight: 10 kg, target address: home address) are required by a service in order to generate service offers that include details such as service availability and price. We use a set theory projection to map sets of parameters to distinct values required for generating service offers.

Available service descriptions are often specified using abstract definitions of service attributes. However, service consumers are mainly interested in concrete, consumable service offers which are specified using concrete values of service attributes. Service offers, due to their request dependence and dynamicity, have to be generated on-the-fly what may require interaction with a service. We propose a service description model that facilitates creation of consumable service offers. A large number of service offers can be generated considering flexible search requests. In order to address that, we propose a novel approach to dynamic generation of service offers. Our approach is based on genetic algorithms and reduces the number of relevant service offers. For evaluation purposes we apply our approach to the shipping domain where real shipping services on the Web are used to prove the effectiveness and usability of our approach in a real-world domain.

1

Introduction

Service discovery and selection are one of the core research topics in the Service Computing area. Services should be comparable and tradable in order to facilitate service discovery and selection. However, existing service descriptions are often incomplete and underspecified [14] what hinders their discovery and selection. A single, highly configurable service [10] may provide a large number of possible service offers created for different service requests. An offer has a well-defined business meaning and it should include at least the following four conditions [16]: delivery date, price, terms of payment and fair description of an item or service. Service consumer can accept an offer and once service provider approves service consumer’s decision then legally binding contract is

978-0-7695-4536-3/11 $26.00 © 2011 IEEE DOI 10.1109/ECOWS.2011.9

23

In this paper we contribute with the following:

2

• Service description model that facilitates creation of consumable service offers. Our service model contains: (1) data-fetching interfaces for on-the-fly service interactions carried out in order to obtain details of service offers, (2) derived parameters which describe dependencies between service parameters, and (3) hard constraints which capture various restriction on service usage.

In this section we define a search request R that expresses service consumers’ needs, and a service description S which can capture different levels of service abstraction. We introduce domain ontologies O that service consumers and service providers share. O, R and S are specified semantically using a combination of RDF [7] and SPARQL as a rule language [13]. Over the last years we have observed growing adoption of Linked Data [1] principles and growth of datasets specified in RDF. Linked Data is the set of best practices for publishing and interconnecting structured data on the Web. Linked Data is published using RDF where URIs are the means for connecting and referring between various entities on the Web. There is a considerable interest from organisations in publishing their data in RDF and increasing number of public vocabularies (ontologies). We capitalise on the Linked Data by grounding our conceptual model in the combination of RDF and SPARQL. We use RDF as a lightweight language for describing and linking data, whereas we use SPARQL for advanced data querying including usage of SPARQL as a rule language [13]. In our examples, we use existing public vocabularies what should facilitate use of our approach by service consumers and service providers. We use domain ontologies as a shared conceptualisation between search requests and service descriptions. Listing 1 shows a fragment of the shipping domain ontology example in RDF using a human-readable N3 notation. In here, the shipping domain contains entities such as SourceAddress, TargetAddress, Package, ShippingPrice, and ShippingDelivery. We use vcard6 (vcard: prefix) open vocabulary for defining addresses (line 12). We also use dbpedia7 (d: prefix) as a dataset that unambiguously identifies entities (e.g., countries, cities) on the Web.  

• Service offer discovery which uses genetic algorithms [3] for selecting input projections in order to reduce a number of relevant service offers. Our approach is applicable to dynamic, highly configurable services whose parameters are volatile (e.g., price frequently changes) and depend on a number of other parameters (e.g., in shipping scenario price depends on the package size, weight, source and target address). It our previous work on service offers [18] we introduced data-fetching interfaces in the context of SWS-Challenge1 initiative. In [17] we used statistical methods to mine services. We enriched service descriptions with predictor functions which reflect hidden dependencies between service parameters. Derived service parameters can be expressed using previously proposed predictor functions. Service mining is not feasible in cases when service parameters often change (e.g., shipping availability depends on the shipper’s workload, date, etc.). We apply our discovery approach to the shipping scenario where we discover real online services of shipping companies like FedEx2 , TNT3 , USPS4 , AnPost5 and others. Due to the lack of the shipping Web services, we have built service wrappers that perform on-the-fly interactions and screen scraping with the shipping Web sites. From the service consumer perspective, it is much more valuable to operate on concrete, consumable shipping offers (e.g., shipping using FedEx Express, price 100 EUR, from Germany to Ireland, delivery within one day) rather than to operate on abstract service descriptions (e.g., FedEx shipping company, ships packages up to 500 kg, between various source and target destinations). Available service descriptions require manual work in order to move to the service offer level. Our approach aims to automate this step. We structure the paper as follows. In Section 2 we introduce our conceptual model of search requests and services. In Section 3 we present our service configuration and ranking algorithm. In Section 4 we provide evaluation of our approach. In Section 5 we describe related work, and we conclude the paper in Section 6.

Conceptual Model

1 2 3 4 5 6

@prefix rdf: . @prefix rdfs: . @prefix xsd: . @prefix so: . @prefix d: . @prefix vcard: .

7 8 9 10 11 12

so:SourceAddress a rdfs:Class. so:TargetAddress a rdfs:Class. so:hasAddress a rdf:Property; rdfs:domain so:SourceAddress, so:TargetAddress; rdfs:range vcard:VCard.

13 14 15 16 17

so:Package a rdfs:Class. so:hasWeight a rdf:Property; rdfs:domain so:Package; rdfs:range so:Weight.

18 19 20



so:ShippingPrice a rdfs:Class. so:ShippingDelivery a rdfs:Class.

1 http://sws-challenge.org 2 http://www.fedex.com

Listing 1. Shipping Domain Ontology Snippet

3 http://www.tnt.com 4 http://www.usps.com

6 http://www.w3.org/Submission/vcard-rdf/

5 http://www.anpost.ie

7 http://dbpedia.org

24



2.1

Service Description

19 20 21 22

We model services descriptions in a hierarchy of service description variants with varying concreteness levels as shown in Figure 1. Consumable service offers are variants of more abstract service variants. Service offers Sof f er are the most concrete service descriptions. Service description S may contain: O, ST , SC , SD , SX . O is a reference to domain ontologies, ST is a textual description that contains service category, tags and keywords, SC are hard constraints, SD are derived parameters that are dependent on other service parameters, and SX is data-fetching interface used for handling dynamic parameters. Derived parameters SD and data-fetching interfaces SX are used for creating service offers. Service description uses parameters described in the domain ontologies O. We distinguish two types of parameters: (1) input parameters P I = {pI1 , pI2 , ..., pIn } (e.g., SourceAddress, TargetAddress) required by a service, and (2) output O O parameters P O = {pO 1 , p2 , ..., pm } (e.g., ShippingPrice, ShippingDelivery) provided by a service in response to P I . P I and P O map to concepts defined in domain ontology shown in Listing 1.

23 24 25 26 27 28 30 31 32 33 34



Derived Parameters (RD ) define dependencies between input and output parameters. Derived parameters are utilised during the matchmaking process to provide concrete values for service output parameters P O . Dependencies that do not changes frequently can be defined in derived parameters. Each derived parameter SD defines constraints (SPARQL FILTER) and assignments (SPARQL LET). Listing 2 in lines 2–11 shows an example of a derived parameter priceDeliveryIreland. It produces a new instance of the ShippingPrice and ShippingDelivery concepts if source, destination and weight constraints are satisfied. The price is calculated as a fixed fee of 30 Euro per package and 5.75 Euro per kg. Data-fetching Interface (RX ) is an interface that refers to service input, output and endpoint provided by the original service (e.g., WSDL service). Not all dependencies between input and output parameters can be explicitly specified using derived parameters due to the dynamicity of service output parameters, complexity of parameter dependencies, or their business sensitivity. In such cases, values of output parameters P O must be obtained on-the-fly from service provider’s back-end system that is accessed via referred endpoint. A data-fetching interface is public service interface that is used during the discovery process to dynamically fetch output parameters P O . We define it as: SX = (Σ, C) where Σ ⊆ (P I ∪ P O ) is the signature of symbols, i.e., input and output parameters from the domain ontology O; and C is a set of constraints. Constraints C must hold before the interaction with service endpoint can be started. The data-fetching interface represents a requestresponse interaction with the service endpoint. Listing 2, lines 14–22 shows an example of the datafetching interface. This data fetching interface is executed only if the the source country is Ireland and the destination is some European country (lines 17–19). Instances of ShippingPrice and ShippingDelivery concepts will be obtained from the service. Lowering definition in line 21 refers to the mapping from RDF to XML, while lifting definition in line 22 refers to the mapping from XML to RDF. Hard Constraints (SC ) specify constraints on a service us-

variant of

variant of

(e.g., FedEx Global Express) variant specific description

variant of (e.g., FedEx Global Express from: UK, to: Ireland, Weight = 15 kg, Insurance = 500 EUR, Price = 204 EUR, Delivery = 1 day)

Figure 1. Service Hierarchy  1 2 3 4 5 6 7 8 9 10 11

/∗Derived Parameter − price and delivery for addresses in Ireland∗/ :priceDeliveryIreland s:DerivedParameter; s:hasReqParam so:SourceAddress,so:TargetAddress,so:Package; s:hasProvParam so:ShippingPrice, so:ShippingDelivery; s:hasValue ”FILTER (?srcCountry = d:Ireland). FILTER (?trgCountry = d:Ireland). FILTER(?weight==12.0 && ?weight=30 && ?length