architecture tutorial 1 overview of todays talks provenance data structures recording and querying...

1

Architecture TutorialArchitecture Tutorial

Overview of Today’s Talks

• Provenance Data Structures• Recording and Querying Provenance

– Break (30 minutes)• Distribution and Scalability• Security• Methodology


Process Documentation: Concepts and Data Structuresby Simon Miles ([email protected])

3


Process Documentation

• The provenance of x is the process that led to x.

• How do we find the provenance of x?• Two steps:

1. Document the process in an application2. Retrieve the process that led to X from the

documentation

4


World View

• Every application is made up of actors• Every change that happens is an action by

an actor• Actors communicate by sending

messages.• Every action is triggered by a message• The outputs of (messages sent by) an

actor are caused by the inputs to (messages received by) the actor

5


Interaction in the Organ Transplant Process

Donor DataCollector

Electronic HealthcareRecord System

Request healthcarerecord for patient PID1

6


Request Message Contents

<soap:envelope><soap:header>…</soap:header><soap:body>

<echrs:request> <echrs:patient> PID1

</echrs:patient></echrs:request>

</soap:body></soap:envelope>

7


Identifying a Message

• An interaction is a message being sent by one actor and received by another

• An interaction is identified by the following– The source of the message (startpoint)– The sink of the message (endpoint)– A unique ID that distinguishes between

interactions with the same source and sink

8


Interaction KeyWeb Services:Endpoint Reference

9


Asserting the Content of a Message• In asserting the content of a message it

has sent or received, an actor provides the following:– A unique id for the assertion– The style in which the content is asserted– The content of the message

10


Interaction P-Assertion

11


Request Message Contents

<soap:envelope><soap:header>…</soap:header><soap:body>

<echrs:request> <echrs:patient> PID1

</echrs:patient></echrs:request>

</soap:body></soap:envelope>

12


Styled P-Assertion

<ps:interactionPAssertion> <ps:localPAssertionId>1</ps:localPAssertionId> <ps:documentationStyle> http://www.pasoa.org/.../styles#AnonymisedPatient </ps:documentationStyle> <ps:content> <soap:envelope> <soap:header>…</soap:header> <soap:body> <echrs:request> <echrs:anoymisedPatient> x93ab4 </ echrs:anoymisedPatient> </echrs:request> </soap:body> </soap:envelope> </ps:content></ps:interactionPAssertion>

13


Asserting the State of an Actor

• In asserting its state, an actor provides the following:– A description of part or all of its state– Optionally, the style in which it is asserted– A unique id for the assertion

14


Actor State P-Assertion

15


Example (Donor Data Collector)

<ps:actorStatePAssertion> <ps:localPAssertionId> 2 </ps:localPAssertionId> <ps:content> <donor:dataHeldOn> <echrs:patient> PID5 </echrs:patient> <echrs:patient> PID16 </echrs:patient> … </donor:dataHeldOn> </ps:content></ps:actorStatePAssertion>

16


Data Within Assertions

• Application messages and actor states contain parts, e.g. arguments to operations

• These parts can have independent provenance

17


Another Interaction

Donor DataCollector Testing Lab

Blood Analysis Results

18


Analysis Results Message Contents<soap:envelope> <soap:header>…</soap:header> <soap:body> <testlab:analysisResults> <testlab:sampleID> Sample3

</testlab:sampleID> <testlab:results> negative </

testlab:results> </testlab:analysisResults> </soap:body></soap:envelope>

19


Referring to Data ina P-Assertion<soap:envelope> <soap:header>…</soap:header> <soap:body> <testlab:analysisResults> <testlab:sampleID> Sample3

</testlab:sampleID> <testlab:results> negative </ testlab:results> </testlab:analysisResults> </soap:body></soap:envelope>

20


Pointing to Data Within Assertions

• In order to refer to a part of an assertion’s content, we need to provide the following:– The ID of the assertion– How to access the part within the assertion’s content

21




• In the example, the ID of the assertion is given by:– Interaction Key– View Kind– Local P-Assertion ID

22




• In the example, the ID of the assertion is given by:– Interaction Key– View Kind– Local P-Assertion ID

• The data part is given by a data accessor, such as an XPath expression:– / soap:envelope / soap:body /

testlab:analysisResults / testlab:sampleID

23


Related Interactions

Donor DataCollector User Interface

Blood Analysis Results

Electronic Healthcare Record

OrganDonationDecision

24


Functional View of Decision

<donor:decision> fit for donation </donor:decision>

DiagnosePotential

Organ

Decision

<testlab:results> negative </ testlab:results>

Lab Results<echrs:record> … </ echrs:record>

Healthcare Record

25




DiagnosePotentialOrgan

Decision



Healthcare Record

Parameter Names

26




DiagnosePotential

Organ

Decision



Healthcare Record

Subject

Relation

Object Object

27


RelationshipP-Assertion

28


Sharing Context

• To connect assertions made by different actors some information must be shared.

• For example:– A sender & receiver in an interaction need to

use the same interaction key.– An actor might like to inform other actors as to

which provenance store it used to store assertions.

– Messages can be marked as being part of the same process.

29


Demarcating Processes

Testing Lab

Donor DataCollector

User Interface

Testing Lab

Donor DataCollector

User Interface

Run 1 Run 2

30


Demarcating Processes

Testing Lab

Donor DataCollector

User Interface

Testing Lab

Donor DataCollector

User Interface

Run 1 Run 2

Tracers

31


Tracers

• Tracers are added by an originating actor• Tracers are passed between actors if the

messages are part of the same process

32


Interaction Context

• States some metadata about an interaction.

• It contains:– An interaction key for that interaction– And interaction metadata.– Examples of such metadata are:

• Tracers• References to provenance stores that contain

assertions about the interaction.

33


P-Header

• Interaction Contexts can be transferred in P-Headers.

• P-Headers are additional provenance specific information added to existing application messages.

• P-Headers can also be used to assign an interaction key to the message that its sent in.

34


P-Header

35


Message with P-Header<soap:envelope> <soap:header> <pHeader> <interactionKey> <messageSource> …Donor Data Collector… </messageSource> <messageSink> … Testing Lab … </messageSink> <interactionId> 345 </interactionId> </interactionKey> <interactionMetaData> <link> http://DDC.provenance.store </link> <tracer> http://process/9467 </tracer> </interactionMetaData> </pHeader> </soap:header> <soap:body> …</soap:body></soap:envelope>

36


Summary

• Our data structures allow assertions about past processes to be succinctly and exactly specified

• Interaction and actor state p-assertions can be styled, so that what is asserted differs from that which actually occurred in a well-specified way

• Relationship p-assertions express functions between wholes or parts of p-assertions

• Actors share context to ensure that consistent identifiers are used throughout documentation

• Context can include process identifiers, called tracers

37


Questions?

Simon [email protected]

architecture tutorial 1 overview of todays talks provenance data structures recording and querying...

Documents