Keywords

1 Introduction

In the era of multiple device ownership [1], software applications are no longer ran strictly on a single device [6]. The liquid software [23] metaphor [25] associates the behavior of a fluid, which can adapt to the shape of its own container, to software that can be deployed and can operate seamlessly across multiple devices owned by one or multiple users. Liquid software needs to adapt to the capabilities of a single device (e.g. responsive) and it must be able to adapt to the set of devices running the application.

The metaphor focuses on the expected liquid user experience when the users interact with applications deployed on multiple devices, in particular liquid software can: 1. adapt the user interface to the set of devices being concurrently used to run the application; 2. seamlessly migrate [21] the running application, or some part of it (e.g. individual components of the whole application), across multiple devices; 3. synchronize the state of the application distributed across all paired devices; 4. offload computations to neighbour paired devices in order to increase the overall performance of the application.

Web applications were traditionally developed following a thin client architecture whereby most of the logic and the entire persistent state of the application would be executed and stored on a central Web server [4]. Because of the different drivers in the design choices, traditional Web software architectures would offer only partial support for the liquid user experience [11]. However as the Web evolves, and as the Web technology standards increase in number and variety, we can evolve from traditional to new architectures suited for liquid software. For example, thanks to new communication protocols defined in the WebRTC standard, we can revisit the architectural design decision of traditional Web architectures and systematically study and design architectures driven by different software quality drivers.

2 Motivation

The development of liquid applications with high deployability, that can correctly operate and adapt their behavior in accordance to their deployment context on multiple devices, requires to address these issues at the design time. Liquid software deals with the following use cases scenarios [17]:

  • Sequential Use: a single user runs an application on different devices at different times. The users can stop working on a device and resume their work on a new one. The application needs to be responsive and adapt to both devices and it needs to be able to resume the work accomplished by the user on the first device and display it in the new one.

  • Simultaneous Use: a single user can access the application from several devices concurrently. The application needs to adapt to the set of devices, which can dynamically change over time, i.e. the users can connect to the application with new devices or can disconnect some of the devices. The devices can display a distributed view of the application user interface instead of just copying and adapting the user interface to each device. In the case of a distributed user interface, each device has a distinct role in the application [20].

  • Collaborative Use: several users run the same application on their devices. The collaborative use case scenario can be either sequential or simultaneous.

All the scenarios share the same challenges in adapting the user interface to different devices and in synchronizing the data and state of the execution between them. The data and state synchronization is fundamental in the implementation of liquid software [23] because the devices and users need to be aware of the results of their actions previously or simultaneously done in other devices.

The liquid software ecosystem should allow the connection of heterogeneous devices and overcome the native software ecosystem boundaries. In this way, the developers need to implement the application once, which could then adapt itself and run on all kind of connected devices [7]. We realize the liquid software ecosystem by leveraging on the Web ecosystem, where applications are deployed on demand and through Responsive Web Design [22] are adapted to fit on the local device displays. Properties such as openness and freedom from proprietary features make the Web a natural choice over native applications that are bound to a particular operating system, manufacturer, or vendor-specific ecosystem [24].

Different solutions have been developed and researched during the past years on how liquid applications could be built, starting from server-centric approaches like the platform Joust developed in 1999 [19]. However, as the number of connected devices grows, a centralized approach is not enough and we need to switch to decentralized solutions and techniques, such as the Fluid computing middleware [5]. In the past years HTML5 standards led the Web to what Anthes called the Web Revolution [2]. The Web now is more developer-friendly and any device able to run a Web browser can run the same application on top of it even if the devices are completely different from one another. Thanks to the Web, liquid applications can automatically run across heterogeneous device environments by using frameworks like the Cross-Device [20] or Liquid.js for Polymer [9]. Even though most current Web applications have a strongly centralized architecture, we are quickly heading back towards the decentralized Web [3]. Shifting to a decentralized or distributed paradigm changes the way we are using the Web [18].

3 Research Questions

The objective of this research is to propose a way for developers to efficiently upgrade solid Web applications allowing them to become liquid. For this reason we are building a prototype framework that allows the creation of new liquid applications and the upgrading of already existing applications. By building such framework we aim to: – Show that it is possible to upgrade solid applications with all liquid features without the need to completely redesign and build the whole software again. Since the solid behavior of the software should be unaffected, we aim to add the liquid behavior of the software around the application itself, successfully decoupling the liquid functionalities from the solid behavior of the software. – Evaluate the overhead of the added liquid behavior on top of the solid application. From the developer’s point of view, the added liquid behavior of the software should not affect the non-functional quality attributes of the solid application (such as performance, scalability, ...). However, since it is not possible to upgrade a software without affecting any of its qualities, we aim to study the trade-offs so that the execution of the application remains unaffected. From the user’s perspective the Liquid User Experience should be as performant as the environment allows. The liquid software should minimize latency in the synchronization between devices, while also trying to minimize bandwidth and memory usage.

The goal of research is to answer the following research questions: – RQ. 1: How can we allow Web developers to design liquid software and liquid User Experiences? Liquid Web applications are complex software solutions able to interact with multiple devices simultaneously. The complexity of these interactions is transparently hidden behind the liquid User Experience and requires real-time message passing and data synchronization among all the connected devices in order to seamlessly move applications among them. Liquid Web software can be designed following different quality attribute drivers and the design can be reflected into a multitude of different software architectures depending on the design alternatives that are selected during the design phase. What are the design alternatives related to liquid Web applications? What are the implication of such choices? – RQ. 2: Can we abstract liquid Web applications away from the current strongly centralized deployment approaches? The vast majority of Web applications implementing a liquid User Experience rely on centralized architectures and deployment, however interactions between the devices do not necessarily need to relay on a Web server and can happen directly between them. From the user perspective, this approach can preserve privacy, since the user data and all user interactions can be modeled to be synchronized independently from a centralized Web server deployed in the Cloud outside the user’s control. What are the trade-off of this choice? – RQ. 3: How can we make the liquid User Experience of a Web application automatically adapt to the set of connected devices? Developers of liquid software should provide to the user a mechanism for populating all of their devices with pieces of the application they are running. For this reasons we must provide to the developers the tools for developing automatic complementary views. This allows the developers to have a certain degree of control on how the application is migrated across the devices, instead of exclusively let the user decide how the application deployment configuration will evolve over time. A misuse of the manual liquid User Experience may lead to non-intuitive deployment configurations which contradict with the developer expectations and intent. – RQ. 4: How can we take advantage of all resources provided by the connected devices? Any connected device has access to at least a screen, a data storage and a CPU. While the Liquid User Experience takes advantage of all the screens and the decentralized synchronization can take advantage of all the provided data storages, we need to further develop a mechanism for efficiently exploit the CPUs of all connected devices in the liquid software environment. Without such a mechanism all the devices computes the same operation multiple times, even if it would be better to compute the operation in a single device and then broadcast the result.

4 Contributions

So far we have published and presented papers relative both to the design of liquid architectures and to Liquid.js for Polymer: – we modeled the design space of liquid software [15, 16] where we discussed the implications and the relative design decisions of liquid software; – we studied the architectures of liquid applications and derived the maturity model for liquid architectures [11]. In the maturity model we describe the evolution of liquid applications in the Web and abstract their design from the technologies employed in the system, moreover we describe the driver quality attributes associated to each level of the maturity model. – We have several contributions related to Liquid.js for Polymer. In [10] we show how we design the migration of Web components between devices, in [9] we discuss the design of the distributed state in the framework, and in [8] we discuss how to handle child liquid components instantiated inside parent liquid components. We presented the Liquid.js API in [13], the decentralized view adaptation in [12] and the complementary view adaptation in [14].