simpA: A Simple Agent-Oriented Java Extension for Developing Concurrent Applications

simpA: A Simple Agent-Oriented Java Extension
for Developing Concurrent Applications

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

LAnguages, methodologies and Development tools for
multi-agent systemS (LADS 2007)
Durham, September 4–6, 2007

Outline

simpA Background and Motivation

The A&A Conceptual Model

simpA Framework and Technology
simpA Agents
simpA Artifacts
Agent-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 more
part of mainstream programming
multi-core architectures
network computing
Service-Oriented Architecture and Web Services
Mainstream programming languages (e.g. Java) oﬀer basic low-level
concurrency mechanisms and ﬁne-grained synchronization mechanisms
native support for multi-threading
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 to
introduce a general-purpose abstraction layer for simplifying the
development of concurrent applications
simpA vs actors
Differently from actor-based approaches, in simpA also the passive
components of the systems are modeled as first-class entities
(artifacts), alongside the active parts (actors in actor-based
systems).

simpA vs active objects
Active-objects are typically objects with further capabilities, while
in simpA a strong distinction between active and passive entities is
promoted: agents and artifacts have completely different
properties, with a clear distinction at the design level of their role,
i.e. encapsulating pro-active behavior (agents) and
function-oriented behavior (artifacts).

simpA vs agent-oriented Java extensions

JACK and JADEX extend the basic Java platform in order to
support the programming of intelligent agents, based on the BDI
architecture and the FIPA standards
They are cognitive agent programming platforms
They are targeted to the engineering of distributed intelligent
systems for complex application domain
However, simpA targets mainstream instead of special purpose
programming, and focusses on concurrency as a design model
rather than on agent intelligence

simpA vs agent-oriented Java-based platforms

JADE provides a general-purpose middleware that complies with
the FIPA specifications for developing peer-to-peer distributed
agent-based applications
In JADE there are only agents, in simpA there are agents and
artifacts
Activities in simpA are similar to behaviors in JADE, but. . .
. . . in simpA the definition of structured activities is done
declaratively in the activity agenda, while in JADE is done
operationally by creating and composing objects of specific
classes

What is simpA?
simpA is a library-based extension of Java which provides
programmers with agent-oriented abstractions on top of the basic
object-oriented layer, as basic building blocks to deﬁne the
architecture of concurrent applications
Why multi-agent systems?
Agents and multi-agent systems natively capture and model
decentralization of control, concurrency of activities, and
interaction and coordination of activities: therefore, they can be
considered a good candidate for deﬁning a paradigm for
mainstream concurrent programming.

Agents and Artifacts (A&A)
simpA is based on the Agents and Artifacts meta-model, combining
activity-oriented components with function-oriented components as
a 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 in
human cooperative working environments, investigated by
socio-psychological theories such as Activity Theory
Reference system
The reference example is the modeling of a complex system where
multiple concurrent activities are carried on in a coordinated way

Interaction
Humans work concurrently and cooperatively in the context of the
same activities, interacting
directly, by means of speech-based communication
indirectly, by means of artifacts and tools that are shared and
co-used

A&A Abstractions (II)
The basic modeling abstractions are agents and artifacts

the agent abstraction models
the (pro-)active part of a
system, encapsulating the logic
and control of such activities
the artifact abstraction models
the resources and tools created
and used by agents during their
activities

Besides, the notion of workspace provides a logic container of
agents and artifacts, and can be used to structure the overall sets
of entities, deﬁning a topology of the working environment and
providing a way to frame the interaction inside it

Deﬁning Agents

An agent is an activity-oriented component whose computational
behavior accounts for performing actions in an environment and
getting information back in terms of perceptions
Actions and perceptions
Actions and perceptions concern in particular the use of artifacts
and direct communication with other agents

Memory and state
As a state-full entity, each agent has:
a long term memory used to store data and information
needed for its overall activity
a short term memory used as a working memory to store
temporary information useful when executing single actions

Defining Artifacts
An artifact is a passive function-oriented component designed to
provide some kind of functionality that can be used by agents
Structuring functionalities
The functionality of an artifact is structured in terms of operations
whose execution can be triggered by agents through artifact usage
interface
Usage interface
The usage interface defines a set of commands used to trigger and
control operation execution, each one identified by a label and a
list of input parameters
Artifact observability
The information flow from the artifact to agents is modeled in
terms of observable events generated by artifacts and perceived by
agents, and of observable properties as variables whose value can
be inspected by agents dynamically, without necessarily executing
operations on the artifact

Agent-Artifact Interaction: Use and Observation (I)

1a
use opX(params)
2a
opX EXECUTION
TRIGGERED

Step 1a The interaction starts by means of an agent
performing a use action
Step 2a The use action triggers and control the execution of
an operation over an artifact

Agent-Artifact Interaction: Use and Observation (II)

Sensors
The observable events possibly generated by the artifact executing
an operation are collected by agent sensors, that are those agent
parts connected to the environment where the agent is situated

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

No control coupling
There is no control coupling between an agent and an artifact
within the execution of an operation: when an agent triggers the
execution of an operation, it retains its control (ﬂow) and the
execution of the operation on the artifact is carried on
independently and asynchronously.

Agent-Artifact Interaction: Use and Observation (III)
1b
sense with-my-ﬁlter

opX EXECUTION

2b
SENSOR

XYZ

e
my_event1
e
op_exec_completed

Step 2b The execution of an operation by an artifact
generates observable events collected by agent
sensors, and results in updating the artifact inner
state and possibly artifact observable properties
Step 1b Agents perform a sense action to explicitly retrieve
the observable events collected by their sensors

Part III

simpA Framework and Technology

Design Principles

simpA is an extension of Java to support the main
abstractions from the A&A conceptual model
realized as a library
exploiting Java 5 annotations
Compilation and execution of simpA programs use standard
compiler and Virtual Machine
no need for preprocessors, compilers, class loaders, JVM
patches
Agents and artifacts are not ﬁrst-class abstractions for the
language and Virtual Machine
simpA promotes a programming approach as agile as possible
minimize the number of classes to be introduced to deﬁne
agents and artifacts
simpA is Open Source
available at http://www.alice.unibo.it/simpa

A reference simpA application

The application creates a simple Cafeteria workspace composed
by a single Waiter agent using two CoffeeMachine artifacts.
Waiter
The Waiter agent is programmed with the objective to make one
coffee and one tea by exploiting two different coffee machines, and
to deliver them when both are ready within a certain amount of
time, or just the coffee if the tea production lasts too long

Coffee Machine
The CoffeeMachine artifact provides a usage interface with
controls for selecting the type of drink (coffee or tea) and making
it. Then, while making the drink, it provides a usage interface to
adjust the sugar level and possibly stop the operation.

The simpA environment

public class TestCafeteria {
public static void main(String[] args) {
ISimpaEnvironment env = Simpa.getInstance(quot;Cafeteriaquot;);
env.createArtifact(quot;cmOnequot;, quot;CoffeeMachinequot;);
env.createArtifact(quot;cmTwoquot;, quot;CoffeeMachinequot;);
env.spawnAgent(quot;waiterquot;, quot;Waiterquot;);
}
}

Agents in simpA

An agent (template) is represented by a single class, extending
alice.simpa.Agent. The elements deﬁning an agent are mapped
onto class elements, suitably annotated.
Atomic and structured activities
Activities can be either atomic or structured, i.e. composed by
sub-activities
Atomic activities are implemented as methods with the
@ACTIVITY annotation, with no input parameters and void
return type
Structured activities can be described as activities composed
by a hierarchy of sub-activities
The execution of an agent consists in executing the activities as
speciﬁed in its template, starting from the main one

Agent structured activities
The notion of agenda is introduced to specify the set of the
potential sub-activities composing the activity, referenced as todo
in the agenda
Each todo speciﬁes the name of the sub-activity to execute,
and optionally a precondition
When a structured activity is executed, the todo in the
agenda are executed as soon as their preconditions hold
If no precondition is speciﬁed, the todo is immediately
executed, so that multiple sub-activities can be executed
concurrently in the context of the same activity
A persistent todo is reinserted in the agenda after its
execution, so as to be possibly executed again
A structured activity is implemented by methods with an
@ACTIVITY WITH AGENDA annotation, containing todo descriptions
as a list of @TODO annotations that specify the name of the
sub-activity to execute and an optional pre property as its
precondition

The Waiter agent
public class Waiter extends Agent {

}

The Waiter agent

void main() {}

}

The Waiter agent
@ACTIVITY_WITH_AGENDA({

}) void main() {}

}

The Waiter agent
@TODO(activity=quot;makeOneCoffeequot;),
@TODO(activity=quot;makeOneTeaquot;),

}) void main() {}

}

The Waiter agent
@TODO(activity=quot;deliverBothquot;,
pre=quot;completed(makeOneCoffee),
completed(makeOneTea)quot;),
@TODO(activity=quot;deliverJustCoffeequot;,
memo(tea_not_ready)quot;),
}) void main() {}

}

The Waiter agent
@TODO(activity=quot;deliverBothquot;,
completed(makeOneTea)quot;),
@TODO(activity=quot;deliverJustCoffeequot;,
memo(tea_not_ready)quot;),
}) 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 basic
set of predeﬁned predicates
use and/or logic connectors in the form of the , and ;
symbols, respectively
Amongst the predeﬁned predicates there are completed/1,
failure/2, memo/1, duration/2
The predicates make it possible to specify conditions on the
current state of the activity agenda, in particular
on the state of sub-activities, if they started, completed, or
aborted
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 called
memo space, where the agent can dynamically attach, associatively
read and retrieve chunks of information called memo
a memo is a tuple, characterized by a label and an ordered set
of arguments, not necessarily bound to some data object
a memo is identiﬁed by its label
only one instance of a memo can exist at a time
Instance ﬁelds of an agent class are not used

Short-term memory
Local variables in methods are used to represent short-term
memory for a single atomic activity

Using memo

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

use(id, new Op(quot;selectTeaquot;));
use(id, new Op(quot;makequot;), sid);
try {
Perception p = sense(sid, quot;tea_readyquot;, 6000);
memo(quot;drink2quot;, p.getContent(0));
} catch (NoPerceptionException e) {
memo(quot;tea_not_readyquot;);
throw new ActivityFailed();
}
}

Artifacts in simpA

An artifact (template) is represented by a single class, extending
alice.simpa.Artifact. The elements deﬁning an artifact are
mapped onto class elements, suitably annotated.
Atomic and structured operations
Operations can be either atomic, executed as a single
computational step, or structured, composed by multiple steps
Atomic operations are implemented as methods with the
@OPERATION annotation and void return type
The name and parameters of the method coincide with the
name and parameters of the operation
Structured operations are implemented by dynamically
specifying the operations steps composing the operation

The CoffeeMachine artifact

class CoffeeMachine extends Artifact {

}


@ARTIFACT_MANUAL(
states = {quot;idlequot;,quot;makingquot;},
start_state = quot;idlequot;)

}


@ARTIFACT_MANUAL(

@OPERATION(states={quot;idlequot;}) void selectCoffee() { ... }
@OPERATION(states={quot;idlequot;}) void selectTea() { ... }
@OPERATION(states={quot;idlequot;}) void make() { ... }

}


@ARTIFACT_MANUAL(

@OPERATION(states={quot;makingquot;}) void addSugar() { ... }
@OPERATION(states={quot;makingquot;}) void stop() { ... }
}


@ARTIFACT_MANUAL(
@OBSPROPERTY String selection = quot;quot;;
@OBSPROPERTY double sugarLevel = 0.0;

}


@ARTIFACT_MANUAL(
@OBSPROPERTY String selection = quot;quot;;

int nCupDone = 0;
boolean makingStopped;

}

Operation steps
Operation steps are implemented by methods annotated with the
@OPSTEP annotation, and can be triggered by means of the
nextStep primitive by specifying the name of the step to be
enabled and possibly its parameters
Multiple steps can be triggered as next steps of an operation
at a time
If multiple steps are to be run at the same time, one is chosen
according to the order in which they have been triggered with
the nextStep primitive
Multiple structured operations can be in execution on the
same artifact at the same time, but with only one operation
step in execution at a time, enforcing mutual exclusion in
accessing the artifact state
Each step is executed in mutual exclusion with respect to the
steps of the other operations in execution

Operation guards
For each operation and operation step, a guard can be specified,
i.e. a condition that must be true in order to actually execute the
operation or step after it has been triggered
Guards are specified in the guard property of the operation or
step annotation
Guards are implemented as boolean methods annotated with
the @GUARD annotation, with the same parameters as the
operation or step guarded

Temporal guards
Also temporal guards are supported, i.e. guards whose evaluation is
true when a specific delta time is elapsed after triggering.
a tguard property must be specified inside the operation or
step annotation instead of guard
the property is assigned a long value indicating the number of
milliseconds that elapse between triggering and actual
execution

Structured operations with steps and guards
@OPERATION(states={quot;idlequot;}) void make() {
if (selection.equals(quot;quot;))
signal(quot;no_drink_selectedquot;);
else {
makingStopped = false;
switchToState(quot;makingquot;);
signal(quot;making_quot; + selection);
nextStep(quot;timeToReleaseDrinkquot;);
nextStep(quot;forcedToReleaseDrinkquot;);
}
}

else {
}
}

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

else {
}
}

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

@OPSTEP(guard=quot;makingStoppedquot;) void forcedToReleaseDrink() {
releaseDrink();
}

@GUARD boolean makingStopped() { return makingStopped; }

Artifact observability

To be useful, an artifact typically should provide some level of
observability
The signal primitive generates events that can be observed
by the agent using the artifact

Observable properties
Observable properties are implemented as instance ﬁelds with the
@OBSPROPERTY annotation
Any change of the property by means of the updateProperty
primitive would generate an observable event of type
property updated(PropertyName) with the new value of
the property as content
That event is observed by all the agents that are focussing on
the artifact, not only the agent using the artifact

Observable properties


@OPERATION(states=quot;makingquot;) void addSugar() {
double sl = sugarLevel + 0.1;
if (sl > 1)
sl = 1;
updateProperty(quot;sugarLevelquot;, sl);
}
}

Agent-Artifact interactions

Artifact use is the basic form of interaction between agents and
artifacts, involving two fundamental aspects
1. executing operations on the artifact, by means of the use
primitive
2. perceiving through agent sensors the observable events
generated by the artifact, by means of the sense primitive

Agent communication
Direct communication between agents is supported by the tell
primitive, to send a message to another agent, and the listen
primitive, to specify sensors to be used to collect messages

Agent-artifact interaction
@ACTIVITY void makeOneCoffee() throws Exception {
SensorId sid = linkDefaultSensor();
ArtifactId id = lookupArtifact(quot;cmOnequot;);

use(id, new Op(quot;selectCoffeequot;));
use(id, new Op(quot;makequot;), sid);
sense(sid, quot;making_coffeequot;);

focus(id, sid);
Perception p = null;
do {
use(id, new Op(quot;addSugarquot;));
p = sense(sid,
quot;property_updated(quot;sugarLevelquot;)quot;);
} while ((Double) (p.getContent()) < 0.5);

Perception p1 = sense(sid, quot;coffee_readyquot;, 5000);
memo(quot;drink1quot;, p1.getContent(0));
}

Part IV

Ongoing and Future Work

Ongoing and future work

Learning new activities
The structure of new complex activities could be learned by
modifying the agenda
New atomic activities could be represented by classes instead
of methods (possibly exploiting design patterns such as Proxy
and Command)

An agent-oriented programming language
Finalizing a formal model for simpA basic programming
Deﬁning a full-ﬂedged simpA language and virtual machine on
top of the Java platform

simpA: A Simple Agent-Oriented Java Extension for Developing Concurrent Applications

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a simpA: A Simple Agent-Oriented Java Extension for Developing Concurrent Applications

Semelhante a simpA: A Simple Agent-Oriented Java Extension for Developing Concurrent Applications (20)

Último

Último (20)

simpA: A Simple Agent-Oriented Java Extension for Developing Concurrent Applications