A Framework for Semantic Web Services Discovery
Jyotishman Pathak Neeraj Koul∗ Doina Caragea Vasant G Honavar Artificial Intelligence Research Laboratory Department of Computer Science Iowa State University Ames, IA 50011-1040, USA {jpathak, neeraj, dcaragea, honavar}@cs.iastate.edu
ABSTRACT looking them up in directories (e.g., Yellow Pages). Such This paper describes a framework for ontology-based flexible human-oriented service selection and utilization serve as mo- discovery of Semantic Web services. The proposed approach tivation for Web service discovery in a Service-Oriented Ar- relies on user-supplied, context-specific mappings from an chitecture (SOA) [12]. SOA supports a directory in which user ontology to relevant domain ontologies used to specify service providers can advertise their services in a form that Web services. We show how a user’s query for a Web service enables potential clients to find and invoke them over the that meets certain selection criteria can be transformed into Internet. The notion of Semantic Web services [15] takes queries that can be processed by a matchmaking engine that us one step closer to interoperability of autonomously de- is aware of the relevant domain ontologies and Web services. veloped and deployed Web services, where a software agent We also describe how user-specified preferences for Web ser- or application can dynamically find and bind services with- vices in terms of non-functional requirements (e.g., QoS) can out having a priori hard-wired knowledge about how to dis- be incorporated into the Web service discovery mechanism cover and invoke them. OWL-S [6] is a specific OWL [4] to generate a partially ordered list of services that meet user- ontology designed to provide a framework for semantically specified functional requirements. describing such services from several perspectives (e.g., dis- covery, invocation, composition). During the development of a service, the abstract procedural concepts provided by OWL-S ontology can be used along with the domain spe- Categories and Subject Descriptors cific OWL ontologies which provide the terms, concepts, H.3.5 [Information Storage and Retrieval]: Online In- and relationships used to describe various service properties formation Services—Web-based services (i.e., Inputs, Outputs, Preconditions, Effects or IOPE’s). In general, ontology-based matchmaking is used to discover and invoke service providers against a specific service re- General Terms quest [13, 17]. However, this approach suffers from several Design, Algorithms limitations. In a SOA, individual users or communities of users are expected to query for services of interest to them Keywords using descriptions that are expressed using terms in their own ontologies. But with proliferation of independently de- Semantic Web, Web Service Discovery, Ontologies, Quality veloped and deployed services, the semantic correspondences of Service between the user ontology on which the user queries are based and the domain ontologies on which the service de- 1. INTRODUCTION scriptions are based, are likely to vary. Consequently, users The creation, deployment, and use of services that meet ought to be able to specify inter-ontology correspondences to the needs of individuals and communities in virtually all ar- facilitate matchmaking between the service requests and ser- eas of human endeavor is one of the hallmarks of civilization. vice advertisements. Current approaches for describing ser- We select suitable service providers based on recommenda- vices on the Semantic Web (e.g., OWL-S [6]) do not support tions from friends, family, acquaintances or experts, or by for establishing semantic correspondences between ontolo- gies. Although lately, new frameworks such as, WSMO [7] ∗ Neeraj Koul is also affiliated with UGS Corporation, 2321 and WSDL-S [8], have been proposed to provide support North Loop Drive, Ames, IA 50010-8615 USA for the needed inter-ontology translation. Existing state-of- the-art technologies for publishing and finding web services (e.g., WSDL [5], UDDI [3]) use static descriptions of ser- vice interfaces. Consequently, they lack support for service Permission to make digital or hard copies of all or part of this work for selection based on non functional attributes such as Qual- personal or classroom use is granted without fee provided that copies are ity of Service (QoS). Some approaches to incorporation of not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to QoS criteria in service discovery lack support for dealing republish, to post on servers or to redistribute to lists, requires prior specific with semantic differences among independently developed permission and/or a fee. service specifications [21]. Finally, with the proliferation of WIDM'05, November 5, 2005, Bremen, Germany. Web services and service providers, it is inevitable that there Copyright 2005 ACM 1-59593-194-5/05/0011 ...$5.00. Class will be services offered by multiple providers with the same HomeDelivery functionality. In such scenarios, the users should be able to rank (or order) the discovered services based on some crite- subClassOf domain Class ria e.g., quality of service (QoS) ratings, cost, etc. However, FoodDelivery existing approaches for service selection [13,14,17] make no type String domain domain provision for user-specified ranking criteria as part of the DataTypePropery service request. ObjectProperty DataTypePropery ObjectProperty Has_ZipCode range domain Has_Item Has_Restuar Has_ShipAddr Against this background, this paper builds on the recent antRating ess domain domain range range range developments on Semantic Web services [15] and ontology- DataTypePropery type Class Class Has_Street based solutions for service selection [13, 14, 17] to develop domain FoodItem Integer DeliveryAddress an approach for discovery of Semantic Web services. In range particular, we allow the users to specify context-specific se- domain type String mantic correspondences between multiple ontologies to re- DataTypePropery DataTypePropery domain domain domain solve semantic differences between them. These correspon- Has_Name DataTypePropery Has_CityName dences are used for selecting services based on the user’s Has_Quantity range range DataTypePropery type functional and non-functional requirements, which are then range type String Has_AptNum ranked based on a user-specified criteria. String type Integer range The rest of the paper is structured as follows. Section ObjectProperty type 2 describes an example to provide a better formulation of Integer Has_CCInfo ObjectProperty the problem. In Section 3 we introduce interoperation con- range Has_CreditCard straints to specify mappings between the user ontologies and Class ObjectProperty range CreditCardInfo the domain ontologies used for service description, and a Has_CardNa domain service selection criteria, which provides a way to dynami- Class range me CreditCardType domain domain cally select and rank services based on functional and non- oneOf domain DataTypePropery functional aspects. Our prototype implementation is de- DataTypePropery oneOf Has_CardNu Class Has_CardHol scribed in Section 4. In Section 5 we discuss related work, derName m oneOf Discover DataTypePropery oneOf range and finally, we summarize our work in Section 6. Class range Has_CardEx Class type piryDate type AmericanExpress MasterCard String range Integer
2. MOTIVATING EXAMPLE Class type Suppose there exist community-based domain ontologies Visa MonthYear which describe various concepts and their properties for home delivery of food by different restaurants O (Fig- HomeDelivery Figure 1: Domain Ontology for Home Delivery of ure 1) and different types of Chinese food O (Fig- ChineseF ood Food ure 2). Now assume, there exists a Web service W1 which allows the users to order Chinese food for home delivery and uses the domain ontologies (Figure 1 & 2) to specify its ca- some kind of a mediator/service) to provide mappings or pabilities (i.e., IOPE’s) and the service it offers. W1 may ex- translations such that, the Web service discovery engine pect the name of the food item (where, the different types of can translate the concepts in the user’s request in terms of food that it serves is specified by OChineseF ood), user’s credit the concepts in domain ontologies, and hence, can select card information and delivery address as its inputs, and an candidate service providers (from some repository) by doing email confirmation might be sent upon successful completion matchmaking. U of the order (its outputs). In addition, sufficient credit bal- For example, the user ontology ODelivery might have a ance and a valid delivery address could be the pre-requisites concept Food, which could be mapped to concept F oodItem for invoking the service (its preconditions), whereas, charg- in the domain ontology OHomeDelivery. Similarly, a con- U ing the credit card for the appropriate amount of money cept Chicken (in OChinese) might have a correspondence and delivering the ordered food (via some delivery person- to Poultry (in OChineseF ood). The user might also define nel), the effects after a successful invocation of the service procedural mappings between the domains of various con- (its postconditions). Similarly, another Web service W2 may cepts (e.g., from YY-MM to MM-YY). Furthermore, the also provide the same service for home-delivery of Chinese user might want to select those services which have a higher food and use the domain ontologies to describe its capabil- customer service rating and rank the discovered candidate ities. However, it might have a different customer rating or service providers based on some criteria (e.g., increasing items that are being served. physical distance of the restaurant from the delivery loca- ′ Now, suppose there exists a user U, who wants to order tion). Similarly, another user U , with different ontologies, some Chinese food from his/her home via the Internet (us- willing to order Chinese food via the Internet for home de- ing some agent). It is quite conceivable that the user might livery has to follow the same procedure as U. have his/her own understanding of the domain in discourse Thus, discovering of Semantic Web services comprises of U U and hence have user ontologies, ODelivery and OChinese, two important steps: which might be different from the shared domain ontolo- • Specifying mappings between the terms and concepts O O gies, HomeDelivery and ChineseF ood. In such a situation, of the user ontologies and the domain ontologies (which it is not possible for the user’s agent to discover candidate are used to describe the services). services from a repository because the concepts in the dif- ferent ontologies may be semantically different. To reconcile • Specifying a service selection criteria which uses such semantic heterogeneity, there is a need for the user (or the mappings to select candidate service providers against Class of Interoperation Constraints (IC) the set of relationships Food
ObjectProperty ObjectProperty that exist between elements from two different hierarchies. Has_Gravy Is_Spicy range H1 H2 range subClassOf For two elements, x ∈ and y ∈ , we can have one of domain domain the following Interoperation Constraints:- x : H1 =y: H2, Class Class Class 1 2 1 2 1 2 ChineseFood oneOf Gravy x : H 6= y : H , x : H ≤ y : H , and, x : H 6≤ y : H . Spicy oneOf For example, in the Chinese food domain, assuming that the oneOf Class U oneOf Class oneOf ontologies OChinese and OChineseF ood associate is-a order- No Class Yes oneOf Class Class ings to their corresponding hierarchies, we can have the fol- Hot subClassOf subClassOf Class SomeWhat None lowing interoperation constraints, among others- Chicken : Mild subClassOf subClassOf U U HChinese = Poultry : HChineseF ood, F ish : HChinese = U SeaF ood : HChineseF ood, Chicken : H 6= Appetizer : Class Class Chinese Appetizer Vegetables HChineseF ood, and so on.
Class Class oneOf oneOf oneOf Poultry SeaFood Class 3.2 Service Selection Criteria oneOf Class MouShu oneOf CrabRangon oneOf oneOf oneOf oneOf The service selection criteria in our framework comprises oneOf Class Class Class oneOf oneOf ShrimpToast Class Class JumboShrimpC FriedSalmon Class of two components: Selection of the service providers and ChickenWings SesameChicke urry GreenSautedB n eans then, Ranking the selected providers. Class Class Class Class SzechaunChick DicedChicken AngryCatFish BuddhistDelight en 3.2.1 Service Selection The first step in service selection is to determine a set of Figure 2: Domain Ontology for Chinese Food service providers which offer the requested functionality. We call this set as candidate service providers. Definition (candidate service providers): Let S = {S1,··· , a service request query and rank/order them based on Sn} denote the set of services which are available (or regis- ′ user-specified ranking criteria. tered with our system). We call, S ⊆ S, the set of candidate providers, if they meet the requested functional properties 3. DISCOVERING SEMANTICALLY HET- of the user (in terms of IOPE’s). EROGENEOUS WEB SERVICES In general, some services will match all the requested IOPE parameters, while others will not. To distinguish 3.1 Ontologies and Mappings between them, we categorize them based on the degree of An ontology is a specification of objects, categories, prop- match [13, 17]: Exact, Plug-in, Subsumption, Intersection, erties and relationships used to conceptualize some domain and Disjoint. Such a categorization also provides an (im- of interest. We introduce a precise definition of ontologies plicit) ranking amongst the potential providers (e.g., Exact as follows. match is given the highest rank). Since, the set of services Definition (hierarchy) [11]: Let S be a partially ordered which fall under Intersection and Disjoint categories do not set under ordering ≤. We say that an ordering ¹ defines a match the service request (in terms of functional aspects), hierarchy for S if the following three conditions are satisfied: we ignore them for the rest of the service selection process and only consider the services which belong to Exact, Plug- (1) x ¹ y → x ≤ y; ∀ x, y ∈ S. We say (S, ¹) is better in and Subsumption categories. than (S, ≤)), The second step in the service selection process further refines the set of candidate service providers based on user- (2) (S, ≤) is the reflexive, transitive closure of (S, ¹), specified non-functional attributes, namely Quality of Ser- (3) No other ordering ⊑ satisfies (1) and (2). vice (QoS). In unison with [19], we define Quality of Service as a set of non-functional attributes that may impact the An ontology associates orderings to their corresponding hi- service quality offered by a Web service. Because, Web ser- erarchies. For example, let S = {Food, ChineseFood, Appe- vices are distributed as well as autonomous by their very tizer} (Figure 2). We can define the partial ordering ≤ on nature, and can be invoked dynamically by third parties S according to an is-a (or sub-class) relationship. For exam- over the Internet, their QoS can vary greatly. Thus, it is ple, Appetizer is-a sub-class of ChineseFood, ChineseFood is- vital to have an infrastructure which takes into account the a sub-class of Food and, also Appetizer is-a sub-class of Food. QoS provided by the service provider and the QoS desired by Besides, every class can be regarded as a sub-class of itself. the service requester, and ultimately find the (best possible) Thus, (S, ≤) = {(ChineseFood, ChineseFood), (Appetizer, match between the two during service discovery. Appetizer), (Food, Food), (Appetizer, ChineseFood), (Appe- However, different aspects of QoS might be important tizer, Food), (ChineseFood, Food)}. The reflexive, transi- in different applications and different classes of web ser- tive closure of ≤ is the set: (S, ≺) = {(ChineseFood, Food), vices might use different sets of non-functional attributes (Appetizer, ChineseFood)}, which is the only hierarchy as- to specify their QoS properties. For example, bits per sociated with (S, ≤). second may be an important QoS criterion for a service In order to make ontologies interoperable, so that the which provides online streaming multimedia, as opposed to, terms in different ontologies are brought into correspon- security for a service which provides online banking. As dence, we need to provide mappings. These mappings are a result, we categorize them into: domain dependent and specified through interoperation constraints. domain independent attributes. As an example, Figure 3 Definition (interoperation constraints) [11]: Let (H1, shows the taxonomy that captures the QoS properties of ¹1) and (H2, ¹2), be any two hierarchies. We call a set those restaurant Web services which provide home deliv- ery. The domain-independent attributes represent those one or more services which satisfies user’s constraints (in QoS characteristics which are not specific to any particu- terms of IOPE’s) and has an overall score (for the non- lar service (or a community of services). Examples include functional attributes) greater than some threshold value spec- Scalability, Availability etc. A detailed list and expla- ified by the user. If several services satisfy these constraints, nation about such attributes can be found in [19]. On the then they would be ranked according to the user-specified other hand, the domain-dependent attributes capture those ranking criteria (section 3.2.2). But, if no service exist, then QoS properties which are specific to a particular domain. an exception is raised and the user is notified appropriately. For example, the attributes Overall RestaurantRating, For example, let S = {S1,S2,S3} be the set of candidate ser- PresentationDecor etc. shown in Figure 3 correspond to vice providers which match the requested IOPE’s. Assum- the restaurant domain. As a result, the overall QoS taxon- ing, that the user is interested in attributes Scalability omy is flexible and enhanceable as different service providers and Availability, let the quality matrix be: (or communities) can define QoS attributes corresponding to S1 S2 S3 their domain. However, in certain cases, a user might consider some Q = Scalability 0.90 0.80 0.30 non-functional attributes valuable for his/her purpose (and Availability 0.90 0.45 0.20 hence, defined in the user ontology), instead of all the at- Further assuming that, the user specifies W eightScalability tributes in the QoS taxonomy (Figure 3). We use those = 0.80, W eightAvailability = 0.50, and threshold score value, attributes to compose a quality vector comprising of their UT hreshold = 0.50, only S1 and S2 will be selected (after values for each candidate service. These quality vectors are calculation of their respective fQoS scores). used to derive a quality matrix, Q. Definition (quality matrix): A quality matrix, Q = {V (Qij ); 3.2.2 Service Ranking 1 ≤ i ≤ m; 1 ≤ j ≤ n}, refers to a collection of quality In a real world scenario, given a service request, it is con- attribute-values for a set of candidate services, such that, ceivable that there exist scores of service providers, which each row of the matrix corresponds to the value of a par- not only satisfy the functional requirements of the requester, ticular QoS attribute (in which the user is interested) and but also the non-functional requirements. As a result, it is each column refers to a particular candidate service. In other th of vital importance to let the requesters specify some rank- words, V (Qij ), represents the value of the i QoS attribute ing criteria (as part of the service request query), which for the jth candidate service. These values are obtained from would rank the retrieved results (i.e., the list of potential the profile of the candidate service providers and mapped to service providers). The traditional approach for ranking the a scale between 0 & 1 by applying standard mathematical results of matchmaking is completely based on the degree of maximization and minimization formulas based on whether match [13, 17] between the profiles of the service requester the attribute is positive or negative. For example, the val- and service provider. In our framework also, we use de- gree of match to categorize (and implicitly order) the set Class of candidate service providers based on the functional re- subClassOf QualityOfService subClassOf quirements of the user. We further refine each category and Class Class select only those candidate service providers which satisfy DomainDependent DomainIndependent the non-functional requirements of the user.
subClassOf Although this is beneficial, we believe the requester should subClassOf Class have additional capabilities to specify personalized ranking Class Scalability OverallRestaurantRating criteria as part of the service request query. For example, Chinese food restaurants which may not have the highest quality ratings for food tastiness, but provide speedier home Class subClassOf Class subClassOf Availability delivery, may be of higher value for a person who is in hurry PresentationDecor Class Class (and hence wants faster food delivery), compared to a food Class Latency Throughput connoisseur, who will have a preference for tastier food. As subClassOf Performance a result, the former user would want to rank the candi- subClassOf subClassOf date service providers based on their promptness of delivery, whereas the later would prefer to have the service providers Figure 3: Sample QoS Taxonomy ranked based on the quality of food they serve. To achieve this, we introduce the notion of ranking at- ues for the attributes Latency and Fault Rate needs to be tributes and a ranking function (based on those attributes), minimized, whereas Availability needs to be maximized. which will be used to rank the selected candidate service Also, to give relative importance to the various attributes, providers. Once the service providers are ranked, it is left the users can specify a weight value for each attribute, which at user’s discretion to select the most suitable provider (e.g., are used along with the QoS attribute values to give rela- the user may do some trade off between the services which tive scores to each candidate service using an additive value meet all the non-functional requirements, but not all the function, fQoS . Formally, functional requirements exactly). Definition (ranking attributes): The set of ranking at- m tributes, RA, comprises of all the concepts (its sub-concepts, fQoS (Servicej ) = (V (Qij ) × Weight ) (1) X i properties) in the domain QoS taxonomy which have corre- =1 i spondences (via interoperation constraints) to the concepts where, m is the number of QoS attributes in Q. in the user ontology, OU , that capture the non-functional For a particular service request query, our system selects aspects/requirements of the user. For example, if OU has a QoS concept ServicePerformance which has a correspon- are stored in the JESS KB, they are evaluated during the dence to the concept Performance in the domain QoS taxon- matchmaking process against a service request. omy (Figure 3), then {Performance, Throughput, Latency} The Service Requester specifies a request for service se- ∈ RA. lection using the Service Requesting API. Such a request Definition (ranking function): Let S represent the set is described using OWL-S. The requester also specifies the of candidate services which match the functional and non- interoperation constraints (ICs) between the terms and con- functional requirements of the user, x ∈ RA is the ranking cepts of its ontologies to the domain ontologies. These on- attribute, and RO ∈ {ascending, descending} is the rank- tologies along with the set of ICs are stored in the Ontology ′ ing order, then: fRank(S,x,RO) = S , is called the ranking Database. For our first prototype, the constraints are defined ′ function, which produces S , the ordered set of candidate manually. However, we are working towards incorporating services. For example, let S = {S1,S2} be the set of ser- (semi) automatic approaches for specifying such correspon- vices selected based on the desired QoS properties (from dences [10]. With the help of these translations, the ser- the previous section/example), x = {Cost}, and, RO = vice requesting API transforms the requester’s query, into a {ascending}. Assuming, Cost of S1 is more than S2, we domain-specific query. In other words, the API transforms ′ have, fRank(S,x,RO) = {S2,S1} = S . the original service request description (using the terms and concepts from the user ontology) into a pseudo description 4. PROTOTYPE IMPLEMENTATION (using the terms and concepts from the domain ontologies). These descriptions are also translated into JESS facts and rules (as described above). The matchmaking engine then
JESS KB tries to find service advertisement(s) which match the user’s request. The matchmaking algorithm that we implemented Service Registry is based on [17]. This algorithm typically uses subsump- tion reasoning to find similarity between service advertise- Matchmaking Engine ments with the requests based on the match between inputs (based on Jess & Jena) and outputs. We extend their algorithm2 by incorporat- Service Registering / Requesting API ing semantic matching based on service category, precon- ditions and effects (apart from inputs and outputs). Each
Ontology of these matches are individually scored and the results ag- Service Registration using Service Querying using Database, OWL-S Descriptions OWL-S Descriptions Mapping gregated to determine a set of candidate service providers Storage (Section 3.2.1), which are then categorized based on their degree of match. These candidate service providers (for each Service Provider Service Requester Specify Mappings between the Ontologies category) are further refined based on whether they satisfy the non-functional requirements of the requester and then ranked on some user-specified ranking criteria (if any), e.g., Figure 4: Framework for Semantic Web Services physical distance between the requester and the service. Fi- Discovery nally, the user selects a service provider (from the ordered list of services) using his/her prudence. Figure 4 shows a simple architecture of our prototype im- plementation1 for discovery of Web services over the Se- mantic Web. Initially, the Service Providers advertise their 5. RELATED WORK services (namely, profile, process, grounding in OWL-S [6] Recently, there have been a few proposals for Web ser- terminology) with the Service Registry. This registry serves vices discovery based on OWL ontologies [14, 15] and De- 3 as a repository for the service advertisements, against which scription Logic [13,17] inferences . Sycara et al. introduced the service request queries are matched. At the time of reg- LARKS [20] for describing agent capabilities and requests, istration, the Service Registering API parses the OWL-S de- and their matchmaking. The discovery/matching engine of scriptions (by using Jena [1]) and converts an OWL ontology the matchmaker agent is based on various filters of differ- into a collection of JESS [2] facts, which are stored as triples ent complexity and accuracy which users can choose. How- (i.e., < Subject, P redicate, Object >) in the JESS KB. The ever, the model lacks in defining how service requests will JESS reasoning engine can infer more facts to ensure that all be specified by users. Also, LARKS assumes the existence the