Introduction
In our approach, the choreographies are published in a shared repository, similarly to the publication of a guideline by a committee. Participants search the appropriate choreographies when they need to perform an activity that requires the coordinated activity of other actors. The choreographies are matched against the participants' capabilities: the participants select the choreography that best fit them and advertise their intention to perform a role in them. If all the roles are filled, the interaction can start.
Interaction Models
The core concept is the shared interaction models (IM), performed by different applications and service providers. These actors are the participants, called peers, of the interactions, and they play roles in them. In an interaction all the roles have equal weight; the behaviour of all the peers and in particular their exchange of messages are specified.
IMs are written in the Lightweight Coordination Calculus (LCC) and published by the authors on the distributed discovery service (DDS) with a keyword-based description. LCC is a compact, executable choreography language based on process calculus.
An IM in LCC is a contract that defines the expected, externally observable, behavioural interfaces of the roles that participants can take in the interaction: an IM is a set of role clauses. Participants in an interaction take their entry-role and follow the unfolding
of the clause specified using combinations of the sequence operator (then) or choice operator (or) to connect messages and changes of role. Messages are either outgoing to (⇒) or incoming from (⇐) another participant in a given role. A participant can take, during an interaction, more roles and can recursively take the same role (for example when processing a list). Message input/output or change of role is controlled by constraints. In its definition, LCC makes no commitment to the method used to solve constraints - so different participants might operate different constraint solvers.
More information on LCC can be found here.
Lifecycle
A peer that wants to perform some task, such as providing an imaging service for breast cancer screening, searches for published IMs for the task by sending a keyword-based query to the DDS. The DDS collects the published IMs matching the description (the keywords are extended adding synonyms to improve recall) and sends the list back to the peer, that needs to choose the one to subscribe.
The peer matches the annotated signatures of the constraints and of the methods creating adaptors, that bridge the constraints to the methods. An adaptor has a confidence level, reflecting the distance between the constraints and the matching method, that gives a measure of how well the peer can execute an interaction, and it used to select the most fitting IM. Once the peer has selected an IM, it subscribes to its role in the discovery service.
When all the roles are filled, the discovery service chooses randomly a peer in the network as coordinator for the interaction, and hands over the IM together with the list of involved peers in order to execute it.
The coordinator first asks each peer to select the peers they want to interact with, forming a mutually compatible group of peers out of the replies. The selection process is subjective to the peers. All the participants receive the list of peers subscribed to all the roles, and they can check the subscriptions, selecting the preferred ones. A peer can also select none of the participants, excluding itself from a particular run of the interaction, for instance due to overload. The framework provides only an interface for the selection method, as its implementation is delegated to the application developer.
