-Communities of web services have been proposed to gather web services having the same functionalities but possibly different nonfunctional properties. Current approaches into communities of web services focus on developing, managing and designing communities of web services through a suitable architecture, but can benefit from a stronger treatment of flexible interactions. These approaches ignore the collaboration and business-level contracts between various web services and the ability to formally delegate service to another web service within the same community. This paper presents a significant step towards enhancing communities of web services using an agent-based approach that synthesizes mentalistic states (e.g. goals, tasks), social commitments and argumentative dialogues for modeling and establishing communities of web services. This paper has three contributions: first, we extend the community structure with alliances structure to allow collaboration between various web services; second, we propose a new engineering methodology based on concepts of Tropos methodology for managing communities of web services with alliances structure; and third, we specify internal-organizational business interactions within web services in terms of commitments augmented with argumentative dialogues to reason about the validity of these commitments. We evaluate our methodology using a large existing case study of auto insurance claim processing.
The notion of community has been proposed to gather web
services having the same functionalities independently of their
origins and the way they carry out these functionalities [
In fact, web services of business scenarios begin with
a user’s need and end with a user’s need fulfillment. The
structure of community facilitates and speeds up the process of
web services discovery in open settings and helps in selecting
the best ones for composite business scenarios [
Recently, a certain number of significant proposals have
been introduced [
¡ The architecture based on traditional software
engineering methodologies proposed in [
registers (WS1,...WSn)
-WS1
-WS11
of communities, commitments and argumentative dialogues
for modeling CWSs extended with alliances structure. In fact,
this work is an extension of our previous research in which
we have modeled and specified CWSs based on argumentation
capabilities. This model enables web services through
associated agents to argue, persuade and negotiate with their peers
using a dialectical process to satisfy their goals in an efficient
way [
The contributions of this paper are manifold: (i) alliances structure within CWSs enhances response time of web services that handle users’ requests and reduces the number of interconnections between members of community; (ii) a new agent-based engineering methodology synthesizing mentalistic states, social commitments and argumentative dialogues; and (iii) a composition mechanism allowing agent-based web services to collaborate with each other in the form of delegation operations. Additionally, we present a case study of auto insurance industry scenario to evaluate our methodology.
The remainder of this paper is organized as follows. Section II introduces the notion of alliance structure and key concepts for our methodology. Section III presents our engineering methodology for developing communities of web services. Our case study is presented in Section IV to evaluate different steps of our methodology. The paper ends in Section V with the relevant literature discussions and future work directions.
In [
We develop this view by considering nonfunctional proprieties (e.g., QoS, reputation, response time) associated with each agent-based web service as a vital principle to cluster two or more web services into different alliances as the second level of community, since the first level is occupied by master web service (see Fig.1). Whereas the third level of community contains web services within alliances that underpin the same
-WS2
-WS2j
-WS1i
-WS21
-WS111
-WS11k
-WS1i1
-WS1ik
-WS211
-WS11n
-WS2j1
-WS2jn
For example, in the purchase scenario of goods, the functionality of a community is purchasing goods. This community combines web services having complementary functionality within an alliance, such as placing an order, paying, and shipping with a high reputation and response time. Notice that, these agent-based web services have logically distinctive functionalities and involve distinctive roles from the community’s functionality but they can collaborate with each other to achieve a goal by combining or composing their functionalities (i.e., purchasing goods) and to satisfy the community’s functionality.
As a result the new internal organization of the community with alliances structure make it easier to detect failures and errors as we search in micro-communities and reduce the number of interactions between members of the community since the master web service has one connection with each alliance structure instead of a direct connection with each web service (i.e., this minimize the overhead). Moreover, an alliance inherits a dynamic property from its community where new members can admit to or exclude from the alliance, and alliances themselves can either discard or merge at any-time.
The key concepts of our methodology are inspired by
Tropos methodology [
1) Community: a collection of web services with similar or part of total functionality organized into three broad levels without explicitly referring to concrete web services that will implement this functionality within alliances structure at runtime (see Fig.1).
2) Agent: a computational representation of web service within community structure with metaphors that make it appropriate for developing, designing and implementing distributed business systems. Each agent has strategic goals and capabilities to execute tasks. It engages with others in business relationships to get other agents performing the delegated tasks on its behalf and to reason about the validity of their tasks.
3) Role: an abstract entity over agent-based web services and can be specified by their related sets of commitments augmented with argumentation systems within a community. Multiple agents could play one role and different roles could be played by a single agent in a community.
4) Goal: a state of the world that an agent would like to reach or bring about. In other words, a goal is a final or an acceptance state. Tropos methodology defines two types of goals: hard goals are functional requirements and often have a measurable satisfaction condition that can be satisfied. The latter one, called soft goals, no precise criteria for its satisfaction can be found, these goals model nonfunctional requirements of the community. The AND/OR decomposition is used to decompose a root goal into subgoals.
5) Task: an abstract method by which a goal can be achieved. Parallel with the concept of goal, there are two types of tasks to achieve the companion goals. Here we also use AND/OR decomposition to decompose a root task into subtasks compatible with subgoals. The AND requires all subtasks; OR requires one subtask.
6) Dependency: used to identify the dependent relationship between two roles where one role (the depender) depends upon the other (the dependee) in order to achieve a goal or execute a task. This relation is written as the depender depends upon the dependee.
7) Commitment: a commitment C(id; dbtr; cdtr; Cx; Ã; Á) means that the debtor dbtr is responsible to the creditor cdtr within community context Cx for satisfying the content Á if the condition à holds. The commitment has the form of contractual style where id is the unique identifier for commitment, dbtr is the debtor role, cdtr is the creditor role, the context Cx may be an institution, a company, organization, marketplace (e.g., eBay) in which ongoing interactions occur, and Á and à are formulas in a given formal language.
Commitments capture state of the dependencies relation
between roles and allowing a variety of possible manipulation
based on a set of operations. For instance, the debtor is
able to create, fulfill, violate commitments, withdraw from
commitments and delegate commitments to another agent.
Whilst the creditor has the right to release the debtor from
commitments and assign commitments to another agent [
8) Argumentative dialogue: a dialectical process for the
exchange of various arguments for and against some
conclusions [
III. ENGINEERING METHODOLOGY FOR WEB SERVICES
COMMUNITIES
Having captured the core concepts of our methodology,
here we introduce the proposed methodology that intended
to support all phases of developing CWSs based on the notion
of Tropos methodology. The latter one has been developed in
[
This phase enhances the early and late requirements in the phases of Tropos methodology with a community concept.
1) Step 1: Identify Community: the engineer initially concerns with understanding the organizational context of community that gathers agent-based web services. This step includes substeps to be completed.
1.1) Define the functionality (e.g., hotels booking, weather
forecasting, etc.) of community by binding to a specific
ontology [
1.2) Identify agents and roles in a community using terms like master, alliance and slave web service. The master web service plays the main role in a community and refers to a special web service that leads the community as well as it takes over multiple responsibilities (e.g., checking the credentials of alliance web services before they are established in the community). The other of web services in the community are slave web services.
1.3) Identify alliance web services by clustering two or more slave web services having the same nonfunctional properties satisfy the users’ requests and having different functionality. For example, the master web service gathers slave web services that have a high QoS in the first group under the management of alliance web service1 and the other slave web services that have a medium QoS in the second group under the management of alliance web service2, etc. (see Fig.1).
1.4) Specifying dismantle community: the master web service is only responsible for dismantling community when all alliance structures present low precision to users’ requests (i.e., irrelevant results) and low recall (i.e., missing relevant information). This happens when the number of slave web services within alliances structure is not enough to satisfy users’ requests as well.
2) Step 2: Determine Goals and Dependencies: this step iteratively determines the goal dependencies between the roles. First, it searches UDDI registries to find posted services based on the similarity that exists between users’ requests and these registered services. Thus, the composite goal of users’ requests is identified at the master web service as a hard goal. Second, the master web service uses nonfunctional properties to refine its populated alliance web services into one that satisfies this composite goal (say G). Third, using means-end analysis to decompose this composite goal into subgoals (say G = fg1; g2; : : :g), thereafter, alliance web service introduces roles that adopt these subgoals. This iterative analysis continues decomposing these subgoals until no new goal dependencies arise.
Description 1.1) Identify community function 1.2) Identify agents and roles in community 1.3) Identify alliance web services 1.4) Specify dismantling community 2) Identify goals and goal dependencies 3) Identify tasks and task dependencies 4) Identify commitments 5) Identify argumentative dialogues
Input A specific ontology and composition scenario.
Agent-based web services and composition scenario.
Slave web services, composition scenario and nonfunctional properties.
Request from alliance web service to its master web service.
Alliance web services, slave web services, composition scenario and goals are introduced in architecture.
Alliance web services, slave web services, goal dependencies and composition scenario.
Tasks dependencies, scenario commitments description.
Nonfunctional properties and commitments.
Output All agent-based web services having the same or part of community’s functionality.
Master web service and slave web services.
Alliance web services and their slave web services.
Terminating community.
Goals and goal dependencies of each dependee role (in step 1.2).
Tasks and task dependencies.
Commitments describing business relation.
Accessitable commitments.
3) Step 3: Identify Tasks and Dependencies: each role from step (2) has goal dependencies, then the ultimate objective of this step is to find task dependencies that will be responsible to achieve goals dependencies. Meanwhile, one goal (say g1) may need a set of tasks (say t1 = ft1:1; t1:2; : : :g) to accomplish it. Subsequently, means-end analysis needs to identify this set of the tasks. Similarly, the task may be decomposed into subtasks and this decomposition analysis will iterate until no new task dependencies arise.
The architectural design phase plays a crucial role in the
design process. Initially, it defines the organization of the
system in terms of the components and their interdependencies
that are identified in previous phase. This step focuses on
how system components work together to constitute a
multiagent system and introduces resources, goals and roles as
needed. This paper presents an architecture to tackle pitfalls
of standard approaches that do not underpin business meaning
and dynamic composition of existing services in which the
components are agent-based web services and their
interdependencies are specified in terms of commitments augmented with
argumentation capabilities to reason about the validity of these
commitments (we will explain commitment and argumentation
later on). In fact, this architecture is a call and return style in
the form of layered phases and an extension to the architecture
we developed in [
From Fig. 1 the main components of the proposed architecture are service providers, service consumers of web services, UDDI registers and communities with alliances structure. A community with alliances structure is organized dynamically according to the specifications discussed in previous phase (III-A). Hereafter we focus on operationalizing the steps through which the goal dependencies are to be fulfilled. The service providers publish and register the name of their services in UDDI registries with different nonfunctional proprieties (e.g., QoS) so that service consumers or users can search for appropriate QoS. More precisely, there are three kinds of agent-based web services (master-ws, allaincews and slave-ws) constitute the structure of community and collaborate with each other to achieve users’ requests.
A master-ws can be implemented as a web service for compatibility purposes with the slave web services and alliances web services that populate the community as well. It delegates goal dependencies to allaince-ws that will responsible for accomplishing them. The alliance web services manage micro-communities and decompose goal dependencies to slave web services that populate their alliance structure as well. Each slave-ws signs up contract with its alliances to commit to satisfy the delegated subgoal. The slave web services collaborate with each other to achieve these goals. Of course each slave web service has the ability to delegate or assign incomplete tasks to other slave web services to complete its goal. Moreover, allaince-ws can request from master-ws 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 all slave web services satisfy their contracts, their alliance web services consequently achieve their composite contracts. Hence these alliance web services need to inform the masterws with results to finalize users’ requests.
This phase is intended to introduce additional details for each architectural component of a community structure. To support this phase, we adopt social commitment, argumentative dialogues and dialogue games protocol from the agent programming community.
1) Step 4: Identify Social Commitments: our methodology captures high-level business meaning via identifying commitments between roles in terms of tasks. More precisely, this step analyzes each task dependency resulted from step (3) and that discovered in the architecture phase to identify the corresponding commitment. The notion here depends on the task dependency such that when the dependee (or the debtor) commits towards the depender (or the creditor) to execute the dependum task (e.g., t1) or the commitment content, then a commitment exists. The condition of the commitment is defined by identifying a task that dependee needs to satisfy to perform commitment content. Meanwhile, the creditors need to verify some constraints that are conjuncted with this commitment to guide them to determine the corresponding tasks resulting from executing this commitment. Whereas, if the dependee is not committed towards the depender to execute a task, then no commitment exists, in this case the dependee executes the intrinsic task to achieve its internal goal.
2) Step 5: Identify Argumentative Dialogues: this step identifies arguments that can be used either in negotiation, persuasion or information seeking dialogue based on commitments identified in step (4).
Argumentative Locutions Open-dialogue Accept(Ag-ws2; C(idx; Áx)) Refuse(Ag-ws2; C(idx; Áx)) Attack(Ag-ws2; C(idx; Áx);
C(idy; Áy)) Challenge(Ag-ws2; C(idx; Áx)) Justify(Ag-ws2; C(idx; Áx);
C(idy; Áy)) Make-Offer(Ag-ws1; C(idx; Áx)) Close-dialogue Descriptions A special argumentative act used to open the dialogue.
When Ag-ws2 has an argument in favor of Áx.
When Ag-ws2 has an argument against Áx.
When Ag-ws2 attacks the content of C(idy; Áy) by the content of its commitment C(idx; Áx).
When Ag-ws2 has neither an argument for Áx nor for :Áx, then it challenges Áx.
When Ag-ws1 has a commitment C(idx; Áx) to justify another commitment C(idy; Áy).
An Ag-ws1 makes an offer Áx to Ag-ws2 when Ag-ws1 has an argument in favor of Áx.
A special argumentative act used to close the dialogue.
This methodology terms these arguments by social
arguments, not only to emphasise their ability to resolve
conflicts within a social community, but also to highlight the fact
that two agent-based web services having task dependency can
negotiate or persuade and, upon agreement, commit to each
other for the specified value transfers. However, identifying
such arguments is not merely the last step. Since agent-based
web services need a language to express these arguments. In
[
The formal specification of these arguments is defined
in a dialogue game protocol, namely Persuasive-Negotiation
Protocol for CWSs (P N P -CW S) [
Definition 1: (Dialogue game) Let Open(Ag-ws1; C(idk; Ag-ws1; Ag-ws2; Cx; Ã; Á) be the opening action performed by Ag-ws1 and sent to another agent Ag-ws2 about content Á subject to à within alliance context Cx. A dialogue game Dg is a conjunction of rules, where the first rule defines the condition to enter Dg if the argumentation systems of Agws1 and Ag-ws2 support the satisfaction of the commitment condition Ã. The other rules identify possible actions that an agent-based web service can use as a reply when receiving an action from another agent-based web service if a given condition Condij is satisfied. This conjunction is specified as follows: Entry rule : Open(Ag-ws1; C(idk; Ag-ws1; Ag-ws2; Cx; Ã; Á)) ^ Condk Body rules : V0<j·N ¡Actioni(Ag-wsp; Ag-wsm; C(idx; Áx);
C(idy; Áy)) ^ Condij ) Actionij(Ag-wsn; Ag-wsO; C(idz; Áz); C(idw; Áw))¢ In the entry rule, the Open action represents the opening of the dialogue game and is executed just one time at the beginning of the dialogue. The Condk has two possibilities either the commitment condition à is true (i.e., can be generated from argumentation systems of Ag-ws1 and Agws2) or false. The body rules are executed many times during the dialogue game. In these rules, the Actioni(Ag-wsp; Agwsm; C(idx; Áx); C(idy; Áy)) is an action of type i on the propositional commitment,since the commitment condition holds, where Actioni 2 fCreate; F ulf ill; V iolate; Release; W ithdraw; Delegate; Assign; Accept; Ref use; Attack; Justif y; Challenge; M ake-Of f erg. Moreover, the bold elements meaning that they could be removed. For example, if Actioni 2= fDelegate; Assigng, then the element Ag-wsm could be removed. The Actionij (Ag-wsn; AgwsO; C(idz; Áz); C(idw; Áw)) is an action on the commitment of type j with content Áw that depends on the action of type i, where Actionij 2 fCreate; F ulf ill; V iolate; Release; W ithdraw; Delegate; Assign; Accept; Ref use; Attack; Justif y; Challenge; M ake-Of f erg. We notice that n = w when C(idx; Áx) does exists (e.g., Attack and Justify), otherwise, w = y. We also have n = m if Ag-wsm does exist (e.g., Delegate and Assign), ) is the implication symbol for dialogue game rules, and N is the number of allowed actions that Ag-wsn can perform after receiving an action from Ag-wsp where n; p 2 f1; 2g.
The commitment condition and content in this definition are Horn formulas, Condk defines the possibility of entering Dg when the condition of the commitment is satisfied. While Condij is expressed in terms of the possibility of generating an argument from the argumentation system.
To clarify the relationship between commitment and argumentation system, let us first define some notions used in our approach. The knowledge base of agent-based web service (Ag-ws) is denoted by KB(Ag-ws), it contains all information related to functional and nonfunctional requirements of Ag-ws. The argumentation system of Ag-ws is denoted by Argsys(Ag-ws) using Horn logic language where Á / Argsys(Ag-ws) denotes the fact that a Horn propositional formula Á can be generated from argumentation system of Agws. While the formula :Á / Argsys(Ag-ws) indicates that Á cannot be generated from argumentation system of Ag-ws.
The following is an example of dialogue game within alliance context Cx, in which after opening the dialogue, an alliance web service1 (alliance-ws1) invites a slave web service1 (slave-ws1) to join a current composition scenario where alliance-ws1 knows that slave-ws1 has a reasonable role to complete this scenario. The invitation is modeled using M ake-Of f er locution. Then slave-ws1 searches its Argsys(slave-ws1) to decide either to accept or refuse the invitation. slave-ws1 accepts the invitation by verifying some constraints related to the performance of alliance-ws1. That is, if the invited web service (slave-ws1) has an argument favoring the received invitation (e.g., alliance-ws1 has a good reputation) and does not have any argument against this invitation (e.g., slave-ws1 does not commit to join any other alliance). Thereby slave-ws1 has two choices either to accept this invitation, then slave-ws1 creates a commitment towards alliance-ws1 to join this composition scenario or to refuse, then slave-ws1 releases from this commitment. The formal representation of the acceptance case of entering and accepting the invitation is as follows:
Example 1: 1) Open(alliance-ws1; C(id1; alliance-ws1; slave-ws1; Ã; Á)) ^ (à /Argsys(slave-ws1)) ^(à /Argsys(alliance-ws1)) 2) Make-Offer(alliance-ws1; C(id1; Á)) ^ (Reputation-of -alliance = Good / Argsys(slave-ws1)) ^ (: Commit-to-J oin-an-alliance / Argsys(slave-ws1)) ) Accept(slave-ws1; C(id1; Á)) where à = f unctionality-matches-composite-scenario Á = Invitation-f or-joining The commitment manipulation underpins our approach with a simple mechanism of composite services between slave web services to handle users’ requests through three-party actions (e.g., delegation, assignment). In simple case of delegation action (i.e., without metacommitment), we have two commitments among three agent-based web services where if an agent cannot able to complete its service, then it delegates the service to another agent (this delegation is made randomly). To clarify our notion about composing services, suppose slave-ws1 is committed to alliance-ws1 to bring about some facts within alliance context (Cx), if the condition à holds. Meanwhile, the argumentation systems of slave-ws1 and alliance-ws1 support this condition and the argumentation system of slave-ws1 favors the content of this commitment. However, if any reason after creating the commitment, slave-ws1 cannot complete it, then it will delegate the commitment to another agent-based web service in the same alliance (say, slave-ws2). When slave-ws2 observes the delegated commitment, it uses its argumentation system to search if it has an argument supporting the condition of this commitment. Also, if the argumentation system of alliance-ws1 is still supporting the condition of this commitment, the slave-ws2 will create a new commitment towards alliance-ws1 (see Fig.2), formally:
Example 2: 1) Open(alliance-ws1; C(id1; alliance-ws1; slave-ws1; Cx; Ã; Á)) ^ (à / Argsys(alliance-ws1)) ^ (à / Argsys(slavews1)) 2) Make-Offer(alliance-ws1; C(id1; alliance-ws1; slavews1; Á)) ^(Á / Argsys(slave-ws1)) ) Accept(slave-ws1; C(id1; slave-ws1; alliance-ws1; Á)) 3) Accept(slave-ws1; C(id1; slave-ws1; alliance-ws1; Á)) ^ (® / Argsys(slave-ws1)) ) Delegate(slave-ws1; slave-ws2; C(id1; slave-ws1; alliance-ws1; Cx; Á)) ^ (à / Argsys(alliance-ws1)) ^ (à / Argsys(slave-ws2)) 4) Delegate(slave-ws1; slave-ws2; C(id1; slave-ws1; alliance-ws1; Cx; Á)) ^ (Á / Argsys(slave-ws2)) ) Create(slave-ws2; C(id2; slave-ws2; alliance-ws1; Cx; Á)) where à = the condition of the commitment Á = bring about some f acts ® = Á cannot be completed by slave-ws1 and Á can be perf ormed by slave-ws2
To illustrate the application of our methodology, we
consider a real-life insurance claim processing that has been
studied under the CrossFlow project [
profits. The last goal is represented in terms of soft goal.
Thus the customer depends upon the Insurer to handle
claim with Qos = f100%g and in exchange the Insurer
depends upon the customer for paying the insurance
premium [
According to the ontology associated with the community, mation task is decomposed into two subtasks, t1:2 =
the functionality of the community is InsuranceClaimProcess- frequest policy inf ormation; validate inf ormationg.
Acing 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 = f100%g of the automo- freceive claim; check invoice; agree to repair; obtain repair
bile damage and from now we refer to AGFIL by the Insurer estimate; inspect vehicleg. 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 [
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,
the repairer depends on the assessor for checking the invoice
and forwarding it to the Insurer, if the repairer sends the
invoice. Likewise, the call center and the assessor, the repairer
requires to define a new goal to receive repair charge from the
Insurer by depending on executing a task of receiving repair
charge [
This step transfers each task dependency into an appropriate
commitment to represent business meaning of interacting
parties of AGFIL. In [
We define two subscenarios from AGFIL scenario to
explain why we need argumentative dialogues to reason
about the validity of commitment operations. The first
subscenario is established between the Insurer and assessor
where the assessor commits to the Insurer to reach
agreement with the repairer for the vehicle repair, formally:
C(id3; assessor; Insurer; Insx; pay assess f ees; agree to
repair) [
1) Create(repairer; C(id3:1; repairer; assessor; Insx; Á)) ^ Cond1 ) Challenge(assessor; C(id3:1; repairer; assessor; Insx; ; Á)) 2) Challenge(assessor; C(id3:1; repairer; assessor; Insx; Á)) ^ Cond2 ) Justify(repairer; C(id3:2; repairer; assessor; Insx; Á0); C(id3:1; repairer; assessor; Insx; Á)) 3) Justify(repairer; C(id3:2; repairer; assessor; Insx; Á0); C(id3:1; repairer; assessor; Insx; Á)) ^ Cond3 ) Accept(assessor; C(id3:2; repairer; assessor; Insx; Á0)) W here : Á = Estimate-Repair-Cost = V; with V is a given value Cond1 = :(Á / Argsys(assessor)) ^ :(:Á / Argsys(assessor)); Á0 = Á01 ^ Á02; Cond2 = Á0 / Argsys(repairer); Cond3 = Á0 / Argsys(assessor)
Notice that the value of Á0 = Á01 ^ Á02 means that the cost of repair includes the value of the part1 (Á01) and part2 (Á02). Similarly, the adjustor and assessor can entre in negotiation dialogue about the estimated inspection cost. Moreover, argumentative dialogue in our case study can be used to spread agent-based web service knowledge in the form of information seeking dialogue. For example, when the call center requests policy information from the Insurer, the available information may be not enough to validate the received claim. Thus, the call center may need to spread his knowledge by requesting more information from the customer that enable the call center to send a valid information to the Insurer.
The second subscenario is established between the customer, Insurer and call center. When the customer reports an accident and his claim is valid, then the call center assigns a garage for vehicle repair. Otherwise, the call center does not assign a garage as it gathers invalid information from the customer compared to the information received from the Insurer. Thereby the intuitive semantic of the interaction between the call center and customer lacks clarity of business meaning related to the content of interaction (i.e, it is not meaningful). But, argumentative dialogue makes interaction more meaningful by guiding the call center to undertake a subtle decisions when the conflicts arise, then it challenges the customer to justify the validity of its commitment and to reach a mutual agrement that helps the customer to repair the vehicle. Moreover, the Insurer should persuade the call center, repairer, assessor and adjustor to join alliance structure by offering rewards that alliance grants to them.
In this paper, we first exposed some obstacles that restrict the use of agent-based web services in complex business applications and then, offered some solutions to tackle these obstacles through extending community structure with alliances structure and proposing a new methodology based on Tropos methodology. This methodology synthesizes three approaches: mentalistic states, social commitments and argumentative dialogues. The mentalistic artifacts such as goals, tasks and dependencies modeling techniques are compatible with concepts of Tropos (e.g., plan in Tropos is the task here). The social commitments define dependencies between agent-based web services in the early stages as businessmeaning of interactions and guide Tropos for accommodating and tracing the changes in the various phases of the methodology. While Tropos provides commitment with cues that identify different parties of dependencies (e.g., agents, goals, plans). Moreover, commitments enable the community to support dynamic reconfiguration of business interactions via delegation and assignment operations without altering the overarching structure of web services interactions. Argumentative dialogues support web services with richer capabilities to negotiate or seek information with other peers via reasoning about the correctness of commitments
The social-arguments proposed here are different from the
approach proposed in [
Let us now focus on comparing the proposed methodology
with the related ones. Many of Agent-Oriented Software
Engineering (AOSE) methodologies have been proposed over
the last years based on the concepts of actors, roles, goals
and plans include Gaia, Prometheus, MaSE, and Tropos.
These methodologies support various phases of the software
development life cycle, but Tropos differs from them in
including an early requirements phase. Moreover, some of
these methodologies like Gaia differs from Tropos in
involving safety and liveness conditions for the processes and
agents should be coarse-grained computational systems (like
UNIX process). Meanwhile, Gaia lacks reasoning scheme
based on early requirements engineering which limits the
flexibility of Gaia, as well as implementation phase is not
covered in this methodology. Our methodology complements
these methodologies by concentrating on social arguments
and argumentative dialogues, which they are ignored in these
methodologies. A key difference between our methodology
and Tropos [
Pankaj et al. [
Desai et al. [
Riemsdijk et al. [
Li et al. [
Regarding to CWSs, Maamar et al. [
As future work, we aim to formalize the strategic polices of service providers that help organizing web services in alliances structure and investigating the organization laws and norms ruling the roles within the community. The trustworthiness level of a master web service towards alliance web services and how a social-argumentative dialogue model is automatically mapped into a BDI-agent specification that can, at execution time, give useful feedback to refine the original design are fundamental issues we plan to investigate.
The authors would like to thank the reviewers for their valuable comments and suggestions. They also would like to thank NSERC (Canada), NATEQ FQRSC (Que´bec) and ERESSON for their financial support.