Dynamic service composition enabled by introspective ... - Springer Link

Auton Agent Multi-Agent Syst (2013) 26:54–85 DOI 10.1007/s10458-011-9182-5

Dynamic service composition enabled by introspective agent coordination Yasmine Charif · Nicolas Sabouret

Published online: 14 October 2011 © The Author(s) 2011

Abstract Service composition has received much interest from many research communities. The major research efforts published to date propose the use of service orchestration to model this problem. However, the designed orchestration approaches are static since they follow a predefined plan specifying the services to be composed and their data flow, and most of them are centralized around a composition engine. Further, task decomposition is made prior to service composition, whereas it should be performed according to the available competencies. In order to overcome these limitations, we propose to model a dynamic approach for service composition. The studied approach relies on the decentralized and autonomous collaboration of a set of services whose aim is to achieve a specific goal. In our work, this goal is to satisfy requirements in software services that are freely expressed by human users (i.e. not predefined through a composition plan). We propose to enable the service collaborations through a multi-agent coordination protocol. In our model, agents offer services and are endowed with introspective capabilities, that is, they can access and reason on their state and actions at runtime. Thereby, the agents are capable of decomposing a monolithic task according to their service skills, and dynamically coordinating with their acquaintances to cover the whole task achievement. This paper presents the adaptive agent-based approach we propose for dynamic service composition, describes its architecture, specifies the underlying coordination protocol, called omposer, verifies the protocol’s main properties, and validates it by unfolding an implemented scenario. Keywords Dynamic service composition · Multi-agent systems · Coordination model · Interaction protocol · Introspective agents

Present Address: Y. Charif (B) Xerox, 800 Phillips Road, Webster, NY 14580, USA e-mail: [email protected] Y. Charif · N. Sabouret Université Pierre et Marie Curie, UMR 7606, LIP6, 4 Place Jussieu, 75005 Paris, France N. Sabouret e-mail: [email protected]

123

Auton Agent Multi-Agent Syst (2013) 26:54–85

55

1 Introduction If an application or a client requires functionalities which cannot be provided by a single service or business process, one of the core functions of a service-oriented architecture (SOA) platform is to make it possible to combine several services in order to respond to the expressed needs. This function is referred to as service composition. Service composition aims to make several services interoperate, interact, and coordinate so as to realize a specific goal [34]. In this paper, we are interested in the problem of dynamic service composition, or the processes underlying the satisfaction of user needs expressed in open environments such as the web or ambient intelligence (AmI). These processes are complex and require: (1) the collaboration of several (software) services, (2) the runtime identification of the services involved in this collaboration, (3) the runtime determination of each of the service tasks to successfully perform this collaboration. Current research and development efforts [6,7,15,47] address the service composition problem by specifying the roles of the involved services (the tasks performed), the messages exchanged between the services playing these roles (the data flow), as well as the constraints on the messages’ execution order (the control flow). In other words, they advocate the specification of a service orchestration. However, such an approach fails to cope with variable custom user needs, a constantly evolvable pool of services, and dynamic service binding glue code that characterize open SOA environments. On the other hand, adaptive approaches were proposed in agent and multi-agent system (MAS) communities in order to model autonomous and interactive agents and models to enable their coordination. Indeed, analogously to service collaboration, coordination among autonomous agents is defined as the process of organizing and distributing actions of a (distributed) system in order to achieve a specific goal or to obtain better system profitability. According to Malone and Crowston, coordination is also defined as the management of interdependencies among activities [44]. Thus, several agent coordination mechanisms (e.g., [4,23,30]) have been specified in order to help agents build solutions alone or cooperatively with other agents. In these models, and in contrast to service orchestration and choreography approaches [1,15,20,39], there is no global model governing the agents’ communications. Instead, agents’ coordination emerges due to their interactions with other agents. MAS are for this reason particularly well adapted to model distribution, openness, flexibility, and collaboration problems characterizing the design of dynamic service composition. In this context, one of the crucial evolutions of SOA concerns the substitution of the current object-oriented kernel of services by an agent-oriented kernel [13,36]. This will have the fundamental advantage of ensuring that services are proactive, intelligent, and really interactive. Furthermore, since agents can be involved in complex interactions while maintaining coordination with their acquaintances, services could be extended with the required properties so as to model dynamic service collaboration. For all these reasons, the general concern of our work is to study the use of MAS paradigm, and particularly agent coordination mechanisms, to model dynamic service composition. More precisely, our work aims at defining an agent coordination protocol, whereby agents can reason over the necessary tasks to achieve and decompose them according to their competencies. We talk about introspective agents to appoint these agents which have the ability to observe their own actions and infer whether they are capable of taking charge of a monolithic task integrally or partially. We make the assumption that agents are cooperative, in the sense that they will always answer to queries if they can (i.e. they behave as services). Using the defined protocol, these agents can coordinate with other agents in order to overcome their

123

56

Auton Agent Multi-Agent Syst (2013) 26:54–85

limitations and cover the satisfaction of needs freely expressed by the user, in the context of open and decentralized environments such as the web and AmI. The remainder of this paper is organized as follows. Section 2 analyzes traditional service composition techniques as well as service composition approaches relying on agent-based coordination mechanisms. It then discusses the autonomous and adaptive properties that an agent coordination model should meet to support dynamic service composition. Section 3 presents an overview of our approach and describes our SOA binding agent and web service technologies. More specifically, it describes the introspective agent model, the agents’ dialogue game syntax, a formalization of the user requirements, and the agent communication language (ACL). Section 4 describes omposer, our agent COordination PrOtocol for SERvice composition, and particularly specifies its transition and synthesized dialectical rules, which agents use to manage their conversations. Section 5 presents the analytical and experimental evaluations of our protocol first by verifying the main protocol’s properties (automated dialogues, termination, communication, and computation complexities), then by illustrating our protocol behavior through an implemented scenario. Finally, Sect. 6 concludes this paper with the main contributions of our agent-based service composition approach and future work directions.

2 Agent coordination and service composition in the literature This section reviews traditional service composition mechanisms used in the SOA space, and then analyzes those based on agent coordination models. From the good practices of each approach, it finally highlights the service composition properties suited for a dynamic and adaptive model. 2.1 Traditional service composition approaches SOA literature [6,7,47] highlights three viewpoints under which service composition may be described: behavioral interface, orchestration, and choreography. The behavioral interface describes the legal execution order of a service’s specific operations. The orchestration describes, from a service point of view, the service’s interactions as well as the internal steps (e.g., data transformation, internal modules invocations) between its interactions. Finally, the choreography describes, from a global point of view, those service interactions. 2.1.1 Behavioral interface A behavioral interface highlights the external observable behavior of a web service. We find this notion, for instance, in the abstract process concept of BPEL and in the collaboration protocol profile concept of ebXML [1,7]. 2.1.2 Service orchestration A service orchestration may be considered as the implementation of a behavioral interface. Both view service composition from one participant/service viewpoint. However, service orchestrations differ in their business purpose, as they do not only focus on the observable behavior of a web service, but specify also the required internal steps to the service’s execution.

123

Auton Agent Multi-Agent Syst (2013) 26:54–85

57

BPEL and BPMN [1,15] are reference languages to describe executable service orchestrations. Other languages for executable process languages include XLANG, WSFL, XPDL, and BPML [63]. 2.1.3 Service choreography A service choreography is a collaborative view of the interactions between services that allows each actor to describe its role in the collaboration [54]. It differs from a behavioral interface and a service orchestration in that it focuses on the exchanged messages by different participants, and not on one actor’s behavior. For instance, WSCI [3] uses the information provided by WSDL files to reconstitute the global schema of the message exchanges. In contrast, WS-CDL [39] and ebXML’s Multiparty Collaboration Model [7] centralize those descriptions and define pairwise process exchanges. The collaborative schema is therefore built by putting together the different descriptions. 2.1.4 Discussion The languages previously presented allow describing the workflow, the message exchanges, and the behavioral contract of each service in a service composition. Thereby, in order to achieve their collaborations, services are constrained to follow the specification of service interactions, the control and data flow defined by an IT designer in a choreography document or an orchestration script. Thus, these techniques do not suffice in open environments where the user needs vary, and where new services may appear, existing ones disappear or change their interface. For this reason, we study in the following service composition approaches that leveraged adaptive multi-agent coordination models. 2.2 Service composition approaches enabled by agent coordination models Explicit coordination of agents is supported by: (a) direct messaging mechanisms such as coalition formation, planning, and interaction protocols, and (b) indirect messaging mechanisms, such as tuple space, message queue, and publish/subscribe. In the context of services that have to collaborate so as to satisfy user needs in AmI and web environments, we are interested in direct messaging mechanisms where information is actively propagated to agents,1 in contrast to indirect messaging mechanisms, where no real-time interaction can occur [57]. Therefore, in the following discussion, we only analyze those direct coordination mechanisms that are relied upon by different service coordination approaches. 2.2.1 Coalition formation Several works using MAS techniques for service composition (e.g., [26,49,62]) propose the use of coalition formation mechanisms (e.g., [30,61]). For instance, Müller et al. [49], who propose an approach mixing direct and indirect messaging mechanisms, make use of a user agent that publishes in a blackboard the composition goal to be satisfied. This goal contains the description of a generic workflow referencing “types” of services (e.g., car rental service, hotel, etc). Existing agent-services, over a registration deadline, retrieve from the blackboard the sub-goals to be satisfied, and match the types of services wanted and the services they 1 Coordination of group activities is then based on events caused by the information flow.

123

58

Auton Agent Multi-Agent Syst (2013) 26:54–85

provide in order to assess if they can or not contribute to a coalition. Each agent-service can then propose or accept an offer from another agent-service to join a coalition. To join a new coalition, an agent-service must submit to with the vote of all agent-services forming it. The approach of Ermolayev et al. [26] proposes to compose services through the coalition of mediator agents whose role is to achieve tasks requested by services. The needs to be satisfied are expressed in term of constraints (e.g., budget = $1500) and preferences (e.g., continental breakfast). The decomposition of these needs is then done at the mediator agents’ level, which consult a task ontology [48] to determine whether the task is complex and implies the achievement of many different sub-tasks. More generally, agents in coalition formation algorithms have to reach a consensus to assign to each agent a set of tasks so that all their preferences are satisfied. Nonetheless, in these algorithms we consider that tasks have been decomposed into sub-tasks beforehand, and that each sub-task obtained is monolithic. Thus, coalition formation solutions rely on the assumption that there exist agents capable of completely satisfying one or several sub-tasks. In addition, the proposed service-oriented approaches use evaluation metrics such as the number of formed or abandoned coalitions and neglect qualitative evaluation of the result provided by the service composition according to the needs to be satisfied (e.g., have these needs been completely responded to? which dependencies appearing in the needs have been treated?, etc.).

2.2.2 Distributed planning Planning approaches automate the composition process by handling it as a planning problem (e.g., [11,42,56]). For instance, Bertoli et al. [11] perform planning by first translating available BPEL abstract processes [1] into state transition systems describing dynamic interactions with external services. This transformation into state transition systems allows submitting services to a planning engine. The composition task consists then in finding a plan that fulfills a composition goal among the available services’ domain. The plans generated by the planning algorithm are automata that can be translated into executable code. The SWORD tool [56] automates the composition task by using rule-based service descriptions. The user specifies the facts for the initial and final states. The planner then attempts to build a services’ chain that may satisfy these needs. In the approach of Kuter et al. [42] and Pellier and Fiorino [53], the planner SHOP2, from the Hierarchical Task Network (HTN) planner family, is used to build a global plan from the services’ (preconditions, effects) description. Broadly speaking, distributed planning methods [25,31], particularly multi-agent taskoriented planning, consider a global task that a manager agent decomposes into sub-tasks. The latter are assigned to a set of cooperative agents which are capable of achieving them. The user expresses his or her needs as a goal to the system. In this model, the sub-tasks (and agents’) coordination is performed through the plan built by the manager agent. However, one cannot guarantee the availability of agents capable of achieving a sub-plan. Consequently, several iterations of decomposing and distributing a global task may be necessary before sub-tasks match the available agent capabilities, and before agents genuinely start to execute a plan. Additionally, in this coordination model, no assumption is made on the way agents perform their sub-task(s). Other planning approaches ask the designer to provide the workflow description [51]. These strategies, known as result-sharing strategies, require the explicit specification of the relations between actions (e.g., the result of one agent action is needed by another to realize another action) [24]. Thus, though they have a low cost, they lead to ad hoc solutions which strongly depend on the application. Finally, HTN planning-based

123

Auton Agent Multi-Agent Syst (2013) 26:54–85

59

approaches use a powerful planning method in a domain where knowledge is complete and detailed but this is not the case with web services as demonstrated by Klush et al. [40]. 2.2.3 Interaction protocols An interaction protocol enables agents to have conversations governed by structured message exchanges. Several interaction protocols have been devised for systems for agents, but few address actually dynamic service composition. For instance, Barker et al. [6] propose a choreography language relying on multi-agent protocols (MAP), in which choreographies are formally defined with a process calculus. The proposed approach advocates three main roles for MAP’s agents, user, source, and processor, each of which can assume the sub-roles querier and receiver. A source receives a request message from the user and processes it by extracting information from the agent’s database. It then sends the data directly to the processor, which in turn composes the different replies using some domain specific processing algorithm. Atkinson et al. [4] propose a dialogue protocol called CDP in which commander agents can issue commands to receiver agents with justification for their instruction. Receiver agents can then question the command (e.g., “for joint actions, with whom should Receiver perform the action?”), challenge, accept, or reject it. Paurobally et al. [52] transcribe the Rubinstein Protocol (alternating offer and counter-offer) inside the XML-based service description so as to enable negotiation among services, whereas the WS-Agreement protocol [2] specifies twostep conversations, an offer followed by an agreement, to establish contracts and agreements between a service provider and a service consumer. Other well-known existing protocols such as FIPA’s [29] and Rubinstein [58] suppose that the sub-tasks to be achieved are atomic. This implies that each agent is supposed to be capable of completely executing a task, or not, and no way is consequently specified for agents to seek for other agents’ cooperation. This limits these protocols’ application in service composition, since the services goal decomposition and allocation should be done according to the available functionalities and not a priori [26]. In the FIPA-CNP for instance, a manager agent sends a call for proposal to participant agents who may propose to accept or refuse to perform the overall task (and not just take part of it). It neglects possible reasoning strategies on participant agent capabilities [50]. For these reasons, such a protocol is only applied in problems where tasks to realize are well defined and decomposed. 2.3 Discussion Several works in the literature [5,16] underlined numerous problems that need to be taken into consideration for the development of a service composition approach. They concern mainly service discovery, service management and coordination, information exchange infrastructure, fault tolerance and scalability, and adaptivity. In particular, efficient service discovery should allow finding out all the services conforming to a given functionality, indistinctly of the way to invoke them. For this reason, models such as OWL-S [45] and WSMO [43] have been proposed as semantic languages, for the uniform description of semantic web services. A good discovery architecture should be able to perform reasoning on the service description in order to find out proper services. However, certain sought-after properties may be absent or not necessarily expressed in the service public or semantic interface, as in the formulation of the needs to satisfy. This should not exclude the selection of services, whose description does not exactly match the formulation of the task to be achieved. On the contrary, service adaptivity and coordination might at this point potentially allow any service decomposing

123

60

Auton Agent Multi-Agent Syst (2013) 26:54–85

this task to perform the part it can do and to coordinate with other services in order to achieve the overall task. The main limitation to apply agent coordination models to service composition is their assumption that tasks to perform are decomposed prior to the coordination. On the contrary, a task should be decomposed according to the available functionalities (and not beforehand) into interdependent sub-tasks in term of execution [26]. As advocated by Problem Solving Methods (PSMs) [22,27], agents are required foremost to be capable of accessing their data and actions, in order to reason on them, determine if a task is complex (i.e. needs to be decomposed), and requires the collaboration of other agents for its performance. However, current agent programming frameworks, such as JADE [38], DIMA [33], or JACK [37], do not allow agents to access their actions (preconditions and effects) nor their current state (valid actions and data). Equally, ACL such as FIPA-ACL [29] and KQML [28] do not allow expressing questions or assertions about agents’ capabilities [10,64]. Or in the ACL proposed in Dignum et al. [21], abilities are modeled in a static way through static agent states. Finally, existing interaction protocols [29,58] consider that the tasks to be performed have been decomposed beforehand and do not take into account the dependencies between different sub-tasks resulting from a global task decomposition. As a consequence, even if they constitute a well adapted paradigm to process distribution, openness and flexibility problems characterizing web service and AmI environments, current coordination models do not suffice to cover the dynamic service composition problem. This is where our work steps in. We aim at proposing a task-oriented coordination model, i.e. one which supposes a global composition goal (user needs, typically). In this vision, we would like to design an interaction protocol relying on agents capable of observing their actions, to reason on them, and to interact about complex needs freely expressed by the user according to their own competencies. Agents can then take part dynamically in the decomposition of a task and coordinate with other agents in order to overcome their limitations and cover the overall task required. We present in the following sections the architecture, combining agent and web service technologies, and the introspective agents on which our approach relies. We also specify omposer, the coordination protocol supporting dynamic service composition.

3 Multi-agent-based SOA In this section, we describe our MAS-based SOA. We give an overview of our composition approach together with the layered structure of our agents and the cornerstone of their introspection capability. We describe the syntax of the agents’ dialogue game, propose a formalization for the user needs, and present our ACL. 3.1 Overview of the architecture Our work aims to propose a decentralized and dynamic approach for autonomous service composition. As illustrated in Fig. 1, our approach consists of four main steps (in this paper, only the first and the third ones are detailed): 1. first, a human user freely expresses his or her needs to a mediator (which has a GUI form). These needs consists of requests for data (e.g., “what is the camera’s resolution?”) and/or action commands (e.g., “record this program”, “buy the camera”), as well as global constraints (e.g., a global cost or duration), 2. a discovery module extracts keywords from the user needs in order to find, from an online registry, candidate services for composition,

123

Auton Agent Multi-Agent Syst (2013) 26:54–85

61

Fig. 1 Overview of the composition approach

3. services attempt to solve the user requests by exchanging messages. It is the composition stage. The agents’ conversations are managed by the omposers protocol presented in Sect. 4, 4. finally, the set of services which collaborated to respond to the user’s needs are proposed, along with their answers to the user. This is done on the condition that the services and their answers satisfy the global constraints expressed by the user. A mediator, which we refer to later on as the user agent, is in charge of this selection. In order to design this composition approach, and as recommended by W3C [14], our architecture defines a service as an abstract entity that may be implemented by a concrete agent. As depicted in Fig. 2, our agents are composed of three main layers: Knowledge layer It includes a database and a set of actions that can be encapsulated into a deployable and publishable service on the web (represented by the WSDL interface in Fig. 2). This is why we talk about agents offering services. Communication layer It allows the transportation of messages. This layer is managed by an ACL that defines the message structure. On top of that, our architecture generates a WSDL interface from the agents’ code, making it possible for agents to communicate on the web using standard transportation protocols such as SOAP (this is done by transcribing ACL-based messages into XML and encapsulating them within SOAP envelopes). Request processing and protocol management layer It allows agents to build answers to messages according to their competencies and to the previously exchanged messages. Fig. 2 Structure of an introspective agent offering a service

123

62

Auton Agent Multi-Agent Syst (2013) 26:54–85

Using such a structure, agents provide a set of functionalities—or services—through their knowledge layer. In the following, we describe this layer, upon which, together with the communication layer, the agents perform their reasoning and introspection. 3.2 Knowledge layer: model and knowledge of the introspective agents The language in which the agents of our architecture are programmed is called VDL-XML [59]. It allows associating each agent to a tree defining the agent’s data and actions. This tree is rewritten at each execution step, thus updating the agent’s (data and actions) status. Therefore, each agent can at any moment access its possible and impossible actions and subsequently reason over these actions. This is the reason why these agents are said to be introspective. Formally, an agent’s data and actions are defined as follows. 3.2.1 Data Let X be the set of attribute symbols, such as price, reference, size, duration, etc. An introspective agent’s database is a set D = {di }i∈[1,|D|] . Each data item d ∈ D is defined by: d = ∧ j∈N x j [v j ]

(1)

where v j is the instance value of the attribute x j ∈ X . Example If an agent provides a Camera selling service, it could have in its database the camera characterized by: t ype[camera] ∧ trademar k[canon] ∧ r e f [E O S40D] 3.2.2 Actions In addition to data, agents are provided with actions that constitute the services they offer. Each agent’s action is defined by a tuple A = name, P , E where: – name is the action’s name (e.g., record a TV program), – P is a set of preconditions, – E is the set of the action’s effects. These effects may be modifications to perform on the agent’s data and/or interactions with other agents. In our model, the introspective capabilities that support dynamic agent coordination rely on preconditions P only. We can outline two kinds of preconditions: (1) event patterns describe events that trigger actions. They specify the authorized format of the events which trigger the concerned actions, (2) guard conditions are Boolean expressions,2 which must be verified for the action to be executed (e.g., temperature , 10M px], price[< 200A C]. 3 Analogously to speech acts theory [60], the performative α may be assimilated to the illocutionary act, and

the request content γ to the propositional content.

123

Auton Agent Multi-Agent Syst (2013) 26:54–85 Table 1 Syntax of the request model

65

Request

α

γ

R1 R2 R3 R4 R5 R6 R7 R8

Order What-is Ack Assert-is Assert-cannot Assert-can Unknown Missing

E({xi [vi ]}i∈N ) {xi }i∈N ⊆ X | constraints E({xi [vi ]}i∈N ) {d j } j∈N ⊆ D E E, {xi }i∈N ⊆ X {xi }i∈N ⊆ X {xi }i∈N ⊆ X

Notation To ease readability, we adopt the notation α(γ ) to write requests. Example The request “I can reserve, but I need the checkout date” is written: Assert-can(Reser ve, check Out-date). Or the request “What is the boarding gate of flight number LH710?” is written: What-is(boar dingGate | f light N um[L H 710]). 3.4.2 Request dependencies The processing of What-is and Order requests may depend on the resolution of other requests. In order to formalize requests’ dependencies, we adopt the notation: request-get(x)

(5)

In the above notation, x is an attribute symbol, and request-get expresses that the value of x may be obtained following the resolution of another request. We speak about dependent values. Indeed, if a What-is request constraint or an Order request parameter holds the expression request-get(x), then the concerned request is dependent on the one that will provide the value of the attribute x. Example Consider the following request, which will be referred to as r : What-is(memoCar d-r e f | t ype[memoCar d], storageCapacit y[> 2G B], compliant W ith[request-get(camera Re f )]). The request r asks for the reference of a memory card with a storage capacity that should exceed 2 GB and whose model should be compatible with request-get(camera Re f ), i.e. the reference of a camera which is supposed to be obtained following the resolution of one of the user requests. Consequently, the request r is dependent on the one that will provide the value of the attribute camera Re f .

3.4.3 Dialogue game Similarly to the formalization adopted by McBurney et al. [46], we define the usage of our request model (see Table 1) to carry out dialogue games as follows:

123

66

Auton Agent Multi-Agent Syst (2013) 26:54–85

R1: Order

  – Syntax: Order E ({xi [vi ]})i∈N where E is an event name, ∀i, xi ∈ X is an attribute symbol, and vi is an instance value for xi . – Preconditions: None. – Meaning: This request is used to order an action execution. The set of parameters {xi [vi ]}i∈N tunes the action. – Response: An agent receiving an Order request can: (1) execute the ordered action and send an acknowledgment (see R3), (2) acknowledge that it is not capable of performing the action (R5), (3) only perform part of the action, compute the set of awaited attributes {Xa − Xr }, and then send a request to ask for the cooperation of other agents (R2, R6), or (4) find that the received request depends on another (R8). – Example: Order(Deliver ( pr oduct[ piano123], addr ess[Monzen-N akacho])). R2: What-is – Syntax: What-is({xi }i∈N | constraints) where the syntax of constraints is given in Eq. 4. As in SQL, we can use the keyword ∗ instead of the attribute xi in order to obtain all the attributes related to the required product. – Preconditions: This request can be sent: (1) without any specific context, (2) after the reception of a request R1 and the computation of awaited attributes {Xa − Xr }. – Meaning: This request is used to ask for attributes’ values, typically in the agent’s database. When it is sent after the computation of awaited attributes, its purpose is to help the agent solve a previously received request R1 using the acquaintances’ knowledge. Note that in that case, the request What-is cannot be expressed using dependent values. – Response: An agent receiving a What-is request can: (1) send the requested information through an assertion (R4), (2) inform that it does not hold the required information (R7), or (3) find and inform that the received request holds dependencies (R8). – Example: What-is(boar dingGate | f light N um[L H 710]). R3: Ack

  – Syntax: Ack E ({xi [vi ]})i∈N . – Preconditions: A request Order (R1) must previously have been sent. – Meaning: This request is used as an acknowledgment to confirm that an ordered action (through R1) has been executed. In case that the action’s effect implies computing and sending a result, it expresses it through the request parameters. – Response: None required. – Example: Ack(Conver t Eur oY en(amount[100A C], conver tion Result[16500 ])). R4: Assert-is – Syntax: Assert-is({d j } j∈N ) where ∀ j, d j ∈ D is data as defined in Eq. 1. – Preconditions: A request What-is (R2) or Assert-can (R6) must previously have been sent. – Meaning: This request is used to send assertions about data in order to answer questions on attribute values. Note that this request cannot be built with dependent values. – Response: (1) None required if it answers to a user’s request, (2) In case the original requests What-is and Assert-can have been sent in order to retrieve awaited attributes {Xa − Xr }, then the assertion may be useful for the agent to solve its original Order request (see R1.Response.case 3). – Example: Assert-is(boar dingGate[B31]).

123

Auton Agent Multi-Agent Syst (2013) 26:54–85

67

R5: Assert-cannot – Syntax: Assert-cannot(E). – Preconditions: A request Order (R1) or Unknown (R7) must previously have been sent. – Meaning: This request is used by an agent to inform that it cannot perform an ordered action. – Response: None required. – Example: Assert-cannot(Deliver ). R6: Assert-can – Syntax: Assert-can(E, {xi }i∈N ). – Preconditions: A request Order (R1) must previously have been sent. – Meaning: This request is used by an agent to inform that it can perform an ordered action, but requires additional information (specified through {xi }i∈N ) in order to achieve it. It is typically sent by an agent to the user. – Response: A user receiving an Assert-can request may: (1) have the required information and then send it through an Assert-is assertion (R4), (2) or not have it and send an Unknown request (R7). – Example: Assert-can(Deliver, r eci pient N ame). R7: Unknown – Syntax: Unknown({xi }i∈N ). – Preconditions: A request What-is (R2) or Assert-can (R6) must previously have been sent. – Meaning: This request is used by an agent or a user to acknowledge that it/she doesn’t have the requested information (in its database). – Response: An agent receiving an Unknown request was awaiting an answer for either a What-is or an Assert-can request. Either way, the latter may have been sent after the computation of the awaited attributes {Xa − Xr } to solve an Order request. In case no agent can provide the requested information about the awaited attributes, then it means that the agent in charge of executing the action could neither do it alone nor with its acquaintances’ cooperation. Otherwise, if the Unknown answer came from the user, then it means that the agent needs to start a dialogue and coordination with its acquaintances in order to solve the Order request. – Example: Unknown(boar dingGate). R8: Missing – Syntax: Missing({xi }i∈N ). – Preconditions: Either a request Order (R1) or a request What-is (R2) must previously have been sent. – Meaning: This request is used to notify that a previously received request has dependencies with another request, i.e. some attribute values are expressed using the expression in Eq. 5. The values of the attributes are then requested through a Missing request. – Response: An agent receiving a Missing request may: (1) send the requested attribute values through an assertion (R4), (2) or an Unknown request (R7) if it doesn’t hold them. If the agent processes other user requests within the same conversation, and if by the reception of the Missing request the agent does not hold the queried information, then it first waits until it can solve the other user requests, in case they provide the

123

68

Auton Agent Multi-Agent Syst (2013) 26:54–85

needed information. Agents are provided with time-outs associated to each processed request in order to prevent deadlocks. – Example: Missing(camera Re f ). 3.4.4 The users needs The purpose of agents’ coordination is to satisfy a set of needs expressed by the user. We def formalize them by the pair ϒ = R, C where: – R is a set of Order (R1) and/or What-is (R2) requests as previously defined. Indeed, our model allows the user to express requirements composed only of action commands and questions. – C is a set of global constraints on the requested services. Each constraint c ∈ C is a boolean expression on the results provided by two or more services4 (e.g., purchase plus delivery prices should not exceed $200). 3.5 Communication layer: agent communication language The language used by agents to communicate within our architecture is compatible with FIPA ACL. Nevertheless, in order to simplify syntax and more easily reach our objectives, we introduced higher-level performatives (e.g., Assert-can, Missing) in our ACL to support dynamic coordination needs. This ACL is called VDL-ACL [17] and structures messages as follows: m = [ sender, receiver, conv-id, reply-with, in-reply-to, req-id, content ]

(6)

sender: is the identifier of the sender agent. It is characterized by the agent’s address agent I D. receiver: is the identifier of the recipient agent(s). In our model, the specific agent I D all may be used to broadcast the message to all the agents of the systems. conv-id: is the identifier of the conversation. We assume that it is unique. reply-with: is the identifier that must be used by the receiver when it sends an answer back to this message sender. We make use of the conversation identifier as a value. in-reply-to: is the identifier of the message (actually its reply-with slot) to which the current one answers. req-id: are the identifiers of the user requests to which the content of this message answers. content: is the message content. It is composed of a set of requests {ri }i∈N , whose types were previously specified (see Table 1). This structure is similar to KQML [28] and FIPA-ACL [29] messages in that it has a content and a communication level.5 It however differs in the definition of the content slot. 4 As mentioned earlier in this paper, we do not address the selection of services according to global constraints. 5 As we focus on the protocol specification, we do not address intercomprehension problems that are com-

monly solved using ontologies. For this reason the ontology slot does not appear in our ACL.

123

Auton Agent Multi-Agent Syst (2013) 26:54–85

69

Fig. 3 Overview of the MAS behavior

Indeed, in contrast to KQML and FIPA-ACL, VDL-ACL performative(s) is inside the message content.

4 omposer: a coordination protocol for dynamic service composition This section presents omposer, our COrdination PrOtocol for SERvice composition. Firstly, it gives some of the protocol’s principles, namely the possible agent roles, the traces kept by the agents of their conversations, and how recipient agents for a message are computed. Secondly, it specifies the protocol’s operational semantics through transition rules, and illustrates them graphically through synthesized dialectical rules. 4.1 General overview 4.1.1 Agent roles As depicted in Fig. 3, the coordination protocol omposers used by agents specifies two possible agent roles: (1) Participant agent, which is the role of each agent involved in the coordination, and whose purpose is to interact with other agents to respond to the requirements to be satisfied, (2) User agent, which is mainly in charge of interacting with the user and broadcasting its requests to participant agents. Recall that agents in our system are cooperative since they act as services. In contrast to argumentation frameworks [4,9], our agents do not challenge the received commands; they try to answer them whenever they can. Moreover, argumentations protocols offer to clarify commands’ ambiguity by questioning the command sender. In our protocol, the ambiguity takes the form of the computation of a non-empty set of awaited attributes (not filled through the received command parameters). We specify hereafter how an agent behaves to disambiguate the received command. Definition 1 We say that an agent solved a request if it succeeded to build, for a received request Order (R1) or What-is (R2), an answering request whose performative is Ack, Assert-is, Assert-cannot, or Unknown (respec. R3, R4, R5, R7). We say that it satisfied it

123

70

Auton Agent Multi-Agent Syst (2013) 26:54–85

if the answer’s performative is Ack or Assert-is (i.e. R3, R4). An agent role ends whenever it solved all its requests.

4.1.2 Trace of interactions Agents in our MAS build their answering messages according to the received and previously sent messages. To do so, each agent is provided with a history table. A history table assigned to an agent Agt, and denoted by h¯ Agt , is a set of records, each of which is dedicated to a conversation. From an agent point of view, a conversation record is defined by def ∇ = (id, m 0 , M, U) where: – id is the record’s identifier. It also corresponds to the value of the conversation identifier conv-id of the messages involved in the interaction,6 – m 0 is the message sent to all the participants to trigger the conversation. It contains the user needs to be satisfied and is referred to as the triggering message, – M is the set of messages that the agent exchanged (sent and received) during its dialogues, – U is the set of final answers, built by the agent, to be sent to the user agent. Each final answer is a set {ρ1 j , . . . , ρ|R| j } containing for each user request ri a resolution ρi j (e.g., an agent can propose in ρ11 a Canon camera and in ρ12 a Sony camera). Each time an agent receives or sends a message, it stores or updates in its history table the appropriate element in the corresponding record. Further, it sends the answering message to the user agent as soon as it has built at least one final answer in U (i.e. containing a resolution for each user request). 4.1.3 Computation of the set of recipient agents ℵ When an agent builds a message, it always computes the set ℵ of agents to which the message has to be sent. It proceeds as follows. Let Agt be an agent receiving a message m and h¯ Agt its history table. Let ∇ be the record assigned to the conversation involving m, in which m 0 is the triggering message, such that ∇ = (id, m 0 , M, U). For each request ρi built in answer to a request ri of m, the agent computes the set ℵ of agents to which ρi has to be sent: – if ρi is a request What-is (R2) or Missing (R8) then it has to be sent to all the participant agents7 in order for them to attempt to find the required information; – if the built answer ρi is a request Ack (R3), Assert-is (R4), Assert-cannot (R5), or Unknown (R7), and if it answers to a request of the triggering message, then it is considered as a resolution to one of the user requests. Consequently, it is stored in the history table in the ∇ · U element. Whenever the agent has collected a final response in U (i.e. the agent has received a resolution of each user request), then it sends it to the user agent through an answering message; – in all the other cases, the request is sent to m’s sender only. 6 Note that a message built in response to another has the same value of the slot conv-id. As a consequence,

messages exchanged during a conversation share the same identifier conv-id. 7 These agents’ identities are stored in a local registry. The best agents for answering the request can then be

selected to be in ℵ.

123

Auton Agent Multi-Agent Syst (2013) 26:54–85

71

4.2 Specification of the coordination protocol omposer In an interaction protocol, agents have to agree on the possible sequence of messages and on the messages’ contents [32]. Thus, an interaction protocol is a set of (more or less) generic dialectical rules,8 shared by agents, which manage the agents’ conversation processing. In this section, we represent these rules graphically by means of micro-protocols using AUML (extension of UML 2.0 sequence diagrams) [8]. Before that, we give the operational semantics corresponding to the dialogue game syntax presented in Sect. 3.4.3. 4.2.1 Operational semantics We present here the operational semantics of our protocol in terms of a transition system [35]. A transition rule in our system holds when a specific message is sent and certain conditions are met. The transition leads to a message sending in the system (resulting from the processing of the sent message by the recipient agent), another transition rule, or nothing. We use the notation: P

TR : MSG, conditions − → MSG | TR |. Where MSG: sender, receiver, Ri, and the involved conditions and processings P are defined below. Therefore, the transition rules implied by our protocol are the following: P1

TR1: a, b, Order, r ecogni ze_event −→ b, a, Ack TR2: a, b, Order, ¬r ecogni ze_event −→ b, a, Assert-cannot TR3: a, b, Order, r ecogni ze_event, await_attributes, useragent_r ole(a) −→ b, user, Assert-can TR4: a, b, Order, dependent_values −→ b, ℵ, Missing P2

TR5: a, b, What-is, de f ined_attributes −→ b, a, Assert-is TR6: a, b, What-is, ¬de f ined_attributes −→ b, a, Unknown TR7: a, b, What-is, dependent_values −→ b, ℵ, Missing TR8: a, b, Ack, useragent_r ole(b) −→ . TR9: a, b, Assert-is, useragent_r ole(b) −→ . P3

TR10: a, b, Assert-is, original_r equest (Order) −→ goto(b, TR22) P3

TR11: a, b, Assert-is, original_r equest (What-is) −→ goto(b, TR23) TR12: a, b, Assert-cannot, useragent_r ole(b) −→ . TR13: a, user, Assert-can, de f ined_attributes −→ user, a, Assert-is TR14: a, user, Assert-can, ¬de f ined_attributes −→ user, a, Unknown TR15: user, b, Unknown, original_r equest (Order) −→ b, ℵ, What-is TR16: a, b, Unknown, useragent_r ole(b) −→ . TR17: a, b, Unknown, ¬useragent_r ole(b), r eceived_asser tion −→ . TR18: a, b, Unknown, ¬useragent_r ole(b), ¬r eceived_asser tion, P4

useragent_r ole(c), original_r equest (Order) −→ b, c, Assert-cannot TR19: a, b, Unknown, ¬useragent_r ole(b), ¬r eceived_asser tion, P4

useragent_r ole(c), original_r equest (What-is) −→ b, c, Unknown P2

TR20: a, b, Missing, de f ined_attributes −→ b, a, Assert-is TR21: a, b, Missing, ¬de f ined_attributes −→ b, a, Unknown 8 A dialectical rule specifies which messages are admitted for a given state of the interaction [41].

123

72

Auton Agent Multi-Agent Syst (2013) 26:54–85 P1

TR22: a, a, Order, useragent_r ole(b) −→ a, b, Ack P2

TR23: a, a, What-is, useragent_r ole(b) −→ a, b, Assert-is The transitions are deterministic because they occur in specific contextual or agent intrinsic conditions. A condition may be: r ecogni ze_event: When an action execution is requested (R1) and the implied event is recognized by the receiver agent. await_attributes: When an action execution is requested, and when the set of awaited attributes computed by the received agent is not empty, i.e. {Xa − Xr }  = ∅. useragent_r ole(Agt): Means that agent Agt is a user agent. dependent_values: When values are expressed in a request using request-get(x), where x ∈ X , hence they are dependent on the resolution of other user requests. de f ined_attributes: When requested attributes’ values are defined in the recipient agent’s database. Formally, for a request What-is({xi }i∈N | constraints), we have: – the set of requested attributes: {xi }i∈N – the agent’s data, which has the form: d = ∧ j∈N x j [v j ] (see Eq. 1), – and the constraints that the data must meet, which have the form: constraint = {xk [op vk ]}k∈N , given that op ∈ {>,