Provenance Requirements of the e-Demand Project
Authors: Paul Townend, Simon Miles
Project: This work was conducted as part of the PASOA project (EPSRC GR/S67623/01)
Last modified: 2004 November 10
This document describes the provenance-related use cases provided by the e-Demand project. We first describe what the project involves and then enumerate the possibly relevant use cases. We are grateful to Paul Townend for the information below.
Scenario
The potential size and complexity of service-based applications – together with empirical evidence suggesting that complex asynchronous and interacting systems are very prone to errors and failures – means that we cannot expect such applications to be fault-free, no matter how much effort is invested in traditional methods such as fault avoidance and fault removal. In order to minimize the problems caused by the conditions described above, it becomes necessary to investigate the application of fault tolerant techniques for both Grid computing and Web Services. Fault tolerant software allows errors to be detected and logged, without affecting the running of a system, and potentially offers great improvements in dependability over traditional development methods. The design-diversity approach that we are particularly interested in is that of multi-version design (MVD). Traditionally, MVD works by implementing and executing several functionally equivalent systems, and comparing their outputs, with the consensus output being forwarded as the final system result, thus by-passing faults within individual systems; should no consensus be reached, human operators can be alerted to the situation. We have therefore, as part of the e-demand project (http://www.comp.leeds.ac.uk/edemand/ ), constructed an MVD-based fault tolerance scheme that will enable us to take advantage of the service-oriented nature of Grid computing and Web Services whilst also facilitating in the creation of dependable service based applications.
Use Cases
Use of provenance 1: Identifying Common Dependencies
When developing a multi-version fault tolerant system, a major problem is that of common mode failure. This occurs when n/2 + 1 channels within a MVD system fail and pass incorrect, but identical results. This will in many cases cause the voting system to output this as a "correct" result, which is actually worse than outputting no result at all, as at least in such circumstances the system may be brought into a safe state or a human operator informed. With the service-oriented approach, the only information available to a client about a service is its interface, to which the client can send and receive messages. There is currently no information about how a service has achieved what it has achieved, and so no information on its dependencies. For example, three functionally equivalent services may have different implementations but at some stage all use the same other service. An error in this common service would potentially not be detected by the voting system.
We would therefore like to keep a record of the interactions each service has with others as it performs its tasks, so that we can identify common dependencies. The provenance data required for this is the addresses of the invoking and invoked services, and such data must be made available to the rest of the e-Demand architecture.