Your SlideShare is downloading. ×
simpA: A Simple Agent-Oriented Java Extension for Developing Concurrent Applications
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

2,024
views

Published on

simpA is a library-based extension of Java which introduces a high-level coarse-grained support to prototyping concurrent applications. simpA provides an agent-oriented abstraction layer on top of the …

simpA is a library-based extension of Java which introduces a high-level coarse-grained support to prototyping concurrent applications. simpA provides an agent-oriented abstraction layer on top of the basic Java object-oriented layer to help organize and structure applications.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,024
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
82
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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
  • 2. 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
  • 3. Part I simpA Background and Motivation
  • 4. 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) offer basic low-level concurrency mechanisms and fine-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)
  • 5. 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).
  • 6. 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
  • 7. 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
  • 8. 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 define 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 defining 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
  • 9. Part II The A&A Conceptual Model
  • 10. 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
  • 11. 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, defining a topology of the working environment and providing a way to frame the interaction inside it
  • 12. Defining 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
  • 13. 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
  • 14. 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
  • 15. 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 (flow) and the execution of the operation on the artifact is carried on independently and asynchronously.
  • 16. Agent-Artifact Interaction: Use and Observation (III) 1b sense with-my-filter 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
  • 17. Part III simpA Framework and Technology
  • 18. 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 first-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 define agents and artifacts simpA is Open Source available at http://www.alice.unibo.it/simpa
  • 19. 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.
  • 20. 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;); } }
  • 21. Agents in simpA An agent (template) is represented by a single class, extending alice.simpa.Agent. The elements defining 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 specified in its template, starting from the main one
  • 22. 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 specifies 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 specified, 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
  • 23. The Waiter agent public class Waiter extends Agent { }
  • 24. The Waiter agent public class Waiter extends Agent { void main() {} }
  • 25. The Waiter agent public class Waiter extends Agent { @ACTIVITY_WITH_AGENDA({ }) void main() {} }
  • 26. The Waiter agent public class Waiter extends Agent { @ACTIVITY_WITH_AGENDA({ @TODO(activity=quot;makeOneCoffeequot;), @TODO(activity=quot;makeOneTeaquot;), }) void main() {} }
  • 27. The Waiter agent public class Waiter extends Agent { @ACTIVITY_WITH_AGENDA({ @TODO(activity=quot;makeOneCoffeequot;), @TODO(activity=quot;makeOneTeaquot;), @TODO(activity=quot;deliverBothquot;, pre=quot;completed(makeOneCoffee), completed(makeOneTea)quot;), @TODO(activity=quot;deliverJustCoffeequot;, pre=quot;completed(makeOneCoffee), memo(tea_not_ready)quot;), }) void main() {} }
  • 28. The Waiter agent public class Waiter extends Agent { @ACTIVITY_WITH_AGENDA({ @TODO(activity=quot;makeOneCoffeequot;), @TODO(activity=quot;makeOneTeaquot;), @TODO(activity=quot;deliverBothquot;, pre=quot;completed(makeOneCoffee), completed(makeOneTea)quot;), @TODO(activity=quot;deliverJustCoffeequot;, pre=quot;completed(makeOneCoffee), memo(tea_not_ready)quot;), }) void main() {} @ACTIVITY void makeOneCoffee() throws Exception { ... } @ACTIVITY void makeOneTea() throws Exception { ... } @ACTIVITY void deliverBoth() { ... } @ACTIVITY void deliverJustCoffee() { ... } }
  • 29. @TODO Preconditions Preconditions are expressed as a boolean expression over a basic set of predefined predicates use and/or logic connectors in the form of the , and ; symbols, respectively Amongst the predefined 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
  • 30. 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 identified by its label 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-term memory for a single atomic activity
  • 31. 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(); } }
  • 32. Artifacts in simpA An artifact (template) is represented by a single class, extending alice.simpa.Artifact. The elements defining 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
  • 33. The CoffeeMachine artifact class CoffeeMachine extends Artifact { }
  • 34. The CoffeeMachine artifact @ARTIFACT_MANUAL( states = {quot;idlequot;,quot;makingquot;}, start_state = quot;idlequot;) class CoffeeMachine extends Artifact { }
  • 35. The CoffeeMachine artifact @ARTIFACT_MANUAL( states = {quot;idlequot;,quot;makingquot;}, start_state = quot;idlequot;) class CoffeeMachine extends Artifact { @OPERATION(states={quot;idlequot;}) void selectCoffee() { ... } @OPERATION(states={quot;idlequot;}) void selectTea() { ... } @OPERATION(states={quot;idlequot;}) void make() { ... } }
  • 36. The CoffeeMachine artifact @ARTIFACT_MANUAL( states = {quot;idlequot;,quot;makingquot;}, start_state = quot;idlequot;) class CoffeeMachine extends Artifact { @OPERATION(states={quot;idlequot;}) void selectCoffee() { ... } @OPERATION(states={quot;idlequot;}) void selectTea() { ... } @OPERATION(states={quot;idlequot;}) void make() { ... } @OPERATION(states={quot;makingquot;}) void addSugar() { ... } @OPERATION(states={quot;makingquot;}) void stop() { ... } }
  • 37. The CoffeeMachine artifact @ARTIFACT_MANUAL( states = {quot;idlequot;,quot;makingquot;}, start_state = quot;idlequot;) class CoffeeMachine extends Artifact { @OBSPROPERTY String selection = quot;quot;; @OBSPROPERTY double sugarLevel = 0.0; @OPERATION(states={quot;idlequot;}) void selectCoffee() { ... } @OPERATION(states={quot;idlequot;}) void selectTea() { ... } @OPERATION(states={quot;idlequot;}) void make() { ... } @OPERATION(states={quot;makingquot;}) void addSugar() { ... } @OPERATION(states={quot;makingquot;}) void stop() { ... } }
  • 38. The CoffeeMachine artifact @ARTIFACT_MANUAL( states = {quot;idlequot;,quot;makingquot;}, start_state = quot;idlequot;) class CoffeeMachine extends Artifact { @OBSPROPERTY String selection = quot;quot;; @OBSPROPERTY double sugarLevel = 0.0; int nCupDone = 0; boolean makingStopped; @OPERATION(states={quot;idlequot;}) void selectCoffee() { ... } @OPERATION(states={quot;idlequot;}) void selectTea() { ... } @OPERATION(states={quot;idlequot;}) void make() { ... } @OPERATION(states={quot;makingquot;}) void addSugar() { ... } @OPERATION(states={quot;makingquot;}) void stop() { ... } }
  • 39. 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
  • 40. 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
  • 41. 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;); } }
  • 42. 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;); } } @OPSTEP(tguard=3000) void timeToReleaseDrink() { releaseDrink(); }
  • 43. 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;); } } @OPSTEP(tguard=3000) void timeToReleaseDrink() { releaseDrink(); } @OPSTEP(guard=quot;makingStoppedquot;) void forcedToReleaseDrink() { releaseDrink(); } @GUARD boolean makingStopped() { return makingStopped; }
  • 44. 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 fields 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
  • 45. Observable properties class CoffeeMachine extends Artifact { @OBSPROPERTY double sugarLevel = 0.0; @OPERATION(states=quot;makingquot;) void addSugar() { double sl = sugarLevel + 0.1; if (sl > 1) sl = 1; updateProperty(quot;sugarLevelquot;, sl); } }
  • 46. 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
  • 47. 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)); }
  • 48. Part IV Ongoing and Future Work
  • 49. 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 Defining a full-fledged simpA language and virtual machine on top of the Java platform