Between SaaS and PaaS: Framework as a Service

Early Warning Systems (EWS) may become a powerful tool for mitigating the effects of natural disasters, especially when supported by an advanced IT ecosystem. The maturation of technologies and ever-increasing supply of cheap computing power creates a fertile ground for next-generation early warning systems based on real-time analysis of measurements from in-situ sensors, semiautomatic impact assessment and on-demand scenario simulations. The EU FP7 UrbanFlood project (http://www.urbanflood.eu) develops such a platform for early warning systems with the Common Information Space being the heart of the platform.

UrbanFlood exploits the flood protection use case in which in-situ sensors are leveraged for monitoring of embankments in urban areas in order to support decision making when the possibility of dike failure results in a flooding threat. The Flood Early Warning System (Flood EWS), created using the CIS technology, is composed of several application scenarios connected into a workflow (Fig. 1). In the default mode data from sensors deployed in an embankment is continuously aggregated and fed into machine-learning algorithms which detect anomalies in sensor signals. When a high likelihood of an anomaly is indicated, another level of analysis is automatically enabled which computes the stability of embankments based on current sensor measurements. Again, when the analysis indicates a high risk of dike failure, two simulations can be performed in order to predict the impact of the dike breach scenario: the first simulation covers flooding of the threatened area while the second one predicts evacuation patterns and loss of life in the event of a flood.

Fig. 1: High-level workflow in the Flood Early Warning System powered by the Common Information Space.

Each of the aforementioned application scenarios can itself be a complex system which integrates multiple resources and services. A closer look at the implementation of the Flood Simulation scenario (Fig. 2) best explains the EWS system model introduced by CIS, the complexity of individual EWS application scenarios and CIS runtime services.

• The ‘entry point’ for invoking a scenario is the Flood Simulation Service. It implements high-level business logic which orchestrates all underlying resources involved in the scenario. The service can provide an invocation interface and metadata compliant with the OGC Web Processing Service (WPS) standard.
• Flood simulation involves CPU-intensive computations. The ‘computing backend’ of the scenario consists of two scientific applications implementing the computational models of flooding, wrapped as virtual appliances and deployed in the cloud.
• Early warning systems feature processing of geospatial data. Therefore some input data for the scenario can be provided as links to external data services implemented in compliance with OGC standards; in this case - the Web Coverage Service (WCS). In addition, the output inundation data is archived and also exposed as a WCS service.
• Execution of the scenario is supported by CIS runtime services: Platin (overall EWS management), UFoReg (EWS metadata), ErlMon (EWS self-monitoring), and DyReAlla (optimization of resource allocation, urgent computing scenarios).

Fig. 2: Implementation of the Flood Simulation application scenario, part of the Flood Early Warning System.

CIS aims to be a framework for EWSes for a reason. A software framework is a semi-finished system which can be customized by user-provided code in order to produce a specific system or application. Frameworks typically solve problems common to a class of systems (Web applications, computer simulations, problem solving environments, financial applications, etc.) and control the ways in which user code is invoked. The biggest potential drawback of frameworks is that they propose a one-size-fits-all solution which may not always be suitable. However, when this is not the case, well-designed and battle-tested frameworks can, quite simply, contribute towards higher quality software delivered in a shorter timeframe! Where, then, is the promised ‘Framework as a service’? Well, the CIS service-oriented technology stack not only helps design services for full-blown early warning systems or individual EWS application scenarios, but actually enables one to use ‘blueprints’ for such scenarios, including systems and services. Just like in a traditional engineering process, where detailed blueprints enable manufacture and reproduction of physical objects, system blueprints in the framework-as-a-service model can automate of the entire process of system deployment and configuration.

The blueprints can themselves be deployed as services which basically act as system factories (Fig. 3). Using these factories users can rapidly deploy new early warning systems in new settings. Invoking a system factory service, which ultimately results in creating a new instance of a system, affects all layers of the stack: it spawns a number of associated service instances which in turn require deployment of associated appliances in the cloud. The new instances are customized in several ways:

• By configuring services and appliances existing in the blueprint. A configuration may specify, for example, an endpoint of  service providing sensor data feeds, or a customization of business rules, such as defining thresholds for raised alert levels.
• By user-provided code, mainly as custom appliances implementing a default API. Examples include AI algorithms trained for the target dike-protected location, or an alternative flood simulation model.

Fig. 3: Framework as a service: using a system factory service to create a system instance by customizing its blueprint.

The Framework-as-a-Service (FaaS) approach can provide a reasonable compromise between SaaS and PaaS-based solutions. On the one hand, FaaS offers more flexibility and customizability than a SaaS. On the other hand, it saves implementation and deployment effort which is typically involved in the development of a PaaS-based system.