Hiérarchie & pages

[psouquet]

Je lance ici la conversation sur la hiérachie et la liste des pages de petals cockpit. En lien avec la liste des cas d'usages qui seront mis à jours après cette issue.

---

Originally posted by @vincent-zurczak in #12 (comment)

C'est amusant, parce que c'est le genre de questions auxquelles répond un arbre des tâches. 🙊

digraph G {
    
    style=filled;
    color=lightgrey;
    node [style=filled,color=white];
    a0 [label="Accueil / Sélection des espaces de travail"]
    a1 [label="Espace de travail"]
    a2 [label="Topologies"]
    a3 [label="Conteneur"]
    a15 [label="Registre"]
    a4 [label="Services"]
    a0 -> a1;
    a1 -> a2;
    a2 -> a3;
    a2 -> a15;
    a2 -> a4;
    
    a5 [label="Composants"]
    a55 [label="<Composant> ?"]
    a6 [label="Service Units"]
    a66 [label="<su> ?"]
    a7 [label="Service Assemblies"]
    a77 [label="<sa> ?"]
    a8 [label="Shared Libraries"]
    a88 [label="<sl> ?"]
    a10 [label="admin"]
    a3 -> a10 [style=dashed];
    a3 -> a5; a5 -> a55 [style=dashed];
    a3 -> a6; a6 -> a66 [style=dashed];
    a3 -> a7; a7 -> a77 [style=dashed];
    a3 -> a8; a8 -> a88 [style=dashed];
    
    a9 [label="Services (vue transverse)"]
    a1 -> a9;
}

Pour info, j'ai utilisé cet éditeur pour créer le graphe, et ce site pour l'encoder dans l'URL. L'arbre est un peu fait à l'arrache, je n'ai pas tout précisé. Faîtes simple, considérez la SU comme une SA ou une SL. Tout est au niveau du conteneur. Inutile de rendre les choses plus compliquées pour l'utilisateur... 🙄

URL	Fil d'Ariane	Commentaire
/dev/t	Dev > Topologies	Liste de toutes les topologies dans l'espace dev.
/dev/t/ma%20topologie	Dev > ma topologie	Accès à une topologie.
/dev/t/ma%20topologie/c	Dev > ma topologie > Containers	La liste des conteneurs dans cette topologie.
/dev/t/ma%20topologie/c/bus-0	Dev > ma topologie > Bus-0	Les informations et l'administration de Bus-0.
/dev/t/ma%20topologie/r	Dev > ma topologie > Containers	La liste des registres dans cette topologie.
/dev/t/ma%20topologie/s	Dev > ma topologie > Services	La liste des services dans cette topologie.

Dans ce tableau, les listes ne sont pas accessibles directement dans le fil d'Ariane. Mais le but du fil est de savoir où on est, pas forcément d'avoir accès à tous les liens possibles.

En fait, les vraies questions qui se posent, c'est de savoir quels niveaux se déclinent en pages. Est-ce qu'on veut une page dédiée pour une service unit ? Est-ce que ça a un sens ? Ou bien est-ce qu'une liste avec une vue détaillée suffit ? De même, est-ce qu'on fait une page dédiée pour les actions d'administration sur un conteneur ? Ou bien est-ce que la page d'accueil du bus suffit ? Elle contiendrait alors les options d'administrations et des liens vers les différentes listes d'artefacts.

Autres questions posées par le tableau que je viens de créer : est-ce que le nom autorise les espaces ? Est-ce que les alias ou la casse sont acceptés ? Ma topologie est-elle équivalente à ma topologie et ma-topologie ? J'aurais tendance à dire oui, et que c'est une contrainte à poser. Et cela aura des répercussions dans Petals (parseur de topologie, server.properties, librairie de déploiement) et dans le back-end de Cockpit (base de données, vérifications).

[psouquet]

Originally posted by @bescudie in #12 (comment)

J'ai refait l'arbre des pages:

Le fil d'ariane n'est présent que dans les pages Espaces de travail, car Admin PetalsCokpit et User sont des "Dialog"
Pour le Fil d'Ariane cela donne:

URL	Fil d'Ariane	Commentaire
/W=idWksp	Dev	Page générale du workspace "Dev" id="idWksp", description...
/W=idWksp /T/B=idBus	Dev>Topologie> nameBus	Page du Bus id="idBus" et nom="nameBus" dans le wkspce "Dev"
/W=idWksp /T/B=idBus/C=idCont	Dev>Topologie> nameBus>nameCont	Page Container id="idCont" et nom="nameCont" du bus idBus dans le wkspce "Dev"
/W=idWksp /T/B=idBus/C=idCont/cp=idComp	Dev>Topologie> nameBus>nameCont>nameComp	Page Composant id="idComp" et nom="nameComp" du container idCont du bus idBus dans le wkspce "Dev"
/W=idWksp /T/B=idBus/C=idCont/sa=idSA	Dev>Topologie> nameBus>nameCont> nameSA	Page de la SA id="idSA" et nom="nameSA" du container idCont du bus idBus dans le wkspce "Dev"
/W=idWksp /T/B=idBus/C=idCont/cp=idComp/su=idSU	Dev>Topologie> nameBus>nameCont> nameComp>nameSU	Page de la SU id="idSU" et nom="nameSU" sur le composant idComp du container idCont du bus idBus dans le wkspce "Dev"
...	...	...
/W=idWksp /S/I=idInterface	Dev>Service> nameInterface	Page de l'Interface de Service id="idInterface" et nom="nameInterface" dans le wkspce "Dev"
...	...	...

[psouquet]

Originally posted by @vincent-zurczak in #12 (comment)

Dans la vue qui affiche tout (disons l'explorateur), il est intéressant que les SU apparaissent sous les composants (c'est une vue logique). Mais dans le cadre de la gestion des artefacts, ça oblige à connaître le composant avant d'accéder à une SU. Et si l'utilisateur ne sait pas à quel composant elle est rattachée ? Ou s'il veut une vue globale de toutes les SU (rien que les SU) ?

Plus globalement, la SU associée au composant, c'est comme ça que c'est fait dans Petals, parce que ça vient de JBI. Mais chez les ESB concurrents, tout est au même niveau. Et tous ont un équivalent des SU et des SA. Avoir les deux accès (par le composant ou depuis le conteneur) serait donc préférable. En gros, SU et Composants seraient côte-à-côte, et il y aurait une flèche qui va de Composants vers SU.

Pour le fil d'Ariane.... nameCont> nameComp>nameSU laisse penser que l'ID de la SU est propre au composant, alors que dans Petals, cet ID est unique sur le conteneur (le composant ne vérifie rien de mémoire). Dans les faits, nameCont> nameSU serait plus simple.

[cdeneux]

Voici ma vision avec la notion de model. Dans Topologies, il manque le niveau bus.

digraph G {
    
    style=filled;
    color=lightgrey;
    node [style=filled,color=white];
    a0 [label="Accueil / Sélection des espaces de travail"]
    a1 [label="Espace de travail"]
    a2 [label="Vue Topology"]
    a25 [label="Bus importé"]
    a3 [label="Conteneur"]
    a15 [label="Registry node"]
    a0 -> a1;
    a1 -> a2;
    a2 -> a25;
    a25 -> a3;
    a25 -> a15;
    
    a5 [label="Composants"]
    a55 [label="<Composant> ?"]
    a6 [label="Service Units"]
    a66 [label="<su> ?"]
    a7 [label="Service Assemblies"]
    a77 [label="<sa> ?"]
    a8 [label="Shared Libraries"]
    a88 [label="<sl> ?"]
    a10 [label="admin"]
    a3 -> a10 [style=dashed];
    a3 -> a5; a5 -> a55 [style=dashed];
    a3 -> a6; a6 -> a66 [style=dashed];
    a3 -> a7; a7 -> a77 [style=dashed];
    a3 -> a8; a8 -> a88 [style=dashed];
    
    ab25 [label="Based-model bus"]
    ab3 [label="Conteneur"]
    ab15 [label="Registry node"]
    a2 -> ab25;
    ab25 -> ab3;
    ab25 -> ab15;
    
    ab5 [label="Composants"]
    ab55 [label="<Composant> ?"]
    ab6 [label="Service Units"]
    ab66 [label="<su> ?"]
    ab7 [label="Service Assemblies"]
    ab77 [label="<sa> ?"]
    ab8 [label="Shared Libraries"]
    ab88 [label="<sl> ?"]
    ab10 [label="admin"]
    ab3 -> ab10 [style=dashed];
    ab3 -> ab5; ab5 -> ab55 [style=dashed];
    ab3 -> ab6; ab6 -> ab66 [style=dashed];
    ab3 -> ab7; ab7 -> ab77 [style=dashed];
    ab3 -> ab8; ab8 -> ab88 [style=dashed];
    
    a9 [label="Vue Services"]
    a1 -> a9;
    a11 [label="Vue API"]
    a1 -> a11;
    
    
    vuemodel [label="Vue Model"]
    a1 -> vuemodel
    modeltopology [label="Model de topology"]
    modelservices [label="Model de services"]
    modelbus [label="Model de bus"]
    vuemodel -> modeltopology
    vuemodel -> modelservices
    vuemodel -> modelbus
    ab25 -> modelbus [style=dashed, label="est une instance de"];
}

[vincent-zurczak]

Cela ferait une hiérarchie à 7 niveaux.
Cela fait beaucoup. En IHM, il faut se souvenir que l'on peut mémoriser 6-7 items (mémoire à court terme).

Un arbre des tâches n'est pas un méta-modèle. ❕

[psouquet]

@cdeneux c'est quoi Based-model bus et Vue model ? Un model généré depuis un bus et un model entièrement logique ?

Aussi, vous voulez dire quoi avec <xxx> ? que c'est un artefact ? une ressource ?

[cdeneux]

Based-model bus est un bus instancié depuis un model. A distinguer d'un bus simplement importé, et donc lié à un model.
La modification d'un Based-model bus ne peut se faire qu'au travers d'une modification de son model au contraire du bus importé sur lequel on peut (un)deployer comme on veut.
Vue model est la vue qui permettra la création et l'édition des différents modèles.

[psouquet]

Dans ce cas je pense qu'on peut simplifier comme ça :

Je trouve que ca n'a pas trop de sens que la registry soit "sous" le bus, c'est au même niveau ou "au dessus" selon moi.

Je pense que les vues des bus importés et des bus basés sur un modèle seront assez différentes, mais que les vues des conteneurs/artefacts liés seront similaires, autant les fusionner.
De plus, Bertrand veut que l'on puisse ajouter des conteneurs/artefacts logiques (modèles) depuis la vue topologie, un peu comme un patch. On n'aura probablement pas de bus entièrement physique. Je crée une issue pour ca sinon ca fera trop ici. (edit: issue #14 )

digraph G {
    
    style=filled;
    color=lightgrey;
    node [style=filled,color=white];
    a0 [label="Accueil / Sélection des espaces de travail"]
    a1 [label="Espace de travail"]
    a2 [label="Vue Topology"]
    a25 [label="Imported bus"]
    a22 [label="Registry node"]
    a22 -> a25 [style=dashed label="registers"];
    a22 -> ab25 [style=dashed label="registers"];
    a0 -> a1;
    a1 -> a2;
    a2 -> a25;
    a2 -> a22;
    
    a3 [label="Conteneur"]
    a25 -> a3;
    a5 [label="Composants"]
    a6 [label="Service Units"]
    a7 [label="Service Assemblies"]
    a8 [label="Shared Libraries"]
    a3 -> a5;
    a3 -> a6; 
    a3 -> a7; 
    a3 -> a8; 
    
    ab25 [label="Model-based bus"]
    a2 -> ab25;
    ab25 -> a3;
    
    
    a9 [label="Vue Services"]
    a1 -> a9;
    a11 [label="Vue API"]
    a1 -> a11;
    
    
    vuemodel [label="Vue Model"]
    a1 -> vuemodel
    modeltopology [label="Model de topology"]
    modelservices [label="Model de services"]
    modelbus [label="Model de bus"]
    vuemodel -> modeltopology
    vuemodel -> modelservices
    vuemodel -> modelbus
    ab25 -> modelbus [style=dashed, label="instance of"];
}

[cdeneux]

Petite correction, c'est une registry (et non un registry node) qui peut-être utilisée par plusieurs bus.
Non, les vues bus importés et bus basés sur un modèle devraient être identique, à part peut être l'overview du bus. Par contre, les actions possibles seront différentes.

[psouquet]

Euh, pour moi les vues bus importés et bus basés sur un modèle sont des overviews (quand tu clique sur un bus dans l'arbre en gros). Je les ai laissés séparés pour conserver le lien d'instanciation vers le modèle de bus.
Les actions sont différentes sur tous les artefacts selon si ils sont sur un bus importé ou basé sur un modèle non ? (pas possible de deploy/undeploy sur un bus de modèle)

[cdeneux]

Oui, mais par contre on a le même arbre pour les deux types de bus

[psouquet]

Il y a quelque chose que je ne comprend pas en fait avec ces diagrammes. Je ne comprend pas ce qu'ils représentent vraiment. Est-ce que c'est vraiment la hiérarchie (dans le sens route, cheminement) des pages que l'on veut ou juste la représentation au sens Petals de ces pages (ie: ce que l'on voit dans le fil d'Ariane).
A l'heure actuelle la hiérarchie (cheminement) est comme cela:

Quand on est sur la "vue topologie" (ie: l'arbre est affiché, il n'y a pas de vue à proprement parler) on peut accéder à tout artefact du Bus directement. Je pense que l'on veut conserver cela, ce serait rébarbatif de devoir passer par tous les parents pour voir les détails d'une SU... Cependant, le but du fil d'Ariane est d'aider à la navigation, donc il faut y représenter hiérarchiquement les elements parents au sens Petals. Non ?

Graphe

digraph G {
    
    style=filled;
    color=lightgrey;
    node [style=filled,color=white];
    a0 [label="Accueil / Sélection des espaces de travail"]
    a3 [label="Administration"]
    a0 -> a3 [style=dashed label="admin"];
    a5 [label="Preferences"]
    a0 -> a5;
    
    a1 [label="Espace de travail"]
    a2 [label="Vue Topology"]
    a25 [label="Bus"]
    a0 -> a1;
    a1 -> a2;
    a2 -> a25;
    
    a23 [label="Conteneur"]
    a2 -> a23;
    a29 [label="Composants"]
    a26 [label="Service Units"]
    a27 [label="Service Assemblies"]
    a28 [label="Shared Libraries"]
    a2 -> a29;
    a2 -> a26; 
    a2 -> a27; 
    a2 -> a28; 

    a9 [label="Vue Services"]
    a1 -> a9;
    a91 [label="Service"]
    a92 [label="Interface"]
    a93[label="Endpoint"]
    a9 -> a91;
    a9 -> a92;
    a9 -> a93;
}

[vincent-zurczak]

OK avec la dernière proposition.
La vue "topologie" est l'arborescence de tout ce qui compose la topologie, ce qui devrait inclure les noeuds de registry de service.

• Un modèle de bus doit aussi pouvoir être visualisé sous cette forme.
• Un bus = une topologie, pourquoi remettre le bus sous la topologie ?
• Il manque le noeud de registry sous la topologie.

L'arbre est plus lisible en l'état, mais on peut s'interroger sur le fil d'Ariane qui en découle. Le fil d'Ariane ne doit pas représenter une vue logique de Petals, mais le chemin par lequel l'utilisateur est arrivé sur la page actuelle. C'est de l'IHM. Cependant... Si la vue topologie est arborescente, rien n'interdit que le lien (URL) et le fil d'Ariane incorporent des données arborescentes. En tout cas, le point de vue se défend. Ainsi, si je clique dans l'arbre sur "Container 1 > SU 1", cela peut m'emmener vers "container-1/su-1" et afficher le fil "Container 1 > SU 1".

[bescudie]

Une topologie = 1 Bus, mais dans la vue Topologie d'un workspace il y a 1..n Bus

[bescudie]

La question à trancher est de savoir si la Registry est rattaché à un SEUL bus.
Techniquement le(s) même(s) serveur(s) de registry peu(ven)t servir à plusieur Bus (?).
Est-ce que cela à un sens de partager une Registry entre plusieurs Bus ?