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