Positron: Composing Commitment-Based Protocols

Abstract

We understand a sociotechnical system (STS) as a microsociety in which social entities interact about and via technical entities. A protocol specifies an STS by describing how its members collaborate by giving meaning to their interactions. We restrict ourselves to protocols that specify messages between roles in terms of how they create and affect commitments among the roles. A key idea of our approach, Positron, is that a protocol specifies the accountability of one role to another in addition to the requirements from each role. Specifically, Positron incorporates role accountability and role requirements as two integral aspects of protocol composition. In this way, it seeks to promote collaboration in STSs through natural requirements elicitation; flexibility enactment; and compliance and validation (ascribing accountability for each requirement to a specific role). Positron maps composite protocols to the representations of a well-known model checker as a way to verify protocols to assist in their correct formulation. We evaluate Positron by demonstrating it on real-life protocols.

1 Introduction

We study sociotechnical systems (STSs) wherein autonomous parties interact about and through technical entities [29]. STSs arise in a variety of collaborative settings, including cross-organizational service engagements. A protocol specifies an STS in abstract terms by describing two or more roles and the messages those roles may exchange along with meanings of those messages [7]. Protocols arise commonly in business, e.g., RosettaNet [25], and healthcare, e.g., HL7 [16]. By bringing forth collaboration requirements, protocols separate implementations from interactions, thereby promoting the flexibility of autonomous collaborators, such as is needed in sociotechnical systems.

Existing protocol approaches [16, 25], however, standardize the message formats and operational constraints, but not the meanings of those messages, which are left informally stated. The past several years have seen the development of approaches that apply commitments [26] to specify the meanings of the messages in a protocol [3, 34], where protocol designers define meanings. The commitment-based approaches help deal with the autonomy and heterogeneity of participants and promote flexibility in interactions. The benefits of commitments for modeling service engagements are well established. For example, Telang and Singh [30] demonstrated an error in a published RosettaNet guideline when modeled using commitments. Therefore, for brevity, we do not review the extensive literature on commitments here. Singh [28] provides a conceptual summary.

Challenge: Composition. Composition is a key construct in software engineering as a way to promote reuse and modularity. Existing approaches for protocols, whether operational or commitment-based, do not adequately support their composition, because they incorporate internal details or lack a formal semantics of interactions. Existing approaches, e.g., HL7 [16] and RosettaNet [25], provide atomic two-party protocols with the intent for them to be composed but do not support the composition as such and do not provide a construct by which two or more protocols could be composed. Thus the separation of interaction and implementation fails above the level of the atomic (predefined) protocols. Section 5 reviews the literature in detail. Suffice it to state here that previous relevant research falls into these categories: (a) composition but no commitments [22, 27]; (b) commitments but no composition [14]; and (c) composition and commitments. The last subcategory can be further refined as (c1) purely abstract description without a specification language or tools [19]; (c2) composition of commitment-based protocols based on axioms [9, 11] or regulative constraints [4] but without producing a composite protocol for further reuse and composition; and (c3) our present approach to composition of commitment-based protocols based on role responsibilities and accountabilities.

Motivating Research Questions and Contributions. How can we (1) formalize accountability, a crucial element of secure collaboration, as a basis for formal modeling and verification of STSs and (2) support composition of protocols to specify STSs? We address this question by restricting ourselves to composition and verification of commitment protocols, deferring representing other normative relationships [29] and their mapping to agent decision-making to future work.

Specifically, we propose Positron, a language and verification approach that supports composing commitment-based protocols and formally reasoning about them to verify desired properties. Positron (a) introduces role requirements, which capture a role’s motivation, and role accountability, which captures the commitments a role makes to other creditor roles (that benefit from those commitments) as elements of a composite protocol specification; (b) shows how to recursively expand nested constituent protocols; (c) supports a methodology for composing commitment protocols; and (d) provides a decision procedure and mechanical verification of protocols with respect to role requirements, role accountabilities, and enactments. Positron compiles protocol specifications into MCMAS [17] models and checks protocols against temporal logic formulas. It then employs the MCMAS model checker to verify if the composite protocol satisfies those temporal formulas. The Positron verifier builds upon the Proton [14], verifier for commitment protocol refinement, expanding it to tackle protocol composition.

2 Background and Motivation

We write $\mathsf {C}_{\{\text {debtors}\}, \{\text {creditors}\}}\text {(}antecedent, consequent\text {)}$ [14] to denote a commitment from the specified debtors to the specified creditors that if the antecedent begins to hold, the debtors will bring about the consequent. The antecedent and consequent are Boolean expressions. For example, denotes that PolicyHolder (PH) commits to CallCenter (CC) and Repairer (Re) that he will deliver his car to Repairer whenever requested and the repair request is approved.

When the antecedent becomes true, the commitment is detached, and the debtors become unconditionally committed to the creditors. When the consequent becomes true, the commitment is discharged. Debtors should discharge their detached commitments. However, debtors are autonomous and may violate a commitment, for simplicity, by canceling it. The only computational requirement for commitments is: each detached commitment must eventually be discharged (satisfied, delegate, assigned, or released) or canceled. A commitment imposes no ordering constraint between the antecedent and consequent, although in specific settings there may be a practical constraint.

Running Example: AGFIL. The following real-life case involves automobile insurance claims processing for AGF Irish Life Holding (AGFIL) [5], as Fig. 1 summarizes. This case involves four parties plus PolicyHolder and Adjuster (not shown). AGFIL underwrites automobile insurance policies and covers losses incurred by policy holders. Europ Assist (EA) provides a 24-h help-line service for receiving claims. Approved Repairers provide repair services. Lee Consulting Services (Lee) coordinates with AGFIL, repairers, and adjusters to handle a claim.

Fig. 1.

Traditional process model of cross-organizational insurance claim processing [5].

Figure 1 describes the workflows of each participant along with how they relate to one another. Notwithstanding that one could adopt a standard process notation, the main point is that such a description tightly couples the inner workings of the participants. Conventional protocol approaches [16, 25, 32] deemphasize the inner workings and capture the interactions between the participants via a formal notation in terms of constraints on the ordering of the messages exchanged between the participants.

In contrast, a commitment protocol emphasizes the social state of an interaction, expressed in terms of commitments. A commitment protocol describes the roles involved, the messages they exchange, and any preconditions and effects of the messages on the social state. An agent adopts a role and enacts the specified protocol by autonomously choosing (in accordance with its internal policies) how to interact.

3 Technical Approach

Positron provides a formal language in which to express composite protocols based on existing constituent protocols. Positron is a Java application that reads protocols described in the Positron language (examples shown in Listings 1 and 2), flattens any hierarchically nested protocols, and generates input to the MCMAS model checker.

Recall that Proton [14] provides a language for capturing roles, propositions, commitments, and messages. Positron augments the Proton language by adding constructs to define a composite protocol using a set of parameterized constituent protocols and defines a protocol composition methodology.

Further, while it accepts and verifies any CTL expression, Positron introduces five constructs for common verification patterns when composing protocols: Function Req for role requirements, coupling commitments for role accountabilities, and three path expressions for good and bad enactments.

Definition 1

A Positron protocol is a six-tuple of $\mathcal {P}^{\mathsf {R}}$, a set of $\textit{role}$ names; $\mathcal {P}^{\mathsf {P}}$, a set of role-qualified propositions; $\mathcal {P}^{\mathsf {C}}$, a set of commitments; $\mathcal {P}^{\mathsf {M}}$, a set of guarded messages; $\mathcal {P}^{\mathsf {F}}$, a set of CTL expressions to be verified; and $\mathcal {P}^{\mathsf {U}}$, a set of use (include) statements.

For brevity, we omit the Positron grammar in favor of examples. Listing 1 specifies AGFIL’s Claim Handling protocol as roles (insured and claims handler), propositions, commitments, and messages (with their guards and effects on the propositions).

Listing 2 describes the AGFIL composite protocol. In the statement beginning on Line 4, this protocol uses the Claims protocol in Listing 1, mapping roles and propositions in protocol AGFIL to equivalent versions in protocol Claims. We omit the other constituent protocols for space. It turns out that the AGFIL protocol has no additional messages since all its messages derive from its constituents. The AGFIL protocol includes formulas describing the correctness requirements.

Definition 2

An MCMAS representation is a tuple of ${\mathcal {M}^{\textit{agent}}}$, a set of agent names, including a distinguished agent $\mathsf {Env}$ representing the environment; ${\mathcal {M}^{\textit{state}}}$, a set of agent-qualified variable names; ${\mathcal {M}^{\textit{msg}}}$, a set of agent-qualified guarded transition functions; ${\mathcal {M}^{\textit{evol}}}$, a set of agent-qualified evolution expressions; ${\mathcal {M}^{\textit{init}}}$, a set of agent-qualified variable initializations; ${\mathcal {M}^{\textit{eval}}}$, a mapping from propositions to expressions over variables in ${\mathcal {M}^{\textit{state}}}$; ${\mathcal {M}^{\textit{fair}}}$, a set of fairness expressions; and ${\mathcal {M}^{\textit{ctl}}}$, a set of CTL expressions to be verified.

Protocol Composition. Positron supports nested composition of protocols. A composite protocol $P$ can use (include) a parameterized constituent protocol with a use statement $q: Q(\overline{x}= {\overline{p}})$ specifying protocol name ($q$), protocol type ($Q$), a set of arguments ${\overline{p}}$ passed by a composite protocol P, and a matching set of parameters $\overline{x}$ accepted by constituent $Q$. Arguments and parameters are named and have a type of either role or proposition. The argument and parameter sets must contain matching names and types. Positron expands any hierarchical nesting in $P$ to produce a single, flat protocol $P'$. Expansion gives every element in $Q$ a new, unique name, and replaces each parameter with its corresponding argument. Unique names are constructed by prepending the constituent name $q$ to each element name in $Q$. Positron supports using multiple copies or instances of the same constituent $Q$ by using distinct names $q$ and $q'$.

Definition 3

Given a set of arguments ${\overline{p}}$, a parameterized constituent protocol type $Q$ accepts a set of parameters $\overline{x}$, where the sets ${\overline{p}}$ and $\overline{x}$ agree in both name and type. Define ${Q^{\overline{x}}_{{\overline{p}}}}$ as $Q$ in which all elements in $Q$ are given unique names, and every parameter in $\overline{x}$ is replaced with its corresponding argument in ${\overline{p}}$.

Expanding a composite $P$ containing a constituent $q: Q(\overline{x}= {\overline{p}})$ yields the union of $P$ and ${Q^{\overline{x}}_{{\overline{p}}}}$, and removing $P$’s use statement $q: Q(\overline{x}= {\overline{p}})$.

Definition 4

Given a composite protocol $P$ that uses a constituent protocol $q: Q(\overline{x}= {\overline{p}})$, where $P$ passes a set of arguments ${\overline{p}}$, $Q$ accepts a set of parameters $\overline{x}$, and the sets ${\overline{p}}$ and $\overline{x}$ agree in name and type. Then protocol $P'= \textit{expand}(P, \ q: Q(\overline{x}= {\overline{p}}) )$ is the expanded version of $P$ and $Q$, and is defined as follows, where $\mathsf {x}\in \{ \mathsf {R}, \mathsf {P}, \mathsf {C}, \mathsf {M}, \mathsf {F}\}$

$$\begin{aligned} \mathcal {P}^\mathsf {x}(P')&:=\mathcal {P}^\mathsf {x}(P) \cup \mathcal {P}^\mathsf {x}({Q^{\overline{x}}_{{\overline{p}}}}) \\ \mathcal {P}^\mathsf {U}(P')&:=(\mathcal {P}^\mathsf {U}(P) -{ q} ) \cup \mathcal {P}^\mathsf {U}({Q^{\overline{x}}_{{\overline{p}}}}). \end{aligned}$$

Positron Conversion to MCMAS. The conversion of a Positron protocol, $\mathcal {P}$, to an MCMAS representation $\mathcal {M}= \textit{conv}(\mathcal {P})$ is a two-step process. First, constituent protocol expansion (Protocol Composition) flattens all nested protocols, ensuring $\mathcal {P}^\mathsf {U}$ is the empty set. Second, additional conversion functions, ${\textit{conv}}^{p}_{m}(\mathcal {P}^\mathsf {x})$, convert each element of a Positron protocol to elements of an MCMAS representation. The final MCMAS representation consolidates these generated elements. The ISPL source input into MCMAS is generated from the above-mentioned MCMAS representation.

Role Requirements. A role requirement reflects a role-desired goal of an agent playing a role in the composite protocol. In Positron, Req(r, p, q) means that role r requires that q will occur whenever p occurs. In AGFIL, one of PolicyHolder’s role requirements is: if Insurer offers coverage, I paid the premium, and I have an accident, then my car will be repaired: Req($\textsc {PH}$, $\textit{coverage}$ $\wedge$ $\textit{premium}$ $\wedge$ $\textit{accident}$, $\textit{repair}$)

It is incorrect to formalize a role requirement as the CTL specification: ${{\mathbf A}{\mathbf G}}$($\textit{accident}$ $\rightarrow$ ${{\mathbf A}{\mathbf F}}\,$ $\textit{repair}$), which ignores commitment violations that disrupt a collaboration: a commitment may fail because its debtor either chooses not to, or is prevented by circumstances from, discharging it. In verifying a role requirement, we cannot assume commitments are never canceled. Rather, we express role r’s requirement as: if r fulfills all its own commitments and p holds at any state, then on each branch eventually, either q holds or a role other than r canceled one of its commitments. If r’s requirement fails because r cancels a commitment, that is not a fault of the protocol; it is r’s fault.

A Positron role requirement maps to an MCMAS CTL expression as

$$\begin{aligned} Req(r, p, q)&:={{\mathbf A}{\mathbf G}}(p \rightarrow {{\mathbf A}{\mathbf F}}(q \vee \bigvee _{r' \ne r} r'.\textit{anyCancel})) \end{aligned}$$

where $r'.\textit{anyCancel}$ is true if and only if role $r'$ cancels any of its commitments.

Enactment Requirements. Although capturing all possible enactments is not feasible for all protocols, designers and other stakeholders often know of specific good and bad enactments. We use these enactments for partially verifying a composite protocol as a way to assist designers refine protocol specifications (e.g., its constituent protocols and coupling commitments) or other requirements. An enactment corresponds to a scenario in requirements engineering [13] and yields a unit test. In Positron, the enactment specifications can be “good” (must exist) or “bad” (must not exist).

We use model checking to verify enactments. We introduce three recursive functions to simplify enactment specification. An enactment E is an ordered list of Boolean expressions over states and messages. $\textit{head}(E)$ is the first element in list E, and $\textit{tail}(E)$ is E without the first element, and ${{\mathbf E}{\mathbf X}}$, ${{\mathbf E}{\mathbf F}}$ and are CTL operators. Define

EXPath specifies a path of states that must appear consecutively. EXPath is often too strong a constraint, since it precludes interleaving of constituent protocols. EFPath specifies a path of states that must appear in order, but not necessarily consecutively. EUPath specifies a path of states that must appear in order, and constrains which states can be interleaved in the path. Expression r identifies which states must not be interleaved in the path. An EUPath requirement is stronger than EFPath and weaker than EXPath. Two example requirements from AGFIL include $\lnot \textit{EFPath}(\textit{repair}, \textit{accident})$ and $\textit{EFPath}(\textit{accident}, \textit{deliverReq}, \textit{deliverCar}, \dots , \textit{repair})$.

Coupling Commitments. A composite protocol would in general relate its constituent protocols. All roles are jointly accountable for ensuring constituent protocols are properly interrelated. We capture each role’s role accountabilities as coupling commitments. A coupling commitment’s debtor is the accountable role, and its creditors are (in general) the union of all roles connected by the interrelated constituent protocols, minus the debtor: .

Consider two coupling commitments from AGFIL. (1) CallCenter commits to PolicyHolder and Repairer that it will notify Repairer whenever it receives a request: $\textsf {C}_{\textit{CC},\{\textit{PH, Re}\}}(\textit{deliverReq}, \textit{notify}\textsc {Re})$. (2) PolicyHolder commits to CallCenter and Repairer that he will deliver his car to Repairer whenever requested and the repair request is approved: .

Verification. Positron reads specifications of the composite and constituent protocols and generates a single MCMAS input file. MCMAS reads the input, builds the appropriate model, and reports whether each CTL formula holds in the model.

Fig. 2.

Selected states and transitions for AGFIL.

Figure 2 shows a portion of the state space Positron generates for verification from AGFIL’s constituent protocols and coupling commitments. The start state is $s_0$. Solid lines are valid transitions (messages); dashed lines are transitions that must not occur infinitely often. Since the message guard for $\textit{coverage}$ is $\textit{premium}$, $\textit{coverage}$ can occur only after $\textit{premium}$, making $s_1 \ldots s_8$ invalid start states. Notice that the top row ($\textit{premium}$, $\textit{coverage}$, $\textit{accident}$, and $\textit{repair}$) begins a good enactment. Positron can verify the existence of this path using an EFPath requirement. Further, Positron can ensure that the model is free of specific bad enactments, for example, that $s_1$ must not be a start state.

Positron generates a model checking fairness constraint for each commitment: a commitment must not remain unconditional and unresolved forever. Dashed loops are invalid because they violate a commitment fairness constraint. A composite protocol may fail to satisfy role or enactment requirements for different reasons:

• $\textit{Fail}_{\textit{RR}}$: If a role requirement (Req) formula fails, then coupling commitments are missing; add coupling commitments that require agents to act as appropriate.

• $\textit{Fail}_{G}$: If a good enactment formula fails, then either ($\textit{Fail}_{\textit{GG}}$) some message guards are too strong; weaken guards to enable additional good transitions. Or ($\textit{Fail}_{\textit{GC}}$) some commitment can become detached, but can never resolve; weaken guards to enable transitions that satisfy the commitment’s consequent.

• $\textit{Fail}_{B}$: If a bad enactment formula fails, then some message guards are too weak; strengthen guards to disable existing incorrect transitions.

4 Evaluation of Positron Modeling and Tools

We evaluate our contributions by modeling real-life protocols from the insurance, manufacturing, and healthcare domains. Table 1 summarizes our iterative methodology to develop a composite protocol such as in Listing 2.

Table 1. Inputs and outputs for each step of the methodology.

AGFIL Evaluation. We extend the AGFIL scenario by adding (a) PolicyHolder role and accident reporting; (b) Adjuster role and the redirection of two messages between ClaimHandler and Repairer through Adjuster; (c) payments from Insurer to ClaimHandler and Repairer; (d) a protocol for premiums and coverage between PolicyHolder and Insurer; and (e) Repairer returning the car.

We create the AGFIL protocol of Listing 2 as follows. Roles: Identify roles: Insurer (In) for agent AGFIL, CallCenter (CC) for Europ Assist, ClaimHandler (CH) for Lee, PolicyHolder (PH), Repairer (Re), and Adjuster (Ad). Constituent Selection: Identify constituent protocols: RequestResponse, Exchange (where two roles swap items), Claims for In-CH  and ApprovedWork for CH-Re. Role Requirements: Identify role requirements: PolicyHolder requires: (1) if he has coverage, pays his premium, and has an accident, his car is repaired; (2) if he delivers his car to Repairer, his car is returned. Insurer requires: if a claim is filed, the claim is finalized. All roles except PolicyHolder require payment if they perform their tasks. All these are described as Req functions. Enactments: Identify enactments: (a) PolicyHolder reports an accident to CallCenter (PH-CC); (b) CallCenter assigns and notifies Repairer to repair the car (CC-Re); (c) CallCenter asks PolicyHolder to deliver his car to a specific Repairer (PH-CC); (d) PolicyHolder delivers car to Repairer (PH-Re); remaining steps are omitted. Performing repairs before an accident is reported is a bad enactment: (e) car repaired; (f) accident reported. Coupling: Identify coupling commitments: (1) Between messages (a) and (b) of the accident-reporting enactment (see previous step), if PolicyHolder reports an accident, CallCenter assigns and notifies Repairer and (2) between messages (c) and (d), if CallCenter asks PolicyHolder to deliver his car to Repairer, he does so. Positron: Generate the Positron specification for AGFIL. Listing 2 shows snippets of the Positron specification for AGFIL protocol. Lines 2 and 3 declare roles and propositions. Line 4 instantiates constituent Claims named In-CH. Lines 10 and 11 are two coupling commitments. Line 15 lists one of PolicyHolder’s role requirements. Line 16 lists an Insurer requirement as explicit CTL. Line 18 verifies the good, accident-reporting enactment that must exist in the composite, and Line 19 verifies a bad enactment that must not exist. Listing 1 is the Claims protocol used as a constituent protocol. From all previous artifacts, generate the MCMAS input files. Verification: Run MCMAS model checker.

Quote To Cash Evaluation. Quote To Cash (QTC) is an important business process that supports manufacturing supply chains [24]. Roles: Identify roles: Customer, Reseller, Distributor, Seller, Shipper1, and Shipper2. Constituent Selection: Identify constituent protocols: Customer orders goods and services from Reseller using constituent protocol CommercialTran (ComTran), Reseller fulfills the order by Outsourcing to Distributor, Distributor orders good from Seller using CommercialTran, Seller arranges shipping with Shipper2, and Distributor arranges shipping with Shipper1, using additional instances of Outsourcing, and Seller provides a customer support contract to Customer though StandingService. Role Requirements: Identify role requirements; if Customer pays, he receives goods and services, if Reseller pays Distributor, he receives shipment, and for Customer  whenever a role performs its task, it gets paid. Enactments: Identify two enactments for Customer placing an order and ending with fulfillment: one if Distributor has goods in stock, one if it restocks from Seller. Fulfilling an order before it is verified is a bad enactment. Coupling: Identify coupling commitments: (1) Customer couples Cu-Re and Cu-Re-Di: if Customer receives a shipment, he pays Reseller, (2) Reseller couples Cu-Re and Cu-Re-Di: whenever Reseller receives an order, he orders from Distributor. Positron: Generate Positron specification for QTC. Verification: Run MCMAS model checker.

Healthcare (ASPE) Evaluation. We consider the healthcare process for breast cancer diagnosis, as described by an HHS committee [2]. The resulting ASPE protocol contains five roles (for convenience, we associate feminine pronouns with Patient, Radiologist, and Registrar and masculine pronouns with Physician and Pathologist.) The process begins when Patient visits a primary care physician (Physician), who detects a suspicious mass in her breast. He sends Patient to Radiologist for a mammography. If Radiologist notices suspicious calcifications, she sends a report to Physician recommending a biopsy. Physician requests the Radiologist to perform a biopsy, who collects a tissue specimen from Patient  and sends it to a Pathologist. Pathologist analyzes the specimen, and performs ancillary studies. If necessary, Pathologist and Radiologist confer to reconcile their results and produce a consensus report. Physician reviews the integrated report with Patient to create a treatment plan. Pathologist forwards his report to Registrar who adds Patient to a state-wide cancer registry. There are only two coupling commitments in ASPE. Physician has no coupling commitments because it is his choice whether Patient needs mammogram and biopsy exams from Radiologist.

Table 2. Statistics. (M is $10^6$, G is $10^9$, s is seconds.)

Real-Life Results: Positron and MCMAS were run on all three, hierarchical examples with the statistics and timings for the final, corrected protocols shown in Table 2. Positron processing was quick at less than 4 s, and total processing of AGFIL and ASPE were also quick at less than 8 s. QTC, with a 1000 times larger state space and the most CTL formulas, required 21 minutes.

Model Verification: Resolving verification errors is a challenging task, requiring careful consideration of the interactions between the generated MCMAS model and CTL statements.

Positron helped identify and fix several verification failures. Good enactment failures ($\textit{Fail}_{\textit{GG}}$ and $\textit{Fail}_{\textit{GC}}$) were generally easier to fix, since they only require that some path exist. One or more requirements or coupling commitments were slightly weakened to allow additional branches at appropriate points. Bad enactment failures ($\textit{Fail}_{B}$) were harder to fix as they required the impossibility of a particular enactment. One or more role requirements or coupling commitments were added. Hand checking was insufficient to ensure the changes would eliminate all bad paths; only reruns of Positron and MCMAS could confidently verify the changes.

Model Validation: Although identifying requirements was easy, some initial specifications were incorrect because preconditions were missed. For example, PolicyHolder’s role requirement initially failed ($\textit{Fail}_{\textit{RR}}$) because coupling commitment among CallCenter, PolicyHolder, and Repairer did not include approval; Repairer will not repair a car just because it is delivered to him. And, an accident is insufficient to get PolicyHolder’s car is repaired; PolicyHolder must also have a policy and pay the premium. Positron generates model checking fairness conditions to ensure all unconditional commitments eventually resolve. Initially, one of the AGFIL’s good enactment mysteriously failed because, even though the model allowed all the transitions, the good enactment had unresolvable commitments (invalid by commitment fairness conditions). We corrected the model so all commitments could resolve.

5 Discussion: Literature and Future Work

Positron gains an advantage over both traditional process modeling and existing (operational) protocol approaches by focusing on high-level relationships realized as constituent protocols, and by focusing on commitments rather than control flow. Because role accountabilities are stated as commitments, if a requirement fails, we can trace the failure back to a specific failing role.

Composite protocols provide a formal means to capture how constituent protocols may be composed to realize an STS specification. Because these protocols capture meanings as commitments (generalizable to norms), yet have a formal semantics that maps to sound enactments, they can provide a natural approach to support secure policy-governed collaboration in ways that are not visible to low-level, operational approaches.

Literature. Table 3 compares Positron with other work. Some papers propose a protocol specification language, and some propose an accompanying protocol specification methodology. Some papers address single protocols in isolation; some address common patterns within protocols; some address the composition of multiple protocols to create new composite protocols. Of those papers that address verification, some address sociotechnical requirements; some address verification properties between two protocols or models (such as protocol refinement); some address protocol-wide properties; some verify properties that must hold between the constituents of a composite protocol; some formulate role-specific properties; some formulate good or bad enactment properties; and some address other verification topics not addressed above.

Table 3. Approach comparison. Column abbreviations and citations are Po$\,=\,$Positron; Pr$\,=\,$Proton; DA, DO, Dv and DM$\,=\,$Desai et al.; T$\,=\,$Telang and Singh; Y$\,=\,$Yolum; Mi$\,=\,$Miller and McBurney; G$\,=\,$Günay et al.; C$\,=\,$Cheong and Winikoff, Mc$\,=\,$McGinnis and Robertson, L$\,=\,$Lomuscio et al., B$\,=\,$Baldoni et al. Check marks show the significant topics addressed by each paper. The cell contents of the verification rows indicate whether the paper discusses (D) or mechanizes (M) verification of known good or bad paths.

Desai et al. [9] propose OWL-P [10] and MAD-P [11] for specifying and verifying commitment protocols and their compositions. They employ axioms to specify a composition. These approaches suffer from a key drawback: axiom violations are not assigned to any particular role. In contrast, Positron employs coupling commitments with clear role accountability for the effects of one constituent protocol on others. Further, Amoeba is purely manual, whereas Positron incorporates mechanical verification. Adopting Amoeba’s event ordering idea would add flexibility to our approach, but more granular parameterizations of constituents provides the same functionality.

Telang and Singh [31] (T&S) describe a methodology for modeling STSs that captures the commitments to be created among the parties by melding selected collaboration patterns. In contrast, a protocol in Positron additionally specifies the messages and guards, and the protocols are first-class entities that retain their identity in the composite protocol, yielding improved modularity and modifiability. Most significantly, T&S’s approach verifies if one implementation is sound with respect to the model. In contrast, Positron verifies if the model itself is sound.

Yolum [33] proposes generic correctness properties of commitment protocols for design-time verification, but does not address composite protocols. She considers generic properties, whereas we consider role-specific STS requirements. It would be interesting to formulate Yolum’s generic correctness properties in Positron.

Miller and McBurney [21] (M&M) propose the $\mathcal {RASA}$ language based on propositional dynamic logic (PDL) to specify and compose protocols. $\mathcal {RASA}$’s preconditions, actions and postconditions correspond to Positron’s guards, messages and meanings. Positron additionally incorporates role requirements, coupling commitments, and good and bad enactment paths, making Positron practically viable. Theses are important in naturally describing STS protocols, as we demonstrated above. Whereas M&M describe a custom reasoner, we rely on standard CTL semantics as realized in MCMAS.

Günay et al. [15] treat protocols as sets of commitments and propose automatically generating such sets from an agent’s beliefs, goals, and capabilities. In contrast, we offer a semiautomatic approach where a tool helps designers compose existing protocols. Automatic generation is attractive but may not be feasible for complex settings, although a hybrid approach of developing atomic protocols mechanically and composite protocols with human assistance might be viable.

Cheong and Winikoff [6] describe the Hermes system for goal-oriented interaction. They focus on interaction-level goals, whereas we focus on role-level requirements and commitments. Their action sequence diagrams capture only good enactments.

McGinnis and Robertson [20] propose an approach in which an agent sends a protocol specification to other agents at runtime, as a way to accomplish dynamic, runtime, protocol adaptation. They remark that their approach lacks a way to prevent agents from making an undesirable change to a protocol. If their protocols were augmented with commitments, Positron could help address this gap. For example, an agent may not remove a message from a protocol that brings about the consequent of a detached commitment. While they describe rules for dynamically changing protocols, they do not address formal verification of interaction properties.

Lomuscio et al. [18] semiautomatically compile and verify contract-regulated service compositions with compliance expressed in temporal-epistemic logic using MCMAS (which we adopt). A crucial difference is that Lomuscio et al. consider service compositions; we consider protocol compositions. Since a protocol has a distributed footprint, protocol compositions are inherently more subtle than service compositions. A potential benefit from adopting MCMAS is that it supports more expressive logics such as Alternating-Time Temporal Logic (ATL) [1], which could help capture subtle correctness criteria for protocols.

We propose a methodology and use role responsibilities and role accountabilities using expressions in CTL. Others describe the complementary issue of temporal pattern languages which assist users to correctly capture their high level requirements as temporal expressions. Dwyer et al. [12] describe a pattern language for temporal expressions in CTL, LTL and other formalisms. Baldoni et al. [4] compose protocols using regulative specifications as LTL constraints.

BPMN 2.0 [23] is a standard notation for business process modeling. BPMN addresses both orchestration and choreography; in taking a multiagent approach, Positron focuses on choreography. Our protocols are similar to BPMN Conversation objects. Both protocols and Conversations can involve two or more roles (Participants), and both can have simple or complex message sequencing relationships. But, BPMN does not specify how to describe the relationships between messages in a complex Conversation, except through internal orchestration; our complex protocols fully specify message sequencing relationships using external guard statements. Both support arbitrary nesting. We formally verify our compositions using temporal logic; model verification is explicitly out-of-scope in the BPMN specification. Positron’s primary building blocks are protocols and commitments. BPMN has no counterpart to our coupling commitments, which are key to our interrelating constituent protocols and formal verification.

Threats, Limitations, and Future Directions. One limitation of Positron is that it does not handle varieties of accountability besides commitments [29] and does not show how to evaluate agent goals and decision making with respect to protocols [15]. Importantly, we have not established that practitioners employing Positron can obtain the benefits in abstraction, reusability, and correctness the motivate it.

These threats and limitations lead to useful future directions. At the theoretical level, treating the goals of the participants is natural. At the practical level, generating enactments via tooling would be valuable. At the empirical level, evaluating the effectiveness of Positron (the approach and the tool) with professional developers on collaboration in STSs would be necessary to promote adoption by industry. To this end, we have developed a graphical notation for protocol composition called composite protocol diagrams (CPDs). CPDs seek to succinctly visualize the essence of a composite protocol both to analysts and technical designers, who collaborate in its construction. We defer an empirical evaluation of CPDs and competing notations as a way to determine if the high-level abstractions of Positron can help analysts and designers combat complexity and communicate more effectively with each other.