EdgeWeaver: Unified OaaS-IoT Framework

• EdgeWeaver is a unified OaaS-IoT framework that integrates compute, state, and workflow management across the edge–cloud continuum.
• It automatically parses class definitions with declarative SLAs to orchestrate deployment, state replication, and function placement under defined throughput, availability, and locality constraints.
• Empirical studies show it achieves 31% faster developer task completion, reduced code size, and robust SLA enforcement compared to conventional FaaS models.

EdgeWeaver is the reference implementation for Object-as-a-Service for IoT (OaaS-IoT), integrating unified object abstraction—a composite of compute, state, and workflow—with the edge–cloud deployment continuum. This system enables developers to express application logic as object-oriented classes comprising methods (mapped to serverless functions) and attributes (state containers), alongside declarative Service-Level Agreements (SLAs) dictating non-functional requirements such as throughput, availability, consistency, and locality. EdgeWeaver automatically parses these specifications, orchestrates deployment across datacenters and edge sites, and enforces real-time resource allocation and constraint satisfaction. In human studies and empirical trials, EdgeWeaver achieves superior developer productivity, code maintainability, and operational compliance with SLAs relative to conventional Function-as-a-Service (FaaS) models, evidenced by improvements in developer task completion time, codebase size, and configurational overhead (Lertpongrujikorn, 27 Dec 2025).

1. OaaS-IoT Paradigm and EdgeWeaver Overview

The OaaS-IoT paradigm extends the object abstraction central to OaaS beyond the cloud, spanning geographically dispersed edge nodes and cloud regions. Deployment is realized by annotating class definitions with SLA clauses, which are then interpreted by the EdgeWeaver runtime for automated scheduling, state management, and workflow orchestration. Class methods correspond to serverless functions, while class attributes serve as structured or blob state managed across distributed storage backends. Declarative SLAs encapsulate throughput, latency, availability, consistency, and placement requirements.

EdgeWeaver operates by:

• Parsing class definitions and SLAs.
• Deploying Class Runtimes (CRs) at chosen datacenters (edge/cloud).
• Orchestrating function placement, state replication, and invocation routing to satisfy specified SLAs.

Key outcomes from empirical studies include:

• 31% faster developer task completion.
• 44.5% reduction in lines of code and 10× fewer configuration artifacts compared to FaaS baselines.
• Robust enforcement of SLA-driven execution under dynamic network conditions and partitions.

2. System Architecture

EdgeWeaver’s architecture delineates two layers of deployment (Figure 1):

• Cloud Layer: Package Manager (PM) coordinates global deployment.
• Datacenter Layer: EdgeWeaver Agents per datacenter comprise:
  • Class Runtime Manager (CRM)
  • Class Runtime (CR)
  • Monitoring System (MS)
  • Messaging Infrastructure (MI)
• Device Layer: Optional Device Agents on IoT endpoints.

Within each CR (Figure 1), the following submodules operate:

• Logic Engine: Hosts class methods as Knative-based serverless containers.
• Storage System: Structured state is managed via document databases/in-memory stores, while unstructured data (blobs) are served through object storage with presigned URLs.
• Object Data Grid Manager (ODGM):
  • Invocation Router: Directs method calls to appropriate CRs.
  • Object Access API: Enforces consistency protocol (Raft, anti-entropy).
  • Message Driver: Oversees cross-site RPC and event delivery.

3. Resource Scheduling and Orchestration

EdgeWeaver employs specialized algorithms for automated resource allocation in accordance with declared SLAs:

• Availability Replication: To achieve availability $A$ given node stability $P$, the required replica count $N$ solves $A = 1 - (1 - P)^N$. EdgeWeaver selects datacenters with maximal $P$ and deploys $N$ CR replicas.
• Throughput Guarantee: Declared throughput $R$ (requests/sec) is met by pre-warming containers so invocation can commence every $1/R$ seconds, leveraging predictive real-time serverless scaling.
• Locality Placement: Scheduler co-locates method containers with primary state for classes where SLA.locality = {edge, cloud, any}, using consistent hashing on object IDs to minimize cross-site latency.
• Consistency Enforcement:
  • Strong consistency: Raft consensus among replicas.
  • Bounded staleness (Δ): Anti-entropy protocol with Merkle trees tolerates Δ seconds staleness.
  • Read-Your-Write (RYW): Reads from the local replica processing the last write.
• Scheduling Objective: Multi-objective optimization minimizing $$\sum \text{Cost}_i(x_i) + \alpha \cdot \sum \text{Latency}(x_i)$$, subject to $\text{Throughput}_i(x_i) \geq R_i$, $\text{Availability}_i(x_i) \geq A_i$, and placement constraints.

4. SLA-Driven Management and Runtime Operation

SLAs and deployment constraints (Table 1):

Constraint	Data Type	Use Case
throughput	Integer (rps)	Calls/sec guarantee
availability	Real (%)	Up-time requirement
consistency	{strong, bounded_staleness(Δ), RYW}	Read/write semantics
locality	{edge, cloud, any}	Placement preference
budget	Cost credit limit	Financial constraint
jurisdiction	Allowed datacenters	Data governance

Declarative SLA specification (YAML):

classes: - name: VideoAnalytics sla: throughput: 1000 # rps availability: 99.99 # % consistency: strong locality: edge

Runtime management (Figure 2):

1. PM assigns CRs per datacenter.
2. CRM enforces availability via replica count optimization.
3. CR guarantees requested consistency mode.
4. Logic Engine prewarms containers for throughput fulfillment.
5. MS monitors SLA metrics, CRM triggers rescheduling/scaling on violations.

5. Performance Evaluation

Experimental setups include edge clusters (8 nodes ×8 vCPU, 33 ms RTT) and cloud clusters (3 nodes ×16 vCPU, TACC). Storage utilizes Minio (S3) and ArangoDB. Baselines are Knative (default/concurrency cap/real-time serverless) and the cloud-only Oparaca implementation.

• Throughput: EdgeWeaver precisely matches up to 4,000 rps per declared target across chatty JSON, image resizing, and video transcoding workloads; Knative variants fail at high loads.
• Latency: Locality enforcement on edge sites achieves up to 4× reduction (vs. cloud-only) in tail latency; pre-warmed containers attain latency within 7% of ideal.
• Availability: With induced MTBF = 180s (94.36% stability), EdgeWeaver maintains 99.9–99.999% uptime via 2–9× replicas, marking a 50× replication overhead reduction over AWS defaults.
• Scalability: Linear scaling up to 256 vCPUs (cloud); proportional scaling across edge sites, saturation at network bottleneck.
• Code/Config Effort: In inventory case study, EdgeWeaver reduces code size by 44.5% (363 LoC vs. 666 LoC) and config artifacts by 10× (39 vs. 417 lines).

All metrics are statistical means (5× trials, ±5 ms latency, ±2% throughput); task completion improvement statistically significant ($p < 0.01$).

6. Developer Experience and Human Study Outcomes

Results from a controlled programming study (N=39):

• Quiz accuracy: 84.6% (EdgeWeaver) vs. 81.5% (FaaS); >90% for experienced cloud users.
• Programming task: 22.4 min (EdgeWeaver) vs. 32.4 min (FaaS)—a 31% reduction ($p < 0.005$).
• Code and configuration: Identical logic, but 44.5% less code and 10× less configuration with EdgeWeaver.
• Qualitative feedback: 92% favored the object abstraction, 88% preferred SLAs over manual tuning.

A plausible implication is increased developer preference for OaaS-style object abstraction combined with declarative constraints in edge–cloud applications.

7. EdgeWeaver API and Usage Patterns

Core API primitives (Table 2):

Function	Description
CLASS.create()	Instantiate object, returns ID
CLASS.get(ID)	Retrieve object
commit(obj, attr)	Persist attribute
refresh(obj, attr)	Reload attribute
trigger(func, src, event)	Event-driven invocation

Example: Real-time video workflow (Figure 3)

YAML definition:

classes: - name: VideoProcessor sla: throughput: 30 # fps locality: edge attributes: - name: inputBlob type: Blob methods: - name: extractFrames trigger: OnCreate(inputBlob) - name: detectObject sla: locality: cloud consistency: strong

Pseudocode workflow:

videoId = VideoProcessor.create() VideoProcessor.inputBlob(videoId) = s3.upload("camera1.mp4") VideoProcessor.extractFrames.triggerOn(videoId) // EdgeWeaver handles cross-tier placement & SLA.

EdgeWeaver transparently manages cross-tier deployment, event-triggered orchestration, and SLA compliance, shielding the developer from infrastructure intricacies while delivering predictable performance and maintainability (Lertpongrujikorn, 27 Dec 2025).