there is a need to capture extra information, or process documentation, describing what actually occurred at execution ^M1 time. Process documentation is to electronic data _{Relationship M2} what a record of owner- ^p-assertions ship is to a work of art.

Provenance-aware applications create process documentation and store it in a provenance store offering long-term persistent, secure storage of process documentation (see Figure 1). This role accommodates a variety of physical deployments; for instance, a provenance store can be a single, autonomous service or (to be more scalable) a federation of distributed stores.

When process documentation is recorded, the provenance of data results can be retrieved by querying the provenance store and analyzed to suit the user’s needs. The provenance store and its contents might also need to be managed, maintained, or curated.

I received M1, M4 I sent M2, M3

Interaction p-assertions

computational

:

service

M: message f : function

M3 = f1(M1)

M2 = f2(M1,M4)

M2 is in reply to M1

of p-assertions we expect applications to adopt in order to document their execution. Figure 2 out- _M3 lines a computational ^f1 service sending and ^{f2 M4} Service state receiving messages and ^p-assertions creating p-assertions that describe its involvement in such activity.

In SOAs, interactions consist of messages exchanged between services. By capturing all interactions, one can ana-

lyze an execution and verify its validity or compare it with other executions. Therefore, process documentation includes interaction p-assertions, or descriptions of the contents of a message by a service that has sent or received it.

Whether a service returns a result directly or calls

I received M1 at time t I used algorithm x.y.z

Figure 2. Categories of p-assertions made by a computational service.

Data collection request 11 Blood test request 12 ¹³ Brain death notif ¹⁸ Decision request

Decision + justification 19

Donor data request

14

Donor data 15

16 Blood test request

OPEN MODEL FOR PROCESS

DOCUMENTATION

Process documentation for many applications cannot be produced in a single, atomic

User X

burst but must be interleaved ^{Is logged} continuously with execution.

This makes it necessary for designers to be able to distinguish a specific item documenting part of a process from the whole process of documenta-

User X

tion. We view the former—a p- Is logged assertion—as an assertion made by an individual application service involved in the process. ^{Figure 3. Provenance} Thus, the documentation of a ^{directed acyclic graph of} _{a donation decision.} process consists of a set of p-assertions made by the services involved in the process.

In order to minimize its effect on application performance, documentation must be structured so it can be constructed and recorded autonomously by services on a piecemeal basis. Otherwise, should synchronization be required among these services to agree on how and where to document execution, application performance might suffer dramatically. To satisfy this design requirement, we’ve identified various kinds

17 Blood test result

patient ^{User X} Brain Death ^{Is logged} Notification

13

Is based on

p-assertions

service state relationship

19 interaction

Data

Collection Is caused by Request ₁₁

Donor Data Is response to Donor Request ₁₄ Data ₁₅

Is based on

Decision Request 18

Is response to

Donation

Decision 19

Is caused by Is justified by

Is based on

Blood Test Is caused by Request ₁₂

Blood _Blood Test Is response to _Test Request 16 Result 17

Justification Report 19

User Y Is logged

User Y Is logged

 

other services, the relationship between its outputs and inputs is not generally explicitly represented in the messages themselves but is understood through analysis of the service’s business logic. To promote openness and generality, we make no assumptions about the technology (such as source code and workflow language) used by services to implement their business logic. Rather, we require services to provide information in the form of relationship p-assertions, or descriptions asserted by a service as to how it obtained output data sent in an interaction by applying some function or algorithm to input data from other interactions. (In Figure 2, output message M3