Located Functions for Distributed Computations Stephen Crouch, Peter Henderson, Robert John Walters...
-
date post
19-Dec-2015 -
Category
Documents
-
view
218 -
download
0
Transcript of Located Functions for Distributed Computations Stephen Crouch, Peter Henderson, Robert John Walters...
Located Functions for Distributed ComputationsStephen Crouch,
Peter Henderson, Robert John Walters
University of Southampton, Southampton, United Kingdom, SO17 1BJ{stc,ph,rjw1}@ecs.soton.ac.uk
Popular approaches abstract away location • (GRID) Users are discouraged from considering
location
• Exemplified by Web Services
• Attention is concentrated on the meaning of computation (calculations)
But,
• Locations cannot be ignored
• They have to be considered if computations are to be performed efficiently and reliably
• A suitable notation is required for describing and reasoning about them
Consider a simple GRID task
• Data extracted from a database (and processed)
• More data extracted from another (and processed)
• Results of both operations are combined
• Final processing and formatting for presentation
Might look like this
Process Data &Visualise
Process Data &Visualise
Database1
Database1
Database2
Database2
DatabaseService 1DatabaseService 1
DatabaseService 2DatabaseService 2
Query
Query
Results
Results
Result
Process Data &Visualise
Process Data &Visualise
Database1
Database2
DatabaseService 1
DatabaseService 1
DatabaseService 2
DatabaseService 2
Query
Query
Results
Results
ResultProcess Data &
Visualise
Process Data &Visualise
Database1
Database2
DatabaseService 1
DatabaseService 1
DatabaseService 2
DatabaseService 2
Query
Query
Results
Results
Result
Could be abstracted to:
Useful for reasoning about meaning and getting the right result
3121 ,,, DDhDDgf
Issues for realisation
• Data may be available from multiple locations
• Processing may be available in many places
• Factors: speed, bandwidth, reliability, security, cost…
• When one dataset is huge, it may make sense to move many others
• Exploiting useful/necessary processing power may also involve apparently unnecessary relocations of data
• Choices have to be made but the abstract description devoid of locations doesn’t help…
Our proposition,
• “Decorate” abstract description with locations
• A natural way to specify where data comes from, and where it is processed
• Implications of location decisions easy to understand and quantify
The notation:
• Add locations to names of data and processes of the abstract notation
• List alternatives where they exist
• Use _ for unknowns or “don’t care”
In the example:
• Data D1 is at location 1, D2 is at 2 …
• Can do f anywhere, g must happen at 2
• Process h can be executed at 1 or 2
3121 :3,:1:2/1,:2,:1:2:_ DDhDDgf
Making decisions
• Where to get the data (and where to put it)
• Where to do the processing
• Processing has to be co-located with the Data it uses
• Implication of choices is evident from the notation
Process Data &Visualise
Process Data &Visualise
Database1
Database2
DatabaseService 1
DatabaseService 1
DatabaseService 2
DatabaseService 2
Query
Query
Results
Results
ResultProcess Data &
Visualise
Process Data &Visualise
Database1
Database2
DatabaseService 1
DatabaseService 1
DatabaseService 2
DatabaseService 2
Query
Query
Results
Results
Result 3121 :3,:1:2/1,:2,:1:2:_ DDhDDgf