Application Requirements

From SELFMAN Wiki

Table of contents
1 Application Requirements, Demonstrators & Evaluations

1 Description of the Working Package & Deliverables
2 Application Requirements (Deliverable D5.1*)

2.1 Deliverable Template
2.2 M2M Use Case
2.3 Storage Use Case
2.4 Appendices (Publications and Other Documents)
[edit]

Application Requirements, Demonstrators & Evaluations

Editor : Thierry Coupaye

[edit]

Description of the Working Package & Deliverables

The purpose of the WP5 is to provide application requirements, demonstrators and evaluations in different use cases.

Application requirements (D5.1*) cover the description of an applicative context, the proposition of some autonomic scenarios in this context and finally the requirements on components, transactions, overlay networks and self-* features associated to the implementation of the proposed scenarios in the considered applicative contexts.

Demonstrators cover the design specification (D5.2*) and actual implementation of (some) autonomic scenarios (D5.3*)

Evaluations cover both qualitative evaluations of self-management properties based on usage scenarios (D5.4*) and quantitative evaluations based on load injection (~traffic generation) (D5.5*). In addition, a dedicated evaluation of security mechanims will be proposed (D5.6) as well as a final report giving "guidelines" for developping self-managing applications (D5.7).

[edit]

Application Requirements (Deliverable D5.1*)

Four use cases are currently investigated. The two first ones are confirmed. The first one proposed by France Telecom concerns M2M systems. The second one proposed by ZIB concerns storage systems. Two additional use cases are currently investigated and could be studied in D51.: one by KTH-PeerTV which concerns P2P video streaming (P2P TV), one by Bull which concerns autonomic J2EE servers.

[edit]

Deliverable Template

  • INTRODUCTION

Objectives and organisation of the document: introduce several use cases made each of an applicative context, some autonomic scenarios in this context, the associated requirements needed to implement the scenarios.

Then, Each use case will be given is a specific section which should follow the following template (cf. M2M Use Case as an example):

  • Applicative Context
  • Autonomic Scenarios

The proposed scenarios organised in paragraphs:

    • self-configure
    • self-protect
    • self-repair
    • self-optimise
  • Requirements
    • Requirements w.r.t. functional and non functional properties
    • Mechanims to support the identified requirements organized in 4 paragraphs:
      • Components
      • Transactions
      • Overlay networks
      • Autonomics (self-* properties)
  • Conclusion

conclusion + explain/introduce the documents found in the appendices (papers published or not, technical reports, etc.)

  • CONCLUSION: general conclusion of the deliverabke if needed
  • APPENDICES

Papers, technical reports and other documents produced in the context of Selfman WP5 organized in the same way as the deliverable body, i.e. one sub-section per use case.

[edit]

M2M Use Case


  • CONTEXT

The applicative context we consider is that of a large M2M (Machine-To-Machine) system dedicated to the management of the termal environment of buildings. Thousands (or millions) of buidlings are equiped with sensors such as thermometers and smoke detectors ; and actuators on thermal equipments such as heaters and boilers. The M2M system is responsible for transporting data for sensors to several services which in turn process data and send commands to the thermal equipments. The M2M system architecture is typically a data-flow (Pipe & Filter) architecture made of interconnected nodes that receive, process and send data. The system we is made 5 interacting services: 3 are applicative services: fire alarming, weather, thermal Regulation and 2 infrastructure (technical, generic) services: log and notification. The services are distributed: each service is made of a set of interconnected nodes. The complete M2M system is made of the interconnected service nodes. An important feature is that different criticities are associated to services (and hence possibly to the data they manipule): the fire alarling service is of higher priority than the thermal regulation service which is itself of higher priority than weather forecast service. Due to different criticities, M2M infrastructure elements (service nodes) may be shared or not between services. An other feature du to the large scale of the system is the hierarchical data diffusion pattern used (with typically 3 layers: local, regional, national) .

Fire Alarming service

    • Detects and notifies fires by means of
      • Smoke detectors (sensors) only (default)
      • Smoke detectors and correlations with thermal regulation (see later)
    • Fire alarms service is prioritary
      • High priority messages
      • Load balancing and intra-service routing
      • Resources may be « stolen » from other services
      • Fire alarm service has a dedicated infrastructure : Fire alarming (sub)graph should always be connected

Weather Forecast service

    • Provides local, regional, national data about current and forecast weather based on observed local temperatures (sensors) and satellite data (national forescast only)
    • Data are notified and/or used by other services (e.g. thermal regulation - see later)
    • Strong connectivity between regional and national nodes
    • Local nodes may be disconnected and/or use nodes from other services

Thermal regulation service

    • Provides in-house thermal regulation through equipments management (actuators) according policies: confort levels (temperature ranges), power consumption (local, global)
    • Uses data from local sensors (temperature, power consumption) and possibly weather forecast (smoothing)
    • Data and commands have a Time-To-Live to avoid unrelevant data and commands (hysteresis)
    • Some nodes (e.g. 3) needs to cooperate with other nodes to send commands

Logging service

    • Logging Service is a generic and common technical service
    • Logging services could be a self-organized network in which any client node (i.e. a node belonging to the Fire Alarming, Weather Forecast or Thram Regulation services) can read/write any log data from any log node.
    • Logging could be transactional (atomic write request/response)?

Notification service

    • Notification Service is a generic and common technical service
    • Notifies messages to subscribers on different media (email, SMS, fax, text-to-speak, etc.)
    • Can be centralized (current) or decentralized (overlay) as the logging service
    • Data from smoke detectors and temperatures sensors are correlated to diagnose false alarms or detect fires without smoke detection

Interactions between services

    • There can be inter-services routing e.g. all nodes can be used as routers for notification
    • Weather forecasting uses local temperature data
    • Data from smoke detectors and temperatures sensors are correlated to diagnose false alarms or detect fires without smoke detection
    • Thermal regulation uses weather forecasting data at regional level
  • SCENARIOS
    • Self protect
      • failure prevention: re-intantiate a node on a degraded host on another host -> prevent failures of the notification service
      • gracefull service degradation to avoid complete system failure: disconnect nodes and paths in case of severe overload -> degrade Weather Forecast (local then regional then global) then Thermal Regulation in favor of Fire Alarming
    • Self repair
      • nodes failure recovery: re-instantiate nodes after fault detection -> Fire alarming must be self-repaired
    • Self optimize
      • manage message QoS (delivery guarantee, delay): drop/delay data processing according data quality (priority, freshness) ->local weather data (temperatures, pressure, humidity) may be dropped without penalizing national weather forescast nor regional weather forescast (if a viable number od data keep incoming in the latter case though)
      • Manage availability through routing, node clustering and load balancing: route data to available nodes, posiibly instantiate new nodes in case of light overload -> Used for Thermal regulation that is the most stressed service
      • optimize resource consumption and communications through nodes co-localization ->transversal to applicative services
    • Self-configure
      • Self configuration of log networks -> a common (self configured) overlay networks for FireAlarm, Regulation and Meteo
  • REQUIREMENTS
    • Requirements w.r.t. functional and non functional properties
      • flexibility, manageability, maintainability: ability to manage (configure, deploy, administrate) distributed software configurations in terms of components and components assemblies
      • scalability: ability to handle thousands to millions M2M nodes
      • reliability, integrity, consistency: no data loss, reliable (re)configurations
      • availability: QoS on messages delivery: all data must be treated within the « best » end-to-end delay (network traversal), priorities between applications
      • accountability: guarantee no message loss, facturation (pay-per-use)
    • Mechanims to support the identified requirements
      • Components: configuration (ADL), dynamic reconfiguration, deployment (package, deliver, install, configure, activate, update/upgrade, de-activate, uninstall),
      • Transactions (reliability, integrity, consistency, concurrency, recovery): transactional reconfiguration, end-to-end transactional behaviour, transactional behaviour inside a node, transactional P2P logging
      • Overlay networks: self-configured logging and accounting
      • Autonomics: monitoring, decision making (rules, policies), node characterization (performance, resource consumption), performance simulation, self-dimentioning of the logging overlay
  • CONCLUSION

conclusion + explain/introduce the documents found in the appendices (papers published or not, technical reports, etc.)

[edit]

Storage Use Case

  • INTRODUCTION

This document will give a short overview of the wiki(pedia) scenario and discusses some of the requirements in the context of the SELFMAN project.

  • CONTEXT

Wikipedia is a free encyclopedia where any user can edit existing or add new content. The current version is a traditional three-tier application with proxies, application servers and database servers (http://meta.wikimedia.org/wiki/Wikimedia_servers).

For SELFMAN, it can be treated as database-like application with versioning, replication and transactions. Trust management and self-optimization can also easily be integrated.

The wikipedia scenario covers the major topics of SELFMAN and in addition the real data sets are available for testing (http://download.wikipedia.org/backup-index.html) ranging in size from several kilobytes to several gigabytes.

  • AUTONOMIC SCENARIOS
    • Trusted Environment:

Instead of using separate hosts as proxies, application and database servers, each wikipedia server could run one peer of a structured overlay with a database like abstraction which provides the same functionality as the existing software.

The self-* components could autonomously balance the load and adapt system parameters to optimize the performance, e.g. the replication factor. Replica placement is also an issue as the performance can be improved by placing German content on servers in the center of Europe.

    • Untrusted Environment:

The server farm could be replaced by a structured overlay network where the peers run on the computers of the users of wikipedia. In this case self-* components, replication and trust management become more challenging. ...

Running the system in an untrusted environment means that the system has to handle a higher failure rate among nodes. Replication is needed to guarantee availability of the content in case of node failures. However with replication in SONs, keeping replicas in a conistent state becomes more complicated. In fact it is not possible to optimze for high availability, consistency and network partition tolerance at the same time. It has to be investigated to which extent availability should be optimized and which consistency level is sufficient for a wiki scenario.

To provide strong consistency, update operations have to be atomic. We might even do transactions on data. Suppose a user editing some content. The system has to check whether the user had been working on the lastest version at the time he wants to make his changes permanent. It should be ensured that changes made in between don't get lost. Data therefore gets some kind of version tags, and transactional mechanisms ensure that changes made by other users are not overwritten.

Besides regular editing and reading of pages, modern Wikis provide a host of additional features: Support for attachments, user-based access control, storing per-page metadata (author, geographic coordinates etc.), antispam filtering, and several techniques to enhance navigation. These include fulltext searching, backlinks, and page categorization. All navigational features require storing of additional information that must be kept synchronized with page content. For example, to provide backlinks, it is necessary to have an additional reverse index that allows to find all links pointing to a page. Keeping these additional index structures synchronized requires the use of atomic transactions. Without atomicity, it becomes impossible to update page content and index structures consistently.

  • REQUIREMENTS

A distributed database supporting: - versioning - replication - availability - transactions - load balancing

A distributed webserver which accesses the database and renders the web pages.

A distributed trust management component to assess the quality of the contributions of users.

  • CONCLUSION

The main challenge is to build a system based on a SON, which provides the user with an acceptable performance and sufficient data consisteny. Therefore a proper tradeoff between availability, data consistency and network partition tolerance has to be found.

[edit]

Appendices (Publications and Other Documents)

NB: Please be careful: some of these documents are currently unpublished material. Access and diffusion is restricted to Selfman partners.


  • Storage Use Case
  • P2P TV Use Case
  • J2EE Use Case
Retrieved from "https://ist-selfman.org/Application_Requirements"