Contracts and Interaction Operators

In my last blog entry I discussed how contracts are a useful notion to facilitate coordination. A contract is essentially a meta command, that is it's a promise to fulfill a command. In the categorization of speech acts, a contract is the "accept proposal" speech act. That is the reification of the action of accepting a previously submitted proposal to perform an action. However, its quite evident that the lifecycle of a complex has a lot more detail that's worth a bit more investigation.

So, let's consider a contract as a resource, a resource that's shared by multiple parties. Now, the contract has a lifecycle, this lifecycle based on the available speech acts would be "call for proposal", "propose", "accept/reject proposal", "agree/cancel" and then finally "confirm/disconfirm". This in analagous to the closed loop business interaction model proposed by Terry Winograd:

1. Preparation: The Customer plans work to be completed by the Performer and issues a request.
2. Negotiation: The Customer and Performer negotiate until they reach an agreement (commitment) about the work to be fulfilled.
3. Performance: The Performer fulfills the agreement and reports completion.
4. Acceptance: The Customer evaluates the work and either declares satisfaction or points out what remains to be done to fulfill the agreement.

Now it's interesting that Winograd's framework is a useful tool for coordinating interaction and is most commonly used to support workflow. Matter of fact, this lifecycle is quite universal, the only other speech acts not covered by this lifecycle are "inform", "query" and "request". These interestingly enough are "direct" commands, that is it's not a command that's about a command, its just a simple command. REST commands in fact are in the same category.

This relates to Milner's new computing model. That is when you have a concept of a name (i.e. the reification of an action) then you have the elementary particles for describing interaction.

One may think that REST because its four basic actions aren't higher order that it can't comprehensively support all interaction. However, one shouldn't overlook the aspect of addressable resource, that is the URLs. These addressable resource can be contracts at different states of its lifecycle.

However, one needs to wonder, because of the restrictive set of actions available to REST, the semantics of a contract's lifecycle is hidden in the semantics of the resource. I'm just wondering if you promote several speech acts like PROPOSE, ACCEPT, CONFIRM etc. to standard REST like actions, that this could lead to some very interesting applications. What sort of "interaction operators" can we conceive of?

Let's take a look at the contract itself, divorcing ourselves from its lifecycle. Peyton Jones has put together a set of primitives for defining contracts (of the financial kind):

zero :: Contract zero is a contract that may be acquired at anytime. It has no rights and no obligations, and has an infinite horizon.

one :: Currency -> Contract (one k) is a contract that immediately pays the holder one unit of the currency k. The contract has an infnite horizon.

give :: Contract -> Contract To acquire (give c) is to acquire all c's rights as obligations, and vice versa. Note that for a bilateral contract q between parties A and B, A acquiring q implies that B acquires (give q).

and :: Contract -> Contract -> Contract If you acquire (c1 `and` c2) then you immediately acquire both c1 (unless it has expired) and c2 (unless it has expired). The composite contract expires when both c1 and c2 expire.

or :: Contract -> Contract -> Contract If you acquire (c1 `or` c2) you must immediately acquire either c1 or c2 (but not both). If either has expired, that one cannot be chosen. When both have expired, the compound contract expires.

truncate :: Date -> Contract -> Contract (truncate t c) is exactly like c except that it expires at the earlier of t and the horizon of c. Notice that truncate limits only the possible acquisition date of c; it does not truncate c's rights and obligations, which may extend well beyond t.

then :: Contract -> Contract -> Contract If you acquire (c1 `then` c2) and c1 has not expired, then you acquire c1. If c1 has expired, but c2 has not, you acquire c2. The compound contract expires when both c1 and c2 expire.

scale :: Obs Double -> Contract -> Contract If you acquire (scale o c), then you acquire c at the same moment, except that all the rights and obligations of c are multiplied by the value of the observable o at the moment of acquisition.

get :: Contract -> Contract If you acquire (get c) then you must acquire c at c's expiry date. The compound contract expires at the same moment that c expires.

anytime :: Contract -> Contract If you acquire (anytime c) you must acquire c, but you can do so at any time between the acquisition of (anytime c) and the expiry of c. The compound contract expires when c does.

These primitives concerns Contracts in the context of its acquisition and exchange. What happens when a Contract expires and therefore executed is factored out. So, we have here a pretty compelling example of operators that apply to "meta" or "higher order" commands. What happens when you have a more general "interaction" operators? What happens when you define these for all states in a contract 's lifecycle? So if you've got operators then you potentially got a an algebra or calculus. Or working the other direction, if you got an interaction calculus then you could use is as a framework for reasoning about this in a much clearer fashion.

Something to mull over.