Caching OGSI Grid Service Data to Allow Disconnected State Retrieval Alastair Hampshire University of Nottingham

Overview Motivation: –Why would intermittently connected devices use the grid? The problem: –Lack of support in OGSI for intermittent network connectivity. A set of recommendations –Using caching to improve access to the state of intermittently connected services Conclusion

Intermittently Connected Devices on the Grid Rationale: –Allows devices to exploit a wealth of grid service functionality, e.g. for data processing and archival Intermittently Connected Sensors –Mobile Sensors: –E.g. Wearable Medical Sensing –Remote Sensors: –E.g. Antarctic Sensing Probe Ubiquitous Computing

The MIAS-Equator Toolkit Aims –Explore the extent to which the grid could be used to support mobile sensing devices Prototype Toolkit –MIAS-Equator toolkit: toolkit designed to expose sensing devices as grid services Deployment and Trials –Wearable Medical Sensing Device –Antarctic Sensing Probe Partners: - EQUATOR eScience programme in collaboration with MIAS IRC.

Lack of Support in OGSI for Intermittent Network Connectivity Invocations failure –Extended network disconnections cause grid service invocation failure Failed Service Data Requests –Best case: delayed data retrieval –Worst case: data loss

Approach Caching Grid Service Data (SD) –Allow access to the SD of a temporarily disconnected service –Allow access SD from a temporarily disconnected client Improved access to SD in intermittently connected network environments

Caching OGSI Service Data OGSI findServiceData requests allow easy identification of SD requests SD marked as static or constant does not change for the lifetime of the service and is therefore ideal for caching Paper covers recommendations for: –Which SD to cache? –How to populate the SD cache? –How to check the consistency of the cache?

Which SD to cache? Caching all SD would be excessive Strategies: –Client selects which SD to cache –Service selects which SD to cache –Notification request triggers SD caching –SD request triggers SD cache

How to populate the SD cache? Approaches to populating the cache –Speculative Caching A cache retains a copy of the response from all successful find SD requests –Proactive A cache actively maintains any up-to-date copy of cacheable SD elements

Checking the cache consistency Difficult to monitor changes to SD –Internal factors may effect the service state Static of Constant SD never changes and need not be updated Extendable or mutable SD: –Cache SD elements alongside a timestamp –When a cached item is retrieved, calculate the age: items under a given age a considered valid Cache validity determined by: –The client –The cache

Conclusions Demonstrated a requirement for the grid to better support intermittently connected devices –E.g. mobile or remote sensing devices Demonstrated how OGSI does not adequately support intermittently connected devices. Proposed caching as a mechanism to improve access to the state (service data) of intermittently connected devices Provided a set of recommendations for the use of cache in OGSI to support disconnected state retrieval

Questions?