=Paper= {{Paper |id=Vol-494/paper-4 |storemode=property |title=Enhancing Engineering Methodology for Communities of Web Services |pdfUrl=https://ceur-ws.org/Vol-494/mallowawesomepaper4.pdf |volume=Vol-494 |dblpUrl=https://dblp.org/rec/conf/mallow/El-MenshawyBD09 }} ==Enhancing Engineering Methodology for Communities of Web Services== https://ceur-ws.org/Vol-494/mallowawesomepaper4.pdf

Enhancing Engineering Methodology for
Communities of Web Services
M. El-Menshawy J. Bentahar, R. Dssouli
Depart. of Electrical and Computer Engineering Concordia Institute for Inf. Sys. Engineering
Concordia University, Montreal, Canada Concordia University, Montreal, Canada
m elme@encs.concordia.ca {bentahar, dssouli}@ciise.concordia.ca

Abstract—Communities of web services have been proposed Recently, a certain number of significant proposals have
to gather web services having the same functionalities but been introduced [1], [3], [4], [10]–[13] to address the mod-
possibly different nonfunctional properties. Current approaches eling and management issues of communities of web services
into communities of web services focus on developing, managing
and designing communities of web services through a suitable (CWSs) in order to allow them to interact more flexibly for the
architecture, but can benefit from a stronger treatment of growing needs of business processes. However, the main ob-
flexible interactions. These approaches ignore the collaboration jective of modeling and managing CWSs and the collaboration
and business-level contracts between various web services and between web services in an efficient way along with business
the ability to formally delegate service to another web service relationships has not been reached yet. In particular, we have
within the same community. This paper presents a significant
step towards enhancing communities of web services using an three broad elements which should be addressed: designing,
agent-based approach that synthesizes mentalistic states (e.g. engineering, and managing communities.
goals, tasks), social commitments and argumentative dialogues
for modeling and establishing communities of web services. This − The architecture based on traditional software engi-
paper has three contributions: first, we extend the community neering methodologies proposed in [3], [4], [11] lacks
structure with alliances structure to allow collaboration between business-level contracts that represent underlying inter-
various web services; second, we propose a new engineering actions between web services. This architecture depends
methodology based on concepts of Tropos methodology for on message occurrence and ordering irrespective of the
managing communities of web services with alliances structure;
and third, we specify internal-organizational business interactions message meanings, thereby a message-based approach
within web services in terms of commitments augmented with hides many details of the internal organization of the
argumentative dialogues to reason about the validity of these architecture that affect designing business processes.
commitments. We evaluate our methodology using a large existing − Existing methodology [4], [11] for modeling, opera-
case study of auto insurance claim processing. tionalizing, and evolving CWSs ignores formalizing the
I. I NTRODUCTION delegation process that is used to delegate incomplete
services within community, in the case of replacing mis-
The notion of community has been proposed to gather web
behaving web services and keeping the system reliable.
services having the same functionalities independently of their
Furthermore, this methodology does not consider the
origins and the way they carry out these functionalities [3],
collaboration among members of the community and
[4], [11]. In recent years, the capability of argumentation and
the mentalistic states of agent-based web services. In
dialogue games has been used in managing and reconciling
general, the approaches discussed in the literature con-
conflicts of interests that may arise within a community of
sider only two-party operations, while real-life scenarios
web services. In this context, the argumentation theory allows
are typically multiparty operations that need a mediator
agent-based web services to interact rationally, argue about the
agent-based web service to complete users’ requests.
reasons that support or disavow their conclusions, persuade a
− The process of handling failures and exceptions is very
new web service to join a community, negotiate with other
hard to implement within the current structure of the
peers to reach a deal and assail each other through an attack-
community. Moreover, the number of interactions be-
binary relation as well as specify the interaction mechanisms
tween members of the community needs to be reduced to
within communities [3], [4].
enhance the response time of participating web services.
In fact, web services of business scenarios begin with
a user’s need and end with a user’s need fulfillment. The This paper aims to enhance the community structure by setting
structure of community facilitates and speeds up the process of up alliances structure among web services to overcome the
web services discovery in open settings and helps in selecting aforementioned shortcomings in [3], [4], [11]. Thereby the
the best ones for composite business scenarios [12], [14] when resulting community structure becomes more realistic with
users’ requests cannot be satisfied by a single available web the real-life business scenarios in distributed systems. By so
service but need collaboration among available web services doing, we propose a new engineering methodology based on
to handle them [11]. Tropos methodology [17], which we enhance with concepts
of communities, commitments and argumentative dialogues or part of the community’s functionality. These web services
for modeling CWSs extended with alliances structure. In fact, need to collaborate with other peers to achieve the whole or
this work is an extension of our previous research in which global community’s functionality.
we have modeled and specified CWSs based on argumentation
Discover Discover
capabilities. This model enables web services through associ- Service
Consumers
UDDI
registers
Service
Consumers
ated agents to argue, persuade and negotiate with their peers (WS1, ...WSn)

using a dialectical process to satisfy their goals in an efficient Business Meaning Business Meaning

way [3], [4]. Specifically, here we reconfigure the design
of community with alliances structure from the perspective Service
Providers
Service
Providers
of the collaboration between agent-based web services that
participate in composition business scenarios and benefit from Business Meaning Business Meaning

agent reasoning capabilities about nonfunctional properties. Community1 of Community2 of
Web services Web services
The contributions of this paper are manifold: (i) alliances Master
-WS1
Master
-WS2

structure within CWSs enhances response time of web ser-
Business Meaning Business Meaning
vices that handle users’ requests and reduces the number of Alliance
Alliance Alliance
interconnections between members of community; (ii) a new Alliance
-WS11 -WS1i
-WS21 -WS2j

agent-based engineering methodology synthesizing mentalistic Business Business Business Business

states, social commitments and argumentative dialogues; and Meaning Meaning Meaning Meaning

(iii) a composition mechanism allowing agent-based web ser- Slave Slave Slave Slave Slave Slave Slave Slave
-WS111 -WS11k -WS211 -WS11n
vices to collaborate with each other in the form of delegation -WS1i1 -WS1ik -WS2j1 -WS2jn

operations. Additionally, we present a case study of auto
insurance industry scenario to evaluate our methodology. Fig. 1. An architecture of communities extended with alliances structure.
The remainder of this paper is organized as follows. Section
For example, in the purchase scenario of goods, the func-
II introduces the notion of alliance structure and key concepts
tionality of a community is purchasing goods. This community
for our methodology. Section III presents our engineering
combines web services having complementary functionality
methodology for developing communities of web services. Our
within an alliance, such as placing an order, paying, and
case study is presented in Section IV to evaluate different steps
shipping with a high reputation and response time. Notice
of our methodology. The paper ends in Section V with the
that, these agent-based web services have logically distinctive
relevant literature discussions and future work directions.
functionalities and involve distinctive roles from the commu-
II. A LLIANCE S TRUCTURE AND C ONCEPTS nity’s functionality but they can collaborate with each other
to achieve a goal by combining or composing their function-
This section defines alliances structure within communities
alities (i.e., purchasing goods) and to satisfy the community’s
of web services and key concepts to be used clearly in our
functionality.
methodology.
As a result the new internal organization of the community
A. Alliance Structure with alliances structure make it easier to detect failures and
errors as we search in micro-communities and reduce the
In [3], [4], [11] the notion of communities of agent-based
number of interactions between members of the community
web services has been introduced. Here we would prescribe
since the master web service has one connection with each
how to extend it via introducing alliances structure. In essence,
alliance structure instead of a direct connection with each
the service providers over forced to improve their strategies
web service (i.e., this minimize the overhead). Moreover, an
and redistribute business functionalities to be able to compete
alliance inherits a dynamic property from its community where
with others should think about building alliances. An alliance
new members can admit to or exclude from the alliance, and
structure based on Quality of Service (QoS) is the concept
alliances themselves can either discard or merge at any-time.
that reconfigures community structure to achieve competitive
pressures between service providers and collaboration between B. Key Concepts
agent-based web services. In [3], [11] an alliance structure as The key concepts of our methodology are inspired by Tro-
a subset of community or a micro-community based on mutual pos methodology [17] with the extra flexibility resulting from
agreements between providers of web services as part of their considering new concepts such as community, commitment
partnership strategies has been superficially introduced. and argumentative dialogue. The purpose is to enhance Tropos
We develop this view by considering nonfunctional propri- capabilities in order to deal with the intrinsic complexity of
eties (e.g., QoS, reputation, response time) associated with business processes.
each agent-based web service as a vital principle to cluster 1) Community: a collection of web services with similar
two or more web services into different alliances as the second or part of total functionality organized into three broad levels
level of community, since the first level is occupied by master without explicitly referring to concrete web services that will
web service (see Fig.1). Whereas the third level of community implement this functionality within alliances structure at run-
contains web services within alliances that underpin the same time (see Fig.1).
2) Agent: a computational representation of web service web services.
within community structure with metaphors that make it III. E NGINEERING M ETHODOLOGY FOR WEB SERVICES
appropriate for developing, designing and implementing dis- C OMMUNITIES
tributed business systems. Each agent has strategic goals and
capabilities to execute tasks. It engages with others in business Having captured the core concepts of our methodology,
relationships to get other agents performing the delegated tasks here we introduce the proposed methodology that intended
on its behalf and to reason about the validity of their tasks. to support all phases of developing CWSs based on the notion
3) Role: an abstract entity over agent-based web services of Tropos methodology. The latter one has been developed in
and can be specified by their related sets of commitments [17] as an agent-oriented software methodology in terms of
augmented with argumentation systems within a community. goal, task and dependency. Tropos has been enhanced with
Multiple agents could play one role and different roles could commitments to capture business interactions among partners
be played by a single agent in a community. with high-level business meaning [15]. In the same direction,
4) Goal: a state of the world that an agent would like to this paper improves the last version of Tropos introduced in
reach or bring about. In other words, a goal is a final or [15] with arguments and argumentative dialogues to increase
an acceptance state. Tropos methodology defines two types its capabilities via enabling agent-based web services to argue,
of goals: hard goals are functional requirements and often seek information and negotiate with other peers about the
have a measurable satisfaction condition that can be satisfied. compliance of their commitments, thereby increasing its prac-
The latter one, called soft goals, no precise criteria for its ticality in distributed business systems. Table (I) summarizes
satisfaction can be found, these goals model nonfunctional the steps in our proposed methodology. The subsections below
requirements of the community. The AND/OR decomposition describe a step-by-step way the progress of our methodology.
is used to decompose a root goal into subgoals. A. Requirements Analysis
5) Task: an abstract method by which a goal can be This phase enhances the early and late requirements in the
achieved. Parallel with the concept of goal, there are two phases of Tropos methodology with a community concept.
types of tasks to achieve the companion goals. Here we also 1) Step 1: Identify Community: the engineer initially
use AND/OR decomposition to decompose a root task into concerns with understanding the organizational context of
subtasks compatible with subgoals. The AND requires all community that gathers agent-based web services. This step
subtasks; OR requires one subtask. includes substeps to be completed.
6) Dependency: used to identify the dependent relationship 1.1) Define the functionality (e.g., hotels booking, weather
between two roles where one role (the depender) depends upon forecasting, etc.) of community by binding to a specific ontol-
the other (the dependee) in order to achieve a goal or execute ogy [13] (e.g., Web Ontology Language (WOL)). This binding
a task. This relation is written as the depender depends upon is important since providers of web services use different
the dependee. terminologies to describe the functional and nonfunctional
7) Commitment: a commitment C(id, dbtr, cdtr, Cx , ψ, φ) requirements of their respective web services.
means that the debtor dbtr is responsible to the creditor 1.2) Identify agents and roles in a community using terms
cdtr within community context Cx for satisfying the content like master, alliance and slave web service. The master web
φ if the condition ψ holds. The commitment has the form service plays the main role in a community and refers to a
of contractual style where id is the unique identifier for special web service that leads the community as well as it takes
commitment, dbtr is the debtor role, cdtr is the creditor role, over multiple responsibilities (e.g., checking the credentials
the context Cx may be an institution, a company, organization, of alliance web services before they are established in the
marketplace (e.g., eBay) in which ongoing interactions occur, community). The other of web services in the community are
and φ and ψ are formulas in a given formal language. slave web services.
Commitments capture state of the dependencies relation 1.3) Identify alliance web services by clustering two or more
between roles and allowing a variety of possible manipulation slave web services having the same nonfunctional properties
based on a set of operations. For instance, the debtor is satisfy the users’ requests and having different functional-
able to create, fulfill, violate commitments, withdraw from ity. For example, the master web service gathers slave web
commitments and delegate commitments to another agent. services that have a high QoS in the first group under the
Whilst the creditor has the right to release the debtor from management of alliance web service1 and the other slave web
commitments and assign commitments to another agent [20]. services that have a medium QoS in the second group under
8) Argumentative dialogue: a dialectical process for the the management of alliance web service2, etc. (see Fig.1).
exchange of various arguments for and against some conclu- 1.4) Specifying dismantle community: the master web ser-
sions [3], [4]. Indeed, argumentation provides agent-based web vice is only responsible for dismantling community when all
services with an effective means to reconcile conflicts, seek alliance structures present low precision to users’ requests
information, persuade and negotiate with other peers within the (i.e., irrelevant results) and low recall (i.e., missing relevant
same alliance structure. It relies on actions on commitments information). This happens when the number of slave web
to generate a suitable set of arguments during dialogues to services within alliances structure is not enough to satisfy
achieve mutually acceptable agreements between agent-based users’ requests as well.
2) Step 2: Determine Goals and Dependencies: this step system in terms of the components and their interdependencies
iteratively determines the goal dependencies between the roles. that are identified in previous phase. This step focuses on
First, it searches UDDI registries to find posted services based how system components work together to constitute a mul-
on the similarity that exists between users’ requests and these tiagent system and introduces resources, goals and roles as
registered services. Thus, the composite goal of users’ requests needed. This paper presents an architecture to tackle pitfalls
is identified at the master web service as a hard goal. Second, of standard approaches that do not underpin business meaning
the master web service uses nonfunctional properties to refine and dynamic composition of existing services in which the
its populated alliance web services into one that satisfies components are agent-based web services and their interdepen-
this composite goal (say G). Third, using means-end analysis dencies are specified in terms of commitments augmented with
to decompose this composite goal into subgoals (say G = argumentation capabilities to reason about the validity of these
{g1 , g2 , . . .}), thereafter, alliance web service introduces roles commitments (we will explain commitment and argumentation
that adopt these subgoals. This iterative analysis continues later on). In fact, this architecture is a call and return style in
decomposing these subgoals until no new goal dependencies the form of layered phases and an extension to the architecture
arise. we developed in [3], [4].
From Fig. 1 the main components of the proposed architec-
Description Input Output
ture are service providers, service consumers of web services,
1.1) Identify community A specific ontology All agent-based
function and composition web services having UDDI registers and communities with alliances structure. A
scenario. the same or part community with alliances structure is organized dynamically
of community’s according to the specifications discussed in previous phase
functionality.
(III-A). Hereafter we focus on operationalizing the steps
1.2) Identify agents Agent-based web Master web
and roles in community services and service and slave through which the goal dependencies are to be fulfilled.
composition scenario. web services. The service providers publish and register the name of their
1.3) Identify alliance Slave web services, Alliance web services in UDDI registries with different nonfunctional pro-
web services composition scenario services and
and nonfunctional their slave web
prieties (e.g., QoS) so that service consumers or users can
properties. services. search for appropriate QoS. More precisely, there are three
1.4) Specify dismantling Request from alliance Terminating kinds of agent-based web services (master-ws, allaince-
community web service to its community. ws and slave-ws) constitute the structure of community and
master web service.
collaborate with each other to achieve users’ requests.
2) Identify goals and Alliance web services, Goals and goal
goal dependencies slave web services, dependencies of A master-ws can be implemented as a web service for
composition scenario each dependee compatibility purposes with the slave web services and al-
and goals are role (in step 1.2). liances web services that populate the community as well.
introduced in
architecture. It delegates goal dependencies to allaince-ws that will re-
3) Identify tasks Alliance web services, Tasks and task sponsible for accomplishing them. The alliance web services
and task dependencies slave web services, dependencies. manage micro-communities and decompose goal dependencies
goal dependencies and
composition scenario.
to slave web services that populate their alliance structure
4) Identify commitments Tasks dependencies, Commitments as well. Each slave-ws signs up contract with its alliances
scenario commitments describing to commit to satisfy the delegated subgoal. The slave web
description. business relation. services collaborate with each other to achieve these goals. Of
5) Identify argumentative Nonfunctional Accessitable course each slave web service has the ability to delegate or
dialogues properties and commitments.
commitments. assign incomplete tasks to other slave web services to complete
its goal. Moreover, allaince-ws can request from master-ws
TABLE I
O UTLINE THE STEPS IN OUR METHODOLOGY.
to search for a new slave-ws to join in its structure instead
of the existing slave-ws that it does not work well. When
3) Step 3: Identify Tasks and Dependencies: each role all slave web services satisfy their contracts, their alliance
from step (2) has goal dependencies, then the ultimate ob- web services consequently achieve their composite contracts.
jective of this step is to find task dependencies that will be Hence these alliance web services need to inform the master-
responsible to achieve goals dependencies. Meanwhile, one ws with results to finalize users’ requests.
goal (say g1 ) may need a set of tasks (say t1 = {t1.1 , t1.2 , . . .})
C. Detailed Design
to accomplish it. Subsequently, means-end analysis needs to
identify this set of the tasks. Similarly, the task may be This phase is intended to introduce additional details for
decomposed into subtasks and this decomposition analysis will each architectural component of a community structure. To
iterate until no new task dependencies arise. support this phase, we adopt social commitment, argumenta-
tive dialogues and dialogue games protocol from the agent
B. Architecture Design programming community.
The architectural design phase plays a crucial role in the 1) Step 4: Identify Social Commitments: our methodology
design process. Initially, it defines the organization of the captures high-level business meaning via identifying commit-
ments between roles in terms of tasks. More precisely, this Attack, Challenge, Justify, Close} forming the basic building
step analyzes each task dependency resulted from step (3) blocks of this protocol. Here we present the description of
and that discovered in the architecture phase to identify the these locutions in natural language (see Table (II)). To simplify
corresponding commitment. The notion here depends on the the notation, a commitment will be denoted by C(idx , φx )
task dependency such that when the dependee (or the debtor) when the participating agents and the other elements are clear
commits towards the depender (or the creditor) to execute the from the context. These locutions specify our communication
dependum task (e.g., t1 ) or the commitment content, then language that can be used to communicate about satisfying
a commitment exists. The condition of the commitment is goals or tasks.
defined by identifying a task that dependee needs to satisfy
to perform commitment content. Meanwhile, the creditors Definition 1: (Dialogue game) Let Open(Ag-ws1 , C(idk ,
need to verify some constraints that are conjuncted with this Ag-ws1 , Ag-ws2 , Cx , ψ, φ) be the opening action performed
commitment to guide them to determine the corresponding by Ag-ws1 and sent to another agent Ag-ws2 about content
tasks resulting from executing this commitment. Whereas, if φ subject to ψ within alliance context Cx . A dialogue game
the dependee is not committed towards the depender to execute Dg is a conjunction of rules, where the first rule defines the
a task, then no commitment exists, in this case the dependee condition to enter Dg if the argumentation systems of Ag-
executes the intrinsic task to achieve its internal goal. ws1 and Ag-ws2 support the satisfaction of the commitment
2) Step 5: Identify Argumentative Dialogues: this step condition ψ. The other rules identify possible actions that an
identifies arguments that can be used either in negotiation, agent-based web service can use as a reply when receiving
persuasion or information seeking dialogue based on commit- an action from another agent-based web service if a given
ments identified in step (4). condition Condij is satisfied. This conjunction is specified as
follows:
Argumentative Locutions Descriptions
Open-dialogue A special argumentative act used Entry rule : Open(Ag-ws1 , C(idk , Ag-ws1 , Ag-ws2 , Cx , ψ, φ))
to open the dialogue. ∧ Condk¡
Accept(Ag-ws2 , C(idx , φx )) When Ag-ws2 has an argument V
in favor of φx .
Body rules : 0
'"
g1 , of the call center depends on four tasks to achieve it, t1 =
# ( ! '!
) ( "
! {gathering inf o, validating claim, assigning garage,

+,-- +./0.1 2.3,41.1
sending claim}. The call center gathers information
and assigns a garage when the customer reports an ac-
Fig. 3. Cross flow insurance claim processing [19]. cident and validates claim information. Thus, the re-
pairer depends on the call center to assign a garage
and the customer depends on call center for gathering
A. Step 1 claim information. Meanwhile, the validate claim infor-
According to the ontology associated with the community, mation task is decomposed into two subtasks, t1.2 =
the functionality of the community is InsuranceClaimProcess- {request policy inf ormation, validate inf ormation}. Ac-
ing and this community includes all agent-based web services cording to the architecture design the call center can define
supporting the similar or part of this functionality. Thereafter, a new goal to receive payment of claim reception charge
the engineering designer selects one of them as master-ws1 from the Insurer via executing a task of receiving payment
(as the manager of the company) that starts to cluster the or delegate the task to another (e.g., the reporter to prepare its
slave web services into alliances structure based on the policy report). Finally, it sends a valid claim to the Insurer to finalize
classes (a form of nonfunctional properties related to QoS), claim processing.
such as class1 , class2 and class3 cover 100%, 90%, 80% The assessor has claim assessment goal, g2 , delegated
respectively from each claim request. We here only consider from the Insurer. The tasks needed to satisfy this goal are: t2 =
alliance structure that covers QoS = {100%} of the automo- {receive claim, check invoice, agree to repair, obtain repair
bile damage and from now we refer to AGFIL by the Insurer estimate, inspect vehicle}. The receive claim task depends
(i.e., the role of this alliance is identified by the Insurer). upon send claim task of the Insurer to the assessor. Meanwhile,
The unique role names of slave web services that populate the Insurer and repairer depend on the assessors’ tasks for
this alliance are defined as call center for Europ Assist and checking the invoice and agreeing to repair. Moreover, the
assessor for Lee CS, as well as repairer and adjustor. We assessor depends upon the repairer to obtain the repair
modify this use case [16] by establishing a direct dependency estimate by performing estimation repair cost task. The
between the Insurer on one side and repairer and adjustor assessor depends upon the adjustor to inspect a vehicle and
on the other side. Also, we introduce the direct dependency requires to define a new goal to receive assessment fees from
between the customer and Insurer. At the end of this step, the Insurer by executing a task of receiving assessment fees.
the Insure context is denoted by Insx and the manager (or The repairer has a vehicle repair goal, g3 , and the
master-ws1 ) delegates the customer’s request to the Insurer. tasks needed to satisfy this goal are denoted by t3 =
{repair vehicle, estimate repair cost, send invoice}. The
B. Step 2 customer depends upon the repairer for repairing vehicle
The customer has one relevant goal: vehicle repair, when received valid claim from the customer. The assessor
while the Insurer has the goals: handle claim and maximize depends upon the repairer for estimating repair cost to decide
agreeing to repair or negotiating with the repairer. Meanwhile, Create(adjustor, C(id2.1 , assessor, Insx , pay inspection
the repairer depends on the assessor for checking the invoice f ees, estimate inspection cost))
and forwarding it to the Insurer, if the repairer sends the
invoice. Likewise, the call center and the assessor, the repairer E. Step 5
requires to define a new goal to receive repair charge from the We define two subscenarios from AGFIL scenario to
Insurer by depending on executing a task of receiving repair explain why we need argumentative dialogues to reason
charge [6], [16]. about the validity of commitment operations. The first sub-
scenario is established between the Insurer and assessor
D. Step 4 where the assessor commits to the Insurer to reach agree-
This step transfers each task dependency into an appropriate ment with the repairer for the vehicle repair, formally:
commitment to represent business meaning of interacting C(id3 , assessor, Insurer, Insx , pay assess f ees, agree to
parties of AGFIL. In [16] the authors have ignored the repair) [16]. However, the assessor cannot estimate his as-
formulation of actions on commitments and focused only sessment fees without engaging in a dialogue with the repairer
on commitment itself (although actions on commitments re- to reach a deal about “estimate the repair cost”. The solution
flect dynamic behaviors of agents). For example, commit- proposed in [16], which is based only on commitments, is not
ment C(id1 , call center, customer, Insx , report accident ∧ enough to specify this dialogue especially when the assessor
valid claim, assign garage) means that when the customer needs to negotiate the repair charge with the repairer. The
reports an accident and if the claim is valid, then the call center proposed argumentative dialogues are natural solutions to this
commits to assign a garage to him within the Insurer. But, how problem. The following dialogue game explains only the steps
the Insurer delegates claim reception to the call center, how after the commitment being delegated to the repairer. This
the Insurer formally assigns the assessor to get the inspection means that request to estimate repair cost (i.e., ψ) is supported
fees from the adjustor, how the call center withdraws from his by argumentative systems of the assessor and repairer (i.e.,
commitment, etc. Here we complement [16] with commitment ψ / Argsys (assessor) ∧ ψ / Argsys (repairer)). Then the
operations. From step (2) the Insurer has five subgoals (claim dialogue is opened and this dialogue can be considered as
reception, claim assessment,vehicle repair, claim finalization a continuation to example (2). The repairer creates a com-
and vehicle inspection) that are delegated to the call center, mitment towards the assessor to estimate the repair cost. The
assessor, repairer and adjustor respectively. Formally we define assessor has a conflict with the Insurer because the estimated
this delegation operation, but in the case of the Insurer that cost does not respect the delegated constrains from the Insurer
delegates claim reception to the call center only as follows: (estimate cost should be < 500 to maximize the Insurer
Delegate(Insurer, call center, C(id1 , Insurer, Insx , profits). Then assessor challenges the repairer to justify the
customer, pay insurrance premium, claim reception)) estimated repair cost. When the argumentation system of the
This operation intuitively means that the Insurer withdraws assessor supports the justification of the estimate repair cost,
from the commitment and the call center creates a new then it reaches a deal with the repairer and informs the Insurer
commitment such that it becomes the debtor towards the to pay the assessed fees.
customer to receive claim reception. Formally we need two 1) Create(repairer, C(id3.1 , repairer, assessor, Insx , φ))
steps to perform this: ∧ Cond1
Withdraw(Insurer, C(id1 , Insurer, policy holder, Insx , pay ⇒ Challenge(assessor, C(id3.1 , repairer, assessor,
insurrance premium, claim reception)) ∧ Insx , , φ))
Create(call center, C(id1.1 , call center, customer, Insx , 2) Challenge(assessor, C(id3.1 , repairer, assessor,
claim reception)) Insx , φ)) ∧ Cond2
According to step (3) the claim reception needs four tasks to ⇒ Justify(repairer, C(id3.2 , repairer, assessor, Insx ,
be achieved, one of them is gathering information from the φ0 ), C(id3.1 , repairer, assessor, Insx , φ))
customer. We define it formally as: 3) Justify(repairer, C(id3.2 , repairer, assessor, Insx ,
Create(call center, customer, C(id1.1 , call center, φ0 ), C(id3.1 , repairer, assessor, Insx , φ)) ∧ Cond3
customer, Insx , report accident, gather inf o)) ⇒ Accept(assessor, C(id3.2 , repairer, assessor,
Moreover, the Insurer assigns the assessor to obtain inspection Insx , φ0 ))
fees from the adjustor when the estimate repair cost returned W here :
from repairer is more than 500 (a threshold amount). φ = Estimate-Repair-Cost = V, with V is a given value
Assign(Insurer, assessor, C(id2 , adjustor, Insurer, Insx , Cond1 = ¬(φ / Argsys (assessor)) ∧
pay inspection f ees, estimate inspection cost)) ¬(¬φ / Argsys (assessor)),
φ0 = φ01 ∧ φ02 , Cond2 = φ0 / Argsys (repairer),
This action is similar to the delegation action. Formally we
Cond3 = φ0 / Argsys (assessor)
need two steps to perform this:
Release(Insurer, C(id2 , adjustor, Insurer, Insx , pay Notice that the value of φ0 = φ01 ∧ φ02 means that the cost
inspection f ees, estimate inspection cost)) ∧ of repair includes the value of the part1 (φ01 ) and part2 (φ02 ).
Similarly, the adjustor and assessor can entre in negotiation their organizational roles. The approach lists the possible rules
dialogue about the estimated inspection cost. Moreover, ar- that can be applied when conflicts of interest occur. These
gumentative dialogue in our case study can be used to spread rules, for example, are used to reject or accept proposals as
agent-based web service knowledge in the form of information well as to enforce the social relations within a multiagent
seeking dialogue. For example, when the call center requests system. However, the rules in [8] are not used for justifying the
policy information from the Insurer, the available information content of commitments within negotiation dialogue and they
may be not enough to validate the received claim. Thus, the do not consider agents’ goals that can affect agents decisions
call center may need to spread his knowledge by requesting as we have done here.
more information from the customer that enable the call center Let us now focus on comparing the proposed methodology
to send a valid information to the Insurer. with the related ones. Many of Agent-Oriented Software
The second subscenario is established between the cus- Engineering (AOSE) methodologies have been proposed over
tomer, Insurer and call center. When the customer reports an the last years based on the concepts of actors, roles, goals
accident and his claim is valid, then the call center assigns and plans include Gaia, Prometheus, MaSE, and Tropos.
a garage for vehicle repair. Otherwise, the call center does These methodologies support various phases of the software
not assign a garage as it gathers invalid information from development life cycle, but Tropos differs from them in
the customer compared to the information received from including an early requirements phase. Moreover, some of
the Insurer. Thereby the intuitive semantic of the interaction these methodologies like Gaia differs from Tropos in in-
between the call center and customer lacks clarity of business volving safety and liveness conditions for the processes and
meaning related to the content of interaction (i.e, it is not agents should be coarse-grained computational systems (like
meaningful). But, argumentative dialogue makes interaction UNIX process). Meanwhile, Gaia lacks reasoning scheme
more meaningful by guiding the call center to undertake a based on early requirements engineering which limits the
subtle decisions when the conflicts arise, then it challenges flexibility of Gaia, as well as implementation phase is not
the customer to justify the validity of its commitment and to covered in this methodology. Our methodology complements
reach a mutual agrement that helps the customer to repair the these methodologies by concentrating on social arguments
vehicle. Moreover, the Insurer should persuade the call center, and argumentative dialogues, which they are ignored in these
repairer, assessor and adjustor to join alliance structure by methodologies. A key difference between our methodology
offering rewards that alliance grants to them. and Tropos [17] is the considerations of concepts of commu-
nity, commitment and argumentative dialogue. In Tropos the
V. R ELATED W ORK AND C ONCLUSIONS depender depends upon the dependee for achieving a goal or
In this paper, we first exposed some obstacles that restrict executing a plan without any condition from the depender’s
the use of agent-based web services in complex business side, but in commitment the debtor is obliged towards the
applications and then, offered some solutions to tackle these creditor to bring about its commitment when a condition is
obstacles through extending community structure with al- hold. Thus, Tropos lacks capability to model real-life business
liances structure and proposing a new methodology based scenarios between economic partners [15].
on Tropos methodology. This methodology synthesizes three Pankaj et al. [15] enhanced Tropos methodology with con-
approaches: mentalistic states, social commitments and argu- cept of commitments to capture business meaning of interac-
mentative dialogues. The mentalistic artifacts such as goals, tions among independent parties in early requirement phases
tasks and dependencies modeling techniques are compatible and successively refined using means-end and AND/OR anal-
with concepts of Tropos (e.g., plan in Tropos is the task ysis during the progress of the system being engineered. This
here). The social commitments define dependencies between methodology [15] is close to our methodology but it lacks the
agent-based web services in the early stages as business- argumentative capabilities to enable agent-based web services
meaning of interactions and guide Tropos for accommodat- to negotiate or seek information with other peers based on
ing and tracing the changes in the various phases of the their commitments. Moreover, the authors translate goals into
methodology. While Tropos provides commitment with cues concrete tasks for their fulfillment before considering the
that identify different parties of dependencies (e.g., agents, overall organization of the system, which makes software
goals, plans). Moreover, commitments enable the community systems fragile and less reusable although commitments can
to support dynamic reconfiguration of business interactions be modified. The reason is that they ignore architecture design
via delegation and assignment operations without altering the phase. We present the architecture design phase with alliances
overarching structure of web services interactions. Argumen- structure to satisfy a number of quality requirements related
tative dialogues support web services with richer capabilities to performance, usability, modifiability and reusability. For
to negotiate or seek information with other peers via reasoning example, the Insurer can delegate the responsibility to the
about the correctness of commitments assessor to finalize users’ claims or to pay inspection fees
The social-arguments proposed here are different from the to the adjustor on his behalf.
approach proposed in [8] for argumentation-based negotiation Desai et al. [7] proposed Amoeba as a process modeling
based on social commitments. The agents are influenced by methodology based on commitment protocols. This method-
social relationships and negotiate with other peers based on ology guides software designers to evolve requirements based
on separating service interactions into two layers: commit- at execution time, give useful feedback to refine the original
ment protocols and polices. They represent business process design are fundamental issues we plan to investigate.
in terms of fine-grained messages with commitments where ACKNOWLEDGEMENTS
commitments capture business interactions. Our methodology
The authors would like to thank the reviewers for their
includes in addition of that mentalistic states and argumenta-
valuable comments and suggestions. They also would like
tive dialogues.
to thank NSERC (Canada), NATEQ FQRSC (Québec) and
Riemsdijk et al. [18] used a goal-oriented approach inspired
ERESSON for their financial support.
by the field of cognitive agent programming for service-
oriented computing to help handling failures and specify the R EFERENCES
semantics of the services. An orchestration approach has been [1] B. Benatallah, M. Dumas and Q.Z. Sheng. Facilitating the Rapid Devel-
used to coordinate the invocations of services from a workflow. opment and Scalable Orchestration of Composite Web Services. J Distrib
Parallel Databases vol.17(1), pp.5-37, 2005.
Burmeister et al. [5] presented an approach to business process [2] B. Benatallah, Q.Z. Sheng and M. Dumas. The Self-Serv Environment for
management using BDI-agent features to capture the ability of Web Services Composition. IEEE Internet Computing, vol.7(1), pp.40-48,
the process to adapt and pro-actively adapt itself to a changing 2003.
[3] J. Bentahar, Z. Maamar, D. Benslimane and P. Thiran. An Argumentation
environment (or what they call an “agile process”) to avoid Framework for Communities of Web Services. IEEE Intel. Sys. vol.22(6),
problems before they arise. The goal-oriented approach is pp.75-83, 2007.
the core of our methodology, but it differs from [5], [18] [4] J. Bentahar, Z. Maamar, W. Wan, D. Benslimane, P. Thiran and S. Subra-
manian. Agent-Based Communities of Web Services: An Argumentation-
in considering goals as commitments, which provide more Driven Approach. In Service Oriented Computing and Applications,
flexibility in terms of manipulation (e.g., assign, release or Vol.2(4), pp.219-238, 2008, Springer.
withdraw) and agents use argumentative dialogues to enable [5] B. Burmeister, M. Arnold, F. Copaciu, G. Rimassa. BDI-Agents for Agile
Goal-Oriented Business Processes. In Proc. of 7th Int. Conf. on Aut.
each participant to satisfy its hard goals and soft goals in an Agents and Multiagent Sys. (AAMAS 2008), pp.37-44, 2008.
efficient manner. Moreover, an orchestration reflects only one [6] N. Desai, A.K. Chopra and M.P. Singh. Business Process Adaptations via
participant’s view of the overall business process and lacks Protocols. In Proc. of the IEEE Int. Conf. on Services Computing (SCC),
pp.103-110, 2006.
business meaning of service engagements. The conceptual [7] N. Desai, A.K. Chopra and M.P. Singh. Amoeba: A Methodology for
framework proposed in [5] has been successfully applied to a Modeling and Evolution of Cross-Organizational Business Processes.
business process for engineering change management domain, ACM Transactions on Software Eng. and Methodology (TOSEM), 2009.
[8] N.C. Karunatillake, N.R. Jennings, I. Rahwan and T.J. Norman.
but it lacks the cooperation between agents. Argument-Based Negotiation in a Social Context. In Proc. AAMAS
Li et al. [9] proposed an agent-based framework to model Workshop on Argumentation, pp.74-88, May 2005.
and develop dynamic service-oriented operations. In our ap- [9] Y. Li, W. Shen and H. Chenniwa. Agent-Based Web Services Framework
and Development Environment. Comput Intell, vol.20(4), 2004.
proach, web services are also viewed as software agents, [10] Z. Maamar, M. Lahkim, D. Benslimane, P. Thiran and S. Sattanathan.
but what is new in our approach is that web services can Web Services Communities-Concepts and Operations. In Proc. of the 3rd
communicate with other peers within a community by dialogue int. conf. on web information sys. and technologies (WEBIST’2007),
Barcelona.
game protocols. [11] Z. Maamar, S. Subramanian, J. Bentahar, P. Thiran P and D. Benslimane.
Regarding to CWSs, Maamar et al. [11] recently presented An Approach to Engineer Communities of Web Services Concepts,
an engineering methodology for modeling CWSs based on Architecture, Operation, and Deployment. In the Int. Journal of E-
Business Research, vol.5(4), 2009, IGI Global.
the concepts that assist in using community, selecting web [12] B. Medjahed and Y. Atif. Context-Based Matching for Web Service
services, identifying allowable operations to each web service Composition. Distrib Parallel Databases. Springer, Heidelberg, vol.21(1),
and deploying community. However, they ignore the collab- pp.5-37, 2007.
[13] B. Medjahed and B. Bouguettaya. A Dynamic Foundational Architecture
oration between web services, high-level business meaning for Semantic Web Services. Distributed and Parallel Databases. Kluwer,
of interactions, alliance structure, user interactions (although Dordrecht, vol.17(2), pp.179-206, 2005.
these interactions are crucial and ought to be recognized within [14] B. Medjahed, B. Bouguettaya and A. Elmagarmid. WebBIS: An Infras-
tucture for Agile Integration of Web Services. Int. J. Cooperative Inf.
community). Last but not least, Medjahed et al. [14] proposed Syst. (IJCIS) , vol.13(2), pp.121-158, 2004.
the WebBIS system as a generic framework for compos- [15] P.R. Telang and M.P. Singh. Enhancing Tropos with Commitments: A
ing and managing web services in terms of pull-and push- business Metamodel and Methodology. Alex Borgida, Vinay Chaudhri,
Paolo Giorgini and Eric Yu (eds), Conceptual Modeling: Foundations
communities within dynamic environments. Our methodology and Applications, June 2009.
underpins a simple mechanism for empowering composition [16] P.R. Telang and M.P. Singh. Business Modeling via Commitments. In
of web services based on means-end and AND/OR analysis Proc. of the 7th AAMAS Workshop on Service-Oriented Computing:
Agents, Semantics and Eng. (SOCASE), May 2009.
within the notion of delegation operation that captures flexible [17] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia and J. Mylopoulos.
interactions. Tropos: An Agent-Oriented Software Development Methodology. Au-
As future work, we aim to formalize the strategic polices tonomous Agents and Multi-Agent Systems, vol.8(3), pp.203-236, 2004.
[18] M.B. van Riemsdijk, M. Wirsing. Using Goals for Flexible Service
of service providers that help organizing web services in Orchestration: A First Step. In Service-Oriented Computing: Agents,
alliances structure and investigating the organization laws and Semantics, and Eng. vol.(4504) of LNCS, pp. 31-48. 2007, Springer.
norms ruling the roles within the community. The trustwor- [19] S. Browne and M. Kellett. Insurance (Motor Damage Claims) Scenario.
Document Identifier D1.a, CrossFlow Consortium, 1999.
thiness level of a master web service towards alliance web [20] M.P. Singh. An Ontology for Commitments in Multiagent Systems:
services and how a social-argumentative dialogue model is Toward A unification of Normative Concepts. AI and Law, vol.7, pp.97-
automatically mapped into a BDI-agent specification that can, 113, 1999.