State Space

The state space of the ASM is shown in Figure 4.11. We model a distributed system as a set of actors, A, communicating via asynchronous message passing over a set of

communication channels,K. We identify specific subsets of actors in the system, namely, senders, receivers and provenance stores. An actor may be a member of all these subsets. These subsets map to roles defined previously.

Communication channels are assumed to be reliable and secure, and not to duplicate messages. No assumption is made about message order in the channel (i.e. sending mes- sage A before sending message B does not guarantee that A will arrive at its destination before B). Because of this assumption, channels are represented as bags of messages between pairs of actors. The messages listed in Figure 4.10 are sent over these com- munication channels and are formally defined as an inductive type producing setMin Figure 4.11.

Having defined the state space for communication between actors, we now model it for the internal functionality of each actor role.

Provenance Store State Space Informally, we can see a provenance store as an actor containing a table that maps interaction keys and a role identifier to a set of identi- fied messages. This models the Views within a provenance store (V). An interaction key (κ) together with a role identifier (v) and set of identified messages is labelled a View. In Figure4.11, the table (store T) is defined as a function that takes an interaction key and role identifier and returns a triple containing a submission finished message, several record messages and some local p-assertion ids. We use the power set notation (P) to

denote that there can be more than one of a given element. We define the set of prove- nance stores, P SS, as a mapping from an actor identity to a set of Views. Since each set of Views can be located at a different actor, our model allows for multiple prove- nance stores; practically, this allows process documentation to be located in multiple institutions.

Sender and Receiver State Space Now, we define the state space of sending and receiving actors in Figure 4.11. This state space describes the various tables that these actors use to keep track of the messages they need to send to the provenance store

(TO SEND), the messages they have sent to it (SENT) and the acknowledgements

Chapter 4 Recording Process Documentation 87

A = {a1, a2, . . . , an} (Set of Actor Identities)

Senders ⊆ A (Set of Sender Identities)

Receivers ⊆ A (Set of Receivers Identities)

PS ⊆ A (Set of Provenance Store Identities)

REL = {r1, r2, . . . , rn} (Set of Business Logic Descriptions)

P-Assertion = {α1, α2, . . .} (Set of P-Assertions)

M = app:IK×Data→ M (Set of Messages)

| rec:IK×RI×A×LPID×P-Assertion→ M | sf:IK×RI×A×LPID×N+→ M

| ack:IK×RI×LPID→ M

SF = {m∈ M |m=sf(κ, v, ι, na)} (Set of Submission Finished Messages)

R = {m∈ M |m=rec(κ, v, ι, lpid, α)} (Set of Record Messages)

IK = Senders×Receivers×N (Set of Interaction Keys)

RI = {S,R} (Set of Role Identifiers)

V = IK×RI→SF⊥×P(R)×P(LPID) (Set of Views)

PSS = A→V (Set of Provenance Stores)

TO SEND = A→IK→Bag(M) (Set of Messages To Send Tables)

SENT = A→IK→Bag(M) (Set of Sent Messages Tables)

ACK = A→IK→Bag(M) (Set of Acknowledged Messages Tables)

ASSERT = A→IK×RI→Bag(P-Assertions) (Set of p-assertions to be recorded)

LPID MAP = A→IK×RI→P(LPID) (Map from actor to

local p-assertion ids)

LC = Senders→N (Set of Local Counters)

K = A×A→Bag(M) (Set of Channels)

C = PSS× K ×TO SEND×SENT×

ACK×ASSERT×LPID MAP×LC (Set of Configurations)

Characteristic Variables: a ∈ A as ∈ Sender ar ∈ Receiver aps ∈ PS r ∈ REL m ∈ M d ∈ Data α ∈ P-Assertion κ ∈ IK v ∈ RI na ∈ N+ lpid ∈ LPID k ∈ K lpids ∈ P(LPID) recs ∈ _P(R) store T ∈ PSS to send T ∈ TO SEND sent T ∈ SENT ack T ∈ ACK assert T ∈ ASSERT

lpid T ∈ LPID MAP

lc ∈ LC

c ∈ C Initial State / Configuration:

ci=hstore Ti, ki, to send Ti, sent Ti, ack Ti, assert Ti, lpid Ti, lcii

where:

store Ti = λaλκv· h⊥,∅,∅i, ki = λaiaj· ∅,

to send Ti = λaiκi· ∅, sent Ti = λaiiki· ∅,

ack Ti = λaiiki· ∅, assert Ti = λaiκivi· ∅,

lpid Ti = λaiκivi· ∅, lci = λai·0 Figure 4.11: State Space

Chapter 4 Recording Process Documentation 88

sender or receiver need to record in a provenance store (ASSERT) and how an actor

keeps track of the local p-assertion ids it has already used (LPID MAP). Finally, each

sending actor has a local counter (LC) used to create interaction keys.

The state space that we have described may appear to be global in Figure4.11. However, each table for a sender or receiver is indexed by an actor identity (A) and can be

implemented with updates that are local to actors. Hence, the protocol does not require any global knowledge by actors of other actors’ state.

For convenience, we define two accessor functions. The accessor function to access the state of the View is defined as follows:

Ifstore T(a)(κ, v) =hsf, recs, lpidsi then

store T(a)(κ, v).sf=sf,

store T(a)(κ, v).recs=recs, store T(a)(κ, v).lpids=lpids

The function takes an actor identity, interaction key, and role identifier as input and returns a View. From the View, its contents such as record messages, local p-assertion ids and submission finished message can be retrieved. The inputs of the function act as a key to an index of Views within provenance stores.

We also define a function for accessing the state of a submission finished message. The function is defined as follows:

Ifsf =sf(κ, v, a, `, na) then sf.κ=κ, sf.v =v, sf.a=a, sf.`=`, sf.na=na

This function just provides an easier notation for addressing the various contents of the submission finished message. This is helpful in the rules where the completeness of a View is checked.

Having described the state space of our ASM, a state (or configuration) of the machine is described in Figure 4.11. The machine’s initial state can be summarised as

• empty interaction record stores,

• empty communication channels,

• all sending and receiving actors having empty p-assertion and message tables,

Chapter 4 Recording Process Documentation 89

The machine proceeds from this initial state through its execution by going through

transitions that lead to new states. These transitions are defined by the rules of the state machine discussed in the next section.

When describing the execution of a state machine, we use the following notation and definitions.

• A transition is the application of a rule to one configuration to achieve another configuration.

• A reachable configuration is a configuration of the ASM that can be reached by transitions from the initial configuration.

• 7−→denotes a transition.

• c 7−→∗ c0 denotes any number of transitions from a configuration c to another configurationc0.

We now discuss the specific rules of the ASM.