Negotiating Robustness in Semantic Web Service Composition

Freddy Lecue, Usman Wajid, Nikolay MehandjievThe University of Manchester

Booth Street East, Manchester, UK{(firstname.lastname)@manchester.ac.uk}

Abstract—Automating Web service composition is a chal-lenging area of Service Oriented Computing, requiringprogress on a number of issues concerning the automationof control flow, the alignment of data flow, verification,execution monitoring, etc. In this paper, we focus on aligningdata flow in semantic web service composition to ensure therobustness when executing the composed service by prevent-ing any cases when the wrong type of data is passed on fromone service to the next. The proposed solution is unique inthat it ensures the robustness of data flow when automaticallycomposing web services through the use of agent-basednegotiation between web service providers. Starting fromthe semantic specification of a non-robust composition, weadapt the mechanism of Concept Abduction to compute theset of additional semantic descriptions necessary to ensurerobustness of the semantic connections within the composedservice. An agent-based negotiation is then used to solicitthe additional semantic definitions which are required forachieving robust web service compositions.

Keywords-Service Composition, Web Service, SemanticWeb, Description Logic, Agent Negotiatiion.

I. I NTRODUCTION

The Semantic Web extends the World Wide Web struc-tures by giving semantic descriptions to web resources,be it web pages or web services [1]. Rich description lan-guages based on Description Logics DLs [2], such as theWeb Ontology Language (OWL) [3], are used to providesemantic annotations. A number of these languages arespecialised for describing web services, including OWL-S[4], WSMO [5] or SA-WSDL [6]. We can thus define

Semantic web services [7] as web services that havebeen enhanced with formal semantic descriptions.

These descriptions allow automatic reasoning about thefunctionalities of Semantic Web Services. This reason-ing can support the automated discovery, selection andcomposition of different services to accomplish the goalsspecified by service consumers.

A composition of existing web services is often usedto overcome the problem where no single service cansatisfy the goal specified by the service consumer. Startingfrom an initial set of available services, web servicecomposition aims at selecting and inter-connecting Webservices provided by different partners in order to achievea particular goal.

In doing this, we need to consider many issues related tocontrol flow, data flow, verification, execution monitoring,or recovery actions (e.g.,compensation). In this work, westudy robustnessof data flow in semantic Web servicecomposition, i.e., how to ensureseamlessdata integration

in composition, avoiding cases where the wrong typeof data can be passed from one service to another. Tothis end we focus on data which is exchanged throughoutput and input parameters of web services. Even ifsome methods have approached this issue by discoveringpotential semantic connections between web services [8],no solution addresses the issue of robust data flow within acontext of automated composition of web services. Indeed,once semantic connections between the output parameterof one service and an input parameter of another (alsoknown as semantic links [9]) are elaborated during thecomposition process [9], [10], some of them can causefailure during the execution of the composed service.

For instance some input parameters of services mayrequire data which is narrower in range than the dataprovided by the output parameters of other services. Thus,the compositions that are realized by semantic match-making are meaningful, but rarely robust and executable.This is mainly caused by heterogeneity of Web servicedescriptions, which affects the data integration within Webservice compositions.

In this work, semantic links are considered mainly fori) guaranteeing the semantic connection and interactionbetween services, and ii) detecting areas of non-robustnessin the data flow of any web service composition. Fromthis we can compute the DL-based description of the datarestrictions which can be added to the specifications ofthe service outputs to make the whole composition robust.Then we elaborate this approach into an agent-basedsolution, which allows the negotiation of these additionalrestrictions within the different web service providers, toensure the implementation of the robust version of theweb service composition. We illustrate the operation ofthe proposed approach using an extended example runningthrough the paper.

The remainder of this paper is organised as follows.In the next section we review semantic links based webservice composition, as well as the robustness charac-teristic. Section 3 presents an approach to compute aDL-based description of restrictions which can be addedto turn a non-robust semantic linkinto a robust one.Section 4 presents the protocol used by agents to negotiatethe acceptance of these additional restrictions. Section 5discusses the novelty of the proposed approach comparedto related work. Finally Section 6 draws some conclusionsand possible future directions.

II. W EB SERVICE COMPOSITION

First of all, we present the concept ofsemantic links.Then we restate the definition of theirrobustnessandfinally we describesemantic-link-based web service com-position.

A. Semantic Links

In the semantic web, input and output parameters ofweb services are specified using concepts from a commonontology1 or Terminology T (an example of such isgiven in Figure 3), where the OWL-S profile [4], WSMOcapability [5] or SA-WSDL [6] can be used to describethem (through semantic annotations).

At functional level web service composition involvesretrieving some semantic links between output parame-ters Out si ∈ T of servicessi and input parametersIn sj ∈ T of other servicessj . Such a semantic link[9] sli,j (Figure 1) between two functional parameters ofsi andsj is formalized as〈si, SimT (Out si, In sj), sj〉.Thereby si and sj are partially linked according to amatching functionSimT .

The latter function expresses which matching typeis employed to chain services. The range ofSimT isreduced to the four well known matching type introducedby [11] and the extra type Intersection [12]:

• Exact If the output parameterOut si of si and theinput parameterIn sj of sj are equivalent; formally,T |= Out si ≡ In sj .

• PlugIn If Out si is sub-concept of (i.e.,more specific than) In sj ; formally,T |= Out si @ In sj .

• Subsume If Out si is super-concept of (i.e., moregenral than)In sj ; formally, T |= In sj v Out si.

• Intersection If the intersection ofOut si andIn sj

is satisfiable; formally,T 6|= Out si u In sj v ⊥.

• Disjoint OtherwiseOut si andIn sj are incompat-ible i.e.,T |= Out si u In sj v ⊥.

Output ParameterService Input Parameter

ServiceService

Inn sj

Semantic Link sl

sjOut sisi

In0 si

Ink si

Inn si

(SimT (Out si, In sj))

In sj

Out sj

Semantic Link sli,jOut0 si In0 sj

Outn si

Figure 1. A Semantic Linksli,j .

B. Robust Semantic Link

The matching functionSimT enables us to determinethe degree of semantic compatibility among independently

1Distributed ontologies are not considered here but are largely inde-pendent of the problem addressed in this work.

defined web service descriptions at design time. This canrange from the strongly compatibleExactthroughPlugIn,Subsumeand Intersection to the strongly incompatibleDisjoint. However, as emphasized by [13], the matchingtypes Intersection and Subsume need some refinements tobe usable for semantic-links-based web service composi-tion.

Example: Step 1. (Semantic Link & Subsume MatchingType)Suppose s1 and s2 are two services such thatthe output parameter NetworkConnection ofs1 is (semantic) linked to the input parameterSlowNetworkConnection of s2 (sl1,2 in Figure2). According to the example ontology in Figure 3, thissemantic link is valued by a Subsume matching type sinceNetworkConnection A SlowNetworkConnection.

It is obvious that such a semantic link should notbe directly applied in a service composition since theNetworkConnection is not specific enough to be usedby the input parameterSlowNetworkConnection,which may cause data-based exception during execution.Indeed the output parameterNetworkConnection re-quires further restrictions to ensure a data-robust compo-sition of s1 and s2.

Output ParameterInput ParameterService

Over Specified Description

SlowNetworkConnection

≡ ≡

s2w

∀netPro.P rovider∀netPro.P rovider

∀netSpeed.Speed u ∀netSpeed.Adsl1Mu

Under Specified Description

Semantic Link sl1,2

s1NetworkConnection

Semantic Link sl

Figure 2. Illustration of a Semantic Linksl1,2 valued by a SubsumeMatching Type.

A semantic link valued by the Intersection matchingtype requires a comparable refinement. In this direction,[13] defined a robust semantic link and their composition.

NetworkConnection ≡ ∀netPro.Provider u ∀netSpeed.Speed

SlowNetworkConnection ≡ NetworkConnection u

∀netSpeed.Adsl1M

FastNetworkConnection ≡ NetworkConnection u

∀netSpeed.AdslMax

Adsl1M ≡ Speed u ≥ 1mBytes

AdslMax ≡ Speed u ≥ 8mBytes

AdslSuperMax ≡ Speed u ≥ 16mBytes

Address @ >, IPAddress ≡ Address u ∀protocol.IP

V oIPId ≡ Address u ∀network.Telecom

Figure 3. Sample of anALN TerminologyT .

Definition 1. (Robust Semantic link)A semantic link〈si, SimT (Out si, In sj), sj〉 is robust

iff the matching type betweenOut si andIn sj is eitherExact or PlugIn.

Property 1. (Robust Web Service Composition)A composition is robust iff all its semantic links are robust.

A possible way to replace a link〈si, SimT (Out si, In sj), sj〉 valued by an Intersectionor Subsume matching type in its robust form consistsin computing the information (as DL-based description)contained in the input parameterIn sj and not in theoutput parameterOut si.

This information is then used as an additional restrictionon the Out si data type when a suitable web serviceis procured. We say that addition this latter restriction”transforms” the non-robust semantic link in its robustform.

To do this, we apply initial ideas of [8], which adapt anon standard inference matching type i.e., theAbductionoperation [14], [15] (Definition 2) for comparingALNDL-based descriptions. Alternatively (depending on theDL expressivity), different inference matching types suchasDifferencecould be employed (Section V-A).

Definition 2. (Concept Abduction)Let L be a DL,C, D be two concepts inL, andT be aset of axioms inL. A Concept Abduction Problem (CAP),denoted as〈L, C, D, T 〉 aims at finding Extra Description,as a conceptH ∈ L such thatT |= C u H v D.

According to Definition 2, a compact representation of“difference” H between DL-based descriptionsOut si

andIn sj of a semantic linksli,j can be computed.Such a descriptionH is formally defined byT |=

Out sj u H v In si as a solution of theConceptAbductionproblem〈L, Out si, In sj , T 〉. In other wordstheExtra DescriptionH refers to information required byIn sj but not provided byOut si to ensure a correct dataflow between web servicessi andsj .

Example: Step 2. (Robustness and Extra Description)Suppose the semantic linksl1,2 in Example: Step 1 andFigure 2.

Such a link is not robust enough (Definition 1)to be applied in a robust composition sinceT |=NetworkConnection A SlowNetworkConnection.

The additional restriction which has to beprovided to the NetworkConnection if thisoutput is to be used by the input parameterSlowNetworkConnection is referred by theExtra DescriptionH of the Concept Abduction Problem〈L, NetworkConnection, SlowNetworkConnection, T 〉i.e., ∀netSpeed.Adsl1M (see Figure 3).

In other words, we can turn non-robust semantic linksinto robust ones by retrieving theExtra Descriptionthatchanges an Intersection in a PlugIn matching type, and aSubsume by an Exact matching type.

C. Semantic Link Composition Model

Here, the process model of web service composition andits semantic links is specified by a directed graph which

has the web service specifications as its nodes, and thesemantic links (data dependencies) as its edges.

In addition some basic composition constructssuch as sequence, conditional branching (i.e., OR-Branching), structured loops, concurrent threads (i.e.,AND-Branching), and inter-thread synchronization can bespecified, where their semantic is similar to the one theywill be given within a statechart [16]. In the followingwe focus on data flow involved in any statechart-modeledsemantic web service composition.

Example: Step 3. (Process Model of a Semantic Linkbased Composition)Supposesi,3≤i≤8 are six services extending Example: Step1 and Figure 2 in a more complex composition. Theprocess model and the data flow diagram of this compositeservice is illustrated in Figure 4. Such a compositionconsists in an OR-Branching and AND-Branching whereinnine semantic links (as data flow) are involved.

Given i) an approach to compute robust semantic links(Definition 2) and ii) the previous model of web servicecomposition, we address the issue of automatically com-puting robust web service composition (Property 1).

Example: Step 4. (Robustness of Web Service Compo-sition)Suppose the composition in Example: Step 3 and Figure 4.In addition tosl1,2, sl1,4 (valued by a Subsume matchingtype) andsl7,8 (valued by an Intersection matching type)are two other non-robust semantic links. In this respect,the issue that we address is how to define the overall ExtraDescription that is required for robust composition?

III. W HAT IS M ISSING IN NON ROBUST

COMPOSITIONS?

Definition 2 provides the mechanism to compute theDL-based additional restriction which can be added toeach non-robust semantic link to ensure its robustness.This description is useful for achieving robustness at locallevel (i.e., computing description ofeachnon-robust linkin an independently way and then requesting it). Thereforesuch a description can be provided separately by end-users, other services or any third party, depending on theapplication we want to automate.

Before automating the process that provides descriptionfor non-robust compositions, we focus on an overallmethod that gathers the differentExtra Descriptionin amore specific (in terms of Subsumption “@” relationship)description, hence a more specific view of missing de-scription in robust web service composition.

A. Most Specific Description

Suppose a non-robust composition of services whereinn semantic links are not robust enough. Therefore someExtra Descriptions Hi,1≤i≤n

are required to changenon robust semantic links into their robust forms.Here we suggest to group them in a more specificform H (Definition 3) rather than using the local de-scription to achieve local robustness. In this definition

Connection

Slow

Semantic Link sl Input Parameter Output Parameter

NetworkConnection

Fast

Network

Connection

s: Service

VoIPId

IPAddress

NetworkSequence

s4

ANDBranchings1 s5

s2 s3

OR-Branching

s6

s7

sl5,7

sl6,8sl1,2

sl4,5

s8

sl7,8sl1,4

sl2,3

sl5,6

sl3,5

Figure 4. Data Flow Diagram of a Semantic Link based Composition.

〈si, SimT (Out si, In sj), sj〉 refers to a semantic linkin the composition model.

Definition 3. (Most Specific Description)The Most Specific DescriptionH, which is required in anon-robust composition is defined by the lower bound ofits Extra Description. FormallyH is defined as follows:

H := infv{H ∈ 〈L, Out si, In sj , T 〉}\set {>} (1)

wherein 〈si, SimT (Out si, In sj), sj〉 are non-robustsemantic links andT 6|= Out si u In sj v ⊥.

The Most Specific DescriptionH of a Web servicecomposition gathers different descriptions from the set〈L, Out sy, In sx, T 〉 wheresy andsx are chained by anon-robust semantic link. Since Definition 3 computes theMost Specific Description, such a DL-based descriptionshould be used by a finite set of not robust semantic linksto change them in their robust forms.

During computation, the relationship of each non-robustlink to one of the tuple elements within theMost SpecificDescriptionH is stored separately, to allow the transfor-mation into robust form. The descriptions used to performthese changes will be theMost Specific Descriptionsofthe Extra Description.H does not only explain why the composition process

failed but also gives a solution of the robustness problemof semantic links hence a way to reach robustness insemantic Web service composition.

Example: Step 5. (Most Specific Description)Let us consider the composition depicted in Figure 4.Such a composition exposes a Web service compositionwhereinsl1,2, sl1,4 and sl7,8 are not robust. Some ExtraDescription are required in order to obtain a compositionof robust semantic links. The computation ofH givesdirections to solve local robustness of semantic links.According to Definition 3, the Most Specific DescriptionHis constituted of conjunction of three Concept AbductionProblem in DL and their respective solutions:

1) 〈L, NetworkConnection, SlowNetworkConnec-tion, T 〉 to changesl1,2 by a semantic link valued byan Exact matching type i.e.,∀netSpeed.Adsl1M

2) 〈L, NetworkConnection, FastNetworkConnec-tion, T 〉 to changesl1,4 by a semantic link valued byan Exact matching type i.e.,∀netSpeed.AdslMax,

3) 〈L, V oIPId, IPAddress, T 〉 to replacesl7,8 by asemantic link valued by a PlugIn matching type i.e.,∀protocol.IP .

Since other semantic links are robust, and∀netSpeed.AdslMax @ ∀netSpeed.Adsl1M , H isdefined by

{∀netSpeed.AdslMax, ∀protocol.IP} (2)

Each DL-based element ofH is attached to their non-robust semantic links in order to solve robustness. Forinstance∀netSpeed.AdslMax will be attached to seman-tic links sl1,2 and sl1,4 whereas∀protocol.IP will beattached tosl7,8.

In this work, theMost Specific DescriptionH is com-puted independently (by means of a DL reasoner) ofthe composition constructs involved in the composition.However this definition can be adapted by considering,for instance, different approaches to compute theMostSpecific Descriptioni.e., we can compute different levelsof description on each OR-Branching and then considerall of them during the robustness evaluation. We can alsoimagine alternative approaches for compositions whereinsome structured loops are involved.

During all manners of computation we need to preservethe link between each non-robust link such assl1,2 and itstuple element in theMost Specific DescriptionH (in thisexample∀netSpeed.AdslMax), to allow for the effectiveprocurement of web services at the next stage.

B. XML Encoding of Extra Description

Since we aim at automatically providing robust com-position of web services, we present a common interface(as an XML encoding) that any third party such as webservices or agents can interact with in order to manipulateand reason onExtra Descriptionand their most specificform. To this end we adapt the DIG interface specification2

[17] in order i) to model any Extra DescriptionHi,1≤i≤n

2http://dig.cs.manchester.ac.uk/.

or H (Definition 3), and ii) to provide uniform access toDL reasoners, hence facilitating discovery or negotiationof the latter description by means of DL reasoning pro-cesses.

In more details we considered i) a subset of theDIG (DL Implementation Group) overall specification byfocusing only on itsConcept Language(actually anylanguage no more expressive thanSHOIQD such asthe ALN DL language we use in this work), and morespecially its XML Schema3. In such a subset

• Atomssuch as Concepts and ObjectProperty;• Concept Operatorssuch asAND (u), ATLEAST(≥

n), ATMOST(≤ n), ALL (∀),

are considered for the XML definition of any Extra De-scription (as well as their most specific form).

Example: Step 6. (XML Encoding of Extra Descrip-tion)Suppose{∀netSpeed.AdslMax, ∀protocol.IP} is theExtra Description in Example: Step 5. Its XML encodingis defined as following:

<?xml version="1.0" encoding="ISO-8859-1"?><REQUEST

xmlns="http://dl.kr.org/dig/2003/02/lang"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://dl.kr.org/dig/2003/02/langhttp://dl-web.man.ac.uk/dig/2003/02/dig.xsd"uri="urn:uuid:abcdefgh-1234-1234-12345689ab">

<defconcept name="ED1"/><equalc>

<catom name="ED1"/><all>

<ratom name="netSpeed"/><catom name="AdslMax"/>

</all></equalc>

<defconcept name="ED2"/><equalc>

<catom name="ED2"/><all>

<ratom name="protocol"/><catom name="IP"/>

</all></equalc>

</REQUEST>

where ED1 and ED2 are respectively the Extra Descrip-tions ∀netSpeed.AdslMax and ∀protocol.IP .

Once the set ofExtra DescriptionsH andH (Definition3) are computed through Concept Abduction, a processthat automatically compiles them (for instance, from anyservice providers) is required. Here the Extra Descriptionswill be negotiated with other agents representing webservice providers. In other words the agents are thenresponsible of negotiating theExtra Descriptionthat thesystem needed to elaborate the final robust composition ofweb services, hence satisfying the initial user request inan automatic way.

IV. N EGOTIATING ROBUSTNESS OFCOMPOSITION

Software agents have a high degree of autonomy, sothey can decide when and under what conditions an actionshould be performed. This coupled with their interaction

3http://dig.cs.manchester.ac.uk/schema.xsd.

capability makes them suitable for facilitating dynam-ic/automated composition of services and ensuring itsrobustness as well, which would otherwise require manualcoordination among various entities.

Existing approaches for automated service composition[18], [19], [20] require the existence of a central direc-tory of service specifications, which restricts the scopeof automation to computing compatibility and efficiencyof potential compositions. However, in these approachesa composition is typically based on a single-iterationapproach and fails to involve service providers in findingmissing additional services.

In this paper, we propose an agent-based solution toaddress the complex issues underlying automation ofrobust service composition. Our approach exploits theinherent interaction capability of agent technology, whichallows agents representing service providers to play a moreactive role in the composition e.g., agents can exchangecounter proposals and impose conditions over the use ofservices. Finally, a negotiation mechanism as a process ofreaching on agreement (provision of desired informationand reducing inconsistency) has been used to realize robustservice composition.

Negotiation is a process in which interested partiesresolve, dispute or agree up on course of action. Agent-based negotiations typically imply the use of a negotiationprotocol to support coordinated action on a specific matteror topic. An Agent Interaction Protocol (AIP) describes acommunication pattern as allowed sequence of messagesbetween agents. In Section III we have discussed thespecific type of information which represents the topic ofnegotiation. This is complemented by the details of thenegotiation protocol, provided in the next section.

A. Protocol for Robust Composition

In agent-based research a variety of negotiation pro-tocols are proposed that support varying perspective ofagents as well as facilitate different types of negotiationse.g., [21], also formalised as official FIPA specification4.The generic and task independent nature of these protocolsmeans that they can be used in different domains. Forinstance, Contract-Net protocol and English Auction pro-tocols have been employed for agent-based service com-positions [22], [23]. However, a common aspect of theseprotocols is that they give initiator agents the control overinteraction (or negotiation), whilst the role of participatingagents is limited to providing the required information.

In contrast, in the proposed approach agents are givena more active role. They can negotiate using proposalsand counter-proposals to reach on agreement over varyingperspectives. To enable such a behavior, a negotiationprotocol is proposed.

The proposed protocol is a customized form of FIPAIterated Contract Net Interaction Protocol5. It allowsagents to employ a range of strategies in terms of

4FIPA English Auction Interaction Protocol Specification.http://www.fipa.org/specs/fipa00031/XC00031F.html

5http://www.fipa.org/specs/fipa00030/SC00030H.html

generating proposals; evaluating proposals and offeringcounter proposals [6] until an agreement is reached or thenegotiation is terminated. In the following, we assumean agent (here the Initiator agent) being responsiblefor negotiating the provision of the most specificExtraDescription H with other agents, called Participantagents. The latter represent different service providers,therefore they would be able to satisfy different aspectsof the semantic descriptions that can potentially resolvethe robustness issue. The main role of the protocolis to support the negotiation about the provision ofthe descriptionH. The agent negotiation process issummarized in following steps (Figure 5):

1) The interaction protocol starts when the Initiatoragent sends a Call-for-Proposals (CFP) to theParticipant agent(s). The CFP contains the XMLencoding (as shown in Example: Step 6) in itsmessage contents.

2) A Participant agent decodes the XML encoding andconsults its service providers regarding the requiredMost Specific Description.

3) If the Participant agent is willing and able tocontribute towards the robustness issue then it willrespond with Propose, otherwise it will send Refuse.In Propose, the message contents may containthe required XML encoding of a proposed ExtraDescriptionHp1, which is subsumed by theMostSpecific DescriptionH. This may be accompaniedby costs or other conditions that the Participantagent wants to attach to this proposal.

4) On receiving a proposal (or proposals from severalagents), the Initiator agent may decide whetherto accept a proposal (and hence send an Accept-Proposal response), or to iterate the processby issuing a revised CFP with a new requireddescription Hp2. The latter is subsumed by theoriginal Most Specific DescriptionH and specifiesthe elements ofH which are not yet covered by theset of received proposalsHp1 (see M3 in SectionIV-B for further details).

5) The protocol ends when the Initiator agent sendsAccept-Proposal to a set of agents, or when it doesnot issue a new CFP.

6) After receiving Accept-Proposal a Participant cansend an optional acknowledgment to the Initiatoragent.

The graphical notation (Figure 5) provides a high levelspecification of the protocol. However, more detail is oftenrequired for the design of agents that take part in the pro-tocol. For example Initiator agent requests proposals fromParticipant agents by sending a call-for-proposal (CFP).However, the graphical notation do not stipulate neither

Figure 5. Negotiation Protocol for facilitating robust service composi-tion.

the conditions for the use of a particular communicativeact (CA) nor the procedure employed by agents to generatetheir responses.

To define the communicative acts along with theconditions for their use, for each CA we specify anypre-conditions required for its utterance, the type ofresponses required and the impacts of the utterance onthe information store of the agent.

S1) Call-for-Proposal(Ax, Ay,H), by initiating a CFPthe Initiator agentsAx can invite proposal fromAy

agents in the system about the proposition of therequired Most Specific DescriptionsH.

Precondition: To initiate a CFP the initiatoragentsAx must be responsible for a compositionwhich is not robust, and must have a calculated theMost Specific Descriptions - see M1, Section IV-B.

Expected Response:

Response(CFP(Ax, Ay,H)) =

{

Refuse(Ay→xi,H)

Propose(Ay→xi,Hp1

)

where CFP(Ax, Ay,H) refers to the call-for-proposal concerningH. Message(Ay→xi

,H) meansthat agentsAy sends Message with H to onespecific agentAxi

. Hp1represents the proposal by

the participating agents to a particular Initiator agent.

Information Store: No update.

S2) Propose(Ay, Axi,Hp1

) , whereAy refers to the setof Participant agents.Axi

∈ Ax is the initiator of

the CFP such thatHp1refers to the proposal which

is generated in response to theH in CFP.

Precondition: A call-for-proposal must bepublished before the use of this CA. The agentsAy

must have the information e.g.,Hp1v H that may

result in the robust composition.

Expected Response: The initiator of CFPi.e. Axi

have the following options:

Response(Propose(Ay, Axi,Hp1

))

=

Accept Proposal(Ax→yj,Hp1

)

Reject Proposal(Ax→yj,Hp1

)

CFP(Ax, Ay,H2)

The response should be communicated to theparticipanting agents e.g.Ayj

where Ayj∈ Ay,

using the appropriate CA.

Information Store: For each proposalHp1a

tuple (Axi, Ayj

,Hp1) is inserted intoIS(Ay).

S3) Refuse(Ay, Axi,Hr), where Hr refers to the

conditions for refusingH in the previously receivedCFP.

Precondition: A call-for-proposal must bepublished before the use of this CA and this CAcannot be uttered after Propose(Ay, Axj

,Hp1).

Expected Response: Not required

Information Store: No update.

S4) Accept-Proposal(Axi, Ayj

,Hp1), by using this CA

the Initiator agentAxiconveys the acceptance of the

proposalHp1which was submitted by the Participant

Ayj∈ Ay .

Precondition: A proposal in the form Propose(Ayj

, Axi,Hp1

) must have been received by theagentAxi

before the utterance of this CA.

Expected Response: Not required

Information Store: A tuple (Axi, Ayj

,Hp1) is

inserted intoISAx.

Finally we specify the optional communicativeact in the proposed protocol.

S5) Inform(Ayj, Axi

,H), by using this CA the Participantagent Ayj

acknowledge the use of information inHp1

by the Initiator agentAxi∈ Ax.

Precondition: Ayjcan only acknowledge

the use of information inHp1after it receives

Accept-Proposal(Axi, Ayj

,Hp1) from the agent

Axi∈ Ax.

Expected Response: Not required

Information Store: No update.

B. Enabling Automated Negotiation

The specification of communicative acts and thecondition for their use in Section IV-A highlight thesyntactical aspects of the protocol. However, the genericnature of these rules needs to be complemented withspecific processing and decision-making mechanisms. Inthis respect,we recognize high level agent functionalitythat is necessary for enabling automated negotiationsamong software agents.

M1: Need for Most Specific Descriptions:A mechanismthat enable agents to compute and realize theneed for Most Specific Descriptions (Definition 3),which is required for robust composition. The non-availability of Most Specific Descriptions can actsas a trigger for automated agents-based negotiationprocess supported by the proposed protocol.

M2: Proposal Formation:A mechanism for participatingagents to compute the required information andgenerate a proposal. The mechanism also ensuresthat the same information (in the current proposal)is not already presented to the initiator agent in theprotocol.

M3: Proposal Evaluation and Ranking:This mechanismallows the initiator agent to evaluate the receivedproposals and compute the best course of action.At every round of proposals, the initiator agentwill calculate the set of outstanding elements ofHand, unless this set is empty, will proceed to inviteproposals covering these outstanding elements.Depending on the configuration of individualinitiator agents, the proposal gathering may stopwhen all known service providers have beencontacted or after a fixed number of iterations, evenif there are still outstanding elements not covered byproposals. The initiator agent will then proceed toevaluate and rank proposals using any of the knownsolutions to the set partitioning problem (see [24]).Further details about formulating this problem areprovided below.

M4: Notification of Decision:A mechanism for initiatoragent to notify participant agents about the outcomeof their proposals. This mechanism follows M3, asshown in Figure 6.

M5: Acknowledgement:This mechanism allows theparticipant agent to acknowledge the use of its(previously proposed) information by the initiatoragent. In contractual terms this acknowledgementcan serve as the receipt for the use of service.

Figure 6. The Specification of Proposal Evaluation and NotificationMechanisms.

Mechanism 3 above uses the well-known set partition-ing problem as formulated in [24] (equation (SPP) on page712):

min{c× x|Z × x = e, xj = 0 or 1, ∀j ∈ N} (3)

We seek to minimise the cost functionc × x, wherec is the cost vector, containing the costs for selectingeach provider, andx is the vector of choices about whichprovider’s offer to accept. Each provider is offering toprovide some elements ofH, these are recorded as valuesof 0 or 1 in the matrixZ. We should have each elementof H covered exactly once, soZ × x = e wheree is avector containing “1” in every element. Thus we shouldremove from consideration those elements ofH for whichwe have no offers.

We have proposed the high level functionality of themechanisms that are required for automated negotiationsamong software agents. In this respect, Figure 7 showshow these mechanisms feed into the different communica-tive actions that are defined in Section IV-A.

Figure 7. The Processing Mechanisms Feed into Various Communica-tive Actions in the Protocol.

Example: Step 7. (Negatiation of Robustness)Upon computing the Most Specific DescriptionH providedin (2), the initiator agent sends out a CFP specifyingH asa condition. The CFP is addressed to a number of serviceprovider agents, which are referred to as ”Participants”in the protocol. One of the participants can provides1,but instead of the condition

∀netSpeed.AdslMax for sl1,2, (4)

they can propose a new condition∀netSpeed.AdslSuperMax. The latter is subsumedby ∀netSpeed.AdslMax, so it still leaves the semanticlink sl1,2 robust. So the description proposed is

Hp1 : ∀netSpeed.AdslSuperMax (5)

The Initiator accepts this proposal and sends outAccept Proposal(AInitiator→Participant,Hp1). Notethat the description∀protocol.IP (which is requiredby sl1,2 to be robust) could be provided by the latterparticipants or any other as well.

Alternatively, they can propose a newHp2, whichrequires the speed to be≥ 12mBytes, hoping anotherrecipient will agree on this, or the first recipient will droptheir speed requirements.

V. RELATED WORK

In this section we discuss the advantages of the pro-posed approach compared to existing research work in theareas of i)Concept Abduction, ii) Robustnessin semanticweb service composition and iii)Agent-based Negotiationfor web service composition.

A. Concept Abduction

Besides Concept Abduction, the Concept Difference[25] can be applied to evaluate robustness in web servicecomposition. The difference operation of [25] requires asubsumption relation between descriptions to be matchedsince it requires the extra and strict conditionC v D.This strict condition makes Concept Difference impossibleto use in case of semantic links valued by an Intersec-tion matchmaking type. Therefore robustness cannot beresolved by using such an operator.

Alternatively [26] proposed a refinement of this defini-tion by taking the syntactic minimum instead of a semanticmaximum in [25]. Its main advantages are as follows: i)firstly it does not contain redundancies in its result and i)secondly it is more readable by a human user.

However Concept Difference [25] and [26] are more ac-curate, but more time consuming reasoning than ConceptAbduction since they perform an equivalence between twoconcept descriptions (T |= BuD ≡ C or BuD ≡ CuD)whereas the Concept Abduction computes a subsumptionof concept descriptions (T |= B u D v C).

B. Robustness in Composition

An intuitive method is discussed in [8] to immediatelyretrieve theExtra Description. Such a solution can be em-ployed and implemented in any composition approach. In

case of a non-robust semantic link, theExtra Descriptionis exposed to a Web service discovery process which isin charge of retrieving relevant Web services. The latterservices are able to provide theExtra Descriptionas outputparameters. TheExtra Description can be reached byone or a conjunction of Web services, depending on theExtra Descriptionand the discovery process. The mainconstraint of this method is related to the complexity ofcomposition. The more non-robust semantic links in a Webservice composition the more important the cardinality ofWeb services will be implied in the composition. Moreovereach input parameter of these Web services has to be eitherknown at run time or linked to an output parameter ofanother Web service through a robust semantic link.

Alternatively the set of Extra Descriptions is suggestedto the end user in [27]. This user is then responsible ofproviding the Extra Description that the system needed toelaborate the final composition. The new information thatend users will provide to the system is necessary to com-pute and elaborate a robust composition of web service,hence satisfying the initial user request. The suggestedmethod has the advantage of relaxing constraints on theend user. However, in this paper we suggest an automatedapproach which does not require any end user support.

C. Agent-based Negotiation

Software agents are considered a promising approachto service composition, partly because agent negotiationsprovide an effective way of addressing the complexityof a range of issues associated with automated servicecompositions [22]. Existing agent-based service compo-sition approaches often rely on the use of a third party,which acts as a mediator between service consumersand service providers [28], [29]. However, the proposedapproach removes the need for such a third party since itis based on direct negotiation between concerned partiesto produce desired results. The focus of our approachis on the negotiation issue of providing extra semanticdescriptions for achieving semantic robustness, and on thedesign of a protocol to facilitate negotiation among variousagents. Details of the tactics that agents can employ intheir negotiation are not discussed here, the reader isinstead referred to [30].

VI. CONCLUSION

In the domain of realistic web service composition, oneof the most important practical and theoretic concernsis that of ensuring robustness of the resultant compo-sitions. Our paper has proposed an automated approachto ensuring robustness during web service composition,which can compute the DL-based descriptions that a non-robust composition requires to be robust, and negotiatetheir provision with service provider agents.

Our approach is based on Concept Abduction and itsadaptation to ensuring robust composition of web services.From this we have suggested to compute a general DL-based description which is required to convert our non-robust composition into a robust one.

Once the description is computed, we propose theuse of agent-based negotiation approach to retrieve theelements of this description from a number of potentialservice providers, and thus achieve robust web servicecomposition. Our approach goes beyond the prevalent one-shot procedure (sending request and collecting results)by allowing agents to play a more active role in thecomposition process.

The approach is based on an iterative agent negotiationprotocol, which allows agents to engage in negotiationwith multiple agents by means of exchanging proposalsand counter proposals. In this respect, the protocol facil-itates agreement on service composition while allowingagents to decide on their actions and resolve their dif-ferences which may hinder robust composition. We haveillustrated the operation of the proposed approach usingan extended example running through the paper.

The main direction for future work is to consider ro-bustness in more expressive composition of web services.In addition the issues involved in coupling semantic andsyntactic data flow require further investigation.

ACKNOWLEDGMENTS

This work is conducted within the European Commis-sion VII Framework IP Project Soa4All (Service OrientedArchitectures for All) (http://www.soa4all.eu/), ContractNo. IST-215219.

REFERENCES

[1] T. Berners-Lee, J. Hendler, and O. Lassila, “The semanticweb,” Scientific American, vol. 284, no. 5, pp. 34–43, 2001.

[2] F. Baader and W. Nutt, inThe Description Logic Hand-book: Theory, Implementation, and Applications, 2003.

[3] M. K. Smith, C. Welty, and D. L. McGuinness, “Owl webontology language guide,” W3C, W3C Recommendation,2004.

[4] A. Ankolenkar, M. Paolucci, N. Srinivasan, and K. Sycara,“The owl-s coalition, owl-s 1.1,” Tech. Rep., 2004.

[5] D. Fensel, M. Kifer, J. de Bruijn, and J. Domingue, “Webservice modeling ontology submission, w3c submission,”2005.

[6] K. Sivashanmugam, K. Verma, A. Sheth, and J. Miller,“Adding semantics to web services standards,” inICWS,2003, pp. 395–401. [Online]. Available: citeseer.ist.psu.edu/sivashanmugam03adding.html

[7] K. P. Sycara, M. Paolucci, A. Ankolekar, and N. Srinivasan,“Automated discovery, interaction and composition ofsemantic web services,”J. Web Sem, vol. 1, no. 1,pp. 27–46, 2003. [Online]. Available: http://dx.doi.org/10.1016/j.websem.2003.07.002

[8] F. Lecue, A. Delteil, and A. Leger, “Applying abductionin semantic web service composition.” inICWS, 2007, pp.94–101.

[9] F. Lecue and A. Leger, “A formal model for semantic webservice composition,” inISWC, 2006, pp. 385–398.

[10] A. Sirbu and J. Hoffmann, “Towards scalable web servicecomposition with partial matches,” inICWS, 2008, pp. 29–36.

[11] M. Paolucci, T. Kawamura, T. Payne, and K. Sycara,“Semantic matching of web services capabilities,” inISWC,2002, pp. 333–347.

[12] L. Li and I. Horrocks, “A software framework for match-making based on semantic web technology,” inWWW,2003, pp. 331–339.

[13] F. Lecue and A. Delteil, “Making the difference in semanticweb service composition.” inAAAI, 2007, pp. 1383–1388.

[14] S. Colucci, T. D. Noia, E. D. Sciascio, F. Donini,and M. Mongiello, “Concept abduction and contractionfor semantic-based discovery of matches and negotiationspaces in an e-marketplace,” inECRA, vol. 4, no. 3, 2005,pp. 41–50.

[15] T. Di Noia, E. Di Sciascio, F. M. Donini, and M. Mongiello,“Abductive matchmaking using description logics,” inProceedings of Eighteenth IJCAI-03. Acapulco, Mexico:MK, Aug. 2003, pp. 337–342. [Online]. Available: http://sisinflab.poliba.it/sisinflab/publications/2003/DDDM03

[16] D. Harel and A. Naamad, “The statemate semantics ofstatecharts,”ACM Trans. Softw. Eng. Methodol., vol. 5,no. 4, pp. 293–333, 1996.

[17] S. Bechhofer, R. Moller, and P. Crowther, “The dig descrip-tion logic interface,” inDescription Logics, 2003.

[18] S. A. McIlraith and T. C. Son, “Adapting golog for compo-sition of semantic web services,” inKR, 2002, pp. 482–496.

[19] S. Thakkar, “Dynamically composing web services fromonline resources,” inAAAI Workshop on Intelligent ServiceIntegration, 2002.

[20] M. Desjardins, M. Sheshagiri, and T. Finin, “Aplanner for composing services described in DAML-S,”May 05 2003. [Online]. Available: http://citeseer.ist.psu.edu/579497.html;http://umbc.edu/∼finin/papers/icaps03.pdf

[21] R. A. S. E. David and S. Kraus, “An english auctionprotocol for multi-attribute items,” inLNCS 2531/2002,2002, pp. 361–378.

[22] S. Paurobally, V. A. M. Tamma, and M. Wooldridge, “Aframework for web service negotiation,”TAAS, vol. 2, no. 4,2007.

[23] C. Priest, “Agent-based service composition through simul-taneous negotiation in forward and reverse auctions,” in4thACM Conference on E-Commerce, 2003.

[24] E. Balas and M. W. Padberg, “Set partitioning: A survey,”SIAM Review, vol. 18, no. 4, pp. 710–760, 1976.

[25] G. Teege, “Making the difference: A subtraction operationfor description logics,” inKR, 1994, pp. 540–550. [Online].Available: citeseer.ist.psu.edu/teege94making.html

[26] S. Brandt, R. Kusters, and A. Turhan, “Approximationand difference in description logics,” inKR, 2002,pp. 203–214. [Online]. Available: citeseer.ist.psu.edu/brandt02approximation.html

[27] A. B. Hassine, S. Matsubara, and T. Ishida, “A constraint-based approach to horizontal web service composition,” inISWC, 2006, pp. 130–143.

[28] P. Kungas, J. Rao, and M. Matskin, “Symbolic agent ne-gotiation for semantic web service exploitation,” inWAIM,2004, pp. 458–467.

[29] J. Yan, R. Kowalczyk, J. Lin, M. B. Chhetri, S. K. Goh,and J. Zhang,Computer Supported Cooperative Work inDesign III, 2007, ch. An Agent Negotiation Approach forEstablishment of Service Level Agreement, pp. 459–468.

[30] C. Sierra, P. Faratin, and N. R. Jennings, “A service-oriented negotiation model between autonomous agents,”in Collaboration between Human and Artificial Societies,1999, pp. 201–219.