Located Functions for Distributed Computations Stephen Crouch, Peter Henderson, Robert John Walters University of Southampton, Southampton, United Kingdom,

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