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 ?

[psouquet]

Mon graphe n'est pas une proposition, c'est la hiérarchie actuelle des pages (version existante de cockpit).

Et je pense, au contraire, que le fil d'Ariane ne doit pas refléter le chemin pris pas l'utilisateur mais la position "physique" de l'artefact dans la topologie. Si l'utilisateur clique sur une SU, peu importe d'ou il vient il verra dans le fil: "Workspace1 -> Topologie > Bus1 > Container1 > Composant1 > SU1". Avec l'arbre, tout element est accessible à tout moment; ce serait vraiment confus d'afficher dans le fil le dernier parent uniquement si il a été visualisé juste avant.

[cdeneux]

Une instance de registry n'a de sens que pour un bus. Toutes les instances sont isolées les unes des autres.
Une registry (ou un cluster Hazelcast) peut héberger plusieurs instances de registry, donc être utilisé par plusieurs bus.

[vincent-zurczak]

Et je pense, au contraire, que le fil d'Ariane ne doit pas refléter le chemin pris pas l'utilisateur mais la position "physique" de l'artefact dans la topologie.

Le fil d'Ariane est une notion d'IHM.
On trouve aussi la notion de plan d'un site en général, même si ce n'est pas obligatoire.

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

Vous vous rendez compte que les formations Petals mentionnent toutes une topologie comme un "bus" ? Ce sont des conteneurs qui sont mis en relation les uns avec les autres et entre lesquels peuvent circuler des messages... Attention aux termes. Le but in fine, c'est quand même que Petals gagne des utilisateurs et des clients, il faut donc simplifier...

Ce que je propose :

• Avoir dans l'accueil de l'espace de travail une liste des topologies (indépendantes les unes des autres).
• Avoir, à la fin, ou au début de la liste, un item topologie transverse.
• Ramener la liste des services à ces 2 contextes, cad transverse ou interne à une topologie.
• Pour plus tard : placer les jonctions inter-topologies (via BC gateway).

Sans me retaper le graphe...

• Visualiser l'espace de travail
  ** Visualiser les contextes de travail (transverse / topologie spécifique)
  ** Visualiser les dernières actions
  ** (tous les autres trucs sur la page de l'espace de travail)

Si je décline la notion de contexte...

• Visualiser les contextes de travail (transverse / topologie spécifique - qui sont similaires, mais ont une portée différente)
  ** Gérer un conteneur
  ** Gérer un nœud de registry
  ** Accéder à l'annuaire de services

Quel que soit le contexte choisi, un clic dans l'arborescence mène à une URL / fil d'Ariane identique (Topologie > Conteneur > Artefact). Le contexte n'apparaît pas dans l'URL ou le fil d'Ariane. Selon le type d'utilisateur, en revanche, un contexte aura été préféré plutôt qu'un autre.

• Un exploitant passera par l'approche topologie, car il ne veut pas se tromper.
• Un architecte SI passera sans doute par l'approche transverse.

Quant à un noeud de registry...

• S'il est utilisé dans 2 topologies, il doit apparaître dans les topologies (approche topologie).
• Il n'apparaît qu'une fois dans la vue transverse.
• Il est probable qu'il faudra une vue additionnelle (plus tard) pour l'interconnexion des topologies.

[psouquet]

Et je pense, au contraire, que le fil d'Ariane ne doit pas refléter le chemin pris pas l'utilisateur mais la position "physique" de l'artefact dans la topologie.

Le fil d'Ariane est une notion d'IHM.
On trouve aussi la notion de plan d'un site en général, même si ce n'est pas obligatoire.

Dans ce cas là soit on ne met pas de fil d'Ariane soit on l’appelle autrement. Je ne vois pas l’intérêt de cette feature si on ne positionne pas l'artefact sur son bus/conteneur/(composant). Sinon c'est exactement comme l’existant autant ne rien toucher et enlever nos changements.

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

Vous vous rendez compte que les formations Petals mentionnent toutes une topologie comme un "bus" ? Ce sont des conteneurs qui sont mis en relation les uns avec les autres et entre lesquels peuvent circuler des messages... Attention aux termes.

Je pense qu'il faut trouver un autre nom à la "Vue topologies" alors. Ca fait un moment qu'on en parle mais on n'a pas trouvé de terme plus précis.

Et sinon j'ai du mal à visualiser ce que tu veux dire par item transverse. C'est une sorte d'item logique qui regroupe toute les topologies du workspace ?

[vincent-zurczak]

Cette notion que j'appelle transverse est ce que j'avais évoqué il y a quelques mois déjà. La vue arborescente qui contient tous les bus n'a d'intérêt que pour une vue SI. Mais elle prête à confusion pour un exploitant, qui travaille sur un bus.

Historiquement, un bus = une topologie = un ensemble de conteneurs Petals qui peuvent échanger des messages les uns avec les autres (via le transporteur). Cela exclut donc les inter-connexions entre des bus au travers du BC gateway. Depuis Petals 5, la notion de bus / topologie s'est enrichie des noeuds de registry.

Du point de vue d'un exploitant, il n'y a pas d'ambiguïté. C'est historique : 1 bus = 1 topologie. La nouveauté que Cockpit a introduite est cette vue multi-bus, multi-topologies, transverse. Et comme je le disais, elle n'a d'utilité que pour certains utilisateurs, à mon avis.

C'est la raison pour laquelle je propose que sur l'accueil d'un espace de travail, on puisse décider de travailler dans un contexte mono-topologie, ou dans un contexte multi-topologies. Quoique l'on choisisse, les IHM vont être quasi-identifiques, les sous-arbres des tâches sont les mêmes, l'expérience utilisateur très proche... mais un utilisateur passera par l'un ou l'autre et cela correspondra à ses objectifs.