Aggregate Computing: Bridging the Gaps
Roberto CasadeiPhD Student in CS&Eng
Department of Computer Science and Engineering (DISI)
Alma Mater Studiorum – Università of Bologna
Pervasive Computing course
R. Casadei Intro ACP Analysis Technology Wrap-up 1/49
Engineering apps AC: recap
Outline
1 Introduction
Engineering pervasive computing applications
Aggregate Computing: recap
2 Analysis for an Aggregate Computing Platform (ACP)
3 Technology: quick survey
4 Wrap-up
R. Casadei Intro ACP Analysis Technology Wrap-up 2/49
Engineering apps AC: recap
Outline
1 Introduction
Engineering pervasive computing applications
Aggregate Computing: recap
2 Analysis for an Aggregate Computing Platform (ACP)
Requirements
Analysis
Current framework
3 Technology: quick survey
4 Wrap-up
R. Casadei Intro ACP Analysis Technology Wrap-up 3/49
Engineering apps AC: recap
The starting point of any engineering process
A vision that must be made concrete / top-down or bottom-up
R. Casadei Intro ACP Analysis Technology Wrap-up 4/49
Engineering apps AC: recap
Applications as the interface to the needs
Abstractly defined until some concrete underlying technology is identified
R. Casadei Intro ACP Analysis Technology Wrap-up 5/49
Engineering apps AC: recap
Aggregate Computing: bridging the gap to SASO systems
Supports the development and execution of Aggregate Computing applications
R. Casadei Intro ACP Analysis Technology Wrap-up 6/49
Engineering apps AC: recap
Zooming the AC layer
R. Casadei Intro ACP Analysis Technology Wrap-up 7/49
Engineering apps AC: recap
Outline
1 Introduction
Engineering pervasive computing applications
Aggregate Computing: recap
2 Analysis for an Aggregate Computing Platform (ACP)
Requirements
Analysis
Current framework
3 Technology: quick survey
4 Wrap-up
R. Casadei Intro ACP Analysis Technology Wrap-up 8/49
Engineering apps AC: recap
Aggregate Computing (AC) » what
Goal: programming the collective behaviour of aggregates of devices
Main ideasI Macro-level programming with automatic macro-micro bridging
I DeclarativityI Support for “engineered emergence”
I Composition of aggregate behaviour with predictable dynamicsI Layers of reusable abstractions
I Abstraction from interaction-level and platform-level issuesI Inherent adaptivityI Inherent resiliencyI Operational flexibility
R. Casadei Intro ACP Analysis Technology Wrap-up 9/49
Engineering apps AC: recap
Compositionality in AC: exampletrait DistributedSum extends AggregateProgram {def distribSum(size:Double, metric: =>Double, v:Double): Double = {???
}}
trait Broadcast extends BlockG with ... { s: AggregateProgram =>def broadcast[V: Bounded](src: Boolean, value: V): V =G(src, value)(x => x, nbrRange)
}
trait SumCollect extends BlockC with ... { s: AggregateProgram =>def sumCollect(target: Boolean, value: Double): Double =C(value)(distanceTo(target,nbrRange))(_+_,0)
}
:Distributed sum
I Split the space into regions with grain sizeI Calculate the mean of field v in each region
I Collect the values and the number of nodes in the regionI Compute the averageI Propagate the computed value
R. Casadei Intro ACP Analysis Technology Wrap-up 10/49
Engineering apps AC: recap
Compositionality in AC: exampletrait DistributedSum extends AggregateProgramwith BlockG with BlockC with BlockSwith Broadcast with SumCollect with Utilities
{def distribSum(size:Double, metric: =>Double, v:Double): Double = {val leaders = S(size, metric)???
}}
:
R. Casadei Intro ACP Analysis Technology Wrap-up 10/49
Engineering apps AC: recap
Compositionality in AC: exampletrait DistributedSum extends AggregateProgramwith BlockG with BlockC with BlockSwith Broadcast with SumCollect with Utilities
{def distribSum(size:Double, metric: =>Double, v:Double): Double = {val leaders = S(size, metric)val potential = distanceTo(leaders, metric)???
}}
:
R. Casadei Intro ACP Analysis Technology Wrap-up 10/49
Engineering apps AC: recap
Compositionality in AC: exampletrait DistributedSum extends AggregateProgram ... with SumCollect {def distribSum(size:Double, metric: =>Double, v:Double): Double = {val leaders = S(size, metric)val potential = distanceTo(leaders, metric)val collection = sumCollect(leaders, v)val count = sumCollect(leaders, 1.0)val avg = collection / count
}}
:
R. Casadei Intro ACP Analysis Technology Wrap-up 10/49
Engineering apps AC: recap
Compositionality in AC: exampletrait DistributedSum extends AggregateProgram ... with Broadcast {def distribSum(size:Double, metric: =>Double, v:Double): Double = {val leaders = S(size, metric)val potential = distanceTo(leaders, metric)val collection = sumCollect(leaders, v)val count = sumCollect(leaders, 1.0)val avg = collection / countbroadcast(leaders, avg)
}}
:
R. Casadei Intro ACP Analysis Technology Wrap-up 10/49
Engineering apps AC: recap
Aggregate Computing (AC) » how
I Repeated executionI Provides reactivity and incremental adaptivity
I Broadcast + aligned interactionI Allows the construction of a “local” context for computation
R. Casadei Intro ACP Analysis Technology Wrap-up 11/49
Requirements Analysis Current framework
Outline
1 Introduction
2 Analysis for an Aggregate Computing Platform (ACP)
Requirements
Analysis
Current framework
3 Technology: quick survey
4 Wrap-up
R. Casadei Intro ACP Analysis Technology Wrap-up 12/49
Requirements Analysis Current framework
Outline
1 Introduction
Engineering pervasive computing applications
Aggregate Computing: recap
2 Analysis for an Aggregate Computing Platform (ACP)
Requirements
Analysis
Current framework
3 Technology: quick survey
4 Wrap-up
R. Casadei Intro ACP Analysis Technology Wrap-up 13/49
Requirements Analysis Current framework
Requirements for an Aggregate Computing platform
High-level, Functional
FR1 Support the specification and configuration of AGGREGATE-SYSTEMsFR2 Support the runtime execution of AGGREGATE-APPLICATIONs
High-level, Non-functional
NR1 Scalability to a large number of NODEsNR2 Reliability
I An AGGREGATE-SYSTEM made of unreliable INFRASTRUCTURAL-COMPONENTs andunreliable NODEs should be able to continue operation even in face of faults.
R. Casadei Intro ACP Analysis Technology Wrap-up 14/49
Requirements Analysis Current framework
Outline
1 Introduction
Engineering pervasive computing applications
Aggregate Computing: recap
2 Analysis for an Aggregate Computing Platform (ACP)
Requirements
Analysis
Current framework
3 Technology: quick survey
4 Wrap-up
R. Casadei Intro ACP Analysis Technology Wrap-up 15/49
Requirements Analysis Current framework
Requirements analysis
Approach: informal but systematic (cartesian)
I Give names to thingsI Refine meaning and relationshipsI Explore in (mentally simulated) use, adopt perspectives and visualizeI (Then, formalize early, when enough committed)
I AGGREGATE-LOGIC: the representation-independent view of someaggregate-level behaviour in space/time
I AGGREGATE-PROGRAM: an AGGREGATE-LOGIC expressed in some executablerepresentation
I AGGREGATE-SYSTEM: a set of networked NODEs supporting the collectiveexecution of AGGREGATE-PROGRAMs
I AGGREGATE-APPLICATION: a particular AGGREGATE-LOGIC running on a certainAGGREGATE-SYSTEM, aimed at solving some problem in some context
R. Casadei Intro ACP Analysis Technology Wrap-up 16/49
Requirements Analysis Current framework
High-level, logical, informal model
I Starting point for a systematic characterisation of our (fuzzy) class of systemsI We think of no specific application/system, but a range of applications/systems
I to support/drive analysis and be concrete
R. Casadei Intro ACP Analysis Technology Wrap-up 17/49
Requirements Analysis Current framework
Structure / Interaction / Behaviour decomposition
(Logical) Structure
I DEVICEs (aka NODEs, AGENTs)I Have an identity (UID)I Have SENSORs and ACTUATORs
(Logical) Behaviour/Interaction
I A DEVICE can only directly communicate with the DEVICEs of itsNEIGHBOURHOOD
I A DEVICE computes its part of AGGREGATE-LOGIC on a round-by-round basisI Steps of a round of execution
1) Retrieve the device’s CONTEXT (SENSOR-DATA, NBR-DATA)2) Execute LOCAL-AGGREGATE-LOGIC to produce OUTPUT + EXPORT3) Broadcast EXPORT to NEIGHBOURHOOD4) Feed ACTUATORS with OUTPUT
This characterization is mainly logical and “standard”
I Many questions arise: who? what? where? when? how?
R. Casadei Intro ACP Analysis Technology Wrap-up 18/49
Requirements Analysis Current framework
Analysis » execution rounds I
SCHEDULING-POLICY: who decides when a round has to be executed?
I A SCHEDULER (owned by a device or external)
Construction of the CONTEXT using up-to-date SENSOR-DATA and NBR-DATA
I Ideally, we’d like to separate the time/frequency in which these information arecollected from the time in which they are received
I Retrieval of SENSOR-DATA: request/response to device’s SENSOR or sampling ofan incoming SENSOR-DATA-STREAM
I Note: location data (e.g., GPS coords) may need to be sent to theTOPOLOGY-MANAGER
I Retrieval of NBR-DATA: request/response to a FIELD-MANAGER or sampling of anincoming NBR-DATA-STREAM
Who actually executes the AGGREGATE-LOGIC for a given DEVICE?
I An AGGREGATE-LOGIC-EXECUTOR (owned by a device or external)
R. Casadei Intro ACP Analysis Technology Wrap-up 19/49
Requirements Analysis Current framework
Analysis » execution rounds II
Broadcast of EXPORT to NEIGHBOURHOOD
I By the DEVICE itself (if it knows how to reach its NEIGHBOURHOOD)I But the DEVICE’s awareness of communication is questionable
I “No matter who you are! I know where you are” [ZM04]
I The DEVICE may simply send its computation descriptors (EXPORTs) to theFIELD-MANAGER
I The FIELD-MANAGER in turn may delegate the task to an EXPORT-PROPAGATOR
I which must then know the NEIGHBOURHOODs and how to reach them
Invocation of ACTUATORs
I In general, we may have ACTUATION-DATA-STREAMs directed to ACTUATORswhich may be controlled by (but still decoupled from) rounds.
R. Casadei Intro ACP Analysis Technology Wrap-up 20/49
Requirements Analysis Current framework
Analysis » neighbourhood
NBR-POLICY: how is NEIGHBOURHOOD determined?
I May be communication-determined (i.e., my neighbours are those I can reach)I May be spatially-determined (i.e., derived from the devices’ position in space)I May be ad-hoc (i.e., application-specific)
Who owns the knowledge of a device’s NEIGHBOURHOOD?
I A TOPOLOGY-MANAGER (owned by a device or external)
Who uses the knowledge of a device’s NEIGHBOURHOOD?
I The EXPORT-PROPAGATOR
Properties of NEIGHBOURHOOD
I It is usually dynamicI Can be asymmetric
R. Casadei Intro ACP Analysis Technology Wrap-up 21/49
Requirements Analysis Current framework
Analysis » configuration
How do components locate (the address of) other components?
I DEVICEs should be addressable to support e.g. peer-to-peer interaction or thethe delivery of ACTUATION-DATA
I The mappings between DEVICEs’ UIDs and their ADDRESS may be kept in aREGISTRY
I Devices should also be given some CONFIGURATION data – so that they know theADDRESS of required services
How do AGGREGATE-LOGIC-EXECUTOR obtain the AGGREGATE-LOGIC to execute?
I Can be provided at deployment or configuration time
R. Casadei Intro ACP Analysis Technology Wrap-up 22/49
Requirements Analysis Current framework
Logical components emerging from analysis (dev-centric)
It comes natural to assign many responsibilities to the DEVICEs (cf., p2p setup)..
R. Casadei Intro ACP Analysis Technology Wrap-up 23/49
Requirements Analysis Current framework
Logical components emerging from analysis (sys-centric)
It comes natural to consider DEVICEs only as situated contexts..
R. Casadei Intro ACP Analysis Technology Wrap-up 24/49
Requirements Analysis Current framework
Many kinds of deployments
Such flexibility demands for fluid responsibilities
R. Casadei Intro ACP Analysis Technology Wrap-up 25/49
Requirements Analysis Current framework
The data perspectiveData payloads
I SENSOR-DATA: map from sensor UIDs to sensor valuesI ACTUATION-DATA: map from actuator UIDs to actuation valuesI NBR-DATA (i.e., EXPORTS): map from neighbour UIDs to exportsI CONTEXT-DATA = SENSOR-DATA + NBR-DATA
Control data
I SCHEDULE-DATA (i.e., TICKs)I ...
Configuration data
I Deployment data, addresses, ...I ...
Analysis from a data (flow) perspective
» On an app-specific basis, analysis of Volume-Velocity-Variety-Veracity» Further analysis: persistent vs. transient data» Further analysis: replication, partitioning, ...» Analysis of data flow can help architectural design (cf., reactive architectures)
R. Casadei Intro ACP Analysis Technology Wrap-up 26/49
Requirements Analysis Current framework
Outline
1 Introduction
Engineering pervasive computing applications
Aggregate Computing: recap
2 Analysis for an Aggregate Computing Platform (ACP)
Requirements
Analysis
Current framework
3 Technology: quick survey
4 Wrap-up
R. Casadei Intro ACP Analysis Technology Wrap-up 27/49
Requirements Analysis Current framework
SCAFI: state-of-art
R. Casadei Intro ACP Analysis Technology Wrap-up 28/49
Requirements Analysis Current framework
AC Platform: state-of-art
Key features
I Actor-based (Akka)I Two styles
a) fully decentralised (P2P)b) server-based (mediating interactions)
I Simple object-oriented API façadeI Easy configuration (file, cmd-line, programmatically)
Limitations (work-in-progress)
I Not ready for use across the InternetI Serialization issues and constrained architecture due to nested designI Tightly coupled with SCAFI-core
R. Casadei Intro ACP Analysis Technology Wrap-up 29/49
Requirements Analysis Current framework
AC actor platform: overview
R. Casadei Intro ACP Analysis Technology Wrap-up 30/49
Requirements Analysis Current framework
AC actor platform: building
R. Casadei Intro ACP Analysis Technology Wrap-up 31/49
Requirements Analysis Current framework
AC actor platform: modular actor design
R. Casadei Intro ACP Analysis Technology Wrap-up 32/49
Requirements Analysis Current framework
AC actor platform: styles
R. Casadei Intro ACP Analysis Technology Wrap-up 33/49
Outline
1 Introduction
2 Analysis for an Aggregate Computing Platform (ACP)
3 Technology: quick survey
4 Wrap-up
R. Casadei Intro ACP Analysis Technology Wrap-up 34/49
Message-oriented middlewares
Why: decoupling consumers from producers (in both space and time)
RabbitMQ
I General purpose message brokerI Supports protocols such as AMQP, MQTT, STOMP etc.I Flexible routingI Concepts: publishers, brokers, consumers, exchanges, bindings, queues, ...
Apache Kafka
I Distributed, partitioned, replicated commit-log-based publish-subscribemessaging system
I Persistent messagingI Concepts: producers, consumer instances/groups, topics, cluster of brokers,
per-topic partitioned log, log retention, ...
R. Casadei Intro ACP Analysis Technology Wrap-up 35/49
StreamingDimensionsI Types of datasets: bounded vs. unboundedI Types of processing: batch vs. streaming
Why: need for processing that execs continuously as long as data is being produced
Apache Flink
I Stream processing framework for distributed, high-performing, always-available,and accurate data streaming applications
I Concepts: data sources, transformations, data sinks, dataflow, operatorsubtasks, stream partitions, flexible windows for stream aggregation...
I Deployment modes: cloud / on premise / cluster (managed by YARN or Mesos)I Guarantees exactly-once semantics for stateful computations (checkpointing)
Apache Storm
I Concepts: topology as graph of spouts (sources) and bolts; streams asunbounded sequences of tuples; groupings defining how streams are partitionedamong the bolt’s tasks
I Trident: exactly-once, high-level API, enabling micro-batching within a stream
R. Casadei Intro ACP Analysis Technology Wrap-up 36/49
Lightbend Fast Data Platform
R. Casadei Intro ACP Analysis Technology Wrap-up 37/49
NoSQL data stores and spatial indexes
Why: in Aggregate Computing, data has peculiar characteristics and access patterns
I Nodes are often spatially situated and mobileI Locality principle (cf., neighbourhood)
I Typical query: “get most recent exports of my neighbours”
Spatial DBs and spatial indexes
I Redis supports geospatial indexesI Commands: GEOPOS, GEOADD, ...
I Neo4J (graph DB) and Neo4j Spatial plug-inI PostGIS: spatial and geographic objects for PostgreSQL
R. Casadei Intro ACP Analysis Technology Wrap-up 38/49
Automated cluster managementWhy: abstract over resources and support distributed, fault-tolerant, elasticdeployments
Apache Mesos: a distributed systems kernel for managing clusters
I Provides APIs for resource management and scheduling across datacenter andcloud environments
DC/OS: the datacenter operating system, based on Mesos
I Manages multiple machines in the cloud or on-premises from a single interfaceI Deploys containers, distribute services and legacy apps into machinesI Provides networking, service discovery and resource management to keep the
services running and communicating with each otherI Marathon: a container orchestration platform for Mesos and DC/OS
Docker: SW containerization platform
I Docker Swarm for managing clusters of Docker engines
Kubernetes: platform for automating container operations
I Supports automating deployment, scaling, & management of containerized apps
R. Casadei Intro ACP Analysis Technology Wrap-up 39/49
Outline
1 Introduction
2 Analysis for an Aggregate Computing Platform (ACP)
3 Technology: quick survey
4 Wrap-up
R. Casadei Intro ACP Analysis Technology Wrap-up 40/49
Summary: key ideas
Aggregate programming
• A macro-programming approach to CASs, formally grounded in Field Calculus• Allows composition of (self-stabilizing) SASO patterns.
The abstract model is decoupled from the execution strategy
• Aggregate computing is suitable for exec across several platforms/infrastructures• From ad-hoc networks to cloud/fog computing• Can be extended to dynamically exploit available/heterogeneous infrastructure
SCAFI: a Scala framework for Aggregate Programming
• Provides an internal DSL for field-based computations• Provides simulation facilities• Provides an actor-based platform for building aggregate systems
R. Casadei Intro ACP Analysis Technology Wrap-up 41/49
Perspectives, projects, future works I
Algorithms and SCAFI library
I Flocking and mobility (De Castri/Foschi/Paolucci)I Anticipative Gradient (Berlini)
SW engineering (AC as a case study)
I AC Platform analysis/design and impl/refactoring (Scala)I Actor-based platform bootstrap (Casadei [Cas])I GUI interface to simulator: bootstrap (Varini) & refactoring (Aguzzi)
I Testing/debugging of AC appsI Load/performance testing of AC appsI Tools and automation support in SCAFI
I Continuous Integration (Fantini)
R. Casadei Intro ACP Analysis Technology Wrap-up 42/49
Perspectives, projects, future works II
Integration and applications
I SCAFI on Android (Radaelli, Collini)I SCAFI-Alchemist integration proof-of-concept (Costanzi [Cos])I Web/RESTful interfaces to AC systems, Web of Things (WoT)
AC and Service/Cluster/Cloud Computing
I AC and IoT platforms (Farneti [Far])I Development of a custom PaaS for ACI Prototyping a scalable AC cluster with open-source solutions (Paolucci)I Reactive AC architectureI Fields like Big Data and NoSQL solutions (Riciputi)
R. Casadei Intro ACP Analysis Technology Wrap-up 43/49
Perspectives, projects, future works III
Innovative themes and experiments
I AC and computer security (Mantani [Man])I Aggregate processes (Foschi)I AC and complex networksI AC and topological methods (math-oriented)
MiscellaneousI Comparing AC to BSP-based graph processing systems (Pregel/Giraph)
R. Casadei Intro ACP Analysis Technology Wrap-up 44/49
Application scenarios
I Crowd engineeringI Distributed sensingI Contextual servicesI Smart cityI Smart homeI Industry 4.0I WSNsI Swarm intelligence (robots, drones)I Rescue scenarios
R. Casadei Intro ACP Analysis Technology Wrap-up 45/49
Project example #1: exploration
Scenario: exploration of unknown environments (Mars?)
I Mobile robotsI Must move and stay at the right distance, communicating frequentlyI May need to come back or send information (e.g., hop-by-hop) to a fixed base of
operationsI Assumption: no infrastructure, peer-to-peer communication (ad-hoc network)I Progression: analysis - design - simulation - evaluationI Extension: rescue
R. Casadei Intro ACP Analysis Technology Wrap-up 46/49
Project example #2: dynamic platform reconfiguration
Goal: draft a simple solution design for dynamic reconfiguration of system nodes
I Cf., MAPE designI Monitoring: monitor local status of infrastructureI Analyze: determine the best option for communication and interaction (wrt to
QoS)I Plan: plan a gentle reconfigurationI Execute: distribute the reconfiguration data and commandsI Application example on top: crowd density monitoring and warning servicesI Progression: analysis, design, prototype
R. Casadei Intro ACP Analysis Technology Wrap-up 47/49
Project example #3: AC and WoT
Goal: provide a web interface to system nodes
I E.g., for de/activation of sensorsI E.g., to command actuators (e.g., for mobility)I E.g., to query device stateI Not every node may be able to connect to Internet and support this
I Internet-enabled neighbour nodes may still be able to provide such info
I In practice: design a set of ReSTful services and a web interfaceI Application example on top: distributed sensing
R. Casadei Intro ACP Analysis Technology Wrap-up 48/49
References
References I
[Cas] Roberto Casadei.Aggregate programming in scala: a core library and actor-based platform fordistributed computational fields.Master’s thesis.
[Cos] Simone Costanzi.Integrazione di piattaforme d’esecuzione e simulazione in una toolchain scalaper aggregate programming.Master’s thesis.
[Far] Thomas Farneti.Design and deployment of an execution platform based on microservices foraggregate computing in the cloud.Master’s thesis.
[Man] Giacomo Mantani.Towards security-aware aggregate computing.Master’s thesis.
R. Casadei Appendix 49/49
References
References II
[ZM04] Franco Zambonelli and Marco Mamei.Spatial computing: An emerging paradigm for autonomic computing andcommunication.In Workshop on Autonomic Communication, pages 44–57. Springer, 2004.
R. Casadei Appendix 50/49