A Pragmatic and Pervasive Methodology to Web Service Discovery

A Pragmatic and Pervasive Methodology to Web Service Discovery Electra Tamani and Paraskevas Evripidou University of Cyprus, Department of Computer Science 75 Kallipoleos St., T.K. 537, 1678 Nicosia, Cyprus

Abstract. Service-Oriented computing can be characterized as the motivating force for interoperable web applications. Businesses that embark on service-oriented technology are inclined to an effective interoperation with other businesses. This interoperation not only can expand businesses’ markets but also allow the provision of quality services to citizens for carrying out their everyday transactions. However for an effective utilization of service-oriented computing a variety of other technologies must be involved namely semantics, pragmatics, effective search techniques, intelligent agents and pervasive services. In this paper we focus in one of the phases of service-oriented computing, the web service discovery, and propose an effective pragmatic and pervasive methodology that will enable potential business partners to discover the web services1 /processes of their interest. We are particularly emphasizing on the importance of pragmatics and their application during web service discovery, because only a pragmatic consideration can provide complete and unambiguous meaning to web service usage.

1

Introduction

As the title implies, Service-Oriented Computing is a computing technology based on services. The underlying architecture in a Service-Oriented environment, known as SOA2 , expresses a perspective of a software architecture that facilitates services to support the requirements of software users. In a SOA environment, network resources are deployed as independent services, usually based on Web Services standards, that can be accessed without knowledge of their underlying platform implementation. Web Services have become the de facto standard for interoperability and the technology for building distributed web applications capable of achieving seamless business-to-business or enterprize application integration. Businesses that embark on service-oriented technology are inclined to an effective interoperation with other businesses which eventually will not only allow them to expand their markets but also provide quality services to citizens for carrying out their everyday transactions. 1 2

The term web services, as in this paper, is used to refer to semantic web services. Service-Oriented Architecture.

R. Meersman, Z. Tari, P. Herrero et al. (Eds.): OTM Workshops 2006, LNCS 4278, pp. 1285–1294, 2006. c Springer-Verlag Berlin Heidelberg 2006

1286

E. Tamani and P. Evripidou

However in order for businesses to exploit the full potential of service-oriented technology, they must first be in place of discovering effectively each other’s business services. Web service discovery, is one of the phases of service-oriented computing towards this direction. During this phase the closest3 to the requestors’ context services are retrieved. Latest research motives are emphasizing the need for semantic enhancements, through ontologies usage4 , to a web service life-cycle process in order to facilitate an efficient discovery of web services by prospective business partners. These ontologies however, as pragmatists’ argue, should not, as they are, be exploited as fixed conceptualizations of some domains but rather as dynamic structures which co-evolve with their communities of use[4,10]. Business parties have to communicate and continuously negotiate about what they agree to be their shared background/context[4]. This communication is especially important across organizational boundaries where business parties from different professional, social, or cultural backgrounds need to understand each other in order to collaborate effectively. Therefore, semantics alone can be judged as insufficient in providing effective solutions for collaborative businesses[13]. In this paper, we recognize this limitation and propose a pragmatic approach/ methodology to web service discovery which captures the context of web services’ usage by considering the context of the interacting business parties. We distinguish three types of business collaborators: 1) the provider or the business which provides the web services of some area, 2) the requestor or the business which requests for the discovery of some web services of a specific area, and 3) the provider-requestor or the business which both provides web services but also requests some others. We are considering pervasive solutions that facilitate mobile devices5 , by capturing the context of the interacting business parties in an effective way. We demonstrate the effectiveness of our methodology through an example. The rest of the paper is organized as follows: Section 2 elaborates on the types/roles of business collaborators and their actions in web service discovery. Section 3 introduces the pragmatic methodology that captures the pragmatics (context) of web services’ usage. In Section 4 we consider a pervasive approach which allows business collaborators to define their context. Section 5 presents a realistic example to prove the effectiveness of our methodology. Section 6 introduces related work. Finally, we conclude in Section 7.

2

The Collaborators

The types of the collaborators considered in this paper are grouped into three categories as follows: – Provider : represents the business which provides the web services in order to facilitate collaboration with other businesses and expand its markets. 3

4 5

The term closest is used to refer to those offered web services that have the higher matching degree with those requested. Knowledge repositories of meaningful and structured content. Laptop, handheld.

A Pragmatic and Pervasive Methodology to Web Service Discovery

1287

Table 1. Collaborators’ Actions Type/Role Provider Requestor Provider-Requestor

Actions offer demand offer,demand

Description provision of web service/s request for web service/s provision and request of/for web service/s

– Requestor : represents the business which requests the discovery of web services to exploit them according to its organizational needs/interests. – Provider-Requestor : represents the business which both provides and requests web services from other businesses in order to fulfil its organizational goals. Potential interest for specific retrieved web services from the requestor suggests entering into a commitment with the provider and together they collaborate to achieve a mutual goal which will benefit both of them. Collaborators enact their roles by taking the actions listed in Table 1. As indicated in the table, the role of each collaborator determines the action to be performed. Providers offer the web services the requestors demand. A provider can only offer web services or both offer and demand web services. Similarly a requestor can only demand web services or both demand and offer web services. Let us now see how these roles and actions of collaborators are utilized during web service discovery process.

3

The Pragmatic Methodology to Web Service Discovery

As already indicated, the semantics alone are judged as insufficient in providing effective solutions for collaborative service-oriented businesses[13]. This limitation is particularly evident in web service discovery phase where the most relevant web services (to the requestor context) are retrieved. To backup semantic’s approach insufficiency, let us consider things from the beginning. During web service discovery the question to be answered is whether the offered web service is suitable to fulfill the requested web service needs. Prior to semantic web evolution the offer and request service descriptions were purely message-based, a solution that allowed the usage of rather simplistic matching algorithms (keyword-based search, type-based matchers). The problems with this approach were: – Semantics clarity: the functionality of a web service had to be guessed from the flow of information, a situation that complicated the automatic selection of web services – Strict message compatibility: if messages between provider and requestor did not match, then the service could not be used

1288


Once researchers have identified these limitations, they proposed semantic solutions to web service description. Particularly, OWL-S (Ontology Web Language for Services) group is developing the tools and the technology to enable automation of services on the semantic web. OWL-S is mainly an OWL-based web service ontology which binds operations, inputs, outputs, preconditions, and effects to the corresponding WSDL parts[8]. The OWL-S matchmaker facilitates a matchmaking algorithm for matching two descriptions (offer and request) and identifying the different relations between the two descriptions (match,no match). On the other hand, the WSDL-S (Web Service Semantics) group is suggesting extensions to the current web service description langauge by adding ontology (OWL) references to operations, inputs, and outputs[9]. The matcher facilitated in this case is a combination of two types of matching algorithms (element level and schema) which complement one another in order to find all possible mappings between WSDL and ontology concepts. Finally WSMO (Web Service Modeling Ontology)6 group is developing a conceptual model for the description of semantic web services together with a family of underlying formal languages and an execution environment. Similar to OWL-S matchmaker, WSMO differentiates between different types of matches (exact-match, subsumes-match, plug-in-match and intersection match). In all these semantic solutions, the semantic meaning resolution between the offer and request service descriptions is left completely to the matcher. Let us assume that a generic enough matcher that captures all possible paths to meaning resolution exists. Even if that was the case, our matcher would have dramatically failed when a web service, designed to be used for a completely different situation than that the requestor needed (assuming a successful meaning resolution at every aspect), is selected as compatible. In order for the semantic web to reach its full potential, collaborators must communicate and continuously negotiate about what they agree to be their shared background/context. For this reason ontologies should not be exploited as fixed conceptualizations of some domains, as they are, but rather as dynamic structures which co-evolve with their communities of use. To overcome the problems of the semantic approach during the web service discovery, we propose a pragmatic methodology which captures the context of web services’ usage. According to this methodology, the context of web services’ usage can be determined by considering the context of collaborators themselves. We argue that the context of collaborators must be well defined at the time of offer/demand definition for web services. The methodology we propose to model the context of collaborators is through the exchange of some standard XML-based message types that are to be interpreted identically by all collaborators. Each message, which may be thought of as an object (in the sense of object-oriented programming), has a performative (which may be thought of as the class of the message) and a number of context parameters (attribute/value pairs, which may be thought of as instance variables). The performatives are the permissible actions the collaborators can 6

http://www.wsmo.org


1289

Table 2. The structure of the messages exchanged Performative offer demand offer-demand

Context Parameters who, why, what who, why, what who, why, what

Structure : offer(who, what, why) : demand(who, what, why) : offer-demand(who, why, what)

perform as those have been defined in Section 2. The context parameters, on the other hand, are the content of these actions i.e what is being offered and requested respectively along with some other parameters regarding personal information of the collaborator i.e identity, background information, interests etc. The structure of the messages exchanged along with their context parameters and explanations are listed in Tables 2 and 3 respectively. In this paper we present only those context parameters required. In a later section, we will see how these messages are used through an example. Table 3. Parameter format and meaning Parameter who why what

Sub-Parameters identity, role purpose, goal input/s, output/s

Meaning identity and role of the initiator purpose(and/or interest/s) and goal/s of initiator semantic web service input/s and output/s

The matching process that occurs between the request and the offer first matches the “what” (i.e the semantic input/output parameters) and then the “who” and “why” parameters respectively. This matching process complicates the existing semantic matching algorithms (the “what”) by taking into consideration additional context parameters (the “who” and the “why”) in order to achieve complete and unambiguous matching.

4

Capturing the Context of Collaborators

As already mentioned, pervasive solutions will be facilitated for capturing the context of the collaborators. These solutions will allow collaborators to define their (offer/demand) context through a web site that can be accessed from any internet-enabled desktop machine or mobile device. Due to portability constraints the web site will be kept as simple as possible with a user-friendly interface. In this paper instead of presenting the interface, which is rather simplistic and straightforward to conceive, we show the XML messages format/structure (shown below). We demonstrate examples of the XML messages when we consider our pragmatic scenario later on in this paper.

1290


* *

5

A Pragmatic Scenario

Let us realize the effectiveness of the methodology we propose through an example. Assume that there exists a WYW=WTO (What You Want = What They Offer) broker service that is responsible for the searching and the matching. When a request is received, the broker service searches for web services that meet the request requirements and hands the results to the requestor. During this searching, the matching algorithms applied might also reference trusted ontologies7 (if required) to resolve conflicts. Consider a scenario where a lo-

Fig. 1. A pragmatic scenario

cal government has assigned to a software company the development of a local travel guide in order to better assist tourists when visiting the country and thus increase tourists’ interest for that country. The software company decides to invest in service-oriented technology in order allow easy integration with external/internal businesses. The company seeks to find web services that offer the functionality required for a travel guide to become a reality. Specifically the travel guide is aimed to provide services for accommodation and events lookup, map driving directions etc. Let us consider the accommodation provision for the sake of this example. 7

Ontologies with good reputation values.


1291

Assume that the software company initiates the following request r: “I want a web service that provides me with a hotel list (or1 , or1uri ) given hotel search criteria (ir1 , ir1uri ) to (irn , irnuri )” (where or = request output, ir = request input). Also assume that there exist a local tourism organization and local football federation that provide exactly the desired functionality (refer to Figure 1). In the first case all the hotels available to tourists that match the search criteria are retrieved but in the second case only those hotels that both match the search criteria and have special arrangements with the local football federation to host players are retrieved. Which of the two web services should the matcher/broker select? Unavoidable, automatic selection can be error-prone in this situation where the context of a web service usage is not determined beforehand. The methodology we proposed in this paper solves this problem by considering the context of web service usage. This is accomplished by capturing the context of collaborators in an offer-request service exchange. Let us therefore revisit the above example by considering the context of collaborators as this is defined in Section 3. As table 4 shows the request for a web service that provides a hotel list given n hotel search criteria matches exactly two offers (URI is the semantic annotation of the WSDL part which references an ontology concept). In contrast to before the matcher/broker has additional information to check and therefore extract the offered service that best matches the request. In this case since the requestor targets the service for tourists’ usage, it is clear that the local tourism organization offer is the one that best matches the request. Therefore the matcher automatically selects the web service offer of the local tourism organization. The XML messages exchanged during the web service discovery of our example, are are shown below.

1292

E. Tamani and P. Evripidou Table 4. Offer and Request messages

Type offer :

Message Content who (identity: X, role: provider, local tourism organization), why (purpose: tourists assistance, goal: inform tourists about local hotels), what (input: (hotel search criteria, uri X), output: (hotel list, uri Y)) offer : who(identity: X, role: provider, local football federation), why (purpose: football teams assistance, goal: inform football teams about hotels committed to host football players), what (input: (hotel search criteria, uri X), output: (hotel list, uri Y)) request: who (identity: X, role: requestor, software company), why (purpose: fulfil government assignment, goal: development of local travel guide for tourists), what (input: (hotel search criteria, uri X), output: (hotel list, uri Y))

6

Related Work

The idea of this paper is inspired from Pragmatic Web principles as these have been defined in [4]. The Pragmatic Web is a new research direction which aims to extend the Semantic Web by capturing the context of ontologies’ usage, from the participants’ point of view, in a given communication process. Pragmatic Web research is still in its first stages and nobody knows the direction it will go yet. With the few knowledge we currently possess in that area, we think that the methodology we propose differentiates from Pragmatic Web’s patterns in the fact that it captures the context of web services usage (pragmatics) instantly instead of acquiring it periodically (by continually interrupting the collaborators). The methodology we propose to model the context of collaborators is an exchange of some standard XML-based message types which are interpreted identically by all collaborators. This methodology possess similarities with the Knowledge Query and Manipulation Language (KQML)[18] in the sense they are both message-based. They are both utilizing performatives and context parameter constructs but they differ in the language action perspective and purpose of use. KQML is a message-based langauge for agent communication in contrast to our methodology which is intended for capturing the context of collaborators during web service discovery. Another similar approach with our methodology is the one that the CORBA (the predecessor of web service technology) Trader service facilitates. The Trader service, as in our case, provides location and discovery facilities to requestors. In contrast to our methodology, the CORBA Trader service: 1) maintains a repository where the offered objects are advertised instead of allowing each provider to maintain its own repository, 2) matches the objects against the service type and the characteristics instead of the semantic input/ouput parameters and the context, and 3) returns all possible matchings (in order) instead of the one with the highest value.


7

1293

Conclusion

In this paper we have proposed a pragmatic methodology to web service discovery which captures the context of web services’ usage by considering the context of the collaborators. We have identified three types of business collaborators and presented their roles and actions. Based on these actions we presented the methodology we used to model the context of collaborators and demonstrated its effectiveness through a realistic example. Finally we have shown how pervasive solutions can be facilitated in capturing the context. Limitations of our approach currently lay in the specification of user-defined context, the context parameters list and the frequency of context capturingmatching. In the future we will consider approaches for deriving user context automatically, through the usage some sensor devices, in addition to the userdefined context approach proposed in this paper. Moreover we aim to consider more context parameters when capturing collaborators’ context and possible transformation of our methodology into a full-blown language if that is judged necessary. Finally we will consider introducing multiple rounds of the (offer and request) context capturing-matching so that the maximum desired effect is achieved.

References 1. Alan Cruse : Meaning in Language: An introduction to Semantics and Pragmatics. 2000 2. R. McCool: Rethinking the Semantic Web, Part I. IEEE Internet Computing. 2005 3. A. De Moor: Making Doug’s Dream Come True: Collaborations in Context. 2002 4. A. De Moor: Patterns for the Pragmatic Web (invited paper). 13th International Conference on Conceptual Structures (ICCS 2005). Kassel, Germany.July.2005. 5. Tom Gross and Roland Klemke: Context Modelling For Information RetrievalRequirements and Approaches. 2003 6. K. Jaszczolt: Semantics and Pragmatics: Meaning in Language and Discourse.2002 7. Geoffrey Leech: Principles of Pragmatics.1983 8. David Martin and Massimo Paolucci and Sheila MacIlraith and Mark Burstein and Drew McDermott and Deborah McGuiness and Bijan Parsia and Terry Payne and Marta Sabou and Monika Solanki and Naveen Srinivasan and Katia Sycara: Bringing Semantics to Web Services: The OWL-S Approach.2004 9. Rama Miller and Joel Farrel and John Miller and Meenakshi Nagarajan and MarcThomas Schmidt and Amit Sheth and Kunal Verma: Web Service Semantics WSDL-S. IBM and University of Georgia. April.2005 10. Jacob L. Mey:Pragmatics: an introduction.Blackwell.1993 11. Stuart Russel and Peter Norvig: Artificial Intelligence: A Modern Approach. Pretnice Hall.2003 12. Munindar P. Singh and Michael N. Huhns: Service-Oriented Computing. Willey. 2005.410–495 13. Munindar P. Singh:The Pragmatic Web: Pleliminary thoughts. NSF-OntoWeb Workshop on Database and Information Systems Research for Semantic Web and Enterprises.April. 2002. 82–90

1294


14. Aida Jertila and Mareike Schoop: The Language-Action Perspective and the Semantic Web A Language-Action Approach to Electronic Contracts. The Language Action Perspective on Communication Modelling.2005 15. Amit Sheth and Kunal Verma and John Miller and Preeda Rajasekaran: Enhancing Web Service Descriptions using WSDL-S.2005 16. Electra Tamani and Paraskevas Evripidou: Applying Trust Mechanisms in an agent-based P2P Network of Service Providers and Requestors. Sixth IEEE International Symposium on Cluster Computing and the Grid Workshops (CCGRIDW’06). 2006.13 17. Ken Turner: Semantics vs. Pragmatics.Handbook of Pragmatics.1997 18. Michael Wooldridge: MultiAgent Systems. Willey. 2005