Basically, this research intends to select web services taking part in composition ... The policy of service providers is represented and reasoned by SWRL language. ... Each property acts like a function in mathematics, so it has a domain and a range. ... conditions or constraints to choose the best web service for each node.
IADIS International Conference WWW/Internet 2008
POLICY-BASED DYNAMIC SERVICE COMPOSITION Mehrdad Rahimi Ms Student of Computer Engineering Isfahan University
Farhad Mardukhi PhD Student of Computer Engineering Isfahan University
Naser Nematbakhsh Assistant professor of Computer Engineering ISfahan University
ABSTRACT Dynamic service composition aims to create value-added services by selecting and combining existing services properly on demand. Basically, this research intends to select web services taking part in composition attention to both user query and service provider policy. The policy of service providers is represented and reasoned by SWRL language.
1. INTRODUCTION Web services nowadays are an important issue. One of the reasons that make the web services dominant is its ability to create the virtual organizations. Some of the advantages of virtual organization consist of capability of access to its services remotely, improvement of performance, increasing the quality and so on. Service composition is cost-effective process that composes some low value services in order to create a high value service which has some capabilities that none of those low value services have [1]. Service composition helps to create virtual organization, because organizations are composed of some sets of services work together. The purpose of this paper is to present a service composer with two simultaneous characteristics. The first characteristic is that the composer acts dynamically; it means it composes the services based on user’s needs and requisites in runtime. And the second one is that the composition must be based on the policies of organizations which their web services might participate in final composition.
2. POLICY REPRESENTATION One of the goals of this paper is to introduce a simple and near to life method for representing policies in web services especially for organizations. In this paper we use a language called SWRL (Semantic Web Rule Language) to represent the rules or policies. The SWRL is a combination of RuleML[3], and OWL languages. As you know OWL is a language for creating the ontology in web. One of the reasons for choosing this language is that the organizational policies is enacted by people and is expressed by human languages, so if you want to represent them for computer to recognize and then deduce on them, you have to use ontology. Assume an organization want to elicit the family relationships among people in one city. Also assume this organization has stored the personal information of those people including first name, last name and etc. in an ontology structure like below: People Ontology: Class Person SubClass Male SubClass Female
Properties: Domain Range isFather: Male ------------> Person isMother: Female----------> Person isChild: Person----------> Person isBrother: Male ------------> Person
559
ISBN: 978-972-8924-68-3 © 2008 IADIS
As you can see this organization put people in a global class called “Person”, and of course this class is divided to “Male” and “Female” subclasses. The properties in above structure show the family relations between people. Each property acts like a function in mathematics, so it has a domain and a range. It means this function makes a relation between one member of its domain with one member of its range. For example the “isFather” property, makes a relation between one member of “Male” and one member of “Person” class. In other words, one member of the “Male” class can be the father of one member of the “Person” class. Now assume we want to present a rule, so that the system can extract the uncle of each person. This rule will be like this in human language: “If someone’s father has a brother, that brother is that someone’s uncle”. The SWRL format of this rule is like this: Person(?x) Π isFather(?y,?x) Π isBrother(?y,?z)-> isUncle(?z,?x) After the execution of this rule the information of all person`s uncle will be added to the knowledge base. With SWRL language you can learn and complete your knowledge base. But it is not enough. The next step after creation and learning your knowledge base is choosing a method to query your knowledge base. In this paper we use SQWRL (Semantic Query Web Rule Language) [4] which is a language to query in semantic web. The SQWRL is an extension of SWRL which adds the capability of query to the knowledge base by SWRL syntax. For example if you want to have a list of all persons and their uncles in the previous ontology, it would be enough to put this query in ontology as a rule and then execute it: Person(?x) Π isUncle(?x,?y)-> sqwrl:select(?x) Π sqwrl:select(?y) The SQWRL language has a structure like SQL and returns the results as a semi table to the user.
3. DYNAMIC REPRESENTATION Dynamic composer creates the composition in runtime. In static composer the composition is created in design time. We can look at dynamic method from several points of view. One of them is that the web services may become unavailable or stop serving during the time. In this situation the alternative web services should be used, and of course if the static methods is being used the composition should be designed from the beginning. It is not cost-effective and sometimes impossible. Another point of view is that in some cases you have to pay money to use the web services. Usually the same web services may have different prices. Also not all customers want to pay the same amount of money. So if you use the static composers, it is impossible to customize the composition for each person justifies the money they pay. Other reasons for using dynamic composers are the heterogeneous resources, mobility of resources and users, and localized services [6]. In our method the result composition will be a graph, which is not created in design time, but it is created during recognizing and interpreting the characteristics of each user’s request. Creating the composition graph consists of two levels: a. Creating Abstract Graph: In this level a graph will be created according to the user’s request, which each node of that graph represents one specific service type. These nodes are abstract, means they are not bound to any real and existing web services, but they only show the need for that type of service in composition. For example assume the user of an e-travelling composer, who wants to reserve a plane ticket and a room in hotel and a car in destination. Figure1 shows his/her abstract composition.
Figure 1. Abstract Graph
b.
560
Creating Concrete Graph: in this level the composer must bind existing web services to each node of abstract graph. In this level the composer may want to consider some conditions or constraints to choose the best web service for each node. In this place the policies of each organization must be satisfied, until the composer can use its web service in result composition. In the next section we will provide further description about creating the concrete graph.
IADIS International Conference WWW/Internet 2008
4. COMPOSER ARCHITECTURE In our approach one agent is representative of some web services and is responsible for managing them. This model is fully implemented before [2]. The web services under an agent’s control can participate in any composition if and only if the agent approves of that. The task of this agent is checking to make sure that the attributes of user’s request are matched with the policies of organizations which their web services are under the agent’s control. For example the agent chooses the best hotel web service, considering the needs of user and the policies of each hotel. The policies of each hotel are written with SWRL language in its ontology structure. The agent sends queries to web services’ ontology with SQWRL language and if the needs of user match with policies of each web service, that web service will be chosen for composition.
Figure 2. Composer Architecture
The parts of the composer are described below: • User Request Interface: A graphical interface for taking the user’s request and needs. • User Request Interpreter: This module is responsible for interpreting and eliciting more information from the user’s request. For example in e-travelling, the user only specifies the source and destination cities, but it is the task of this module to determine the shortest path between them. • Abstract Composer: Creates the abstract graph based on the information of the previous module. • Agent Searcher: This module searches for the best agents, relative to each node in abstract graph. Then gives the information of user’s request to the chosen agent. That agent compares the user’s information with the policies in each web service OWL file, and if there is not any contradiction between them, the web service will be given to composer by that agent. Then the composer binds that web service to the result composition. If the agent does not find a suitable service, agent searcher selects another agent from the repository.
5. CONCLUSION In this paper we introduced a composer which firstly operates dynamically, and secondly decides how to put the services in composition according to policies and rules of each service. Also we used SWRL and SQWRL languages respectively to web service policy expressing and querying.
REFERENCES Jian Yang. et al, 2003, A Rule Based Approach to the Service Composition Life-Cycle. Proceedings of the FourthInternational Conference on Web Information Systems Engineering Paul A. Buhler. et al, 2007, Multi-agent Web Service Composition Engine: Revisited. Proceeding of 9th IEEEInternational conference on E-Commerce RuleML WebSite: http://www.ruleml.org/
561
