Spring 2016

Agent Technologies for Developers (TIES454).

Final Session

Things we touched upon

• Communication
  • Between agents
  • Between agents and actuators
  • Between agents and sensors
  • Between agents and external services
  • Language?
• Coordination
  • Finding each other
  • Managing
    • agents
    • external resources
  • Scheduling tasks

Things we touched upon

• Mobility
• Agent logic - behavior
  • Decision making
    • Classifying
  • Learning
  • Optimization
  • Prediction

Communication Between Agents

• Blackboard vs. Messaging
  • Indirect communication vs. Message passing
  • Communicating by sharing memory vs. sharing memory by communicating
  • They are in essence equivalent
• Broadcasting
• Multi-casting
• Publish-subscriber
• Robustness
  • simple retry - failure mechanism
• You need to think about the design!
  • There are O(2^N) blackboards (1 per possible community)
  • O(N!) channels possible to share information between agents!
  • Do not allocate them naively

Communication Between Agents and Actuators, Sensors and External Services

• Is an external service an actuator or sensor?

• Options
  • You can wrap every sensor and actuator inside an agent which is representing it. SmartResource.
  • A sensor, actuator can send messages to the agent and vice verse
    • Sensors and actuators are first class members of the environment.
  • Agents have direct access to sensors and actuators
    • Difficult to synchronize access
    • Calls to sensors might take a lot of time!

Coordination

• Finding each other
  • Directory facilitator (DF)
    • Yellow pages service
      • maps between services and providers
      • Can be pro-active (publish-subscribe)
    • Usually itself an agent
• Managing agents
  • Agent Management System AMS

Agent logic - behavior

• Decision making
• Learning
• AI/soft computing/statistical models are frequently be used
  • Neural networks
  • Genetic Algorithms
  • Fuzzy Logic
  • Petri-nets
  • (Linear) Regression
  • Belief Desire Intentions (BDI)
  • Back chaining (start from goal)
  • Clustering (k-NN, LSH, …)
  • (collaborative) filtering
  • Support vector machines
  • Bayesian networks
  • Hidden Markov models
  • …

Where to go from here - What to avoid

• Many implementations of agent based systems are merely academic and best avoided (except for research purposes)
• Do not use agent based systems where other technology is more appropriate
  • Systems with a fixed/simple set-up
  • Systems which do not solve any concurrent problem
  • Actor based systems vs. Agent Based systems
    • Software engineering vs. AI
    • Agents are actors with some specifics
      • Commitments and goals
      • Planning
      • An actor system is in most cases sufficient

Where to go from here - what to use - agent based systems

• Cougaar
  • Military grade
  • Large scale platforms
  • Highly-survivable (recovery) and secure
  • Includes planning
  • Allows multiple protocols
    • Loopback, RMI, SSL-encrypted RMI, CORBA, HTTP, JMS, and XMPP (Jabber)
  • Complex and does not follow standards
    • Extensive documentation
  • Java
  • Open-source

Where to go from here - what to use instead - agent based systems

• JADE
  • Academic but production ready
  • Still actively maintained
  • FIPA complaint
  • Based on behaviors
    • Composed dynamically
  • (Annoyingly) backwards compatible (Java 1.4)
    • Runs on anything, also on JavaME
  • Easy to get started
  • Sufficient documentation
  • Open-source

Where to go from here - what to use instead - agent based systems

• UBIWARE (developed at JYU)
  • Mainly academic, but used in industry
  • Built on top of JADE
  • Dormant
  • Integrates agent technologies and semantics
  • Dynamic management of sensors and actuators
  • Integrated Beliefs Desires Intention (BDI) storage
  • Hard to program
    • Perhaps too many options
    • Specific agent language called S-APL
  • Parts Open-source

Where to go from here - what to use instead - actor systems

• Languages
  • Erlang
  • Scala
  • Some newcomers
    • Rust (changing frequently)
    • Io (weird)
• Libraries for languages
  • Java / Scala : Akka
  • F# : MailboxProcessor
  • Haskell : Cloud Haskell
  • Many more exist, see wikipedia
• Go is not an agent based or actor system!
  • goroutines do not have identity/communication possibilities built-in
  • But has many similar features

Where to go from here - Reactive manifesto

• Reactive manifesto
• Characteristics of a reactive application
  • Responsive
    • Response time should be independent of load
  • Scalable
    • Up and down
  • Event-driven
    • Loosely coupled design
    • Extendable
    • Maintainable
    • A counter argument : Why Events Are A Bad Idea (for High-concurrency Servers)
  • Resilient
    • 0% downtime
    • Problems in the application should be isolated

Why is writing concurrent software difficult?

• Non-reproducible errors
  • Different execution paths each time
  • Who gets there first
  • Test cases are also themselves concurrent programs
• Different way of thinking
  • Each thread works independently
  • Between each two consecutive statements, a whole lot of other things might happen.
• Shared data
  • Multiple readers and writers
  • Possible data corruption

How do you write concurrent software?

• Avoid shared data
  • Use immutable data structures
• Use external systems
  • SQL databases are responsible for data integrity
• Message queues
  • Channels
  • Publish-subscriber
• Use synchronized data structures
• Locking

Thank You

• Course feedback in korppi