simpA: A Simple Agent-Oriented Java Extensionfor Developing Concurrent Applications

Alessandro Ricci Mirko Viroli Giulio Piancastelli{a.ricci,mirko.viroli,giulio.piancastelli}@unibo.it

LAnguages, methodologies and Development tools formulti-agent systemS (LADS 2007)

Durham, September 4–6, 2007

Outline

simpA Background and Motivation

The A&A Conceptual Model

simpA Framework and TechnologysimpA AgentssimpA ArtifactsAgent-Artifact Interaction

Ongoing and Future Work

Part I

simpA Background and Motivation

The need for high-level concurrency abstractions

Concurrency and concurrent programming is becoming more and morepart of mainstream programming

I multi-core architectures

I network computing

I Service-Oriented Architecture and Web Services

Mainstream programming languages (e.g. Java) offer basic low-levelconcurrency mechanisms and fine-grained synchronization mechanisms

I native support for multi-threading

I barriers, latches, semaphores (e.g. as in java.util.concurrent)

“Today’s concurrent programming languages and tools are at a level

comparable to sequential programming at the beginning of the structured

programming era. What we need is OO for concurrency – higher-level

abstractions that help build concurrent programs, just as object-oriented

abstractions help build large componentized programs.” (H. Sutter,

J. Larus, Software and the Concurrency Revolution, ACM Queue, 2005)

simpA vs extensions of the object-oriented paradigm

simpA shares the aim of actors and active objects approaches tointroduce a general-purpose abstraction layer for simplifying thedevelopment of concurrent applications

simpA vs actors

Differently from actor-based approaches, in simpA also the passivecomponents of the systems are modeled as first-class entities(artifacts), alongside the active parts (actors in actor-basedsystems).

simpA vs active objects

Active-objects are typically objects with further capabilities, whilein simpA a strong distinction between active and passive entities ispromoted: agents and artifacts have completely differentproperties, with a clear distinction at the design level of their role,i.e. encapsulating pro-active behavior (agents) andfunction-oriented behavior (artifacts).

simpA vs agent-oriented Java extensions

JACK and JADEX extend the basic Java platform in order tosupport the programming of intelligent agents, based on the BDIarchitecture and the FIPA standards

I They are cognitive agent programming platforms

I They are targeted to the engineering of distributed intelligentsystems for complex application domain

However, simpA targets mainstream instead of special purposeprogramming, and focusses on concurrency as a design modelrather than on agent intelligence

simpA vs agent-oriented Java-based platforms

JADE provides a general-purpose middleware that complies withthe FIPA specifications for developing peer-to-peer distributedagent-based applications

I In JADE there are only agents, in simpA there are agents andartifacts

I Activities in simpA are similar to behaviors in JADE, but. . .

I . . . in simpA the definition of structured activities is donedeclaratively in the activity agenda, while in JADE is doneoperationally by creating and composing objects of specificclasses

What is simpA?

simpA is a library-based extension of Java which providesprogrammers with agent-oriented abstractions on top of the basicobject-oriented layer, as basic building blocks to define thearchitecture of concurrent applications

Why multi-agent systems?

Agents and multi-agent systems natively capture and modeldecentralization of control, concurrency of activities, andinteraction and coordination of activities: therefore, they can beconsidered a good candidate for defining a paradigm formainstream concurrent programming.

Agents and Artifacts (A&A)

simpA is based on the Agents and Artifacts meta-model, combiningactivity-oriented components with function-oriented components asa novel approach for modeling and engineering multi-agent systems

Part II

The A&A Conceptual Model

A&A Abstractions (I)

The metaphors and abstractions at the core of A&A are rooted inhuman cooperative working environments, investigated bysocio-psychological theories such as Activity Theory

Reference system

The reference example is the modeling of a complex system wheremultiple concurrent activities are carried on in a coordinated way

InteractionHumans work concurrently and cooperatively in the context of thesame activities, interacting

I directly, by means of speech-based communication

I indirectly, by means of artifacts and tools that are shared andco-used

A&A Abstractions (II)

The basic modeling abstractions are agents and artifacts

I the agent abstraction modelsthe (pro-)active part of asystem, encapsulating the logicand control of such activities

I the artifact abstraction modelsthe resources and tools createdand used by agents during theiractivities

Besides, the notion of workspace provides a logic container ofagents and artifacts, and can be used to structure the overall setsof entities, defining a topology of the working environment andproviding a way to frame the interaction inside it

Defining Agents

An agent is an activity-oriented component whose computationalbehavior accounts for performing actions in an environment andgetting information back in terms of perceptions

Actions and perceptions

Actions and perceptions concern in particular the use of artifactsand direct communication with other agents

Memory and state

As a state-full entity, each agent has:

I a long term memory used to store data and informationneeded for its overall activity

I a short term memory used as a working memory to storetemporary information useful when executing single actions

Defining ArtifactsAn artifact is a passive function-oriented component designed toprovide some kind of functionality that can be used by agents

Structuring functionalities

The functionality of an artifact is structured in terms of operationswhose execution can be triggered by agents through artifact usageinterface

Usage interface

The usage interface defines a set of commands used to trigger andcontrol operation execution, each one identified by a label and alist of input parameters

Artifact observability

The information flow from the artifact to agents is modeled interms of observable events generated by artifacts and perceived byagents, and of observable properties as variables whose value canbe inspected by agents dynamically, without necessarily executingoperations on the artifact

Agent-Artifact Interaction: Use and Observation (I)

use opX(params)

opX EXECUTIONTRIGGERED

1a

2a

Step 1a The interaction starts by means of an agentperforming a use action

Step 2a The use action triggers and control the execution ofan operation over an artifact

Agent-Artifact Interaction: Use and Observation (II)

SensorsThe observable events possibly generated by the artifact executingan operation are collected by agent sensors, that are those agentparts connected to the environment where the agent is situated

Active sensing

There is an active sensing model for managing perceptions sincemaking the agent aware of the stimuli collected by the sensors isan action that must be explicitly performed by the agent itself

No control coupling

There is no control coupling between an agent and an artifactwithin the execution of an operation: when an agent triggers theexecution of an operation, it retains its control (flow) and theexecution of the operation on the artifact is carried onindependently and asynchronously.

Agent-Artifact Interaction: Use and Observation (III)

XYZ

opX EXECUTION

e

e

SENSOR

my_event1

op_exec_completed

sense with-my-filter

2b

1b

Step 2b The execution of an operation by an artifactgenerates observable events collected by agentsensors, and results in updating the artifact innerstate and possibly artifact observable properties

Step 1b Agents perform a sense action to explicitly retrievethe observable events collected by their sensors

Part III

simpA Framework and Technology

Design Principles

I simpA is an extension of Java to support the mainabstractions from the A&A conceptual model

I realized as a libraryI exploiting Java 5 annotations

I Compilation and execution of simpA programs use standardcompiler and Virtual Machine

I no need for preprocessors, compilers, class loaders, JVMpatches

I Agents and artifacts are not first-class abstractions for thelanguage and Virtual Machine

I simpA promotes a programming approach as agile as possibleI minimize the number of classes to be introduced to define

agents and artifacts

I simpA is Open SourceI available at http://www.alice.unibo.it/simpa

A reference simpA application

The application creates a simple Cafeteria workspace composedby a single Waiter agent using two CoffeeMachine artifacts.

WaiterThe Waiter agent is programmed with the objective to make onecoffee and one tea by exploiting two different coffee machines, andto deliver them when both are ready within a certain amount oftime, or just the coffee if the tea production lasts too long

Coffee MachineThe CoffeeMachine artifact provides a usage interface withcontrols for selecting the type of drink (coffee or tea) and makingit. Then, while making the drink, it provides a usage interface toadjust the sugar level and possibly stop the operation.

The simpA environment

public class TestCafeteria {public static void main(String[] args) {ISimpaEnvironment env = Simpa.getInstance("Cafeteria");env.createArtifact("cmOne", "CoffeeMachine");env.createArtifact("cmTwo", "CoffeeMachine");env.spawnAgent("waiter", "Waiter");

}}

Agents in simpA

An agent (template) is represented by a single class, extendingalice.simpa.Agent. The elements defining an agent are mappedonto class elements, suitably annotated.

Atomic and structured activitiesActivities can be either atomic or structured, i.e. composed bysub-activities

I Atomic activities are implemented as methods with the@ACTIVITY annotation, with no input parameters and voidreturn type

I Structured activities can be described as activities composedby a hierarchy of sub-activities

The execution of an agent consists in executing the activities asspecified in its template, starting from the main one

Agent structured activitiesThe notion of agenda is introduced to specify the set of thepotential sub-activities composing the activity, referenced as todoin the agenda

I Each todo specifies the name of the sub-activity to execute,and optionally a precondition

I When a structured activity is executed, the todo in theagenda are executed as soon as their preconditions hold

I If no precondition is specified, the todo is immediatelyexecuted, so that multiple sub-activities can be executedconcurrently in the context of the same activity

I A persistent todo is reinserted in the agenda after itsexecution, so as to be possibly executed again

A structured activity is implemented by methods with an@ACTIVITY WITH AGENDA annotation, containing todo descriptionsas a list of @TODO annotations that specify the name of thesub-activity to execute and an optional pre property as itsprecondition

The Waiter agent

public class Waiter extends Agent {

@ACTIVITY_WITH_AGENDA({@TODO(activity="makeOneCoffee"),@TODO(activity="makeOneTea"),@TODO(activity="deliverBoth",

pre="completed(makeOneCoffee),completed(makeOneTea)"),

@TODO(activity="deliverJustCoffee",pre="completed(makeOneCoffee),

memo(tea_not_ready)"),}) void main() {}

@ACTIVITY void makeOneCoffee() throws Exception { ... }@ACTIVITY void makeOneTea() throws Exception { ... }@ACTIVITY void deliverBoth() { ... }@ACTIVITY void deliverJustCoffee() { ... }

}

The Waiter agent

public class Waiter extends Agent {

@ACTIVITY_WITH_AGENDA({@TODO(activity="makeOneCoffee"),@TODO(activity="makeOneTea"),@TODO(activity="deliverBoth",

pre="completed(makeOneCoffee),completed(makeOneTea)"),

@TODO(activity="deliverJustCoffee",pre="completed(makeOneCoffee),

memo(tea_not_ready)"),})

void main() {}

@ACTIVITY void makeOneCoffee() throws Exception { ... }@ACTIVITY void makeOneTea() throws Exception { ... }@ACTIVITY void deliverBoth() { ... }@ACTIVITY void deliverJustCoffee() { ... }

}

The Waiter agent

public class Waiter extends Agent {@ACTIVITY_WITH_AGENDA({

@TODO(activity="makeOneCoffee"),@TODO(activity="makeOneTea"),@TODO(activity="deliverBoth",

pre="completed(makeOneCoffee),completed(makeOneTea)"),

@TODO(activity="deliverJustCoffee",pre="completed(makeOneCoffee),

memo(tea_not_ready)"),

}) void main() {}

@ACTIVITY void makeOneCoffee() throws Exception { ... }@ACTIVITY void makeOneTea() throws Exception { ... }@ACTIVITY void deliverBoth() { ... }@ACTIVITY void deliverJustCoffee() { ... }

}

The Waiter agent

public class Waiter extends Agent {@ACTIVITY_WITH_AGENDA({

@TODO(activity="makeOneCoffee"),@TODO(activity="makeOneTea"),

@TODO(activity="deliverBoth",pre="completed(makeOneCoffee),

completed(makeOneTea)"),@TODO(activity="deliverJustCoffee",

pre="completed(makeOneCoffee),memo(tea_not_ready)"),

}) void main() {}

@ACTIVITY void makeOneCoffee() throws Exception { ... }@ACTIVITY void makeOneTea() throws Exception { ... }@ACTIVITY void deliverBoth() { ... }@ACTIVITY void deliverJustCoffee() { ... }

}

The Waiter agent

public class Waiter extends Agent {@ACTIVITY_WITH_AGENDA({

@TODO(activity="makeOneCoffee"),@TODO(activity="makeOneTea"),@TODO(activity="deliverBoth",

pre="completed(makeOneCoffee),completed(makeOneTea)"),

@TODO(activity="deliverJustCoffee",pre="completed(makeOneCoffee),

memo(tea_not_ready)"),}) void main() {}

@ACTIVITY void makeOneCoffee() throws Exception { ... }@ACTIVITY void makeOneTea() throws Exception { ... }@ACTIVITY void deliverBoth() { ... }@ACTIVITY void deliverJustCoffee() { ... }

}

The Waiter agent

public class Waiter extends Agent {@ACTIVITY_WITH_AGENDA({

@TODO(activity="makeOneCoffee"),@TODO(activity="makeOneTea"),@TODO(activity="deliverBoth",

pre="completed(makeOneCoffee),completed(makeOneTea)"),

@TODO(activity="deliverJustCoffee",pre="completed(makeOneCoffee),

memo(tea_not_ready)"),}) void main() {}

@ACTIVITY void makeOneCoffee() throws Exception { ... }@ACTIVITY void makeOneTea() throws Exception { ... }@ACTIVITY void deliverBoth() { ... }@ACTIVITY void deliverJustCoffee() { ... }

}

@TODO Preconditions

Preconditions are expressed as a boolean expression over a basicset of predefined predicates

I use and/or logic connectors in the form of the , and ;symbols, respectively

I Amongst the predefined predicates there are completed/1,failure/2, memo/1, duration/2

The predicates make it possible to specify conditions on thecurrent state of the activity agenda, in particular

I on the state of sub-activities, if they started, completed, oraborted

I on the memos that could have been attached to the agenda

Agent memory

Long-term memory

Agent long-term memory is realized as an associative store calledmemo space, where the agent can dynamically attach, associativelyread and retrieve chunks of information called memo

I a memo is a tuple, characterized by a label and an ordered setof arguments, not necessarily bound to some data object

I a memo is identified by its label

I only one instance of a memo can exist at a time

Instance fields of an agent class are not used

Short-term memory

Local variables in methods are used to represent short-termmemory for a single atomic activity

Using memo

@ACTIVITY void makeOneTea() throws Exception {SensorId sid = linkDefaultSensor();ArtifactId id = lookupArtifact("cmTwo");

use(id, new Op("selectTea"));use(id, new Op("make"), sid);try {Perception p = sense(sid, "tea_ready", 6000);memo("drink2", p.getContent(0));

} catch (NoPerceptionException e) {memo("tea_not_ready");throw new ActivityFailed();

}}

Artifacts in simpA

An artifact (template) is represented by a single class, extendingalice.simpa.Artifact. The elements defining an artifact aremapped onto class elements, suitably annotated.

Atomic and structured operations

Operations can be either atomic, executed as a singlecomputational step, or structured, composed by multiple steps

I Atomic operations are implemented as methods with the@OPERATION annotation and void return type

I The name and parameters of the method coincide with thename and parameters of the operation

I Structured operations are implemented by dynamicallyspecifying the operations steps composing the operation

The CoffeeMachine artifact

@ARTIFACT_MANUAL(states = {"idle","making"},start_state = "idle")

class CoffeeMachine extends Artifact {

@OBSPROPERTY String selection = "";@OBSPROPERTY double sugarLevel = 0.0;

int nCupDone = 0;boolean makingStopped;

@OPERATION(states={"idle"}) void selectCoffee() { ... }@OPERATION(states={"idle"}) void selectTea() { ... }@OPERATION(states={"idle"}) void make() { ... }@OPERATION(states={"making"}) void addSugar() { ... }@OPERATION(states={"making"}) void stop() { ... }

}

The CoffeeMachine artifact

@ARTIFACT_MANUAL(states = {"idle","making"},start_state = "idle")

class CoffeeMachine extends Artifact {

@OBSPROPERTY String selection = "";@OBSPROPERTY double sugarLevel = 0.0;

int nCupDone = 0;boolean makingStopped;

@OPERATION(states={"idle"}) void selectCoffee() { ... }@OPERATION(states={"idle"}) void selectTea() { ... }@OPERATION(states={"idle"}) void make() { ... }@OPERATION(states={"making"}) void addSugar() { ... }@OPERATION(states={"making"}) void stop() { ... }

}

The CoffeeMachine artifact

@ARTIFACT_MANUAL(states = {"idle","making"},start_state = "idle")

class CoffeeMachine extends Artifact {

@OBSPROPERTY String selection = "";@OBSPROPERTY double sugarLevel = 0.0;

int nCupDone = 0;boolean makingStopped;

@OPERATION(states={"idle"}) void selectCoffee() { ... }@OPERATION(states={"idle"}) void selectTea() { ... }@OPERATION(states={"idle"}) void make() { ... }

@OPERATION(states={"making"}) void addSugar() { ... }@OPERATION(states={"making"}) void stop() { ... }

}

The CoffeeMachine artifact

@ARTIFACT_MANUAL(states = {"idle","making"},start_state = "idle")

class CoffeeMachine extends Artifact {

@OBSPROPERTY String selection = "";@OBSPROPERTY double sugarLevel = 0.0;

int nCupDone = 0;boolean makingStopped;

@OPERATION(states={"idle"}) void selectCoffee() { ... }@OPERATION(states={"idle"}) void selectTea() { ... }@OPERATION(states={"idle"}) void make() { ... }@OPERATION(states={"making"}) void addSugar() { ... }@OPERATION(states={"making"}) void stop() { ... }

}

The CoffeeMachine artifact

@ARTIFACT_MANUAL(states = {"idle","making"},start_state = "idle")

class CoffeeMachine extends Artifact {@OBSPROPERTY String selection = "";@OBSPROPERTY double sugarLevel = 0.0;

int nCupDone = 0;boolean makingStopped;

@OPERATION(states={"idle"}) void selectCoffee() { ... }@OPERATION(states={"idle"}) void selectTea() { ... }@OPERATION(states={"idle"}) void make() { ... }@OPERATION(states={"making"}) void addSugar() { ... }@OPERATION(states={"making"}) void stop() { ... }

}

The CoffeeMachine artifact

@ARTIFACT_MANUAL(states = {"idle","making"},start_state = "idle")

class CoffeeMachine extends Artifact {@OBSPROPERTY String selection = "";@OBSPROPERTY double sugarLevel = 0.0;

int nCupDone = 0;boolean makingStopped;

@OPERATION(states={"idle"}) void selectCoffee() { ... }@OPERATION(states={"idle"}) void selectTea() { ... }@OPERATION(states={"idle"}) void make() { ... }@OPERATION(states={"making"}) void addSugar() { ... }@OPERATION(states={"making"}) void stop() { ... }

}

Operation steps

Operation steps are implemented by methods annotated with the@OPSTEP annotation, and can be triggered by means of thenextStep primitive by specifying the name of the step to beenabled and possibly its parameters

I Multiple steps can be triggered as next steps of an operationat a time

I If multiple steps are to be run at the same time, one is chosenaccording to the order in which they have been triggered withthe nextStep primitive

I Multiple structured operations can be in execution on thesame artifact at the same time, but with only one operationstep in execution at a time, enforcing mutual exclusion inaccessing the artifact state

I Each step is executed in mutual exclusion with respect to thesteps of the other operations in execution

Operation guardsFor each operation and operation step, a guard can be specified,i.e. a condition that must be true in order to actually execute theoperation or step after it has been triggered

I Guards are specified in the guard property of the operation orstep annotation

I Guards are implemented as boolean methods annotated withthe @GUARD annotation, with the same parameters as theoperation or step guarded

Temporal guards

Also temporal guards are supported, i.e. guards whose evaluation istrue when a specific delta time is elapsed after triggering.

I a tguard property must be specified inside the operation orstep annotation instead of guard

I the property is assigned a long value indicating the number ofmilliseconds that elapse between triggering and actualexecution

Structured operations with steps and guards

@OPERATION(states={"idle"}) void make() {

if (selection.equals(""))

signal("no_drink_selected");

else {

makingStopped = false;

switchToState("making");

signal("making_" + selection);

nextStep("timeToReleaseDrink");

nextStep("forcedToReleaseDrink");

}

}

@OPSTEP(tguard=3000) void timeToReleaseDrink() { releaseDrink(); }

@OPSTEP(guard="makingStopped") void forcedToReleaseDrink() {

releaseDrink();

}

@GUARD boolean makingStopped() { return makingStopped; }

Structured operations with steps and guards

@OPERATION(states={"idle"}) void make() {

if (selection.equals(""))

signal("no_drink_selected");

else {

makingStopped = false;

switchToState("making");

signal("making_" + selection);

nextStep("timeToReleaseDrink");

nextStep("forcedToReleaseDrink");

}

}

@OPSTEP(tguard=3000) void timeToReleaseDrink() { releaseDrink(); }

@OPSTEP(guard="makingStopped") void forcedToReleaseDrink() {

releaseDrink();

}

@GUARD boolean makingStopped() { return makingStopped; }

Structured operations with steps and guards

@OPERATION(states={"idle"}) void make() {

if (selection.equals(""))

signal("no_drink_selected");

else {

makingStopped = false;

switchToState("making");

signal("making_" + selection);

nextStep("timeToReleaseDrink");

nextStep("forcedToReleaseDrink");

}

}

@OPSTEP(tguard=3000) void timeToReleaseDrink() { releaseDrink(); }

@OPSTEP(guard="makingStopped") void forcedToReleaseDrink() {

releaseDrink();

}

@GUARD boolean makingStopped() { return makingStopped; }

Artifact observability

To be useful, an artifact typically should provide some level ofobservability

I The signal primitive generates events that can be observedby the agent using the artifact

Observable properties

Observable properties are implemented as instance fields with the@OBSPROPERTY annotation

I Any change of the property by means of the updatePropertyprimitive would generate an observable event of typeproperty updated(PropertyName) with the new value ofthe property as content

I That event is observed by all the agents that are focussing onthe artifact, not only the agent using the artifact

Observable properties

class CoffeeMachine extends Artifact {@OBSPROPERTY double sugarLevel = 0.0;

@OPERATION(states="making") void addSugar() {double sl = sugarLevel + 0.1;if (sl > 1)sl = 1;

updateProperty("sugarLevel", sl);}

}

Agent-Artifact interactions

Artifact use is the basic form of interaction between agents andartifacts, involving two fundamental aspects

1. executing operations on the artifact, by means of the useprimitive

2. perceiving through agent sensors the observable eventsgenerated by the artifact, by means of the sense primitive

Agent communication

Direct communication between agents is supported by the tellprimitive, to send a message to another agent, and the listenprimitive, to specify sensors to be used to collect messages

Agent-artifact interaction

@ACTIVITY void makeOneCoffee() throws Exception {SensorId sid = linkDefaultSensor();ArtifactId id = lookupArtifact("cmOne");

use(id, new Op("selectCoffee"));use(id, new Op("make"), sid);sense(sid, "making_coffee");

focus(id, sid);Perception p = null;do {

use(id, new Op("addSugar"));p = sense(sid,

"property_updated\\(\"sugarLevel\"\\)");} while ((Double) (p.getContent()) < 0.5);

Perception p1 = sense(sid, "coffee_ready", 5000);memo("drink1", p1.getContent(0));

}

Part IV

Ongoing and Future Work

Ongoing and future work

Learning new activities

I The structure of new complex activities could be learned bymodifying the agenda

I New atomic activities could be represented by classes insteadof methods (possibly exploiting design patterns such as Proxyand Command)

An agent-oriented programming language

I Finalizing a formal model for simpA basic programming

I Defining a full-fledged simpA language and virtual machine ontop of the Java platform