Service de gestion de session

Les Diagrammes de Coordination présentés au chapitre précédent donnent les configurations qui sont requises pour la réalisation du travail collaboratif associé au groupe. Ils définissent ainsi les structures valides de la session. Le but premier du Service de Gestion

de Session (SGS) que nous avons proposé est de garantir que, à chaque instant, la session qu’il

manipule respecte une configuration valide. Cette propriété reste garantie pendant la dynamique de la session, dynamique qui survient au niveau du groupe, des rôles des membres, et des outils qu’ils manipulent. Pour cela, le service de gestion de session SGS doit coordonner la prise en compte des événements de session avec le passage d’une configuration valide vers une autre.

2.1.1 Description

Le service proposé contrôle l’évolution du groupe coopératif dans le temps. Il cherche, dès que possible, à passer d’une configuration valide (dans laquelle les membres collaborent en mode synchrone) vers une autre configuration valide, en prenant en compte les requêtes d’entrée et de sortie de la coopération, qui proviennent des membres du groupe. Ce service se charge de l’évolution dynamique de la session, et garantit que, après la prise en compte de requêtes d’entrées/sorties, la structure courante de la session respecte toujours une configuration valide prédéfinie.

Lors de l’arrivée de requêtes d’entrée/sortie, le système propose la nouvelle configuration valide possible à l’ensemble des membres déjà présents en coopération synchrone. Plusieurs possibilités sont envisageables pour changer de configuration. La première est de changer de configuration chaque fois que cela est possible. Le système qui gère la coopération réalise la modification pour chaque nouvelle configuration. La deuxième possibilité, qui a été retenue ici, est de considérer le changement de configuration comme une décision coopérative et d'utiliser un mécanisme générique pour implanter une technique de décision de groupe. Par conséquent, la possibilité de changement se voit proposée à l'ensemble des membres présents en coopération. Ces derniers votent pour accepter ou pour refuser de changer de configuration. Le type et les règles de vote sont spécifiés par l'application coopérative. Suivant le résultat, la configuration valide courante est changée ou non. La structure courante de session reste inchangée si le vote est refusé.

2.1.2 Phases d’évolution et cohérence

Le service SGS gère deux étapes, lorsque la coopération est en cours : la première est l’étape de coopération proprement dite, dans laquelle les membres réalisent le travail de groupe et échangent des informations en suivant la structure de la session.

La seconde étape est celle de la prise de décision lorsque les membres présents votent. Le service de gestion de session supervise le processus de vote. Le changement potentiel de la structure de la session doit être accepté par les membres qui sont actuellement présents en coopération. A la fin de cette étape, le service leur transmet le résultat.

Lors d’une analyse plus fine du comportement du service de gestion de session, il apparaît que les échanges de données peuvent interférer avec les changements de la structure de la session dans le temps, et de ce fait ces deux éléments doivent être synchronisés entre eux. Deux principales synchronisations des données sont nécessaires : avant de changer de structure de session, les données manipulées par les membres doivent atteindre un état cohérent, état qui respecte la structure du diagramme de coordination courant. L’hypothèse minimale retenue par ce service est qu’un état cohérent est obtenu lorsque tous les échanges de données non volatiles entre les membres présents en coopération sont terminés : les membres accèdent alors aux même valeurs pour toutes les données.

Lorsqu’un changement de groupe a été décidé, les nouveaux membres en coopération doivent échanger entre eux l’ensemble des informations initiales qui composent le contexte de chacun, en suivant la structure de la session, ceci avant de commencer la nouvelle coopération. En effet, les nouveaux arrivants n’ont pas connaissance du contexte des autres coopérants avec lesquels ils sont en relation suivant le diagramme de coordination. De la même façon, les anciens coopérants, qui restent dans le groupe, doivent obtenir les contextes des nouveaux arrivants.

Ces besoins en synchronisation se décomposent en quatre phases différentes :

(1) Echange des contextes initiaux entre les membres de la nouvelle configuration. (2) Réalisation du travail en session.

(3) Suspension des échanges de données avec état cohérent pour terminer la configuration courante valide.

(4) Restructuration de la session

2.1.3 Primitives de service

Les primitives de service pour définir le service SGS, sont regroupées par unités fonctionnelles dans le tableau 3.1.

Dans la colonne sens d’utilisation, les flèches indiquent que la primitive va d’un utilisateur vers le service de gestion de session. Les flèches indiquent que la primitive va du service vers l’utilisateur.

Les primitives des unités fonctionnelles d’entrée et de sortie des participants provoquent l’évolution de la session dans le temps. Les primitives de décision permettent à chaque participant présent en session d’accepter ou de refuser un changement. Lorsqu’un changement est accepté, la primitive de changement de configuration informe de la nouvelle configuration de session mise en place. Les primitives d’échange des contextes initiaux interviennent dès la mise en place d’une nouvelle configuration de session. Les primitives d’échange de données

sont utilisées pendant le travail collaboratif associé au groupe. Les primitives de cohérence des échanges permettent de synchroniser les participants avant tout changement de configuration et informent de la cohérence des contextes après la mise en place d’une nouvelle configuration de session.

Nom Sens d’utilisation

Rôle

Entrée d’un participant

joinSessionReq ( id: session_id; role: role_type) joinSessionInd ( id: session_id; result: boolean, session: session_type)

Un participant demande à entrer dans la session courante.

Cette indication signale si l’entrée a été acceptée ou non. Dans l’affirmative, "session" contient la configuration courante.

Sortie d’un participant

leaveSessionReq ( id: session_id)

leaveSessionInd ( id: session_id; result: boolean)

Un participant demande à quitter la session courante.

Cette primitive signale si la sortie a été acceptée ou non. Prise de décision voteInd ( id: session_id; newsession: session_type) voteResp ( id: session_id; result: boolean)

Une nouvelle session courante est possible et les participants présents votent pour accepter ou refuser le changement.

Décision de chaque participant.

Changement de configuration

newSessionInd ( id: session_id; result: boolean;

newsession: session_type)

Cette primitive signale si le changement dans la session courante a été accepté ou non. Dans l’affirmative, "newsession" contient la nouvelle configuration courante.

Echange des contextes initiaux

contextReq ( id: session_id; data: data_type) contextInd ( id: session_id; data: data_type)

Un participant transmet son contexte initial aux membres avec lesquels il est en relation.

Réception des contextes initiaux des autres participants.

Echange de données dataReq ( id: session_id; data: data_type) dataInd ( id: session_id; data: data_type)

Un participant envoie une unité de donnée.

Réception d’une unité de donnée.

Cohérence des échanges

noNewDataInd ( id: session_id)

dataCoherentInd ( id: session_id)

Suspension des échanges de données d’un participant pour atteindre un état cohérent.

Les contextes des participants sont cohérents : le travail peut continuer

Table 3.1. Primitives du service SGS