The article collection

PRIS F7

Fredrik Kilander

Content

• “On agent-based software engineering” Nick Jennings, 1999

• “An agent-based approach for building complex software systems” Nick Jennings 2001

• “A note on distributed computing” Waldo, Wyant, Wollrath, Kendall, 1994

• “The seven deadly sins of distributed systems” Steve Muir, 2004

On agent-based software engineering

1. introduction

2. essential concepts of agent-based computing

3. the appeals of the agent-based approach

4. why agent-based techniques will succeed

5. the drawbacks

6. modelling on the social level

7. the wider implications for AI and CS

In traditional systems development...

• interactions between components are too rigidly defined

• organisational structure is not captured well

Agents, on the other hand...

• are well defined (they have boundaries and interfaces)

• are embedded in an environment

• are designed to fulfill a purpose• are autonomous (need no external activation)

• are reactive and proactive

• are already organised in hierarchies

Agents are also...

• flexible in their interactions

• adaptable to changes in the environment

• able to work in teams for a common goal

Jennings argues that... (1/3)

• ”agent-oriented decomposition is an effective way of partitioning the problem space”

Decomposition → distribution and decentralization

Decentralization → less control complexity

Jennings argues that... (2/3)

• ”the key abstractions of the agent-oriented mindset are a natural means of modeling complex systems”

Subsystems → agent hierarchies

Subsystem components → social interactions

Jennings argues that... (3/3)

• ”the agent-oriented philosophy for dealing with organisational relationships is appropriate for complex systems”

Agent-based systems flexibly form and reshape structures

Individual agents or groups can be developed separately and incrementally added to the system

However...

• interaction patterns are unpredictable

• emergent system behaviour is unpredictable

= (*) =

A note on distributed computingWaldo et al

• Distributed computing is different from local computing

• The programmer should be aware of this

• The language should not hide it

A (false) vision of unified computing

• Object-oriented design conquers all

• Remote objects appear to be local

• Failures depend on the implementation, not on design

Hard problems in distributed computing

• Latency

• Memory access (no pointers => copy)

• Partial failure

• Concurrency

Interfaces and design

• Design remote interfaces to expect breakdowns

• Accept that the programmer must be informed about breakdowns

• E.g. java.rmi.RemoteException

= (*) =

The seven deadly sinsof distributed systems

• Experiences of real systems (PlanetLab Node Manager)

• 400+ Internet nodes at 175 locations.

1 Networks are unreliable

• Large heterogenous networks are fundamentally unreliable

• Packet loss

• Packet duplication

• Packet reordering

• Highly variable latency

2 DNS names make poor node identifiers

• Human errors

• Network reorganisation

• Infrastructure failures

• Network asymmetry (e.g. NAT)

• Non-static addresses, multihoming

3 Local clocks are unreliable

• System timing is poor

• High load

• Bugs

• NTP not always available

NTP: Network Time Protocol

4 Inconsistent node configuration is the norm

• Version skew

• Delays

• Inaccessible nodes

• Update times

• No global synchronization

5 Improbable events are frequent

• Lots of nodes

• 24/7

• Rare bugs WILL manifest themselves• Application programmers must not cut

corners! (“Oh, this error will never happen…”)

6 Over-utilization is the norm

• All systems are used

• No idle time

• Resource expiration times must be extended

7 Limited system transparency hampers debugging

• Incomplete access to remote nodes

• Virtualization hides details

Conclusions for distributed systems

• Local assumptions fail

• Applications must cover all failure modes

• Resource management is harder

• Local operations are affected too

(^_^)