Phase 3 Architecture collaborative Y. Stroppa – A. Ly – F. Badin Bddictionnairique Phase 3 Architecture collaborative Y. Stroppa – A. Ly – F. Badin

Sommaire Introduction Architecture Explication sur le fonctionnement Conclusion

Introduction Actuellement existe au sein de l’application des mécanismes de transferts de données (MajBddClient et MajBddServeur) entre des postes utilisateurs et celui de l’administrateur applicatif. Cette solution a été très peu utilisée et utilisée dans un contexte de proximité. Après divers tests et utilisation, la solution mise en place semble compliquée à utiliser et présente des bogues (détérioration de l’ensemble de la base de données). De plus elle ne permet pas d’étendre le concept multi-auteurs et multi-utilisateurs dans les aspects de sélection et d’extraction. C’est pour cela que nous allons reposer les bases d’une application collaborative et proposer une nouvelle version de l’ensemble. Ce diaporama décrit les fonctionnalités recherchées dans le cadre de cette mise en place de la nouvelle architecture de Bddictionnairique. L’objectif est de favoriser l’échange et la collaboration entre les chercheurs, de permettre une utilisation plus importante des membres internes et éventuellement externes du LLL pour enrichir l’application.

Introduction Tout utilisateur aura la possibilité de compléter la base de données à travers l’application Bddictionnairique. Ajouter des commentaires, des corrections et produire des extractions. Les modifications/corrections pourront être conserver en local et/ou diffuser vers les autres utilisateurs. Ceci devrait permettre une synergie entre les différents utilisateurs. Afin de maitriser et de contrôler la qualité des apports, une étape de contrôle avant diffusion sera effectuée. Elle sera réalisée par un ou plusieurs modérateurs. Déroulement d’une modification et diffusion: De façon simple (mail ou notification) le modérateur doit être averti des ajouts/modifications proposées par les utilisateurs. Il doit pouvoir les consulter, les apprécier et les valider. Une fois validées, il doit pouvoir reconstruire une nouvelle version des données pour permettre son utilisation par l’ensemble des utilisateurs. Chaque modification et/ou ajout de données donnera lieu à une diffusion sur le site de l’application. Les informations que l’on pourra consulter devront indiquer l’auteur, la date et la nature de l’information fournie. Afin d’éviter le transport de la totalité de la base de données vers les postes clients, les modifications seront conserver une forme très légère (identique à un patch) qui viendront compléter la base de données cible.

Architecture proposée MSH Deux rôles : * Site web de l’application: communication et informations * Service API-REST pour les aspects collaboratifs Poste utilisateur Poste utilisateur Poste utilisateur Poste modérateur Poste modérateur Pre-prod prod

MSH – Sites Sur la MSH deux sites vont voir le jour : Un site dédié à la communication sur l’application. Information générale sur l’application et les personnes attachées à ce projet L’application en téléchargement Les informations utilisateurs et manuels divers Un forum de discussion autour de l’application Constitution: CMS Un site dédié à l’application Les dépôts des correctifs apporter par les utilisateurs Les bases de données et leurs suivis Constitution : Api Rest Intérêts d’avoir les deux fonctionnalités dissociées : Les aspects fonctionnels ne sont pas dans le même domaine d’utilisation Aspect uniquement Web pour le premier et le deuxième des connexions via directement l’application. Les besoins d’accès ne sont pas au même niveau Le web : via le CMS et uniquement de l’alimentation de page web Le site API-REST de service : un niveau d’accès administrateur et des ouvertures de ports spécifiques

Scénario d’une mise à jour Un utilisateur à partir de l’application bddictionnairique peut ajouter des notes et commentaires divers sur les mots ou groupes de mots, peut également faire des extractions selon des critères complexes. L’ensemble de ses ajouts sera ainsi préservé en local dans un espace dédiée à l’application. Pour partager ces modifications il lui suffira de se connecter avec au préalable une identification user/passwd et affiliation et de déposer transférer ses modifications. Pour récupérer des modifications, l’application au démarrage si une connexion est possible demandera au site web API si des modifications sont disponibles et si c’est le cas un téléchargement aura lieu pour réactualiser sa base locale. Partie réservée aux Administrateur de l’application : Association-dissociation (les links entres les différents dictionnaires) afin de modifier les liens (voir remplissage_tables).

Scenario Afin d’éviter de stocker l’ensemble de la base de données et d’échanger ainsi des volumétries importantes, on s’attachera à ne transférer que les différences sous une forme réduite (forme SQL éventuellement). En d’autres mots ne conserver que les instructions de modifications et non pas la modification elle même le tout appliquée à une version de la base de données. On vérifiera ainsi qu’il n’y ait pas de conflit de modification multiple sur une même donnée.

Echanges entre l’application bddictionnairique et le serveur web. Demande maj D: maj-Appli-bdd Site web /API Application bddictionnairique D: extractions Collections extractions U: extraction(s) U: correction(s) U: suivi des corrections Bdd Vx.y

Détails des échanges D: maj-bdd D: extractions U: extraction L’application locale effectue une demande de réactualisation de la base de données et de l’application. Si une mise à jour est disponible, l’application doit informer l’utilisateur de cette possibilité et lui permettre de procéder à cette opération. Dans le cadre de la mise à jour de la base de données, il faudra lancer le download de la base de données, ensuite procéder à la fermeture des connexions sur la bdd et procéder à la réactualisation interne mysql de la nouvelle base de données. On conservera une version ancienne de la bdd pour une éventuelle reprise. Si c’est la mise à jour de l’application, il faudra procéder à un dowload de la nouvelle version, à une recopier du fichier jar sous un nouveau nom (attention au système hôte ) et à relancer l’application avec le nouveau jar. D: extractions Possibilité à l’utilisateur de remonter une extraction. Chaque extraction devra être associé à un nom d’utilisateur et d’un niveau d’accessibilité (tout public ou groupe d’utilisateurs). Il recevra une notification d’enregistrement sur le serveur. Une fois la notification effectuée, elle sera ensuite publiée (à voir si on met un modérateur ou pas). U: extraction Possibilité de téléchargement d’une extraction dans son panel interne et de l’exécuter. On pourra le cas échéant l’exécuter en dehors de l’application en mode console. Ou de façon interactive. U: correction L’utilisateur doit pouvoir visualiser les différents correctifs et apports effectués au niveau de son application et pouvoir les transférer sur le serveur.

Détails des échanges U: Suivi des corrections Permettra à un utilisateur de connaître l’état de ses correctifs : Validé, pas validé … Permette à l’administrateur de l’application de regarder les propositions et les différentes informations asscoées (provenance et explications complémenatires) de les valider et de reocmposer ainsi une nouvelle version de la bdd pour une prochaine diffiusion. Afoin d’éviter de devoir diffuser à chauqe correctif, il aura la possibilité de déclencher l’operation de consolidartion qui pourra prndre un ensemble de dmoifications de d’apporter les correctifs;

Conclusion Il faut valider les aspects fonctionnels de la partie collaborative Il faut ensuite débloquer les moyens à mettre en place associé à cette partie Organiser une réunion si besoin avec la MSH pour appuyer ces demandes de moyens Fixer le calendrier des opérations