TRANSFORMATION OF ONTOLOGICAL REPRESENTED WEB SERVICE COMPOSITION PROBLEM INTO A PLANNING ONE

This article deals with automated web service composition (AWSC). We present an approach utilizing a combination of artificial intelligence planning methods with knowledge-based approaches to AWSC. For primary composition problem description we used OWL and OWL-S ontologies, which are than in next step translated into a planning problem. This planning problem is represented in PDDL language and may be solved in arbitrary PDDL planner. For the translation process we introduced several original algorithms, which are implemented as components of a prototype system for AWSC.


INTRODUCTION
Nowadays the service oriented approach to design and implementation of information systems is very hot area of research and development.One of the most interesting and discussed issues in this area is a problem of web service composition, especially automated web service composition [3].Web services composition deals with workflow creation and instantiation.The workflows are composed from available web services with some dataflow.If it is not possible to fulfill the user's request by one web service, there is a possibility to accomplish this request by web service composition.
A very simple language translation problem may be presented as the example of AWSC.Let us assume that there exist several web services, from which each is able to translate a word from one language into another one (e.g. from English to Slovak, from English to German etc.).Now let us assume, that it is needed to translate word from language X to language Y, but there is not a web service available for this direct translation.But there are two web services available, from which first translates a word from language X to language Z, and second translates a word from language Z to language Y. From this can be seen, that with composition of these two web services (i.e.output from first service will be fed as input into the second service) we may translate a word from language X to language Y (accomplish the original users' request).
Web services (WS) are distributed programs located on a computer network (most frequently on internet) and using standard protocols for communication (most frequently HTTP and SOAP).The concept of WS was introduced by major IT Corporations as Microsoft, IBM and Sun and was proposed as alternative to objectoriented distributed standards as CORBA and Java RMI.
There are two main properties of WS: they must be self-descriptive and they must be interoperable together regardless to the environment (i.e. also the program language), in which they were created.There are several standards and technologies, which are related with WS and are important in terms of the AWSC problem: • WSDL (Web Services Description Language) -is the most used language for WS description.It makes it possible to describe the offer of available operations in a WS, parameters of these operations, as well as the way of communication with WS. • SOAP (Simple Object Access Protocol) -is the XML based protocol.It serves for interaction and information exchange over the network interface by using XML messages.It is platform and programming language independent.• OWL (Ontology Web Language) [1] -is a language designed for ontology description on the internet.It belongs to languages, which serve for knowledge representation, and it is approved by W3C consortium.In the computer science ontology represents a formal knowledge representation by a set of concepts and relationships among these concepts in some domain.OWL is semantic language for publishing and sharing ontologies.• OWL-S (Semantic Markup for Web Services) [2] may be characterized as ontologically descriptive language for WS.The base WS descriptive languages (as e.g.WSDL) are in terms of semantic web insufficient (mainly for automation of their activity on the internet).But with incoming ontologies it was shown, that there is a possibility to describe WS by ontologies, and connect these descriptions to existing ontologies.These descriptive ontologies for WS were called OWL-S (for reason that they are OWL ontologies and they are used for service description).Main motivation for creation of OWL-S were the following tasks: automated WS discovery, automated WS invocation and automated WS composition.

AUTOMATED COMPOSITION OF WEB SERVICES
The process of automated web services composition may be divided into several parts.In a simple general system architecture for an AWSC system the following main parts can be identified: • user -a consumer of the system, who provides requests to the system, • translator -translates users' requests in a form suitable for processing by the process generator, • process generator -it solves user's request, i.e. creates a workflow composed from abstract WS, • evaluator -it selects the best solution if there are available multiple possibilities, • executor -it executes selected workflow via composition of concrete WS and provides the results to the user.
The composition problem is in AWSC system represented by two specifications: • external specification and • internal specification.
External specification is used for the primary composition problem definition.There are usually used semantic web technologies.External specification then contains user's request and WS specifications.
Internal specification defines composition problem in relation with selected process generator.One of the most suitable choices for AWSC is use of artificial intelligence planning methods for solving the composition problem.In such a case the internal specification is represented as a planning problem.Planning problem is defined by some formal planning language.

PROPOSAL OF AN AWSC SYSTEM
Our proposal for an AWSC system architecture is presented on the Fig. 1.This proposal is a specification of the general AWSC system architecture, which can be found in [3].  1 Proposal for an AWSC system architecture AI (Artificial Intelligence) Planner has been chosen as a process generator.This means that our internal specification is represented as a planning problem.In general the planning problem is represented as a quintuple <S,S0,G,A,Γ > [8], where: • S represents a set of all possible states in given model of the world, • S0 is a subset of S, and represents the initial state, • G is a subset of S, and represents the goal state, • A is a set of all available actions.Each of them changes the world state by passing world state from one state to another, • relation Γ is a subset of S x A x S and defines preconditions and effects for each action.
In the system we use knowledge approaches.Every web services composition is performed in some domain (e.g.language translation domain, travel domain, crisis management etc.).It is important to have this domain described in a formal way.In our system we assume that this domain is described by means of OWL ontologies and these ontologies will be further referred as domain ontologies.We are able to create some state of the world in given domain by creating OWL individuals in the domain ontology.Therefore by this domain ontology we can create initial and goal state of a composition problem.
For WS description we will use ontology as well.This ontology for WS is formalised in OWL-S and represents WS operations as processes.Processes from OWL-S WS description then will represent actions in planning task.In OWL-S are processes described by IOPE -Input, Output, Preconditions and Effects.Therefore OWL-S may be used also for representation Γ of PDDL actions.Domain, initial and goal OWL ontologies together with OWL-S web services description create external specification, and in the system are called as semantic knowledge composition problem definition.This definition must be translated into a planning problem by a translator.The process of translation from external specification to an internal one is the main topic of our work presented in this article.
After creation of a planning problem we are able to solve it using suitable external planner.In our system we can use available AI planners [8] like GraphPlan1 or FF -Fast Forward planner2 [5].Besides these there is possibility to use arbitrary AI planner.The only condition is to use planner, which is able to work with PDDL language [10].Solved problem is afterwards represented by a plan, which consists of available PDDL actions.Now there is the necessity for mapping these PDDL actions into related WS described by OWL-S.This task is realized in translator again.Finally, we can execute obtained WS and provide results to the user.This process of transformation PDDL plans back into semantic representation and execution of the translated PDDL plan is not discussed in this work.See [13] for more details.

Creation of PDDL description of a planning problem from semantically described WS composition problem
As it has been mentioned above, there exist two problem specifications in AWSC system: external and internal specification.In our case it holds: • external specification is represented by means of available domain ontology, initial and state ontologies created from domain ontology, together with web services described in OWL-S, • internal specification is represented as PDDL planning problem.
PDDL (Planning Domain Definition Language) language [10] arose is a result of standardisation efforts in the planning domain.It has been proposed and further developed for international planning competition requirements ICP and this language is very popular in the planning community.
The process of translation between the external and internal problem specification in our system is showed on Fig. 2. The OWL ontology structure may be divided into three parts: • namespace definition, • ontology header, • ontology elements.
For every element, which is used in the ontology, it has to be specified, from where it comes from.This is either from some other already defined ontology, referencing it via the namespace, or it can be defined in the last part of the ontology.In the header of the ontology additional information can be provided, like e.g. its creator, date of creation, ontology title, ontology comments etc.After namespaces and ontology header definitions original ontology elements are defined.Main ontology elements are: • OWL classes, • OWL properties (object properties, data properties), • OWL individuals (instances).
OWL-S represents ontological description for WS.This description consists of three parts: • service profile -it describes what a particular web service provides for the consumers, • service model -describes how the web service works, • service grounding -provides necessary details about transport protocol and how one can interact with WS.
For the AWSC purpose the most important is service model, which describes WS as processes with their inputs, outputs, preconditions and effects.There are several possibilities how to define preconditions and effects in OWL-S.In our proposal we are using SWRL (Semantic Web Rule Language) conditions' specification as OWL-S preconditions and effects.
PDDL planning task consists from planning domain and planning problem definition (see Fig. 2).These may be further divided into smaller parts.Each from these parts will be presented in the next subsection.PDDL planning domain and problem structures are often defined by EBNF (Extended Backus-Naur Form).Complete definition of PDDL planning domain and problem can be found e.g. in [10].

PDDL planning domain creation
EBNF form of PDDL planning domain may be described in the following simplified form: For creation of PDDL planning domain we will use OWL domain ontology and OWL-S WS description.Each part of this process is described in particular subsection below, together with proposed transformation algorithms in pseudo-code.

Domain name
Domain name is represented as PDDL name.PDDL name is a string of characters beginning with a letter and next containing only letters, or digits, or hyphens (-), or underscores (_).Domain name can be created by using domain ontology, and may be located in header of this ontology (e.g. as title of ontology).This is the reason why the string obtained from ontology header should contain only permitted characters.In such a case a simple algorithm for PDDL domain name creation (Alg. 1) satisfies our purpose.

PDDL domain name algorithm
Alg. 1 Algorithm for PDDL domain name creation

Requirements
This is an optional element of PDDL domain structure.In case that this element is not included, there is an assumed only one requirement, namely STRIPS [4] (:strips).In our case we create PDDL domain from OWL ontologies and therefore we need also other requirements, e.g. the possibility of type definition ISSN 1335-8243 (print) © 2011 FEI TUKE ISSN 1338-3957 (online) www.aei.tuke.skwww.versita.com/aei(:typing).There is an expectation, that requirements we may define in ontology header as additional ontology information.Currently the PDDL domain requirements are created manually in our AWSC system.

Types
PDDL types may be created from OWL classes and from a relationship Class\SuperClass in OWL ontologies.PDDL types are created for each OWL class definition.In case when a particular OWL class has defined a superior class (SuperClass), also the corresponding PDDL type has superior type.If superior class does not exist, superior type for corresponding PDDL type is an object.
PDDL types are represented by a special list called typed list.This list can assign types to its elements.But this possibility is available only in case if there is requirements flag for typing (see antecedent section).If this flags is not presented, the typed list is a normal list of elements.
Our algorithm for PDDL type created based on OWL domain ontology can be seen on Alg.

PDDL domain types algorithm
Alg. 2 Algorithm for identification of PDDL domain types

Predicates
A predicate may represent property or relationship between entities.Predicates are in PDDL domain structures represented as atomic formulas skeletons.Each skeleton represents one predicate and consists from predicate name and from a set of parameters.Predicates may be considered as patterns, by which it is possible to create facts.These facts are created by substitution of predicate variables by concrete objects.
Predicates will be created from OWL domain ontology.For creation of PDDL predicates we use object properties, data properties and OWL classes' definitions.
Our algorithm for definition of PDDL predicates based on OWL domain ontology is presented on Alg. 3.

Actions
Each PDDL action consists of an action name (called also action functor), action parameters and action body.Action body further contains preconditions and effects for respective PDDL action.

Alg. 3 Algorithm for creation of PDDL domain predicates
For creation of PDDL actions we use OWL-S web services descriptions.Each OWL-S description consists of three main parts: profile, process and grouding.In terms of AWSC the process model is important.Process model represents operations as particular processes.An OWL-S process is described by its IOPE (inputs, outputs, preconditions and effects).From this IOPE we create PDDL action parameters and action body.For PDDL action name we use the name of related OWL-S process.
There exist three types of processes in OWL-S description: • Atomic process is simplest OWL-S process.From the user's point of view this process represents one step and there is a direct web service invocation for its execution.This WS is described by OWL-S.• Simple process is not directly executable.Likewise as atomic processes are simple processes considered as one step processes too.Simple process serves for abstract description of atomic and composite processes.• Composite process is a process composed from subprocesses.A decomposition divides a composite process into simpler parts, which are performed by given constructors (sequence, split, split-join, choice, if-then-else, iterate, repeat until and repeat while).A composite process execution inheres in execution its sub-processes.
For every type of OWL-S process we must provide particular way for transformation of this process into PDDL action(s).Our algorithm for PDDL actions creation is shown on Alg. 4, Alg. 5, Alg.6 and [12].

Alg. 4 Algorithm for PDDL domain actions definition
Because of complexity of algorithms for definition of simple and composite processes and the article size limit we describe here only the way of creation of PDDL actions from OWL-S atomic processes.The others are described in [12].

FUNCTION owls2pddlActionAtomicProcess(P :
OWL-S Atomic Process) : PDDL Action VAR a : PDDL Action; BEGIN IF (P is atomic process with only outputs) DO BEGIN a := owls2pddlActionAtomicProcessOutputs(P); END; IF (P is atomic process with only effect) DO BEGIN a := owls2pddlActionAtomicProcessEffects(P); END; owls2pddlActionAtomicProcess := a; END;

Alg. 5 Algorithm for PDDL actions derived from OWL-S atomic processes
In case of atomic process translation we assume that each atomic process contains only outputs or effects, not both [7], [11].Therefore the algorithm presented on Alg. 5 includes calling of one from two available functions with regard to type of atomic process.
The function for creation of PDDL actions from atomic processes, which contains only effects, can be seen on Alg. 6.This is the simple PDDL action creation from OWL-S process.For other PDDL actions creation algorithms please refer to [12].
For PDDL action name we use the name of particular OWL-S process.Inputs of this process are translated into PDDL parameters.Each of these inputs may have type and therefore they are in PDDL actions represented by typed list (see subsection 3.2.3).
Each PDDL action has action body, which presents preconditions and effects.We are able to create these parts by using OWL-S process preconditions and effects.

PDDL domain actions algorithm -atomic process
Alg. 6 Algorithm for PDDL actions derived from OWL-S processes with effects only The condition in OWL-S may be defined in several ways (e.g. by using SWRL -Semantic Web Rule Language, KIF -Knowledge Interchange Format etc.).In presented work we use SWRL conditions for definition of preconditions and effects in OWL-S process model.
Our algorithms of creation of PDDL preconditions and effects from SWRL conditions are presented on Alg. 7 and Alg. 8.These two functions are utilized by function presented above on Alg. 6.On Fig. 3 can be seen a simple example of a PDDL planning domain.This example has been derived by transformation of the semantic description for primary composition problem definition in OWL and OWL-S.This problem was next transformed into PDDL planning problem (Fig. 4) using proposed algorithm (see Alg. 13).

RELATED WORK
Most of the systems and works, which deal with (semi)automatic web service composition, make use of existing automated planning systems.It is due to relatively straightforward and suitable mapping between planning problem and web service composition problem.In our work we introduced a possibility of mapping semantically represented web service composition problem into a planning problem represented in the PDDL language.Before we designed our AWSC system, we analysed a couple of already existing systems and proposals.Summary of the analysed systems can be seen in Tab. 1.
WS Prolog [14] is a system for web service composition, which uses logical programming elements.As already suggests the name of this system, it is based on Prolog programming language.
SHOP2 is domain independent HTN (Hierarchical Task Network) planning system, which won one of the four main prices on international planning competition in 2002 3 .HTN is a planning method, which is focused on task decomposition in order to create a plan.Tasks decomposition is performed until all tasks aren't decomposed into primitive tasks.On given planning system authors in created system for AWSC [7].In this system transformation of OWL-S WS descriptions into HTN planning domain is performed.In our work we are inspired by some of the algorithms from this system, but we use different target language.
OWLSXplan [9] is a tool developed for automatic web service composition by using artificial planning method.This system realises conversion of WS described by OWL-S version 1.1 into equivalent planning problem described by PDDL 2.1 language.After conversion into planning domain the planning itself is performed by XPlan planner.XPlan planner is based on Fast Forward planner improved by HTN planning.One of our innovations with respect to this system is the use of SWRL for conditions specification.
Authors in [15] dealt with web service composition only with using WSDL descriptions.They proposed a system, which goal is to provide WSDL described web service composition through artificial intelligence planner.The problem of composition starts with user part, in which users must select initial WS.Therefore this system is semiautomatic.
SEMCO-WS project [16] dealt with processing web and grid services composition.A service composition is performed through semantic WS and data annotations and afterwards executable workflows are created.Petri Nets are used for representation of workflows and the mechanism for web service composition is completely different than in our approach.

CONCLUSIONS
In this article we presented our proposal for a AWSC system.The main focus of our activity was to design and implement suitable transformation process from external composition problem specification into an internal specification.For external specification we used knowledge approaches (OWL and OWL-S ontology) and for internal specification the PDDL planning problem specification was used.We proposed several original algorithms, presented partially in this article, which were implemented and experimentally verified.

Table 1
Comparison of existing systems (AC = automated composition, SAC = semi AC)