Date post: | 19-Jan-2018 |
Category: |
Documents |
Upload: | anastasia-webster |
View: | 218 times |
Download: | 0 times |
1
Architecture TutorialArchitecture Tutorial
Overview of Today’s Talks
• Provenance Data Structures• Recording and Querying Provenance
– Break (30 minutes)• Distribution and Scalability• Security• Methodology
Architecture TutorialArchitecture Tutorial
Process Documentation: Concepts and Data Structuresby Simon Miles ([email protected])
3
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
Interaction in the Organ Transplant Process
Donor DataCollector
Electronic HealthcareRecord System
Request healthcarerecord for patient PID1
6
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
Interaction KeyWeb Services:Endpoint Reference
9
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
Interaction P-Assertion
11
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
Actor State P-Assertion
15
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
Data Within Assertions
• Application messages and actor states contain parts, e.g. arguments to operations
• These parts can have independent provenance
17
Architecture TutorialArchitecture Tutorial
Another Interaction
Donor DataCollector Testing Lab
Blood Analysis Results
18
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
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
• In the example, the ID of the assertion is given by:– Interaction Key– View Kind– Local P-Assertion ID
22
Architecture TutorialArchitecture Tutorial
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
• 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
Architecture TutorialArchitecture Tutorial
Related Interactions
Donor DataCollector User Interface
Blood Analysis Results
Electronic Healthcare Record
OrganDonationDecision
24
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
Functional View of Decision
<donor:decision> fit for donation </donor:decision>
DiagnosePotentialOrgan
Decision
<testlab:results> negative </ testlab:results>
Lab Results<echrs:record> … </ echrs:record>
Healthcare Record
Parameter Names
26
Architecture TutorialArchitecture Tutorial
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
Subject
Relation
Object Object
27
Architecture TutorialArchitecture Tutorial
RelationshipP-Assertion
28
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
Demarcating Processes
Testing Lab
Donor DataCollector
User Interface
Testing Lab
Donor DataCollector
User Interface
Run 1 Run 2
30
Architecture TutorialArchitecture Tutorial
Demarcating Processes
Testing Lab
Donor DataCollector
User Interface
Testing Lab
Donor DataCollector
User Interface
Run 1 Run 2
Tracers
31
Architecture TutorialArchitecture Tutorial
Tracers
• Tracers are added by an originating actor• Tracers are passed between actors if the
messages are part of the same process
32
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
P-Header
35
Architecture TutorialArchitecture Tutorial
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
Architecture TutorialArchitecture Tutorial
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