The connection, the flow, between people, information and tools becomes fluid
Target: User Experience, Information Integration
Liquid Software (1998)
University of Arizona, Princeton University
Software that easily flows from machine to machine
Target: Active Networks, Compilers
Liquid Modernity (1999)
Zygmunt Bauman
Target: Sociology
Fluid Computing (2003)
IBM Zurich Research Lab
Replication and real-time synchronisation of application states on several devices. The application state flows as a 'fluid' between devices.
Target: Multi-device applications, Replicated State Synchronization
Niagara (2005)
Sun (now Oracle)
Target: Multi-threaded-Multi-Core CPUs
Think Liquid (2005)
BEA (now Oracle)
Target: SOA, integration agility
LiquidPub (2008-2011)
U. Trento et al.
Target: Scientific Publishing on the Web
Firehose API (2010)
Twitter
Target: Streaming Data Source (50Mtweets/day)
Liquid Web Services (2011)
USI Lugano
Services fill up any container capacity
Target: Elastic Scalability, Cloud and Multicores
Liquid Web Streams (2013)
USI Lugano
Dynamic (re)deployment of JavaScript operators on Web servers and Web browsers
Target: Stream processing for Web of Things
Liquid Software Manifesto (2014)
TU Tampere
Roaming between multiple devices shall be as casual, fluid
and hassle-free as possible
Target: Multi-device programming
Liquid Software Manifesto
Liquid Manifesto
Users shall be able to effortlessly roam between all the
computing devices that they have
Roaming between multiple devices shall be as casual, fluid
and hassle-free as possible; device
maintenance and device management shall be hidden from the users.
User’s applications and data shall be synchronized
transparently between all the computing devices
Roaming between multiple devices shall
include the transportation / synchronization of the full state of
each application, so that the users can seamlessly continue
their previous activities on any device
Any
device from any vendor should be able to run liquid software,
assuming the device has a large enough screen, suitable input
mechanisms, and adequate computing power, connectivity
mechanisms and storage capacity
users shall remain in
full
control regarding the liquidity of
applications and data. If
the user wishes
certain functionality
or data
to
be accessible only on a single device,
the user shall
be able to define this in a
simple,
intuitive
fashion
Today users have many devices
Hassle-free multi-device roaming
Transparent Data Synchronization
Strong Code Mobility
Portability, Flexibility, Adaptability
Backwards compatibility
Liquid User Experience
Collaboration Types
Distributed User Interfaces
Distribution Dimensions
Time: Synchronous, Asynchonous
Space: Co-located, Remote
Input: Single Device, Multi-Device
Output: Single Device, Multi-Device
Platform: Single Device, Multi-Device
User: Single User, Multi-User
Input Redirection
Output Redirection
Migration: Pull
Migration: Push
Liquid Code Deployment
Code Mobility
Code (sometime also its execution state) migrates across execution nodes.
Movement can be determined from within the code (autonomous agent) or triggered by its environment (fault tolerance, load balancing, consolidation)
Liquid Code Deployment
Liquid deployment runs code on the most suitable device, offloading work elsewhere to trade off:
Mobile device battery, energy consumption
Network communication (latency/bandwidth/cost)
CPU speed
Cloud rental fees
When are offloading decisions made?
Static: deployment time
Dynamic: invocation time, adaptation time
Never: invoke both and see which one is faster
Liquid Storage
Centralized
Centralized with Cache
Centralized: Master/Slave
Centralized: Update Everywhere
Decentralized
Replication
CAP Theorem
Consistency
All replicas agree on the latest version of their state
Availability
Every request routed to a non-failing replica must result in a response
Partition Tolerance
The network will be allowed to loose arbitrarily many messages between replicas
CAP Theorem
"C and A and P" not possible for decentralized systems
CAP Theorem Proof
Eventual Consistency
Availability prioritized at the expense of strong consistency.
During the recovery of a partition, conflicts between multiple inconsistent states needs to be resolved (e.g., last writer wins).
Liquid Storage Challenges
Full Replication not an option (limited by the smallest device storage capacity)
Partitions happen frequently (devices not always online at the same time)
Single user making localized changes may simplify conflict resolution
Expensive to synchronize everything through the Cloud
Conclusion
The Liquid Software Metaphor describes how the user experience with multi device environments should be
This has implications on the deployment architecture of Web applications, and also on how their state and data are stored
Liquid Software provides a local Cloud obtained with devices owned and controlled by the user
John J. Hartman, Peter Bigot, Patrick Bridges, Brady Montz, Rob Piltz, Oliver Spatscheck, Todd A. Proebsting, Larry L. Peterson, Andy Bavier, Joust: a platform for liquid software, Computer, vol.32, no.4, pp.50-56, Apr 1999
Daniela Bourges-Waldegg, Yann Duponchel, Marcel Graf, Michael Moser, The Fluid Computing Middleware: Bringing Application Fluidity to the Mobile Internet, SAINT 2005
Antero Taivalsaari, Tommi Mikkonen, Kari Systä, Liquid Software Manifesto: The Era of Multiple Device Ownership and Its Implications for Software Architecture, COMPSAC 2014