Remote Data Access in Distributed ObjectOriented Middleware

1
Remote Data Access in Distributed Object-Oriented
Middleware

• Heath James,
• Distributed and High Performance Computing Group
• The University of Adelaide

2
The story so far

• Middleware
• The software layer that provides abstraction over
  heterogeneous processors and networks
• A Research problem
• Providing mobile pointers, or tokens, to code and
  data to enable adaptive execution of programs

3
Problems with existing technologies

• RPC-style comms only good for local-area
  computing with definite end-points
• not so good for wide-area, high latency
• not easily adaptive to changing env
• global pointers tied to architectures and
  run-time systems
• low-level, mobile, short-lived entities

4
Environment model

• queries are composed of high-level operations (or
  services) on data
• network flow model of computation
• schedule created by local machine
• schedule distributed to participants
• data and byte code may be movable
• data and byte code uniquely named
• data is single assignment

5
An example query
6
Our solution

• DISCWorld Remote Access Mechanism (DRAM)
• A rich remote pointer (or a data proxy)
• points to some data (DRAMD) or byte code (DRAMS)
  stored remotely or locally
• contains metadata on the object
• Lightweight in comparison to expected data sizes

7
Operations on DRAMs

• createDRAM()
• create a DRAM from data or service
• copyDRAM()
• create a clone of a DRAM
• moveDRAM()
• send a DRAM to another client or server
• dereferenceDRAM()
• retrieve the object that the DRAM points to

8
(No Transcript)
9
Result-push execution

• DRAMD DRAMS and operations are sufficient for
  result-push
• Great for systems with perfect global state
  information
• Difficult to implement adaptive execution
• data movements are pre-defined
• no scope for optimization of data transfer

10
Partial Global State Information
11
Result-pull execution

• Heuristically decide where to get required data
  from
• Great for systems with partial global state
  information
• Possible reduction of system load by pruning
  query execution tree

12
Our solution .. 2

• DRAM Futures (DRAMFs)
• pointers to yet-to-be-created data
• metadata
• estimated object size
• ETA
• semantically the same as DRAMSs and DRAMDs

13
DRAMs and DISCWorld

• DISCWorld is a experimental testbed for ideas
• DRAMs need the DISCWorld architecture to work
• Global object naming
• Single assignment
• A high-level (network flow oriented) placement
  language

14
DISCWorld daemon (DWd) architecture
15
Benefits of using DISCWorld

• DWd caches all DRAMs
• DRAMs outlive the instance of the DWd
• safe in light of daemon crashes
• dangling pointers avoided
• recipe for construction included in the DRAM

16
Future work

• Better methods to estimate DRAMF object size and
  ETA
• Better system measurement techniques
• Better query specification and placement language

17
Conclusion

• DRAMs provide lightweight, rich pointers to
  existing or future data (and services)
• Can be used to implement result-pull adaptive
  execution scheduling
• Implemented as part of the prototype DISCWorld
  system