(mOSAIC) Redesigning the Dehems system over Mosaic platform

About Dehems

From About the Dehems project:

• The Digital Environment Home Energy Management System (DEHEMS) project is an European Union funded project (Grant Agreement No: 224609) looking at how technology can improve domestic energy efficiency. The project partnership includes a mix of European local authorities, private business and universities. The intention is to develop and test a home energy management system for the home market using Living Labs in 5 cities across Europe. The aim is to improve the current monitoring approach to levels of energy being used by households, with an overall aim of reducing CO2 emissions across Europe. The project is supported by the EU under Framework Programme 7.

Logical Dehems architecture

Redesigned Dehems arcitecture

Notes:

• color code:
  • all that is green is part of the Mosaic platform and is the result of a deliverable;
  • all that is yellow is written by the user of the Mosaic platform;
  • all that is blue is actually part of the cloud;
• there are two API's (lower right corner of the diagram):
  • both API's are part of the Mosaic platform, but serve different roles;
  • there is the cloud API which has the following characteristics:
    • it is provided by the cloud providers;
    • it is directly used by the Mosaic platform in order to control the cloud on which the deployment relies;
    • it standardized by already existing bodies (e.g. OCCI, OVF, etc.);
    • in itself (as an API, protocol, etc.) it is secondary in interest for the Mosaic project;
  • the Mosaic API with the following characteristics:
    • it is provided by us as the result of deliverables;
    • it is directly used by users in order to deploy applications over the Mosaic platform;
    • we should try to standardize this API either: as semantics (i.e. what is the POSIX standard for the UNIX world), either as protocol (e.g. AMQP, HTTP, etc.), or at least as a programmable API (e.g. JMS, JSP, WSGI, etc.);
    • this is the main and most important API from the two;
• there is a shift in design and programming methodology:
  • no user module (boxes in yellow) communicate directly with one-another; all the interaction is done through other Mosaic components (boxes in green) (e.g. distributed databases, message queues, distributed file systems, etc.)
  • no user module has direct access to the internet; all the interaction with external resources (e.g. other web services, mail, raw TCP/IP communication) is done through Mosaic components -- endpoints (e.g. HTTP, SMTP, UDP endpoints, the green boxes on the left);
• the user doesn't control (or use) the cloud resources directly; (nowhere in the upper diagram the yellow boxes are connected to blue boxes;) but only through the abstraction that the Mosaic components provide (thus the Mosaic platform API);
• even though all the modules are depicted as single boxes, these are logical components, and they could and should be embodied by multiple instances at run-time;

(The following image can also be viewed in the scalable PDF format: mosaic-architecture.pdf.)

Simple deployment descriptor

Notes:

• this is not how the final system would look like; this is just a simple mock-up displaying the concepts;

• as we see all the components from the previous figure is embodied by an element in the deployment descriptor;

• also all the links between the user modules and the Mosaic resources are explicitly expressed in the deployment descriptor in the resources section for each module;

• further-more just saying that a module "uses" a resource is not enough, but we need to specify what is the role of the module in the "usage" of the resource (e.g. queue-consumer, and queue-producer);

• the previous roles could and should be enforced by the platform;
• the scalability of the resulting system stems for example from the fact that by monitoring the queues length and knowing which are the producers and which are the consumers, the platform can automatically choose to instantiate another module;
• nowhere in the deployment descriptor is specified anything about the usable cloud providers;
• instead the user requests explicit "capabilities" from each resource (e.g. persistence requirement of the queue system, the fact that we need range queries from the columnar store, etc.), that would guide the Mosaic platform in weeding out and selecting the right set of possible cloud providers;

deployment.xml

Simple code snippets

Notes:

• this is not how the final system would look like; this is just a simple mock-up displaying the concepts;

• the modules are implemented in Java without paying attention to details, but focusing mainly on the platform code;
• in order to obtain scalable modules, these must respect some restrictions:

  • they must be stateless (i.e. the module must not store any state in global variables) -- thus the State argument at the beginning of each method;

  • they must be life-cycle controllable (paused, un-paused, terminated, upgradeable, etc.);
  • in general an event-driven programming style must be adopted; (as we see there are no threads created, there are no loops, etc.; in the initialization method we only register consumers (observer pattern), and we respond to platform events (initialized, terminate, upgrade, etc.));

  • all the configuration is done through the platform (by using the Context instance);

  • in general the stored or communicated data must be in a language-independent format (thus the JsonSerializable interface instead of Serializable for the SensorReading class);

UppSensorReadingDecoder.java GenericSensorReadingDecoder.java