Changes between Initial Version and Version 1 of Ticket #1557


Ignore:
Timestamp:
Mar 24, 2008 1:06:26 PM (6 years ago)
Author:
agocorona
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1557 – Description

    initial v1  
    11Dynamic optimization of CPU and bandwidth resources in a network of nodes. 
    22Components: 
    3    - remote eval, remote fork and optionally "moveTo" primitives 
    4    - service/node discovery 
    5    - distribution & syncronization of data: "split" and "merge" primitives 
    6    - information exchange over "intelligent" channels that memorize bandwith usage and bandwith limits 
    7    - The presentation, processing and data storage exchange data trough these intelligent channels 
    8    - Configurable rules that relocate process and storage depending on the CPU and bandwith usage of their channels. 
     3   1 1st phase: remote install, 2nd phase: Remote eval, remote fork and optionally "moveTo" primitives 
     4   2 service/node discovery 
     5   3 distribution & syncronization of data: "split", "clone" and "merge" primitives 
     6   4 information exchange over "intelligent" channels that memorize bandwith usage and bandwith limits so they can detect bottlenecks. 
     7   5 The presentation, processing and data storage exchange of data is made trough these intelligent channels 
     8   6 Configurable rules that relocate and/or clone process and storage depending on the CPU and bandwith usage of their channels. 
    99 
    10 This could solve a number of different computation problems: 
    11    - automatic optimization of process & data clustering in a network of nodes 
    12    - dymamic relocation of the three tiers in a single node when in stand alone mode 
     10This could solve a number of different system architecture problems that are related with the lack of knowledge of resources at design /installation time: The goal is to allow the application architecture to be defined at runtime:  
     11   -  A Web/client-server application can become local 
     12   -  Remote data access can become local + syncronized 
     13   -  Dymamic relocation of the three tiers in a single node when in stand alone mode,  
     14   -  Expansion when available nodes. 
    1315 
     16Haskell allow for definitions of type classes with default definitions for complex primitives like, for example, synchronization. At the same time it is flexible enough to define when syncronization scenarios are permitted or not, so that automatic or semiatomatic rules can be applied depending on the nature of the data and the  application specification. It is also possible to define clear interfaces for stateless, data storage and stateful processes, the latter one considered as a stateless + a data storage process. 
    1417 
    15 mHaskell may be a good start (http://www.macs.hw.ac.uk/~dubois/mhaskell/)  
     18Some implementations of distributed haskell define some primitives that fill the functionalities 1 and 2. 
     19 
     20mHaskell is the most complete and may be a good start (http://www.macs.hw.ac.uk/~dubois/mhaskell/)