software agents and multiagent systems agent oriented software

Software Agents and Multiagent SystemsAgent Oriented Software Engineering

Viviana [email protected]

SIIT Master, University of Genoa (DISI)

SIIT Master, University of Genoa Software Agents and MASs 1 / 149

Disclaimer

This presentation may contain material protected by copyrightlaws.In particular, many lessons are based on the material that Russeland Norvig made available on the Web, as part of their book“Artificial Intelligence: A Modern Approach”We made this material available on the Web only to ensure timelydissemination among the students of the the SIIT Master of theUniversity of Genova, and is meant only for students’ personaluse.Any use different from the students’ personal use is prohibited.


Outline

1 Introduction

2 AOSE methodologies

3 Notation techniques

4 MAS infrastructures

5 Our research experience: WEST2EAST


Introduction

Introduction

F. Zambonelli, A. Omicini. Challenges and Research Directions inAgent-Oriented Software Engineering. Journal of AutonomousAgents and Multi-Agent Systems, 9(3), pp. 253-283, 2004P. Giorgini, B. Henderson-Sellers. Agent-Oriented Methodologies:An Introduction. In Agent-Oriented Methodologies. December2004 - January 2005. P. Giorgini and B. Henderson-Sellers (Eds.)


Introduction

Introduction

The features of agent-based systems are well suited to tackle thecomplexity of developing software in modern scenarios:

1 the autonomy of application components reflects the intrinsicallydecentralised nature of modern distributed systems and can beconsidered as the natural extension to the notions of modularityand encapsulation for systems that are owned by differentstakeholders;


Introduction

Introduction

2 the flexible way in which agents operate and interact (both witheach other and with the environment) is suited to the dynamic andunpredictable scenarios where software is expected to operate;

3 the concept of agency provides for a unified view of AI results andachievements, by making agents and MASs act as sound andmanageable repositories of intelligent behaviours.


Introduction

Introduction

In the last few years, together with the increasing acceptance ofagent-based computing as a novel software engineeringparadigm, there has been a great deal of research related to theidentification and definition of suitable models and techniques tosupport the development of complex software systems in terms ofMASs.This research, can be roughly grouped under the termAgent-Oriented Software Engineering (AOSE).


Introduction

The Promise of AOSE for distributed systemsengineering

Today’s software engineering approaches are increasinglyadopting abstractions approaching that of agent-based computing.This trend can be better understood by recognising that the vastmajority of modern distributed systems scenarios are intrinsicallyprone to be developed in terms of MASs, and that moderndistributed systems are already de facto MASs, i.e., they areindeed composed of autonomous, situated, and socialcomponents.


Introduction

The Promise of AOSE for distributed systemsengineering: Autonomy

As far as autonomy is concerned, almost all of today’s softwaresystems already integrate autonomous components.At its weakest, autonomy reduces to the ability of a component toreact to and handle events, as in the case of graphical interfacesor simple embedded sensors.However, in many cases, autonomy implies that a componentintegrates an autonomous thread of execution, and can execute ina proactive way.


Introduction

The Promise of AOSE for distributed systemsengineering: Situatedness

Today’s computing systems are also typically situated.For example, control systems for physical domains and sensornetworks, are built to explicitly manage data from the surroundingphysical environment, and take into account the unpredictabledynamics of the environment.Mobile and pervasive computing applications recognise (under thegeneral term of context-awareness) the need for applications tomodel explicitly environmental characteristics and data.Internet applications are also conceived for being aware of thefeatures and the dynamics of the environment where they work,namely, the Web.


Introduction

The Promise of AOSE for distributed systemsengineering: Sociality

Sociality in modern distributed systems comes in different flavors:1 the capability of components of supporting dynamic interactions,

i.e., interaction established at run-time with previously unknowncomponents;

2 the somewhat higher interaction level, overcoming the traditionalclient-server scheme;

3 the enforcement of some sorts of societal rules governing theinteractions.


Introduction

The Promise of AOSE for intelligent systemsengineering

Artificial Intelligence is mainly concerned with building intelligentsystems: the very name of “Artificial Intelligence” literally suggeststhe notion of artifacts exhibiting intelligent behaviour.Therefore, AI can be considered as an engineering field (dealingwith constructive concerns), rather than simply a scientific one(dealing with understanding and predicting intelligent systemsbehaviour).


Introduction


As already seen in the previous lessons, nearly 30 years of AIresearch were conducted by having research groups concentrateon single, isolated aspects of AI (like, say, artificial vision,knowledge representation, planning).There were few attempts of producing a reasonable set ofconceptual and practical tools, which could promote theintegration of such a vast amount of research findings into themainstream practice of software development.This is where agents are actually becoming a key abstraction intoday’s AI.


Introduction


The very notion of agents provides a uniform conceptual spacewhere all the findings of the AI field can be easily framed andrelated, and eventually find mainstream acceptance.There are three main reasons for this.


Introduction


1 Since they are a practical and conceptually affordable entry pointfor new students and practitioners interested in AI, i.e., the rightplace to experience intelligent behaviours, agents are likely towork as the most natural vehicle for spreading the results of AIresearch, as well as their exploitation in real world applicationdomains. In fact, this AI course follows this approach!


Introduction


2 The strong notion of encapsulation promoted by agents (whichincludes encapsulation of control) enables the integration ofcomponents with intelligent behaviour (whatever the model,pattern, or technology actually used to embody intelligence) inlarge software systems, with no influence on the overall systemarchitecture, nor on the overall development process.


Introduction


3 Finally, agent-oriented abstractions naturally provide for a new,powerful approach to the construction of intelligent systems, sothat agents can not only pave the way for classical AIachievements toward industrial systems, but also promote originaland more effective ways to solve highly-complex problems callingfor system intelligence.


Introduction


Correspondingly, the promise of AOSE is twofold.1 First, drawing from AI findings and making them part of the

everyday software engineering practice.2 Second, raising the level of complexity of the problems that can be

solved by human artifacts, by allowing artificial systems toincorporate ever-growing “amounts of intelligence” - whatever thiscould mean both in theory and in practice.


Introduction

Current directions in AOSE

The three current mainstream research directions in AOSE, besidesthose concerned with agent architectures and programminglanguages, already discussed in the previous lessons, are:

1 AOSE methodologies2 Notation techniques3 MAS infrastructures

We will discuss each of them in the next sections of this lesson.


AOSE methodologies

AOSE methodologies

Traditional methodologies of software development, drivingengineers from analysis to design and development, must betuned to match the abstractions of agent-oriented computing.To this end, a variety of novel methodologies to discipline andsupport the development process of a MAS have been defined inthe past few years, clarifying the various sets of abstractions thatmust come into play during MAS development and the duties andresponsibilities of software engineers.


AOSE methodologies

AOSE methodologies

AOSE methodologies, like any other ones, have two components:one that describes the process elements of the approach, and asecond that focuses on the work products and theirdocumentation.AOSE methodologies also need to contain sufficient abstractionsto fully model and support agents and MASs. They need to focuson an organized society of agents playing roles within anenvironment. Within such an MAS, agents interact according toprotocols determined by the agents’ roles.Note that when we speak of an AOSE methodology, we generallydo not mean a methodology that is itself constructed onagent-oriented principles, but one that is oriented at the creationof agent-based software.


AOSE methodologies

Genealogy of some AOSE methodologies


AOSE methodologies

Prometheus

L. Padgham and M. Winikoff. Prometheus: A Methodology forDeveloping Intelligent Agents. In Proceedings of the ThirdInternational Workshop on Agent-Oriented Software Engineering(AOSE 2002), at AAMAS’02, 2002.L. Padgham and M. Winikoff. Developing Intelligent AgentSystems: A Practical Guide. 2004, John Wiley and Sons.L. Padgham, J. Thangarajah, and M. Winikoff. Tool Support forAgent Development using the Prometheus Methodology. InProceedings of the First International Workshop on Integration ofSoftware Engineering and Agent Technology (ISEAT 2005), 2005.The Prometheus Design Tool:http://www.cs.rmit.edu.au/agents/pdt/.


http://www.cs.rmit.edu.au/agents/pdt/

AOSE methodologies

Prometheus

The Prometheus methodology consists of three phases.1 The system specification phase focuses on identifying the basic

functionalities of the system, along with inputs (percepts), outputs(actions) and any important shared data sources.

2 The architectural design phase uses the outputs from the previousphase to determine which agents the system will contain and howthey will interact.

3 The detailed design phase looks at the internals of each agentand how it will accomplish its tasks within the overall system.


AOSE methodologies

Prometheus

C:\Programmi\PDT>java -jar PDT 2 5f.jarOpen C:\Programmi\PDT\Examples\bookstore.pd


AOSE methodologies

Prometheus


AOSE methodologies

Prometheus: System Specification

This phase consists of the following steps, which are interleaved anditerated until the specification is considered sufficiently complete

1 Identification of actors and their interactions with the system, inthe form of percepts and actions;

2 Developing scenarios (by means of use cases) illustrating thesystem’s operation;

3 Identification of the system goals and sub-goals;4 Identifying any external data;5 Grouping goals and other items into the basic roles of the system.


AOSE methodologies

Prometheus: Architectural Design

This phase uses artefacts produced in the System Specification Phaseto determine what agent types will be included in the system and theinteraction between these agents. The steps in this phase are:

1 Determine the agent types2 Develop the interaction protocols3 Develop the system overview diagram


AOSE methodologies

Prometheus: Detailed Design

This phase uses artefacts produced in the Architectural Design Phaseto define the internals of every agent in the system and to specify howagents accomplish their overall tasks.

Each agent is refined in terms of its capabilities, internal events,plans, and data structures.Each capability has a capability overview diagram that capturesthe structure of the plans within this capability and the events thatare associated with these plans.The dynamic behaviour is described by process diagrams basedon the interaction protocols identified in the previous phase.


AOSE methodologies

Prometheus: a running example

We will go through the design and implementation of a small librarymanagement system. This system should be able to do the followingthings:

Allow for checkout of books, providing a return date to thecustomerAllow for return of booksAllow for reservation of unavailable booksAllow for notification of overdue booksAllow for notification of arrival of reserved books


AOSE methodologies

System specification: Goals and subgoals

Checkout books– Record book code to the user id checked out list.– Provide return date.Return books– Remove book code from the user idReserve unavailable books– Record book code as reserved for user id– Show the current due date for the book


AOSE methodologies


Give notification for overdue books– Access book record at the start of the day– Send email for overdue booksGive notification of arrival of reserved books– Access the reserved list for user– Send email notification


AOSE methodologies



AOSE methodologies

System specification: Scenarios

Depending on the system we can identify 5 different scenarios1 When the user comes to checkout the book.2 When the user returns the book.3 When a book becomes overdue.4 When the user asks to reserve a book.5 When the reserved book arrives.


AOSE methodologies

System specification: Scenarios


AOSE methodologies

System specification: Checkout scenario

1 Request for checkout2 Provide return date3 Record book code as checked out4 Provide book


AOSE methodologies

System specification: Return scenario

1 Book returned2 Remove book code from checkout list


AOSE methodologies

System specification: Reserve scenario

1 Request for reservation2 Record book code as reserved3 Show current due date4 Provide current due date


AOSE methodologies

System specification: Arrival scenario

1 Reserved book arrives2 Find the reserved user3 Send arrival email


AOSE methodologies

System specification: Overdue scenario

1 Start of the day2 Find overdue books at the start of the day3 Send overdue email


AOSE methodologies

System specification: Role grouping

1 Checkout books2 Return books3 Overdue books4 Reserve books5 Send Arrival Notification


AOSE methodologies

System specification: Checkout books role


AOSE methodologies

System specification: Return and overdue books roles


AOSE methodologies

System specification:Reserve books and send arrival notification roles


AOSE methodologies

Architectural design: Data coupling

In this phase we need to identify what type of data need to be stored inthe system as beliefs. In our running example, we need to keep theinformation of all books that have been checked out and also thebooks that have been reserved

The checkout books role and return books role update thecheckout belief and the overdue books role uses this to sendoverdue email.The reserve books role updates the reserve belief and the arrivalnotification uses it.


AOSE methodologies

Architectural design:Data coupling for checkout role


AOSE methodologies

Architectural design:Data coupling for reserve role


AOSE methodologies

Architectural design: Agent-role coupling

Now we group the roles and identify three agents to carry out this rolesin the system. The agents identified are:

Checkout AgentReservation AgentOverdue Agent


AOSE methodologies

Architectural design: Checkout agent-role coupling


AOSE methodologies

Architectural design: Reservation agent-role coupling


AOSE methodologies

Architectural design: Overdue agent-role coupling


AOSE methodologies

Architectural design: Agent acquaintance diagram


AOSE methodologies

Architectural design: System overview diagram


AOSE methodologies

Detailed design: Capabilities of the checkout agent

Checkout CapabilityReturn CapabilityGet Return Date Capability


AOSE methodologies

Detailed design: Capabilities of the checkout agent


AOSE methodologies

Detailed design: Checkout plan


AOSE methodologies

Detailed design: Return plan


AOSE methodologies

Detailed design: Get return date plan


AOSE methodologies

Detailed design: Capabilities of the reservation agent

Reservation CapabilityArrival Notification Capability


AOSE methodologies

Detailed design: Capabilities of the reservation agent


AOSE methodologies

Detailed design: Reservation plan


AOSE methodologies

Detailed design: Arrival notification plan


AOSE methodologies

Detailed design: Capabilities of the overdue agent

Find overdue books Capability


AOSE methodologies

Detailed design: Find overdue books plan


AOSE methodologies

PDT demo

PDT can be downloaded fromhttp://www.cs.rmit.edu.au/agents/pdt/.Let us start a demo session...


http://www.cs.rmit.edu.au/agents/pdt/

Notation techniques

Notation techniques

Specific notation techniques to express the outcome of thevarious phases of a MAS development process are needed,because traditional object- and component-oriented notationtechniques cannot easily apply.In this context, the AUML proposal, extending standard UMLtoward agent-oriented systems, is the subject of a great deal ofresearch and it is rapidly becoming a de facto standard.FIPA ACL represents an effort to standardize agentcommunication.


Notation techniques

FIPA specifications: an overview

http://www.fipa.org/repository/bysubject.html


http://www.fipa.org/repository/bysubject.html

Notation techniques

FIPA specifications: communication

http://www.fipa.org/repository/aclspecs.html


http://www.fipa.org/repository/aclspecs.html

Notation techniques

FIPA Message Structure

http://www.fipa.org/specs/fipa00061/SC00061G.pdfSIIT Master, University of Genoa Software Agents and MASs 71 / 149

http://www.fipa.org/specs/fipa00061/SC00061G.pdf

Notation techniques

FIPA Communicative Acts

Accept ProposalAgreeCancelCall for ProposalConfirmDisconfirmFailureInformInform IfInform RefNot UnderstoodPropagateProposeProxy


Notation techniques

FIPA Communicative Acts

Query IfQuery RefRefuseReject ProposalRequestRequest WhenRequest WheneverSubscribe

http://www.fipa.org/specs/fipa00037/SC00037J.pdf


http://www.fipa.org/specs/fipa00037/SC00037J.pdf

Notation techniques

Accept proposal summary

Accept proposal: The action of accepting a previously submittedproposal to perform an action.


Notation techniques

Accept proposal content


Notation techniques

Accept proposal description


Notation techniques

Accept proposal formal model


Notation techniques

Accept proposal example


Notation techniques

AUML

B. Bauer, J. P. Muller, J. Odell. Agent UML: A Formalism forSpecifying Multiagent Interaction, Agent-Oriented SoftwareEngineering, P. Ciancarini and M. Wooldridge eds., Springer,Berlin, pp. 91-103, 2001.J. Odell, H. V. D. Parunak and B. Bauer. Extending UML forAgents, AOIS Workshop at AAAI 2000.F. Bergenti and A. Poggi, Exploiting UML in the Design ofMulti-Agent Systems, ESAW Workshop at ECAI 2000.The AUML Web Site: http://www.auml.org/.


http://www.auml.org/

Notation techniques

AUML

When it makes sense to reuse portions of UML, then do it;when it doesn’t make sense to use UML, use something elseor create something new.


Notation techniques

AIPs in AUML

AUML is very suitable to represent Agent Interaction Protocols(AIPs).We consider the AUML interaction diagrams specificationproposed by the FIPA Technical Modeling Committee, 2003, (FIPAmodeling: Interaction diagrams, first proposal, july 02 2003).


Notation techniques

AIPs in AUML

An AIP is usually defined in relation to a particular agent activity.AIPs in AUML extend UML 2.0 sequence diagrams.The protocol name is contained in a box on the upper-left cornerof the diagram and is preceded by the keyword sd (sequencediagram).


Notation techniques

AIPs in AUML: Actors, roles, and lifelines

An AIP consists of some lifelines; for each lifeline, a rectangularbox contains information about the agent to which that lifelinebelongs, the role it plays in the MAS, and its class.The syntax used is agent-name/ agent-role: agent-class.


Notation techniques

AIPs in AUML: Message exchange

Labelled arrows between two lifelines represent messages.Messages must satisfy standardised communication languages(e.g. FIPA-ACL or KQML) which allow to specify the “speech act”(or “performative”) of the message and the fields that it isexpected to have.


Notation techniques

AIPs in AUML: Message exchange

AUML supports different interaction operators:a box, with an interaction operator given in its top-left corner, cansurround a part of the sequence diagram.Boxes can recursively contain messages and other boxes, and canbe divided into a number of regions separated from each other byheavy horizontal dashed lines.Each region can include a condition depicted as text in squarebrackets.If the condition is satisfied, then that region is selected and theactivities inside it are performed.


Notation techniques

AIPs in AUML: Weak sequencing operator

The weak sequencing operator as defined in UML 2.0 means aweak sequencing in a sequence of messages, that is to say, themessages within this box on the same lifeline are ordered but it isnot possible to make any assumption for message orderingcoming from different lifelines in the same box.


Notation techniques

AIPs in AUML: Alternative operator

Alternative means that there are several paths to follow, andthat agents have to choose at most one to continue.Guards are associated with alternatives: when a guard isevaluated to true, that alternative path is chosen.An else alternative may be optionally present: it is entered if noguard evaluates to true.If no guard is evaluated to true, and no else alternative isprovided, the alternative box of the diagram is not executed.


Notation techniques

AIPs in AUML: Option operator

The option operator only considers one path in the region.If the condition associated with this path is evaluated to true, thenthe path is executed, else nothing happens and the interactionfollows after this portion of the diagram.


Notation techniques

AIPs in AUML: Loop operator

The loop operator allows designers to represent that an orderedset of activities has to be applied several times.Designers can use either lower and upper bounds or a booleanexpression.As long as conditions are satisfied, the loop is executed and themessages are sent and received.


Notation techniques

AIPs in AUML: Parameters

Parameters are written separately outside the diagram in acomment, stereotyped as <<parameters>>.AIPs can have many parameters such as content language formessages, agent communication language (ACL), ontology, etc.


Notation techniques

Visual representation of AIPs in AUML


Notation techniques

Textual representation of AIPs in AUML (after Winikoff)

start FruitMarketagent r readeragent p publisher

message r p request availability and price(fruit(F))box alternativebox seqmessage p r inform available(fruit(F))message p r propose buy(fruit(F),price(EuroForKg))box alternativemessage r p request delivery modesmessage p r inform delivery mode(ListOfModes)message r p request accepted payment methodsmessage p r inform accepted payment methods(ListOfMethods)...

M. Winikoff. Towards Making Agent UML Practical: A Textual Notation and aTool. Proc. of ICQS, pp. 401-412, 2005, IEEE.


Notation techniques

Another PDT demo

Open C:\Programmi\PDT\Examples\protocol.txt to be cut andpasted into Entities ⇒ Edit Protocols


MAS infrastructures

MAS infrastructures

To support the development and execution of MASs, novel toolsand novel software infrastructures are needed.In this context, various tools are being proposed to transformstandard MAS specifications (i.e., AUML specifications) into actualagent code, and a variety of middleware infrastructures have beendeployed to provide proper services supporting the execution ofdistributed MASs.


MAS infrastructures

Infrastructures ad-hoc for MASs

FIPA abstract architecture:http://www.fipa.org/specs/fipa00001/SC00001L.html.


http://www.fipa.org/specs/fipa00001/SC00001L.html

MAS infrastructures

Infrastructures ad-hoc for MASs

There are many free and/or open source implementations of thelatest FIPA standards, including

Agent Development Kit (http://www.tryllian.org/)FIPA-OS (http://sourceforge.net/projects/fipa-os/)JADE (http://jade.tilab.com/)ZEUS (http://sourceforge.net/projects/zeusagent)

There are also several high profile commercial toolkits such asAgent Oriented Software’s JACK, Whitestein’s Living SystemsTechnology Suite and Lost Wax’s agent framework.


http://www.tryllian.org/

http://sourceforge.net/projects/fipa-os/

http://jade.tilab.com/

http://sourceforge.net/projects/zeusagent

MAS infrastructures

Other infrastructures suitable for MAS deployment

The Extensible Markup Language (XML) is the universal formatfor structured documents and data on the Web.The Resource Description Format (RDF) is a framework fordescribing and interchanging metadata.Web services are software systems designed to supportinteroperable machine-to-machine interaction over a network(W3C definition). Because this definition encompasses manydifferent systems, in common usage the term usually refers tothose services that use SOAP-formatted XML envelopes and havetheir interfaces described by WSDL.


MAS infrastructures


Grid computing provides the ability to perform higher throughputcomputing by taking advantage of many networked computers tomodel a virtual computer architecture able to distribute processexecution across a parallel infrastructure. Grid computing issupported by both commercial and open-source toolkits.


MAS infrastructures


A peer-to-peer (or P2P) computer network relies primarily on thecomputing power and bandwidth of the participants in the networkrather than concentrating it in a relatively low number of servers.P2P networks are typically used for connecting nodes via largelyad hoc connections. They are used for sharing content filescontaining audio, video, data or anything in digital format, as wellas realtime data, such as telephony traffic. Examples of P2Psystems are Napster, SETI@HOME (Search for ExtraterrestrialIntelligence), Gnutella.


MAS infrastructures

JADE

F. Bellifemine, A. Poggi, G. Rimassa. Developing multi-agentsystems with JADE. International Workshop on Agent Theories,Architectures, and Languages (ATAL-2000), Boston, MA, 2000.F. Bellifemine, A. Poggi, G. Rimassa. JADE - A FIPA-compliantagent framework. CSELT internal technical report. Part of thisreport has been also published in Proceedings of PAAM’99,London, April 1999, pp.97-108.The JADE home page: http://jade.tilab.com/


http://jade.tilab.com/

MAS infrastructures

JADE

JADE (Java Agent DEvelopment Framework) is a softwareframework fully implemented in Java language.It simplifies the implementation of MASs through a middle-warethat complies with the FIPA specifications and through a set oftools that supports the debugging and deployment phases.The agent platform can be distributed across machines (which noteven need to share the same OS) and the configuration can becontrolled via a remote GUI.The configuration can be even changed at run-time by movingagents from one machine to another one, as and when required.JADE is completely implemented in Java language and theminimal system requirement is the version 1.4 of JAVA (the runtime environment or the JDK).


MAS infrastructures

On-line tutorials

Tutorial 1 http://jade.tilab.com/doc/tutorials/JADEAdmin/startJade.html

Tutorial 2 http://jade.tilab.com/doc/JADEProgramming-Tutorial-for-beginners.pdf

Tutorial 3 http://www.iro.umontreal.ca/%7Evaucher/Agents/Jade/JadePrimer.html


http://jade.tilab.com/doc/tutorials/JADEAdmin/startJade.html

http://jade.tilab.com/doc/tutorials/JADEAdmin/startJade.html

http://jade.tilab.com/doc/JADEProgramming-Tutorial-for-beginners.pdf

http://jade.tilab.com/doc/JADEProgramming-Tutorial-for-beginners.pdf

http://www.iro.umontreal.ca/%7Evaucher/Agents/Jade/JadePrimer.html

http://www.iro.umontreal.ca/%7Evaucher/Agents/Jade/JadePrimer.html

MAS infrastructures

JADE demo

From command line: java jade.Boot -gui


MAS infrastructures

More details on JADE: The HalloWorld Agent


MAS infrastructures

Local names, GUID and addresses


MAS infrastructures

Passing arguments to an agent


MAS infrastructures

Agent termination


MAS infrastructures

The Behaviour class


MAS infrastructures

Behaviour scheduling and execution


MAS infrastructures

The agent execution model


MAS infrastructures

Behaviour types


MAS infrastructures

Scheduling operations at given points in time


MAS infrastructures

More about behaviours


MAS infrastructures

The communication model


MAS infrastructures

The ACLMessage class


MAS infrastructures

Sending and receiving messages


MAS infrastructures

Blocking a behaviour waiting for a message


MAS infrastructures

Selective reading from the message queue


MAS infrastructures

Receiving messages in blocking mode


MAS infrastructures

The yellow pages service


MAS infrastructures

Interacting with the DF Agent


MAS infrastructures

DF Description format


MAS infrastructures

JADE demo


Our research experience: WEST2EAST

WEST2EAST: Main activities of our tool



Our multiagent system implemented in JADE



The Service Provider agent



The WS-aware agent



AUML vs WS-BPEL

AUML WS-BPELRoles ag-name/ ag-role: ag-class myRole and partnerRole tagsMessage Labelled arrows between lifelines invoke and receive act.Content Speech-act based UnspecifiedSequence Weak Sequencing op. Sequence act.Alternative Alternative op. Switch act.Option Option op. If act.Cycle Loop op. While act.



AIPs in AUML



AIPs in WS-BPEL

WS-BPEL specification

1: <process xmlns="http://schemas.xmlsoap.org/..." ....>2: <partnerLinks>3: <partnerLink name="publisherPL" partnerLinkType="lns:SellerBuyer"

myRole="seller" partnerRole="buyer"/>4: <partnerLink name="readerPL" partnerLinkType="lns:BuyerSeller"

myRole="buyer" partnerRole="seller"/>5: </partnerLinks>6: <variables>7: <variable name="continue 1" element="lns:continue 1 type"/>8: <variable name="choose 2" element="lns:choose 2 type"/>....13: </variables>14: <copy><from opaque="yes"/><to>$continue 1.value</to></copy>15: <while condition="$continue 1.value=true">16: <sequence>17: <receive partnerLink="publisherPL" portType="lns:publisherPT"

operation="RCV Mess 1" createIstance="yes"/>18: <copy><from opaque="yes"/><to>$choose2.value</to></copy>19: <switch>20: <case condition="$choose2.value=1">....SIIT Master, University of Genoa Software Agents and MASs 132 / 149


AIPs in WS-BPEL

n-10: <if condition="$condition 6.value=true"/><then>n-9: <invoke partnerLink="publisherPL" portType="lns:publisherPT"

operation="SND Mess 15"/>n-8: <receive partnerLink="readerPL" portType="lns:readerPT"

operation="RCV Mess 15"/>n-7: </then> </if>n-6: </sequence>n-5: </case>n-4: </switch>n-3: </sequence>n-2: <copy><from opaque="yes"/><to>$continue 1.value</to></copy>n-1: </while>n: </process>



AIPs in WS-BPEL

WSDL specification

j: <xs:element name="content of Mess 15" type="xs:string"fixed="i may sell(fruit(F1))"/>

....k: <message name="Mess 15">k+1: <part name="performative" element="inform ca"/>k+2: <part name="Participant" type="tns:Participant MsgFromPublisher"/>k+3: <part name="Content" element="tns:content of Mess 15"/>k+4: <part name="Content Language" element="tns:content language name"/>k+5: <part name="Ontology" element="tns:ontology name"/>k+6: <part name="Protocol" element="tns:protocol name"/>k+7: </message>



AIPs in Winikoff’s notation

start sd FruitMarketFruitMarketOntology first order logicagent-publisher fs fruitSeller fruitSellerClassagent-reader fb fruitBuyer fruitBuyerClass

message r p request availability and price(fruit(F))box alternativebox seqmessage p r inform available(fruit(F))message p r propose buy(fruit(F),price(EuroForKg))box alternativemessage r p request delivery modesmessage p r inform delivery mode(ListOfModes)message r p request accepted payment methodsmessage p r inform accepted payment methods(ListOfMethods)



AIPs in Prolog

process(parameters(ontology(’FruitMarketOntology’),content language(’first order logic’)),...main fragment(seq([send(msg(’REQUEST’, ’availability and price(fruit(F))’)),switch([case(no guard,seq([receive(msg(’INFORM’, ’available(fruit(F),price(EuroForKg))’)),receive(msg(’PROPOSE’, ’buy(fruit(F),price(EuroForKg))’)),switch([case(no guard,seq([send(msg(’REQUEST’, ’delivery modes’)),...



The generated Prolog code

clause 1: exec(s(’sd FruitMarket’,0)) :-check guard(s(’sd FruitMarket’,0), no guard), exec(s(s(’sd FruitMarket’,0),0)).

clause 2: exec(s(’sd FruitMarket’,0)) :- exec(s(’sd FruitMarket’,final)).

clause 3: exec(s(’sd FruitMarket’,1)) :- exec(s(’sd FruitMarket’,0)).

clause 4: exec(s(s(’sd FruitMarket’,0),0)) :-exec(s(s(s(’sd FruitMarket’,0),0),0)).

clause 5: exec(s(s(s(’sd FruitMarket’,0),0),0)) :-send(’REQUEST’,’availability and price(fruit(F))’,’seller@giocas:1099/JADE’),exec(s(s(s(’sd FruitMarket’,0),0),1)).

clause 6: exec(s(s(s(’sd FruitMarket’,0),0),1)) :-check guard(s(s(s(s(’sd FruitMarket’,0),0),1),0), no guard),exec(s(s(s(s(’sd FruitMarket’,0),0),1),0)).

clause 7: exec(s(s(s(s(’sd FruitMarket’,0),0),1),0)) :-exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),0)).



The generated Prolog codeclause 8: exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),0)) :-

receive(’INFORM’,’available(fruit(F))’,’seller@giocas:1099/JADE’),exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),1)).

clause 9: exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),1)) :-receive(’PROPOSE’,’buy(fruit(F),price(Euro))’,’seller@giocas:1099/JADE’),exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),2)).

...................

clause n-3: exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1)) :-check guard(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1),no guard),exec(s(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1),0)).

clause n-2: exec(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1)) :-exec(s(’sd FruitMarket’,1)).

clause n-1: exec(s(s(s(s(s(s(’sd FruitMarket’,0),0),1),1),1),0)) :-receive(’INFORM’,’i may sell(fruit(F1))’,’seller@giocas:1099/JADE’),exec(s(’sd FruitMarket’,1)).

clause n: exec(s(’sd FruitMarket’,final)) :- true.



The generation process: translating cycles

A while(Guard,WhileActivities) action performed in the states(S,I) for reaching the state SFinal, is translated into

clause a: exec(s(S,I)) :- check guard(s(S,I),Guard), exec(s(s(S,I),0)).clause b: exec(s(S,I)) :- exec(SFinal).clause c: exec(s(S,I1)) :- exec(s(S,I)).

Clauses that translate the WhileActivities from s(s(S,I),0) to s(S,I1)



The generation process: translating communicationactions

A communication action (where communication may be either sendor receive) performed in the state s(S,I) for reaching the stateSFinal, is translated into the clause

clause a: exec(s(S, I)) :- communication(Perform,Cont,Addr), exec(SFinal).



The generation process: translating sequences

A seq([Activity0, ..., ActivityN]) action performed in thestate s(S,I) for reaching the state SFinal, is translated into

clause a: exec(s(S,I)) :- exec(s(s(S,I),0)).Clause that translates Activity0 from s(s(S, I),0) to s(s(S,I),1)Clause that translates Activity1 from s(s(S, I),1) to s(s(S,I),2)....Clause that translates ActivityN from s(s(S,I),N) to SFinal



The generation process: translating alternatives

A switch([case(Guard0,Activity0), ...,

case(GuardN,ActivityN)]) action performed in the state s(S,I) forreaching the state SFinal, is translated into

clause a: exec(s(S,I)) :- check guard(s(s(S,I),0),Guard0), exec(s(s(S,I),0)).Clauses that translates Activity0 from s(s(S,I),0) to SFinal

.... clause z: exec(s(S,I)) :- check guard(s(s(S,I),N),GuardN), exec(s(s(S,I),N)).Clauses that translates ActivityN from s(s(S,I),N) to SFinal



The generation process: translating options

An if then(Guard,Then activities) action performed in the states(S,I) for reaching the state SFinal, is translated into

clause a: exec(s(S,I)) :- check guard(s(S,I),Guard), exec(s(s(S,I),0)).clause b: exec(s(S,I)) :- exec(SFinal).

Clauses that translate ThenActivities from s(s(S,I),0) to SFinal



The reasoning stage (for the WS-aware agent only)

In order to complete the protocol execution with a success, theProlog program of the WS-aware agent (the fruit buyer in ourrunning example) must contain the factcondition to check(Condition), where Condition must beinstantiated with exists(Action), forall(Action), or no cond.Action may correspond to one of the transition types, send,receive, check: the WS-aware agent may thus check that there isone possible path where (resp. in any possible path) asend(Performative,Content,Receiver), or areceive(Performative,Content,Sender), or acheck guard(State,Guard), is executed.




In order to verify if its desiderata (either existential or universalproperties) are met by the protocol, the WS-aware agent exploitsmeta-programming facilities offered by Prolog. It makes adepth-first exploration of the SLD-tree for P ∪ {G} via R, where Pis the program generated in the previous step, G is the goal thatstarts the execution of the protocol, and R is the leftmost selectionrule.This exploration is aimed at either finding one path where thedesired action is performed (for demonstrating that an existentialproperty holds), or finding a path where the final state is reached,and the expected action has not been performed (fordemonstrating that a universal property does not hold).



The reasoning stage

I will try to enforce the following path, as long as the choice is up to me

check guard(s(’sd FruitMarket’,0),no guard)send(’REQUEST’,’availability and price(fruit(F))’,’seller@giocas:1099/JADE’)check guard(s(s(s(s(’sd FruitMarket’,0),0),1),0),no guard)receive(’INFORM’,’available(fruit(F))’,’seller@giocas:1099/JADE’)receive(’PROPOSE’,’buy(fruit(F),price(EuroForKg))’,’seller@giocas:1099/JADE’)check guard(s(s(s(s(s(s(’sd FruitMarket’,0),0),1),0),2),0),no guard)send(’REQUEST’,delivery modes,’seller@giocas:1099/JADE’)receive(’INFORM’,’delivery mode(ListOfModes)’,’seller@giocas:1099/JADE’)send(’REQUEST’,accepted payment methods,’seller@giocas:1099/JADE’)receive(’INFORM’,’accepted payment methods(ListOfMethods)’,’seller@giocas:1099/JADE’)




I executed the statement check guard(s(’sd FruitMarket’,0),no guard)I am still following the desired path!

.........

Nondeterministic action: I hoped to receive(’INFORM’,’delivery mode(ListOfModes)’,’seller@giocas:1099/JADE’)The message that I received is the one I was waiting for!

I executed the statementsend(’REQUEST’,accepted payment methods,’seller@giocas:1099/JADE’)I am still following the desired path!

Nondeterministic action: I hoped to receive(’INFORM’,’accepted payment methods(ListOfMethods)’,’seller@giocas:1099/JADE’)The message that I received is the one I was waiting for!

Finally, I have reached my goal!



Let’s run



WEST2EAST home page

http://www.disi.unige.it/person/MascardiV/Software/WEST2EAST.html




software agents and multiagent systems agent oriented software

Documents