1 Introduction
Contracts [15, 16, 11, 7] and session types [13, 19] are both intended as abstractions representing interaction protocols among concurrent processes. In both theories, interaction is modeled by message exchange along channels, abstractly represented by input/output actions indexed over channel names. Also the used formalisms all stem from CCS and its variants, possibly extended by some value passing mechanism. The resemblance is even tighter when considering “session contracts” [1, 7], where only internal and external choices among contracts prefixed by pairwise distinct output viz. input actions are respectively allowed.
Contracts versus Session Types. In spite of similarities, these theories stem from rather different concepts. In case of contracts, the input/output behaviour of a participant to a conversation is formalised as whole by a term of an appropriate process algebra; contract theory then focuses on the “compliance” relation, holding when two or more protocols are such that, whenever there is an action by a participant that is expected to be performed, the symmetric namely dual one is made available by some other participant. Restricting to the binary case, we say that a “server” protocol is compliant with a “client” one if all actions issued by the latter are matched by the respective coactions by the former, possibly until the client reaches a successful state.
Session types are a type system for a dialect of Milner’s calculus. Like with typed calculus, judgments associate to a process a “typing” that pairs channel names with the types of the values that can be transmitted through the channels; since terms are allowed to communicate channel names as well, channel types are among the types of exchanged values. Differently from ordinary calculus types, session types are regular trees of value types, that can be session types as well. In this way a single type can describe the flow of data through each channel that do not need to have all the same type; also input/output communication actions are distinguished by their types. When a “session” is opened by two processes in parallel, a new private channel is created  the session channel  that is shared by the processes; if the two “endpoints”, namely the respective occurrences of the session channel in the participant processes, are typed by dual types  roughly interchanging input and output types  then the interaction will be error free at runtime. Observe that not only the typing has to be checked against the process structure, which is not considered in contract theory, but also the very same process can issue several sessions at the same time, and session channels can be exchanged among processes. Therefore, even in the simpler setting of binary sessions, namely with channel names connecting two processes at a time, difficulties arise from the possible nesting of several sessions, and their ability to communicate across the boundary of a single session.
Orchestrated Compliance. Compliance being a rather restrictive requirement, more liberal constraints have been proposed in the literature, among which are “orchestrated” compliance [18] and “retractable” contracts [4]. According to the orchestrated model the interactions between a client and a server are mediated by a third process  the orchestrator
 ruling interactions by allowing certain actions and coactions only, possibly buffering a bounded number of messages on both sides. In the retractable model instead, actions are classified into irretractable (unaffectible) and retractable (affectible) ones. The concept is that, while irretractable actions by a participant have to be matched with their duals by the other compliant participant, retractable actions are just tried and possibly retracted, in case of communication failure, to issue some other action instead. Although these two models are different, it has been shown in
[3] that, by restricting to certain orchestrators that allow just synchronous communications, contracts that are deemed compliant in both models are the same. Moreover, it is possible to provide an algorithm which synthesizes an orchestrator out of two retractable contracts if they are compliant, or fails otherwise (see [6] and section 6 below).Orchestrated interaction instead of duality. In this paper we address the issue of adapting the idea of retractable contracts to session types. More precisely we see session types as contracts, and propose to replace the otherwise restrictive notion of type duality by the relation of retractable or equivalently orchestrated compliance. To better illustrate the point, let us consider a process in parallel with a system , that has to choose how to interact in a session with by selecting one of several alternatives. Both and are equipped with specification of their behaviours, so that it is known in advance that at least one alternative is actually successful, but not necessarily all of them are. Now there are two possible ways of guaranteeing to successfully complete the interaction with :

either is run on a computational infrastructure that, in case of a synchronization failure, allows to roll back to some previous choice point , and to try a different branch of the interaction;

or, when checking the compliance of the specifications, it is statically computed which are the safe choices, if any, before running , so that they can be stored into a mediating process.
The reason for preferring the second approach is clearly apparent, as it limits the backtracking to static type checking, while avoiding it at runtime. In fact, once types of opposite endpoints have been recognized compliant up to retractability of certain choices (that are kept distinct syntactically from unretractable ones), and an orchestrator has been sinthesized, the very same orchestrator can serve as guidance in the interaction on the session channel. In particular, by putting the orchestrator in parallel with the processes holding the endpoints, it can be used to drive the proper choices at run time. If is the session channel, we write the resulting session by:
representing that the interaction over the private session channel is ruled by .
The orchestrator is obviously an abstraction that allows for many different implementations.
Among the possible ones there are:

a communication infrastructure responsible of running the orchestrator;

the two partners agree on an orchestrator that it is used on both sides as a communication interface.
We do not further discuss implementation issues that would lead us outside the scope of the present paper.
Speculative selection. In sessiontypes formalism the type describes the protocol consisting in selecting the label to be sent as output, and continuing as specified in ; this is the consequence of an internal choice that is transparent to the other participant in the session, that is expected to be able to react to all . The dual is the branching type , expecting a label among as input to continue according to the respective continuation. To these we add a new type constructor written
that we dub speculative selection type. The intended meaning of speculative selection is: try selecting labels among until an is found such that is in the corresponding branching type, and and are compliant. Observe that the speculative selection type has no dual, so that we cannot use the notion of duality in the system.
As a running example suppose that a Client is willing to establish a session with a movieProvider and to behave on her channel end according to the following session type:
where . Accordingly the client will send on the session channel a login information (an element of the ground type String) and then will internally decide whether she intends to buy or to rent a movie. In the former case, she will further decide whether to buy an ultrahighdefinition (uhd) or a highdefinition (hd) movie. In the latter case, instead, it is stated in the speculative selection type that she will proceed according to four possible failureamenable choices: renting an ultrahighdefinition (uhd), a highdefinition (hd), a standarddefinition (sd) or a lowdefinition (ld) movie. In all cases, she will proceed according to type by sending the string with the title of the movie, and either receiving the URL from which the movie can be downloaded, if available (availability corresponds to the reception of ok), or ending the session if it is not (no).
From the previous discussion, if the Client behaves on her endpoint of the session channel according to the type , she can safely interact with the Provider in case the latter behaves on the other endpoint of the session channel according to the following session type :
where .
Now this client/server interaction succeeds in case the client actually buys a movie. If the client intends to rent a movie, instead, the choice uhd will produce a synchronization failure, since no ultrahighdefinition movies are for rent on that server. Also the choice hd of a movie to be rent would produce a syncronization failure, since then the server requires a membership code (as described by ). But this is not all the story, as the remaining two possibilities still lead to success, so that we insist that these two participants can agree at least in part. Indeed to prevent synchronization failures the Client will be instructed at runtime by the orchestrator to select either sd or ld choice only while renting a movie. The orchestrator is computed when the session between the client and the server is tried and possibly opened, hence before it is started. An orchestrator for the example is:
where . This means that on the session channel between Client and Provider, the orchestrator first enables an input/output interaction ( ) and then either () a buy or a rent branching. In case of rent, the orchestrator internally decides () to force either an sd or ld choice; this can be left open as both of them are “safe”, namely do not lead to (not even future) synchronization failures.
Observe that also the following two orchestrators can successfully drive the interaction between Client and Provider:
As a matter of fact, our calculus and its type system do consider any safe orchestrator for a session interaction. In actual implementations, however, one could be interested in limiting the nondeterminism in a session exclusively to that exposed by the two partners. This involves considering deterministic orchestrators only, like and above, that is with no inside.
Adding priorities. For the semantics of the type the actual ordering of the labels is immaterial; therefore the actual choice stored in the orchestrator is up to the synthesis algorithm. In practice, however, the choice of either or should not be randomly determined, rather it might reflect a particular policy representable at type level. A simple way is to provide a priority ordering among the failureamenable choices, that can be expressed by the following modified syntax:
where is now an ordered list. So the above type expresses that the option ld is the one liked best, but in case of failure, sd is the second preferred choice, and so on. The priorities represented by the above speculative selection type force the orchestrator to be synthesized.
We shall show that it is possible to synthesize the deterministic orchestrator which reflects the priorities described in the speculative selection types. Moreover, with an extra computational effort, the priorityordering policy can be lowered down and described at process level.
According to the compliance relation, in a session only the client’s communicating actions are guaranteed to be matched by corresponding actions on the server’s side. Therefore there might be some pending communications on the server side even in case the client has successfully completed. This fact produces particular deadlocks which do not show up in ordinary sessionbased calculi and type systems, as these are based on the notion of duality. We show how to get rid of such stuck states by adding suitable reduction rules. The type system can in fact be proved to be sound w.r.t. the new reductions, preventing typed process from reaching these peculiar stuck states.
In order to focus on the main concepts, in the present paper we do not treat recursion, that can be easily added in a fairly standard way.
Structure of the paper. In Section 2 we define types, orchestrators and the relation of orchestrated compliance. The syntax of the calculus and the type system are treated in Section 3. In Section 4 the operational semantics is defined and the subject reduction property is proved, obtaining error freeness of typed processes as a corollary. The particular deadlocks due to the use of the compliance relation instead of duality is dealt with in Section 5, whereas in Section 6 we restrict orchestrators to deterministic ones, and make them implement a priority selection policy which can be described either at type or process level. Section 7 contains the conclusions and suggests possible extensions.
2 Session types and orchestrated compliance
First we introduce session types following [13] but for recursion (omitted for sake of simplicity) and for the new type for speculative selection, corresponding to retractable choice in [4].
Definition 2.1 (Types).
where . Moreover, the labels ’s belong to a countable set of labels and are pairwise distinct in branching, selection and speculativeselection types.
The syntax of orchestrators is inspired by that in [18] and [6]. Main differences with respect to [18] and [6] are that we do not have buffers, here unnecessary because we do not model asynchronous communications; besides, our orchestrators can introduce some nondeterminism in orchestrated interactions (see Definition 4.2).
Definition 2.2 (Orchestrators).
We define the set Orch of orchestrators, ranged over by , as the terms generated by the following grammar:
where .
We write resp. for resp. ), where and the ’s are pairwise distinct. If is a singleton then () is just a selection prefix.
Definition 2.3 (Orchestrated compliance).
The relation among the orchestrator and session types is the least one such that:

, for any ,

if then and for any ,

if for all then, for any set of indexes ,
and , 
if with and for all then
and .
We say that and are compliant, written , if for some .
Proposition 2.4.
Given it is decidable whether . Moreover if then an orchestrator such that is computable.
Proof.
By induction over the structure of . ∎
Remark 2.5.
Remark 2.6.
In the theory of session contracts [2, 7], compliance does correspond to the composition of duality and subtyping. Such a correspondence does transfer also to session types in a very general sense, as shown in [8]. In our setting, even if a relation of subtyping can be obtained out of a restriction of the subcontract relation defined in [5], the above mentioned correspondence looks unrealistic since, as pointed out in [4], there exists no natural notion of duality^{2}^{2}2Duality for retractable session contracts can be immediately recovered by extending the formalism of [4] with speculative input choices, as done in [5]. Such extension, however, do not seem to have a clear sessiontype counterpart. for retractable contracts.
Example 2.7.
Extending the running example in the Introduction, we include the
higherorder features of session types.
We assume that the Client of the movieProvider has to pay for the buyed/rented movie.
For the payment, if the movie is available, the Provider throws to the Client a session channel (typed by the session ) that can be used to pay using several possible cards.
The new versions of and are now, respectively:
where
and
where
Here we assume that the payment always succeedes and the Client is not cheating. The safe interaction between Client and the Provider is guaranteed by . In fact, for instance, it can be checked that:
where with .
For the payment the Provider establishes a session with the Bank, hence acting as a client. The Provider’s end of the corresponding session
channel is typed by:
where
(notice that is precisely the type of the channelend that the Client
receives from the movieProvider during the interaction described by ).
Hence, once the ProviderBank session is established, the Provider sends the cost of the movie and then delegates the actual payment to the Client.
The polarity ‘’ in the channelsend of indicates that the delegated channel’s end is sent by the applicant of the session. Therefore the receiver has to act as such
^{3}^{3}3The polarities of two corresponding channelsend and channelreceive are always the same, since they both refer to the same channel’s end; in particular, in the present example the polarity is ‘’ also in the channelreceive of ..
On the delegated channel the Client is allowed to pay either by using a Diners, a Mastercard or a Visa, but it is not guaranteed that all of them will be actually available.
We also assume that once the ProviderBank session is established, the Bank behaves on its channel’s end according to the type
where
.
Observe that the Bank can accept any of the Discover, Mcard,
Visa or AExpr cards, but does not accept
Diners. Moreover, after receiving the creditcard number, the Bank does issue the identifier of the transaction
(an element of the ground type TransIDnum), notwhithstanding it is not requested by
the session type. Nonetheless the safeness of the interaction with the Bank
is guaranteed by the fact that .
In fact, for instance, it can be checked that
where
3 Calculus and type assignment
We assume to have a countable set of channel names, ranged over by In a session, we refer to the process performing the sessionopening request as “the client”, while the process which accepts it is referred to as “the server”.
We distinguish among userdefined and runtime processes. While the former represent the code of concurrent programs, the latter formalise the state of the system at runtime. Following [12, 19], clients’ and servers’ channelends are identified by means of polarities and respectively, ranged over by Moreover, we define and .
Definition 3.1 (Processes).
The set of (userdefined) processes is defined as the set of the closed expressions generated by the following grammar:
where , is nonempty and finite, and the labels in branching and speculative selection, all belonging to (as the one in selection), are pairwise distinct.
Let be any user defined process. Runtime processes are defined by the grammar
where channels can be polarized channels, i.e. channel names can be decorated with polarities.
In and the operator is a binder of , and .
In session type systems the compatibility of processes establishing a session lays on the notion of duality of the respective types, that are associated to a port name which is the same on both sides. To duality we have replaced the notion of compliance. It is hence not straightforward to use port names for establishing a session between a client and a suitable server, since there is not a unique type for the possible servers of a given client. So, in order to get a calculus as general and simple as possible, we equip the request and accept operators with their types, without any reference to port names.
Most process actions are similar to those of the calculus in [13],
but for the new speculative selection. A process
is able to send on channel any of the labels ’s and to proceed afterwards as .
The process is aware that some of the synchronizations on the ’s could led to a failure
and an orchestrator is hence expected to drive the choice.
The processes Provider, Client and Bank of the running example can be described as follows (where also conditional processes are used and where only the parts concerning rental are described).
Example 3.2.
Let b be a boolean expression representing the decision of whether buying or renting
a movie.
where
where
where
The Type System
The following type system is the “more liberal” system in [19], where duality is replaced by the relation of orchestrated compliance. There are two kinds of judgments: the first one is , where is an expression of ground type; the second one is , where is either a userdefined or a runtime process. The context is a finite set of typings of expression variables; the processtyping (henceforth just typing) is a finite set of typings , where is a polarised channel name, and a session type. By and we mean the set of variables or channel names that are typed, respectively, in and . Variables and (polarized) channel names are pairwise distinct both in and as usual; note that .
Definition 3.3 (Type System).
The rules of the type system are in Figure 1. In rule InactT a typing is completed if for any we have . In rule ConcT the typing is the union of the typings and provided that , it is undefined otherwise; in the latter case the rule does not apply.
The rules of Figure 1 are similar to those of [19], but for the following. In rules [AccT], [ReqT] port names are not considered; consequently contexts just contains expression variables and we do not have restrictions over port names. In [19] rule [CResT] is
where is the dual of . In the premise we have the typing instead, with the side condition yielding the orchestrator appearing in the process in the conclusion.
It is not difficult to check the parallel composition of the processes of running example is a typable userdefined process, in particular .
4 Operational semantics and error freeness
Because of the presence of orchestrators in session interactions, the notion of structural congruence has to be handled with some extra care than in usual calculi with sessiontypes.
Definition 4.1 (Structural Congruence).
The structural congruence is the least congruence over runtime processes such that:

if is obtained from by alphabetical change of bound channel names, avoiding name clashes,

if ,

if are either userdefined or runtime processes that are not a named orchestrator, then: and .
Definition 4.2 (Operational semantics).
The operational semantics of processes is described by the reduction rules listed in Figure 2.
This operational semantics extends that in [13] by taking into account the new operator and the necessity for interactions of being orchestrated.

[Link] If the session type is compliant with by means of the orchestrator f, the sessionopening request can be accepted by . A new channel is created for the opened session. The ‘’ end is owned by the process who requested the opening (the client) whereas the ‘’ end is owned by the other one (the server). To connect the orchestrator f to the opened session, f is labelled with the channel name . This forces its orchestration actions to act only on synchronizations over the channel .

[OrchComm], [OrchDeleg], [OrchSel] In these rules the orchestrator enables the communication of a value, the communication of a channel, and the selection of a label, respectively. In rule [OrchComm] the side condition reads: expression evaluates to the value .

[OrchSSel] In presence of a speculative selection, i.e. a number of choices possibly leading to synchronization failures, the role of the orchestrator is to suggest one among the safe choices. Notice that, in case the cardinality of is strictly greater than one, this rule is nondeterministic. In actual implementation it is reasonable to expect the orchestrator not to add nondeterminism to the system. We show in Section 6 how this can be obtained by interpreting in as a priority list and how is it possible to synthesize, out of and in [Link], the orchestrator that suggests the safe choice possessing the highest priority, if any.

[Par], [Scop], [Str] These rules are standard.
Example 4.3.
We can now see in Figure 3 the evolution of the userdefined process of our example
We assume that the client decides to rent an available movie.
The type system guarantees typechecked processes to be free from (a version of) the standard synchronization errors of sessiontypebased calculi, which now involve also orchestrators and that we dub orchestrated synchronization errors. It also prevent (a class of) errors due to the absence of orchestration action and that we dub vacuous orchestration errors.
Example 4.4.
Let us see some examples of errors that cannot actually occur in typeable processes (see Lemma 4.6 below).

This process is stuck. It cannot be typed since the types for and should have, respectively, the form and . Rule cannot be applied to type the whole process, since, by Definition 2.3, these types are not compliant (even in case ).

This stuck process cannot be typed since rule requires the compliant types to be assigned to polarized channels with different polarities.

This process is stuck since the orchestrator does not enable the input/output syncronization. It cannot be typed either. In fact the types for and should have, respectively, the form and , and rule cannot be applied since, by Definition 2.3, it is impossible to have .

Since any reduction is necessarily driven by an orchestrating action, there is no possibility for the process to progress. Unlike the previous examples, this sort of deadlock depends exclusively on the lack of orchestration actions.
Definition 4.5 (Errors).

A process is a runtime process term whose first action involves the channel , namely a process having one of the following forms:
, , , , , , ;

A potential redex is a process term formed by the parallel composition of one processe, one processe, for some and , and one named orchestrator;

A process is an orchestrated synchronization error (orchsynch error, for short) if it contains a potential redex which does not reduces;

A process is a vacuousorchestration error if it contains a subterm such that
where is a process;

An error is either an orchestrated synchronization error or a vacuousorchestration error.
The type system guarantees that
a typable process cannot be an error.
Lemma 4.6.
Let . Then is not an error.
By means of the Subject Reduction property we show that
a typable initial process never reduces to an error.
Concerning the typing of expressions, we assume the standard property that if and then . Then the following technical lemma, to be used for the subject reduction property (Theorem 4.9), is proved by an easy induction on derivations:
Lemma 4.7.
If , , and then .
Before proceeding with the Subject Reduction property, we show that typability is invariant with respect to the structural congruence formalized in Definition 4.1. The presence of orchestrators makes this usually fairly standard proof more subtle to handle.
Lemma 4.8.
If and then .
Proof.
By induction over the definition of . We illustrate the case 4.1.2, where we have:
and . The derivation of ends by:
where for some ; ; for some ; finally . Let’s set . Then such a derivation can be rearranged as follows:
To see that this is a correct derivation, let us assume that , because is the side condition of case 4.1.2. Now is defined since , and we know that is defined. On the other hand if then because is defined; also if then since and and are compatible. It follows that is defined. Finally, assuming without loss of generality that as we know that , we conclude:
∎
Since no typable processes is an orchsynch error (Lemma 4.6), the following theorem property guarantees (see Corollary 4.10) that no error can appear during the evolution of a typable userdefined process.
Theorem 4.9 (Subject reduction).
If and then .
Proof.
By induction over the definition of . In case of rule [Link] we have:
for some such that . On the other hand by hypothesis and the shape of the rules, we have the derivation:
where has to be defined (namely ). This implies that:
is defined as well, so that using the fact that , we obtain the following derivation:
In case of rule [OrchComm] we have:
Let us suppose without loss of generality that so that . By hypothesis we have a derivation ending by:
for some such that , and such that . From the derivability of we deduce that for some ground , and that for some . Similarly we know that for some , and that .
Now from this and the fact that we infer by Definition 2.3 that and must be the same and that . Hence we have the derivation:
where follows by , derivability of , that and Lemma 4.7.
In case of [OrchDeleg] we have:
Then by hypothesis there exists the derivation:
where ; further, assuming w.l.o.g. that and hence that , we have , which implies that , , and . Therefore there exists the derivation:
where the fact that is well defined follows by the fact that
Comments
There are no comments yet.