Modèle organisationnel de l’architecture UBIS: Qui fait Quoi?

Dans l’architecture UBIS tout est considéré comme un service. A chaque niveau de visibilité de l’architecture, on peut trouver des composants de service qui rendent un service de type contrôle «CSC», Applicatif «ASC» ou gestion «GSC» qui participent aux différentes phases de la session «user-centric». Dans une architecture de volume et complexité importantes, il est intéressant d’avoir multiples points de contrôle et de gestion qui participent au maintien du service avec le niveau de la QoS requis au cours de la session de l’utilisateur, et cela suivant une approche Top .Down du niveau service (VPSN) au niveau utilisateur (VPUN) pour assurer un pilotage dynamique de la qualité de service de bout en bout. Cet aspect organisationnel nous conduit à prendre comme notion clé l’agent-QoS qui sera intégré dans tout type de services de l’architecture à tous les niveaux de visibilité, c’est-à-dire que chaque composant de chaque niveau architectural sera piloté et invoqué en fonction de son comportement (QoS), qui est contrôlé et géré par son agent de QoS au cours de la session UBIS.

Acteurs (Composant de service)

 Le modèle organisationnel de l’architecture repose sur l’attribution des acteurs et cela pour améliorer la capacité d’actions lorsqu’un changement de QoS apparait suite à la mobilité (utilisateur, terminal, service, session) ou à un dysfonctionnement d’un composant de service. Pour ce faire, chaque acteur doit jouer un rôle organisationnel au sein du niveau de visibilité auquel il appartient (cross-layer) ou bien entre les niveaux de visibilité (intra-layer) pendant la phase de l’exploitation pour participer au processus d’adaptation et du maintient de la QoS de bout en bout pour l’utilisateur final, et il peut être: – Initiateur: représente l’entité qui détecte le changement de QoS grâce à son agent de QoS au cours de la session d’un utilisateur, et se charge d’informer le décideur qui puisse se trouver soit dans le même niveau de visibilité N ou bien dans un niveau de visibilité supérieur (N+1) ou inferieur (N-1), pour qu’il prenne les décisions nécessaires pour maintenir la chaine de QoS de bout en bout. – Décideur: représente l’entité qui se charge de prendre les mesures nécessaires pour alimenter les informations décisionnelles, conformément à ses responsabilités et cela en fonction de son niveau de visibilité. – Exécuteur: représente l’entité qui contrôle le changement de la QoS et effectue les adaptations nécessaires. 

 Les rôles de l’agent de QoS 

L’agent de QoS proposé est un élément générique qui offre une autonomie de traitement de la qualité de service à un composant de service pour avoir une meilleure performance de la QoS au cours de la session de l’utilisateur. Il prend en charge le processus de mesure des ressources internes et également le processus de communication, il assure une coopération au niveau horizontal entre les composants de service quand il s’agit des composants du même niveau de visibilité, et une coordination pour assurer l’agrégation des besoins QoS entre les différents niveaux de visibilité. L’agent de QoS est une entité stable et selon la stratégie de l’organisation et les besoins au cours de la session des rôles lui sont attachés et qui peuvent être de type : Passif, Actif, Interactif ou Proactif .- Le rôle passif désigne l’état où l’agent QoS assure uniquement le traitement interne; il mesure la QoS et met à jour les valeurs de QoS courantes. Dans le cas de non-respect du contrat de QoS c.-à-d. le dépassement des valeurs seuils, il ne communique pas son état à son environnement sauf dans le cas où il est sollicité par sa communauté pour l’informer dans quel état il se trouve. – Le rôle Actif désigne l’état où l’agent-QoS joue le rôle de métrologue et de controleur de la QoS, et il notifie régulièrement, à qui a le droit, le statut de QoS de son composant de service, c’est-à-dire s’il respecte toujours son contrat de service ou bien s’il est hors de contrat de service (In contrat/Out contrat). – Le rôle Interactif désigne l’état où l’agent-QoS est doté d’une capacité d’interactions avec d’autres Agent-QoS. Il peut négocier les paramètres QoS à maintenir dans un même niveau de visibilité, ou bien entre les composants de service à activer dans les autres niveaux de visibilité pour assurer le mappage entre les différents paramètres de QoS et par conséquent avoir une solution de bout en bout. – Le rôle Proactif désigne l’état où l’agent QoS possède les connaissances et les règles qui lui permettent de prendre les décisions tout seul, pour remedier à un problème qui lui est propre ou qui relève de son domaine de responsabilité, et il doit envoyer des notifications à qui de droit.

Les fonctionnalités de l’agent QoS

Comme nous l’avons déjà présenté précédemment, L’agent QoS est une entité autonome intégrée dans chaque composant de service qui mesure la QoS en temps réel pour détecter la défaillance au bon moment durant les changements (mobilité, préférences, dégradation). Nous expliquons dans ce qui suit, les éléments fonctionnels de l’agent de QoS qui sont, d’une part, liés au traitement interne pour assurer une réservation des ressources selon la demande de l’utilisateur, et d’autre part, liés à la communication pour assurer une coordination et une coopération entre les différents composants de services appartenant aux différents niveaux de visibilité de l’architecture UBIS. L’agent QoS s’appuie sur deux éléments fonctionnels de gestion: IQM (Internal QoS manager) et EQM (External QoS manager)(Figure 16): L’IQM est en charge de la gestion et le contrôle local de la qualité de service spécifique pour chaque composant de service. Il surveille les ressources internes du composant de service pour maintenir la QoS. Les fonctions principales d’IQM proposées sont les suivantes: – Local QoS Manager : informe le plan de contrôle des ressources dont il a besoin pour assurer son traitement interne. – QoS Profile Manager : gère le profil de la qualité de service pour chaque élément de service. Il assure en temps réel le traitement nécessaire pour connaître le statut du composant de service en termes de contrat de QoS pendant l’exploitation (In contrat/Out contrat). En effet, l’IQM s’interface avec les bases de données utilisateur et opérateur nommées respectivement Infosphère et Infoware pour l’échange d’informations nécessaires au traitement interne. La principale fonction de l’EQM est la communication et la coordination entre les ressources QoS des différents niveaux de visibilité et il permet également le mappage des paramètres QoS entre les différents nœuds de l’architecture, ce qui permet une continuité de session en cas de dégradation de la qualité de service et ce quel que soit le type de mobilité. Les fonctions principales d’EQM proposées sont les suivantes : – QoS Mapping/Translation Parameters : assure le mappage et la translation des mécanismes et paramètres de QoS utilisés. Ce qui permet la déclinaison des  paramètres QoS entre les niveaux de visibilité. L’opération de QoS mapping/translation s’exécute pendant la phase d’approvisionnement lors de l’établissement de la session, et également lorsqu’un changement se produit pendant la phase de l’exploitation lié à la mobilité ou à une dégradation de la qualité de service. – QoS Negociator : offre une fonction de communication et de coordination verticale entre les niveaux de visibilité pour demander les ressources qui lui sont nécessaires ou les libérer. La communication horizontale assure le signalement d’activité ou de non activité du composant. Nous avons présenté dans cette partie, d’une manière générale, le modèle organisationnel de l’architecture UBIS. Dans ce qui suit, nous présentons le composant de service autonomique (§V.2 ) qui est un élément clé du pilotage dynamique de la QoS de l’architecture UBIS car comme nous l’avons précisé précédemment tout est service.