An Evolutionary Algorithm for Automatic Composition of Information-gatheringWeb Services in Mashups

Thomas Fischer, Fedor Bakalov, Birgitta Konig-RiesFriedrich-Schiller University of Jena

07743 Jena, Germanyfischer.thomas | fedor.bakalov | birgitta.koenig-ries@uni-jena.de

Andreas Nauerz, Martin WelschIBM Research and Development

71032 Boblingen, Germanyandreas.nauerz | martin.welsch@de.ibm.com

Abstract—The idea behind mashups is to provide a mech-anism that allows for more or less spontaneous combinationof existing web applications. Users shall thus be enabledto combine data and services according to their needs.However, existing mashup frameworks require some pro-gramming knowledge, hence are not suitable for non-expertusers. In this paper, we present a system that builds onexisting Semantic Web research to achieve an automatic,ad-hoc generation of mashups thus eliminating the need forprogrammer involvement. At the core of our approach, thereis an evolutionary algorithm that automatically composesdifferent information web services based on semantic servicedescriptions. The information that has been retrieved fromthe invoked web services is automatically transformed intoa semantic representation and presented as a mashup to theusers of the system.

Keywords-Web Service Composition, Semantic Web Ser-vices, Evolutionary Algorithms

I. INTRODUCTION

Traditionally, when users have required new functional-ity or a new combination of existing functionality, they hadto ask the IT department to write a suitable application.This was a slow and often bureaucratic process. Nowa-days, many applications are offered over the Web andcan be discovered and used by the end users without theneed for help from the IT department. A number of suchapplications provide their functionality and informationvia so called Web Services, which allows users to combinethem to fulfill the information needs they might have ina certain situation. Imagine, for instance, a financial man-ager reading about a planned merger of two companies. Hemight be interested to obtain additional information abouta variety of aspects: How is the current trading price ofstocks of the company? What are profit figures for the lastquarter? How is the industry doing in general? What do weknow about the people involved? Where ist the companysituated and which hotels are available?

It is quite likely that applications exist that can offer therequired information. It is rather cumbersome, however,to manually find and combine the individual applicationseach time the user needs them. Furthermore, interests andcontext of the user are changing, thus, the set of requiredapplications is not static, but needs to be adapted to thecurrent situation. Mashups offer a programming modelthat allows for the easy, plug-and-play like combinationof different web applications. An appropriate mashupframework would allow the user to use the chosen combi-

nation of tools automatically in the future. Unfortunately,the creation of mashups is not trivial. While by nowmany frameworks for mashup creation exist, all of themrequire some programming experience as we will discussin Section II.

Based on this observation, we propose a method forthe automatic generation of mashups. The basic idea (seeFigure 1) is to use the information available about a coreapplication and a user’s current task (which we assumecan be found in a user model) to determine what additionalinformation the user is interested in. We then employ anevolutionary algorithm to combine existing applications,to be more precise existing information gathering webservices, in such a way that these information becomeavailable. The newly available pieces of information,which are classified in terms of an ontology, are thentransformed into a mashup page to support the user. Figure

Figure 1. Mashup Process

2 shows an simple example of the system. The initial textof a portlet has been extended by a map, which showshotels on nearby locations. Furthermore, additional infor-mation for specific highlighted entities are available. Theapplication automatically composed a company addressservice, a geocoding service and a service for findinghotels in nearby locations, because the specific user goalhas been set to travelling. Thus, the map displays hotelsof cities that are directly mentioned in the initial text aswell as hotels of cities that are locations of companies ofthe text.

A brief overview of the overall system architecturewhich we used is shown in Section III, while a detaileddescription of the evolutionary algorithm can be found inSection IV. The proposed algorithm is a suitable solution

Figure 2. Mashup

to the problem as we will show with a thorough evaluationin Section V. We will show that the algorithm providescorrect results and scales well - two equally important fea-tures in the mashup context. Finally, Section VI concludesthe paper.

II. RELATED WORK

In this section we first present related work on mashupsand web services to outline their inter-relations. We thengive a brief overview on the huge work on semanticweb service description and composition, because thesesemantic web technologies are used in our proposedapproach to achieve an automatic generation of mashups.This overview serves two purposes: on the one hand, weneed to introduce some foundations that our work buildson, on the other hand, we will explain where limitationsof existing approaches are and why a new approach wasneeded.

A. Mashups and Web Services

1) Mashups: The research on mashups, which are aprinciple of the Web 2.0, has turned out a variety ofmashup definitions [1, 2, 3, 4, 5, 6, 7, 8]. In general,the definitions provide a consensus over the integrationand aggregation of different resources in mashups, whiledifferences arise mostly from the types of consideredresources. Often these resources are Web Services whereasthe mashups themselves put a visual layer on top of theseWeb Services [9]. A comprehensive market overview ofthe different types of mashups and tools could be foundin [9]. Furthermore, a huge set of example mashups ismaintained by ProgrammableWeb1.

The approaches and tools for creating such mashups arevery diverse. They range from fully manual developmentto fully automatic generation, which is proposed in thispaper. An overeview about the different approaches as well

1http://www.programmableweb.com/

as there limitations has been already described in one ofour previous papers [10], thus we give only a short abstracthere.

Today, several tools are available for manual creationof mashups. Systems, such as Apatar2 [11], IBM Damia[12], JackBe Presto Wires3, Microsoft Popfly4, YahooPipes5, Openkapow6, Proto Financial7, Anthracite8, LotusMashups 9, Marmite [13], SABRE [14], provide users witha GUI environment where they can aggregate differentdata sources using certain operators and filters. They offerwidgets associated with data sources (e.g. RSS feeds),which users can drag to the canvas and use to definehow data should be aggregated. This manual connectionis sometimes called wiring or piping of different mod-ules, connectors, components or blocks. The availablecomponents provide different functionality (e.g. data re-trieval, data transformation, data presentation etc.) andhave to be connected to achieve the desired coordinationof the mashups. The tools often support different datasource types such as RESTful and / or SOAPful (e.g.Openkapow, Proto Financial, Anthracite) web services,database, spreadsheets and CSV files.

Furthermore, the creation of mashups is supported byvarious tools that are based on domain specific script-ing languages such as Google Mashup Editor10 (GME),Web Mashup Scripting Language (WMSL) [15, p.1305],Dynamic Fusion of Web Data [4] [16], WSO2 MashupServer11. In general, it seems to be too complicated fora non-developer, to create such scripts in an appropriatetime, because more complex mashups will need a consid-erable amount of rather complex script code.

The present systems have a number of limitations.First, in order to create even a simple mashup, the userhas to possess a certain level of technical knowledge.Second, mashups are mostly used to solve a short-terminformation need, thus they have to be created ad-hoc,for which users are not always willing to invest timemanually assembling data. Third, the number of availabledata sources and aggregation operators are limited to whatthe system provides. Another important limitation is thelack of adaptivity. This means that if the data sources andfunctionalities of the provider change their structure orbehavior the mashup application has to be reengineered bythe endusers. It is therefore an important topic to achievean automatic and adaptive creation of mashups.

Overall, the entirely dynamic and automatic generationof mashup applications has been only limitedly part ofresearch activities. In [17], as one example, a mashupframework for automatic composite mashup applications

2http://www.apatar.com/product.html3http://www.jackbe.com4http://www.popfly.com/5http://pipes.yahoo.com/pipes/6http://openkapow.com/7http://www.protosw.com/8http://www.metafy.com/products/anthracite9http://www-01.ibm.com/software/lotus/products/mashups/10http://code.google.com/gme/11http://ws02.org/projects/mashup

based on Lotus Expeditor is proposed. The frameworkfocuses on mashups of non web service components (e.g.widgets), whereas we focus on the mash-up of backgroundinformation provided by information web services. Fur-thermore, we have a focus on fast ad-hoc creation ofpersonalised mashups, which requires the fast creation ofuser centric compositions of information Web Serviceseven in large Web Service repositories.

2) Web Services: Web Services can be defined as func-tionality that could be engaged over the Web [18, p.520]and that make descriptions of their interfaces available.The Web Service Description Language (WSDL) providesthe possibility to publish technical description of a webservice [19, 20], but it does not allow to capture the seman-tics of the service, i.e., it describes interfaces, messages,and endpoints, but it does not define the meaning of theexchanged messages or the effects the service executionhas. Web Services can be divided in SOAPful and REST-ful services. While the name of the former is derived fromthe underlying Simple Object Access Protocol (SOAP), aprotocol for exchanging XML messages, which can use,e.g., HTTP, SMTP as its underlying transport protocol[18, p.21-36][21], REST stands for Representational StateTransfer)[22]. This means that the invocation of a URIresponds a representation of a source that transfers theclient application into a specific state. The HTTP responsecontains mostly a XML document that denotes the repre-sentation of this resource.

A subclass of web services that is of particular impor-tance for this work, are information web services. Theseare web services that return information for a specificrequest and that achieve no real world effects (in contrastto, e.g. a book buy service).

B. Ontologies

Knowledge representation and ontologies are impor-tant for mashups, because mashups combine data fromdisparate sources that can be only combined in a moreautomatic way, if there is a shared understanding of themeaning of the data. The most prominent definition forontology was given by Gruber [23], who specified anontology as ”an explicit specification of a conceptual-ization”. Conceptualizations can be shared among agents.Therefore, the definition has been extended by Borst [24,p.12]: ”Ontologies are defined as a formal specification ofa shared conceptualization”.

The Resource Description Framework (RDF) [25] is aframework for representing information on the Web. Ingeneral, RDF allows anyone to make statements about anyresource, which could be a material or immaterial thing.A statement is defined as a triple, consisting subject s,predicate p and object o, written as p(s, o). This meansthat subject s has a predicate (or property) p with valueo. RDF provides no means to define the terms of thevocabulary that is used throughout the statements. Thisis addressed by RDF Schema (RDF-S) [26] and the WebOntology Language (OWL) [27].

RDF-S is a minimal ontological language. It has capa-bilities to define classes and properties, and enables thespecification of how they should be used together.

The Web Ontology Language (OWL) is build on topof RDF and RDF-S. OWL provides the three sub lan-guages OWL-Lite, OWL-DL and OWL-Full. The usageof a language depends on the needed expressiveness ofthe ontology. In our framework we use an OWL-DLontology. OWL-DL is an expressive description logic(SHOIN (D)). The logical structure of a DL knowl-edge base is based on a so called TBox and a ABox(KB = 〈TBox,ABox〉). The TBox contains intensionalknowledge and is build through the definition of conceptsand properties [28]. The ABox contains assertions aboutthe named individuals in terms of the defined vocabulary.Furthermore, the ABox depends on the current circum-stances and is part of constant change. A detailed overviewabout description logics can be found in [29].

C. Semantic Service Description

Service description languages are used to describe thefuntional and non-functional semantics of web services.Examples of such description languages are OWL-S [30],WSML [31], SAWSDL [32]. An overview about differentsemantic service description languages can be found in[33]. In the following we give a brief overview aboutOWL-S, which is used in our framework.

The Web Ontology Language for Web Services (OWL-S) is an upper ontology for web services that containsstatements about the web service profile, web servicemodel and web service grounding. The service profile isintended to support the selection of a web service anddescribes inputs, outputs, preconditions and results of aweb service. The web service model describes how theweb service could be used by a client. It could be usedto make a more in-depth analysis for the selection ofa web service or it could support the composition ofweb services. The OWL-S model of a web service isdescribed by process descriptions. A process in OWL-Sis defined by its inputs, outputs, preconditions and results.The preconditions and results can be described by a logicexpression. Amongst others the specification supports KIF,PDDL, SWRL and since OWL-S 1.2 [34] also SPARQL[35] as logical languages. OWL-S defines atomic, simpleand composite processes. An atomic process correspondsto an action that is performed in a single interaction.This means that there are no subprocesses and that theprocess could be directly invoked, if the preconditions arefulfilled. An atomic process is referenced to a groundingthat specifies how to construct the messages.

D. Semantic Web Service Composition

It is likely that complex information needs can notalways be served by a single web service, especially in thecontext of mashups. Therefore, it is important to be able tocreate a plan that represents a composition of different webservices. Web service composition is a kind of a planningproblem and involves search and logic inference of Artifi-cial Intelligence (AI). Planning is the task of the creation

of a sequence of actions that achieve a desired goal [36,p.375]. This means that a planner has to create a sequenceof web services that could be invoked by the softwareagent to achieve its present goal. Actions in AI planningbased approaches are specified by preconditions and ef-fects. The preconditions have to hold before the agentinvokes the action. The effects describe how state changesafter the execution of the action [[36, p.379]. In advanceto the concrete planning process, the majority of plannerstransforms the goals, inputs and outputs of web servicesas well as preconditions and effects in a First-Order-Logic(FOL) problem representation. There are a multitude ofapproaches for Web Service Composition, which couldbe classified, in accordance to [37], as follows: staticvs. dynamic composition, functional- vs. process-levelcomposition. While in a dynamic composition approachthe web services are planned at invocation time, the staticcomposition first generates the plan and then invokes theweb services. Functional-level composition means that aweb service is considered as an atomic entity. This meansthat the web service is specified by its inputs, outputs,preconditions and effects (IOPE) and requires only asimple request-response interaction. Atomic web servicesare also those ones, which are provided as a black-boxand thus the underlying behaviour and interactions are notvisible. Instead, process-level composition considers theinternal interactions of a web service [37], which wouldcorrespond to a more complex interaction schema.

The research on semantic web service compositionstates that their are still open topics on appropriate in-corporation of user preferences in the matching process[38] [39, p.93-94] [40], scalability of planning algorithms[41, 37] as well as adaptive discovery and composition[37]. However, these limitations are important require-ments in the mashup context. The proposed user modelas well as the evolutionary web service compositionalgorithm address these open issues. For these reasons,we propose our own web service composition approach,which uses an evolutionary algorithm for state spacetravesal and a boot strapping evaluation function. Whileevolutionary algorithms has already been used in theweb service challenge [42], we use a novelty evaluationfunction and we also reuse the semantic capabilities ofOWL-S. In contrast to [42], we have a more detailedplan representation that allows parallel execution of webservices in a composition. Furthermore, we also regard theinvocation of the information gathering web services.

III. SYSTEM ARCHITECTURE

Our mashup framework provides users personalizedmashups that are automatically generated based on theknowledge about the user and the information about thecontext of the acting user. The framework augments thedocuments that users are reading with background infor-mation and related content gathered from different sourcesand aggregated into one integrated tool.

In the case of the finance manager mentioned in theintroduction, the framework, for instance, can display a

side menu that shows the situation on the stock market,including the stock quotes of the companies mentioned inthe text. Another side menu can be displayed to providean executive summary of the technology mentioned in thearticle and the list of people from her department who arefamiliar with this technology.

Figure 3. System Architecture

Figure 3 illustrates the high-level components of thesystem architecture of our framework. In order to auto-matically augment the external or portal content (1) withrelevant information, we need a component that is able toextract machine-readable semantics from the content (2).For this purpose, we use the Calais12 Web service andUIMA framework13. These analysis engines are able toextract certain types of entities, such as person, company,location, etc (3).

The semantics extracted from the content is used bythe personalization engine (4) to identify the information-gathering actions that provide the user the information shemay need in a given situation. Each action is describedby its input and output concepts, which denote the inputdata and wanted information respectively. The selectionof actions is based on the personalization rules defined inthe personalization model and the knowledge about theuser interests and expertise stored in the user model, bothof which are based on the domain model. The domainmodel is based on an ontology. More information onall four components can be obtained from our previouspublications ([43] and [44]).

After the personalization engine has identified theinformation-gathering actions relevant to the user, theengine invokes a web service composition request (5) foreach of the selected actions. In the request, it specifies thesemantic input data and the structure of information thatmust be obtained. Then the engine sends the request tothe service composition module, the goal of which it is tofind the services that provide the requested information.The composition module creates a composition (6) by amulti-objective evolutionary algorithm, which operates onthe semantic web service descriptions provided by theapplication registry. The application registry maintains

12http://www.opencalais.com/13http://incubator.apache.org/uima/

the references to the semantic web service descriptions,which are based on OWL-S [30], for each of the registeredRESTful or SOAPful services. Furthermore, it maintainsinformation about the inputs, outputs, preconditions andresults of each semantic web service.

After the composition, the module provides the gener-ated composition to the mashup handler (7), which in turninvokes the semantic web services (8,9) and requests thepresentation module to display the mashup (10).

IV. EVOLUTIONARY ALGORITHM

In the remainder of this paper, we will concentrateon the service composition module. The module searchesfor a plan, or more precisely a web service composition,based on an evolutionary strategy, which traverses thesearch space through a special stochastic hill-climbing.This means that the algorithm evaluates and maintainssimultaneously a population of states (plans) of the searchspace. New states (plans) are created from old states byspecial operators for mutation and recombination, whichare based on the principles of the natural evolution. Theproposed planner is a functional-level static planner thatconsiders atomic web services that are based on a simple-request response interaction schema. Dynamic planningwith the proposed evolutionary process seems to fit notvery well, because this would in general cause the invoca-tion of a lot of unnecessary web services. Furthermore, theinvocation of the web services would slow down the wholesearch. The evaluation function therefore relies on thespecified semantic web service descriptions. It is necessaryto have an expressive web service description to specifythe correctness and completeness of such plans [45].

Section IV-A describes the concepts of the evolutionaryprocess in the context of this paper. Section IV-B definesthe formal representation of the plans. Section IV-C dealswith the definition of the final search problem for webservice composition planning.

A. Evolutionary Process

Figure 4. Evolutionary Process

The algorithm starts with a random set of possiblesolution candidates (web service compositions, plans).Based on the calculated performances of the candidates theparent selection calculates which individuals are admittedfor recombination. The selection is based on a tourna-ment between the individuals. The recombination is animportant evolutionary factor that is based on a two-pointcrossover that pairwise recombines the interconnection ofparts of two candidate plans. This step can lead to very

different phenotypical characteristics. The newly gener-ated child plans are then mutated in different ways witha predefined probability. The mutation changes the webservices identifiers of the plan as well as their ordering. Inaddition, mutation can grow and shrink plans, because thefinal plan length is not known in advance. Mutation andrecombination lead to plans that are often not compliantwith specific assumptions, which are described in SectionIV-B. Therefore, the evolutionary process contains anoperator that repairs the plans. The repaired child plans arethen weighted by the evaluation function and added to theexisting population. However, the plan population has onlya predefined size, which requires to perform a so calledenvironment selection that determines which plans survivefor the next generation of the population. The algorithmhas two conditions that are described in detail in SectionIV-C.

B. Plan Representation

The problem of web service composition planning isrelaxed to the search for an appropriate Directed AcyclicGraph (DAG) (see phenotype of Figure 5). The GraphG = (V,E) is based on a set of nodes, whereby it isassumed that each node represents an atomic web service.Each web service is denoted by its identifier defined bythe application registry. Furthermore, it is assumed thateach web service can be used only once in the plan. Anarrow from node A to node B denotes that the web serviceof node A should be invoked before the web service ofnode B. This is important, because this enables the webservice of node B to utilize the information provided bythe former web service.

The DAG represents the phenotype of the plan repre-sentation. However, the evolutionary operators for recom-bination and mutation operate on the formal genotypicalrepresentation. A DAG could be represented in differentways, such as in a standard matrix or adjacency-listencoding [46, p.22].

Figure 5. Plan Representation (in accordance with Weicker [47])

In this paper, we propose a special adapted version of

an adjacency-list representation (Figure 5). The genotypeG is a tuple G = (G.R,G.F ), whereby G.R ∈ Gdenotes the representation of the DAG and G.F ∈ Rdenotes the value of the evaluation function of the plan.Each genotype G.R contains a list K of web serviceidentifiers and a second list T that contains the topologicalinformation of the composition, to be more specific alist of sets of topological levels. A topological level isequal to a position (index) of a service in the list K.In Figure 5 the topological levels are denoted by “L”,however, this should only outline the principle. In theconcrete representation the level is simply an integer value.Therefore, a topological level l ∈ T [i] corresponds to adirected arc (K[i],K[l]) ∈ E. For instance, L4 ∈ T [2]denotes that there is an arc (K[2],K[4]). This means thatthe outputs of web service 1 are used in the inputs of webservice 8.

This encoding also enables the specification of a light-weight rule that determines the existence of cycles andallows an efficient repair of the genotypes. An encodedplan of length L has no cycles, if ∀l ∈ T [i] : l > i i =0, 1, 2, . . . , L holds true.

Instead of a direct evaluation of the phenotypical planrepresentation by the function f , the weighting of a planis based on the genotypical evaluation function fWC .Furthermore, the decoder function decode determines theappearance of a plan based on the genotypical data. Theweighting value of each plan is then used in the selectionstep. Afterwards, the evolutionary operators for recombi-nation and mutation modify the genotype information.

C. Formal Problem Definition

This section defines the final search problem for webservice composition planning, which is represented asan optimization problem of an objective function. In thefollowing a specific solution state (plan, genotype) in thestate space is denoted by x to simplify the notation of theproblem 14.A single-objective optimization problem (Ω, f,) is de-fined by the state space Ω, a weighting function f : Ω→ Ras well as a relation for comparison . The weightingfunction assigns a rating to each solution candidate (state)x ∈ Ω. The set of global optima is defined by χ = x ∈Ω | ∀x′ ∈ Ω : f(x) f(x′) ([47, p. 21]).

However, web service composition planning is basedon multiple objectives such as correctness, completeness,length, reliability, price etc. of plans. These objectiveshave to be considered for the planning process, whichmakes the search for a solution much more difficult thanin single-objective optimization problems. While single-objective problems may only have one unique optimalsolution, a multi-objective problem could have a set ofpossible solutions vectors. The different objectives arecomputed by objective functions. Since the objectives areconflicting (e.g. completeness versus length) as well as

14Each solution refers to two lists that represent the web services andthe topological information.

operate on different scales (e.g. price versus performance),they have to be aligned appropriately.

The general multi-objective problem searches for asolution x∗ (a state of the state space) that optimizesthe vector function ~f(x) = [f1(x), f2(x), ..., fk(x)]T . Itis clear that in most cases no optimum exists such that∀x∈Ω(fi(x∗) ≥ fi(x)) holds true. This means that thereis not a single solution x∗ that strictly dominates all othersolutions.

Multi objective problems are denoted by a so calledPareto-optimum, which represents the set of possiblesolutions that are efficient. Thus, this set contains onlysolutions that are not dominated by an other solution.The selection of a suitable solution out of the Pareto-optimal set depends on the preference structure of thespecific agent and can be handled a priori, a posteriori orprogressive to the optimization. Bleul et al. [42] state thatthe Pareto-optimization has disadvantages for evolutionaryweb service composition planning, because it spreads thesearch over the complete Pareto frontier and slows downthe performance. In fact, in the context of the proposedframework it is appropriate to specify the preferences apriori, because the preference information are availablefrom the specified user model.

The final web service composition optimization prob-lem is defined as (ζ, fWC , >). fWC(x) = w1 ∗completeness(x)+w2∗correctness(x)+w3∗length(x).We will discuss the individual factors in more detail below.

The search space ζ represents all possible permutationsof web services. Furthermore, the evaluation function fWC

is assumed to be maximized for x ∈ ζ. The main objec-tives correctness, completeness and length are weightedby a specific linear combination. It is important to notethat this handling of goal conflicts is only possible forsuch basic and general objectives. If other more user-sensitive preferences (e.g. reliability, security, price, per-formance, integrity, accessibility, availability, compliance[18]) should be incorporated into the evaluation function,alternative decision theoretic approaches have to be uti-lized.

The function fWC has to provide a gradual weighting[47, p.23] to avoid an uninformed search. Thus, the objec-tive functions should provide a gradual weighting too. Forinstance an absolute weighting of the correctness wouldonly determine if a possible web service compositionis correct or not correct. This would lead to a lack ofinformation about partial good solutions, and thus thedirection of the search could not be specified as detailedas in a gradual weighting. In the following we explainthe calculation of the different objective functions of theevaluation function.

1) Calculation of the Objective Completeness: Thecompleteness measures to which degree the goal of theplanning process is achieved. The goal representation isbased on a list of desired output resources. Algorithm1 gathers the output resources of all web services ofthe genotype and merges them into one comprehensiveset. The operation ”containsAll” checks, if for all desired

mashup output resources w ∈ OUTM there is a resourcesc ∈ OUTC such that c subsumes w (c v w). This meansthat it checks that each output resource of the desiredmashup is addressed by an either equal or more specificoutput resource of the composition.

Algorithm 1 Completeness of compositionRequire: KB = 〈TBox,ABox〉Require: OUTM desired mashup output resourcesRequire: G genotype of the compositionWSi web service in the registryc composition completeness ∈ [0, 1]OUTC composition output listfor all WSi ∈ G.R doOUTC ← OUTC ∪WSi.outputs

end forc← containsAll(OUTC , OUTM )return c

However, there are often web services that do not di-rectly contribute to the goal state, but instead contribute tothe overall plan. This means that intermediate web serviceshave to be considered, by an additional heuristic thatcounts the number of promising web services (Algorithm2). A promising web services is a web service which eitherhas an output that is an desired mashup output resourceor that has an output that is required as an inpunt ofanother promising web service. Both heuristics drive the

Algorithm 2 Number of promising servicesRequire: G genotype of the compositionRequire: OUTM desired mashup output resourcesPWS empty set for the promising web servicesWSi web service in the registryk ← 0for k ≤ treshold do

for all WSi ∈ G.R doif WSi has an output resources that subsumes aresource of OUTM thenWSi ∪ PWSWSi.inputs ∪OUTM

end ifend for

end forreturn PWS.size

optimization towards the objective of completeness.2) Calculation of the Objective Correctness: The

heuristic correctness function (Algorithm 3) utilizes theinput and output information of the OWL-S web servicedescriptions. It checks for each web service, if the inputsare served by resources from the mashup content or by anoutput resource of one or more predecessor web services.For the specification of the predecessor web servicesthe algorithm utilizes the topological information of thegenotype.

3) Calculation of the Objective Length: The lengthof a plan is an important objective that should be min-

Algorithm 3 Correctness of compositionRequire: KB = 〈TBox,ABox〉Require: INC list of available composition inputsRequire: G genotype of the compositionc composition correctness ∈ [0, 1]count← 0 count of web services with served inputsfor all WSi ∈ G.R doOUTPRE ← get output resources from predecessorsof WSi

if containsAll(WSi.inputs, INC ∪OUTPRE) ==1 then all inputs of the web service are servedcount← count+ 1

end ifend forc← count/ number of web services of the planreturn c percentage of correctness of the composi-tion

imized, because it is assumed that unnecessarily longplans lead to higher execution times and unnecessarycosts. The calculation of the length is denoted by thecount of web services in the genotypical encoding. How-ever, tests of the algorithm have shown that the algo-rithm performs better, when the count of unimportantweb services is considered, which could be calculatedby countOfUnimportantWebServices = length −countOfImportantWebServices.

4) Composition Simulation: The heuristics are not ableto prove exactly if a composition is definitely executable.Therefore, we have developed a simulation of the plans.The whole simulation starts with a temporal OWL ABoxwhich is represented in RDF. This ABox contains thesemantic information from the initially input (portal page)of the framework, which is part of the composition request.The simulation is performed for all web services of afound candidate solution, whereby it uses the topologi-cal information of the solution candidate. For each webservice the simulation checks the precondition by anSPARQL [35] ASK query. If the precondition is true,then a SPARQL CONSTRUCT query is executed andthe resulting simulated statements are added to the tem-poral ABox as new available information pieces. Thesenew information are then considered for the subsequentsemantic web services. The simulation is successful ifthe preconditions of all web service could be served. In

Figure 6. Simulation of a semantic web service versus real invocation

our simulation, the preconditions describe the structure ofrequired information and the effects describe the structure

of generated output statements for each web service. Eachprecondition is described by a SPARQL ASK query,which evaluates if the structure of the required inputstatements could be served by the available ABox RDFstatements. If this is true, an SPARQL CONSTRUCTquery is used to generate the structure of triples that arecreated by the invocation of the web service (see alsoFigure 6). In the simulation the generated triples containonly the types of instances as well as blank nodes that areused to create references between different instances. Thisapproach is similar to a real execution, with the difference,that this is much faster than a real invocation and that itcreates no unnecessary costs. Basically, triples are requiredas inputs of the semantic web service and output triples aregenerated by the web service. In a real execution, this isachieved through lifting and lowering schema mappings,which are well known from SAWSDL [32]. The followinglistings provide an example, whereby the prefixes in theSPARQL queries have been omitted.

Listing 1. SPARQL-based Information-Precondition<p r o c e s s : h a s P r e c o n d i t i o n><expr:SPARQL−C o n d i t i o n>ASK ? y r d f : t y p e m i n e r v a : S t o c k .

? y p s y s : m a i n L a b e l ?name . < / expr:SPARQL−C o n d i t i o n>< / p r o c e s s : h a s P r e c o n d i t i o n>

The example is based on a financial stock quote webservice described by OWL-S. The stock quote servicerequires input instances of the type “minerva:Stock” thatare specified by their “mainLabel”. The SPARQL ASKquery (see Listing 1) is used throughout the planning toevaluate if this precondition is fulfilled for a given RDFrepresentation of the current ABox. Listing 2 specifies theresult of the stock quote web service. If the preconditionis fulfilled, then the SPARQL CONSTRUCT query isused to generate the output information. In this case, thestock quote web service creates a “minerva:hasQuote”object property for the existing stock instance. The objectproperty relates a stock quote instance that is denoted bya blank node. The blank node specifies that it is of type“minerva:StockQuote“ and that it is described by data andprice. It is important to note that in the simulation only

Listing 2. SPARQL-based Information-Effect<p r o c e s s : h a s E f f e c t><expr:SPARQL−E x p r e s s i o n>CONSTRUCT ? y r d f : t y p e m i n e r v a : S t o c k ;

m i n e r v a : h a s Q u o t e : a .: a r d f : t y p e m i n e r v a : S t o c k Q u o t e ;

m i n e r v a : d a t e ” ” ;m i n e r v a : p r i c e ” ” .

WHERE ? y r d f : t y p e m i n e r v a : S t o c k .? y p s y s : m a i n L a b e l ?name .

< / expr:SPARQL−E x p r e s s i o n>< / p r o c e s s : h a s E f f e c t>

one instance of “minerva:StockQuote” is created, insteadin the real world invocation the service can respond a setof stock quotes. However, only the structure of available

information is important to determine the correctness ofthe composition during the simulation.

5) Stop Condition: The SPARQL queries lead to atimely costly simulation. Therefore, it is not appropriateto simulate each plan in the evolutionary algorithm. Theheuristics are therefore used to drive the optimizationtowards a promising solution candidate (plan, state), whichis then evaluated by the more exact simulation (see alsoFigure 4). A promising solution state is a plan that isheuristically complete and correct (see calculation above).A final solution is found, if this plan could be simulatedsuch that all web service preconditions could be served.The algorithm creates no plan, if the algorithm exceeds agiven number of iterations (generations). In this case theoriginal content (no mashup) is displayed to the user.

The previous sections has explained the evaluationfunction. More details on the evolutionary algorithm, theevolutionary operators as well as the calculation of theobjective function can be found in [48].

V. EVALUATION

The algorithm has been part of a quantitative evaluationto test the scalability and correctness of this approach.15

An evaluation of the algorithm requires an appropriate testcollection. In the context of this paper, the test collectionshould be based on services that are described with OWL-S service descriptions. Furthermore, the preconditions andresults of the OWL-S service descriptions should be basedon SPARQL (as explained in Section IV-C). In addition,the underlying web services should be atomic and invok-able in reality. Furthermore, we need a large test collectionto test the scalability of the approach.

Unfortunately, there is no standard test collection forweb service composition that meets our requirements.This is a general problem also mentioned in other papers[49, 50, 37]. Therefore, we were required to adapt existingtest collections. We have extended a test collection of 1000OWL-S web service descriptions that has been retrievedfrom the Online Portal for Semantic Services (OPOSSum)[51] and extended them by additional web service de-scriptions. This has been done to increase the size of thesearch space, which is important to show the scalabilityof the algorithm. The planning is based on the abstractsemantic descriptions of the web services, however, totest the automatic invocation of the web services, somedescriptions refer to technical groundings that allow anaccess to corresponding real world web services.

In this paper, we consider a planning problem thatrequires the composition of five financial information webservices and which also involves the search for interme-diate web services that do not directly contribute to thegoal information state. We concentrate on the analysis ofthe performance and scalability of the algorithm. For thegiven problem the planner has been randomly executed

15The evaluation has been performed on an Intel(R) Core 2 CPU 6400with 2.13Ghz and 2GB RAM. The main memory has been restricted toa maximum of 1024 MB.

fifty times to evaluate the performance.16 Figure 7 shows

Figure 7. Performance Analysis

the count of runs of the algorithm with respect to the countof generations until it has found a solution for the problem.The count of runs has been aggregated into classes of 1000generations. For two runs the algorithm has been stoppedat the maximum of 10000 generations without a solution( class(9000,10000] ). The other runs solved the problemon the average in 25 seconds. It can be concluded that thealgorithm is able to solve such problems and that they canbe solved in an acceptable time regarding a web serviceregistry of 1000 web services. 80% of the runs requirebetween 1000 and 5000 generations to come to a solution.Furthermore, there are only a few runs that require muchmore or much less time than the corpus of the runs.

The scalability in dependence to the registry size is alsovery important. Therefore the planner has been executediteratively with registry sizes between 150 and 1000 reg-istered web service descriptions. For each registry sizethe planner has been run for 9 different seed values ofthe random number generator to ensure the comparability.Figure 8 shows the mean of the count of evaluated statesin dependence to the registry size. The count of evaluatedstates is calculated by the number of invocations of theevaluation function until a solution has been found. Forinstance, the evaluation function could evaluate 1000 states(plans) of the state space and then have a correct andcomplete solution. In this case, the measure is 1000. Inall runs of this test the algorithm has found a correct andcomplete solution.

It can be concluded, that an increasing registry sizerequires the evaluation of more states. This was expected,however, it is important to note that the state space in-creases much faster than the number of states the algorithmhas to evaluate. For instance, for 100 web services, thestate space has approximately 100! ∼ 9, 3E157 possiblestates, whereas for 1000 web services the state space has1000! ∼ 4, 0E2567 possible states. At the same time, themean of required states has only multiplied by about five.

16The parameters of the algorithm have been the following: LibrarySize: 1000, Population Size: 8, Selection Size: 8, Selection Type:Tournament Selection, Crossover Type: Two-Point Crossover, ServiceMutation Probability: 0.2, Topology Mutation Probability: 0.7, GrowProbability: 0.3, Shrink Probability: 0.3.

Figure 8. Scalability Analysis

However, one can see that the standard deviation of thecount of evaluated states increases, if the registry sizecontains more web services. This is in accordance withthe previous result, where we have concluded that only afew runs perform really bad or really good. However, apartfrom the outliers, the algorithm has a good scalability evenfor large registry sizes.

In this paper we do not compare these results withother frameworks for web service composition, becausethis would be only appropriate if all evaluations would relyon a standard test collection of real world SOAPful andRESTful Web Services and the same composition requests.This is in accordance with Kuster and Konig-Ries [52],who stated that the past investments in test collectionsdoes not reflect the huge research activities in semanticweb services. The evaluation of the algorithm based on ahuge standard test collection of web services that couldbe also invoked in reality is thus part of important futurework.

VI. CONCLUSION

Mashups are an attractive means to allow for sponta-neous combination of applications to provide new func-tionality. In contrast to existing mashup creation frame-works, which rely on some programming knowledge bythe user, we propose the automatic generation of mashupsvia an evolutionary algorithm. Based on information aboutthe desired functionality, this algorithm automatically de-termines an appropriate combination of existing web ap-plications. We proposed a detailed plan representation anda mean to simulate a found web service composition withSPARQL. We have thoroughly evaluated the algorithm andshown that it provides correct results within a reasonabletime, even if the number of candidate applications is high.Thus this work addresses the open topic of scalabilityof web service composition. In our ongoing work, weinvestigate, how the determination of required function-ality, which is based on a rather simple user model up tonow, can be improved and personalized by an ontology-based user and task model. This will improve the adaptivebehaviour and leads to research on user-centric ad-hoccomposition of web applications.

REFERENCES[1] R. Tuchinda, P. A. Szekely, and C. A. Knoblock, “Building Mashups by

example,” in IUI, J. M. Bradshaw, H. Lieberman, and S. Staab, Eds. ACM,2008, pp. 139–148.

[2] N. Zang, M. B. Rosson, and V. Nasser, “Mashups: who? what? why?” inCHI Extended Abstracts, M. Czerwinski, A. M. Lund, and D. S. Tan, Eds.ACM, 2008, pp. 3171–3176.

[3] A. Ankolekar, M. Krotzsch, T. Tran, and D. Vrandecic, “The two cultures:Mashing up Web 2.0 and the Semantic Web,” J. Web Sem., vol. 6, no. 1, pp.70–75, 2008.

[4] E. Rahm, A. Thor, and D. Aumueller, “Dynamic Fusion of Web Data,” inXSym, ser. Lecture Notes in Computer Science, D. Barbosa, A. Bonifati,Z. Bellahsene, E. Hunt, and R. Unland, Eds., vol. 4704. Springer, 2007, pp.14–16.

[5] J. Lathem, K. Gomadam, and A. P. Sheth, “SA-REST and (S)mashups :Adding Semantics to RESTful Services,” in ICSC. IEEE Computer Society,2007, pp. 469–476.

[6] F. D. Keukelaere, S. Bhola, M. Steiner, S. Chari, and S. Yoshihama, “SMash:secure component model for cross-domain mashups on unmodified browsers,”in WWW, J. Huai, R. Chen, H.-W. Hon, Y. Liu, W.-Y. Ma, A. Tomkins, andX. Zhang, Eds. ACM, 2008, pp. 535–544.

[7] S. Bitzer, S. Ramroth, and M. Schumann, “Mashups as an Architecture forKnowledge Management Systems,” in HICSS. IEEE Computer Society,2009, pp. 1–10.

[8] V. Hoyer and K. Stanoevska-Slabeva, “Design Principles of EnterpriseMashups,” in Wissensmanagement, ser. LNI, K. Hinkelmann and H. Wache,Eds., vol. 145. GI, 2009, pp. 242–253.

[9] V. Hoyer and M. Fischer, “Market Overview of Enterprise Mashup Tools,” inICSOC, ser. Lecture Notes in Computer Science, A. Bouguettaya, I. Kruger,and T. Margaria, Eds., vol. 5364, 2008, pp. 708–721.

[10] T. Fischer, F. Bakalov, and A. Nauerz, “An Overview of Current Approachesto Mashup Generation,” in Wissensmanagement, ser. LNI, K. Hinkelmannand H. Wache, Eds., vol. 145. GI, 2009, pp. 254–259.

[11] A. Khizhnyak, “Apatar connector guide,” 2008. [Online]. Available:http://www.apatarforge.org/wiki/display/GUI/Apatar+Connector+Guides

[12] D. E. Simmen, M. Altinel, V. Markl, S. Padmanabhan, and A. Singh, “Damia:data mashups for intranet applications,” in SIGMOD Conference, J. T.-L.Wang, Ed. ACM, 2008, pp. 1171–1182.

[13] J. Wong and J. I. Hong, “Making Mashups with Marmite: Towards End-UserProgramming for the Web,” in CHI, M. B. Rosson and D. J. Gilmore, Eds.ACM, 2007, pp. 1435–1444.

[14] Z. Maraikar, A. Lazovik, and F. Arbab, “Building Mashups for The Enterprisewith SABRE,” in Int. Conf on Service-Oriented Computing (ICSOC-08),2008.

[15] M. Sabbouh, J. Higginson, S. Semy, and D. Gagne, “Web Mashup ScriptingLanguage,” in WWW ’07: Proceedings of the 16th international conferenceon World Wide Web. New York, NY, USA: ACM, 2007, pp. 1305–1306.

[16] A. Thor, D. Aumueller, and E. Rahm, “Data integration support for mashupssixth international workshop on information integration on the web, iiweb,vancouver, canada,” 2007.

[17] M. P. Carlson, A. H. H. Ngu, R. M. Podorozhny, and L. Zeng,“Automatic Mash Up of Composite Applications.” in ICSOC, ser.Lecture Notes in Computer Science, A. Bouguettaya, I. Krger, andT. Margaria, Eds., vol. 5364, 2008, pp. 317–330. [Online]. Available:http://dblp.uni-trier.de/db/conf/icsoc/icsoc2008.html#CarlsonNPZ08

[18] M. P. Singh and M. N. Huhns, Service-Oriented Computing: Semantics,Processes, Agents, 1st ed. John Wiley and Sons, 2005.

[19] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. (2001, Mar.)Web Services Description Language (WSDL) 1.1. W3C. [Online]. Available:http://www.w3.org/TR/wsdl

[20] R. Chinnici, J.-J. Moreau, A. Ryman, and S. Weerawarana. (2007, Jun.) WebServices Description Language (WSDL) Version 2.0 Part 1: Core Language. W3C. [Online]. Available: http://www.w3.org/TR/wsdl20/

[21] N. Mitra and Y. Lafon. (2007, Apr.) SOAP Version 1.2 Part 0: Primer (SecondEdition). W3C. [Online]. Available: http://www.w3.org/TR/soap12-part0/

[22] R. T. Fielding, “Architectural Styles and the Design of Networkbased Soft-ware Architectures,” Ph.D. dissertation, University of California, 2000.

[23] T. R. Gruber, “Toward Principles for the Design of Ontologies Used forKnowledge Sharing,” in In Formal Ontology in Conceptual Analysis andKnowledge Representation, N. Guarino and R. Poli, Eds. Kluwer AcademicPublishers, 1993.

[24] W. N. Borst, “Construction of Engineering Ontologies for Knowledge Sharingand Reuse,” Ph.D. dissertation, University of Tweenty, Doctoral Thesis of theUniversity of Tweenty, 1997.

[25] G. Klyne and J. J. Carroll. (2004, Feb.) Resource Description Framework(RDF):Concepts and Abstract Syntax. W3C. [Online]. Available: http://www.w3.org/TR/rdf-concepts/

[26] D. Brickley and R. Guha. (2004, Feb.) RDF Vocabulary DescriptionLanguage 1.0: RDF Schema. W3C. [Online]. Available: http://www.w3.org/TR/rdf-schema/

[27] S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. L.McGuinness, P. F. Patel-Schneider, and L. A. Stein. (2004, Feb.)OWL Web Ontology Language Reference . W3C. [Online]. Available:http://www.w3.org/TR/owl-ref/

[28] D. Nardi and R. J. Brachmann, “An Introduction to Description Logics,” in

The Description Logic Handbook: Theory, Implementation, and Applications,1st ed., F. Baader, D. Calvanese, D. L. McGuinness, D. Nardi, and P. F. Patel-Schneider, Eds. Cambridge University Press, 2003.

[29] F. Baader, D. Calvanese, D. L. McGuinness, D. Nardi, and P. F. Patel-Schneider, Eds., The Description Logic Handbook: Theory, Implementation,and Applications, 1st ed. Cambridge University Press, 2003.

[30] D. Martin, M. Burstein, J. Hobbs, O. Lassila, D. McDermott, S. McIlraith,S. Narayanan, M. Paolucci, B. Parsia, T. Payne, E. Sirin, N. Srinivasan,and K. Sycara. (2004, Nov.) OWL-S: Semantic Markup for Web Services.[Online]. Available: http://www.w3.org/Submission/OWL-S/

[31] D. Fensel, M. Kifer, J. de Bruijn, D. Foxvog, U. Keller, M. Kerrigan,J. Kopeck, R. Krummenacher, H. Lausen, A. Sirbu, D. Roman, J. Scicluna,N. Steinmetz, and N. Steinmetz. (2008, Aug.) D16.1v1.0 WSML LanguageReference. [Online]. Available: http://www.wsmo.org/TR/d16/d16.1/v1.0/

[32] J. Farrell and H. Lausen. (2007, Aug.) Semantic Annotations for WSDLand XML Schema. [Online]. Available: http://www.w3.org/TR/sawsdl/

[33] M. Klusch, “Semantic web service description,” in CASCOM: IntelligentService Coordination in the Semantic Web (Whitestein Series in SoftwareAgent Technologies and Autonomic Computing), 1st ed., M. Schumacher,H. Helin, and H. Schuldt, Eds. Birkhauser Basel, 9 2008.

[34] D. Martin, M. Burstein, G. Denker, D. Elenius, J. Giampapa, D. McDermott,D. McGuinness, S. McIlraith, M. Paolucci, B. Parsia, T. Payne, E. Sirin,N. Srinivasan, and K. Sycara. OWL-S 1.2 Pre-Release. [Online]. Available:http://www.ai.sri.com/daml/services/owl-s/1.2/

[35] E. Prud’hommeaux and A. Seaborne. (2008, Jan.) SPARQL Query Languagefor RDF. W3C. [Online]. Available: http://www.w3.org/TR/rdf-sparql-query/

[36] S. Russell and P. Norvig, Artificial Intelligence: A Modern Approach, 2nd ed.Englewood Cliffs, New Jersey: Prentice Hall, 2003.

[37] M. Klusch, “Semantic web service coordination,” in CASCOM: IntelligentService Coordination in the Semantic Web (Whitestein Series in SoftwareAgent Technologies and Autonomic Computing), 1st ed., M. Schumacher,H. Helin, and H. Schuldt, Eds. Birkhauser Basel, 9 2008.

[38] M. Klein and B. Konig-Ries, “Integrating preferences into service requeststo automate service usage,” Dezember 2004.

[39] M. Schumacher, H. Helin, and H. Schuldt, Eds., CASCOM: Intelligent ServiceCoordination in the Semantic Web (Whitestein Series in Software AgentTechnologies and Autonomic Computing), 1st ed. Birkhauser Basel, 9 2008.

[40] Y. Li, X. Yu, L. Geng, and L. Wang, “Research on Reasoning of the DynamicSemantic Web Services Composition,” in Web Intelligence. IEEE ComputerSociety, 2006, pp. 435–441.

[41] U. Kuster, M. Stern, and B. Konig-Ries, “A Classification of Issures andApproaches in Service Composition,” in First International Workshop onEngineering Service Compositions (WESC05), Amsterdam, Netherlands, De-cember 2005, pp. 00–00.

[42] S. Bleul, T. Weise, and K. Geihs, “Making a Fast Semantic Service Com-position System Faster,” in CEC/EEE. IEEE Computer Society, 2007, pp.517–520.

[43] F. Bakalov, B. Konig-Ries, A. Nauerz, and M. Welsch, “Ontology-BasedMultidimensional Personalization Modeling for the Automatic Generation ofMashups in Next-Generation Portals,” in Proceedings of the 1st InternationalWorkshop on Ontologies in Interactive Systems held in conjunction with HCI2008, Liverpool, United Kingdom, September 2008.

[44] ——, “A Hybrid Approach to Identifying User Interests in Web Portals,”in Proceedings of the 9th International Conference on Innovative InternetCommunity Systems, Jena, Germany, June 2009.

[45] M. Klein, B. Konig-Ries, and M. Mussig, “What is needed for semanticservice descriptions? A proposal for suitable language constructs,” IJWGS,vol. 1, no. 3/4, pp. 328–364, 2005.

[46] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein, Introduction toAlgorithms, 2nd ed. The MIT Press, 9 2001.

[47] K. Weicker, Evolutionare Algorithmen (2. Auflage). Stuttgart: Teubner, 2007.[48] T. Fischer, “Automatic Generation of Semantic Mashups in Web Portals,”

Master’s thesis, Friedrich-Schiller University Jena, November 2008. [Online].Available: http://www.db-thueringen.de/servlets/DocumentServlet?id=11921

[49] F. Benigni, A. Brogi, and S. Corfini, “Discovering service compositions thatfeature a desired behaviour,” in CIbSE, M. Lencastre, J. F. e Cunha, andA. Valecillo, Eds., 2008, pp. 4–16.

[50] C. J. Petrie and C. Bussler, “The Myth of Open Web Services: The Riseof the Service Parks,” IEEE Internet Computing, vol. 12, no. 3, pp. 96–95,2008.

[51] U. Kuster, B. Konig-Ries, and A. Krug, “OPOSSum - An Online Portal toCollect and Share SWS Descriptions,” in Proceedings of the 2nd IEEE In-ternational Conference on Semantic Computing (ICSC2008), Demo Session,Santa Clara, CA, USA, August 2008.

[52] U. Kuster and B. Konig-Ries, “On the Empirical Evaluation of SemanticWeb Service Approaches: Towards Common SWS Test Collections,” in Pro-ceedings of the 2nd IEEE International Conference on Semantic Computing(ICSC2008), Santa Clara, CA, USA, August 2008.

[53] K. Hinkelmann and H. Wache, Eds., Fifth Conference Professional Knowl-edge Management: Experiences and Visions, March 25-27, 2009 in Solothurn,Switzerland, ser. LNI, vol. 145. GI, 2009.