Use Case Hidden Bug

From XG Provenance Wiki
Jump to: navigation, search

Owner

Simon Miles

Provenance Dimensions

  • Primary: Debugging (Use)
  • Secondary: Process (Content), Imperfections (Use)

Background and Current Practice

This use case is taken from the following paper: The Requirements of Using Provenance in e-Science Experiments, and comes from interviews with Paul Townend in the context of the e-Demand project, which attempted to make service-oriented grids more reliable. Please see the paper for more background details.

Goal

Determine whether apparently consistent results from apparently independent sources are in fact due to ultimate dependence on a single faulty source.

Knowing the provenance of results can allow us to detect common originators of information, essential in debugging as this would imply a single point of failure.

Use Case Scenario

User A asks the same question of two apparently independent sources, B and C. They each reply with the same answer, leading A to believe that answer to be correct. However, A then determines where B and C got their information from, and it turns out to be D in both cases. A should check whether D is faulty, possibly by finding a truly independent source to compare with.

In the original case study, the sources are services, remotely and independently administered. As the services are described purely by their interfaces, there is no pre-provided way to determine that B and C depend on D.

Problems and Limitations

If there is no record of the operation of B or C in answering a particular question, then we cannot later know whether they both relied on the same ultimate potentially faulty source. Service interfaces do not describe such information, and it may not be static: i.e. B may only rely on D for answering that particular question, not in general.

Technical Challenges:

  • Representing the full record of how one actor depended on another
  • Determining where there was a single point of failure (source of incorrect information) in a process