3.3.1 Démarche de modélisation
La démarche de modélisation préconisée est une démarche progressive et itérative pour la construction des différentes facettes (producteur, consommateur et annuaire de services) de notre modèle. Elle se décompose en cinq phases :
– La première phase d’initialisation est consacrée à l’identification des besoins (expression des besoins), au repérage des sources d’informations et à l’élaboration du plan d’action à suivre ;
– Dans la deuxième phase, on recensera tous les éléments existants dans l’environnement (acteurs, services et structures organisationnelles) ;
– La troisième phase est consacrée à l’analyse du prescrit c’est-à-dire à l’identification et la définition des missions de chaque acteur, service et équipement recensé ;
– Dans la quatrième phase, l’attention se focalise sur la modélisation et la conceptualisation de chaque protagoniste intervenant selon les architectures orientées services ;
– Enfin, dans la dernière phase, les éléments identifiés dans les phases précédentes sont structurés et organisés pour obtenir le modèle final.
3.3.2 Plateforme de services
Comme précédemment évoquées, les architectures orientées services font référence principalement à trois notions : le producteur de services, l’annuaire de services et le consommateur de services. La plateforme de services ainsi proposée répondra à toutes les spécifications SOA et intégrera l’ensemble de services proposés à travers son annuaire UDDI.
Fig. 3.11 Modélisation d’une plateforme de services pour un ENT
Ce modèle met en exergue les étapes et les équipements nécessaires de la plateforme de services à mettre en place permettant l’accès aux services web implantés dans un ENT d’université. Ces services pouvant être accessibles via les équipements à ressources limitées et les postes de travail classiques.
Pour donner un sens à notre schéma, nous avons utilisé la numérotation littérale (A, B, C, …) pour représenter les entités, les équipements et les moyens mis en œuvre d’une part et d’autre part la numérotation numérique (1, 2, 3, …) pour représenter le séquencement des opérations entre les différentes entités.
Les entités (équipements ou moyens mis en œuvre)
(A) Poste de travail fixe
Comme les services web classiques, l’on pourrait accéder à l’ENT à travers les ordinateurs de bureaux ou ordinateurs portables grâce à l’architecture proposée.
(B) Connexion Internet
L’accès à la plateforme sur Internet peut se faire à travers une connexion sans fil (l’IEEE 802.11 ou Wi- , le Bluetooth, l’infrarouge ou encore le GPRS) pour les équipements à ressources limitées et une connexion filaire pour les postes de travail classiques.
(C) Interface service web
Une fois l’utilisateur connecté et authentifié par un mot de passe et un identifiant pour accéder à l’ENT, il pourra alors accéder aux différents services web proposés à travers l’interface qui sera proposée en fonction de son pro l.
(D) Serveur web
Le serveur web ici est une machine dans laquelle sont hébergés le portail web et l’ENT. Toutes les requêtes sont redirigées vers ce dernier.
(E) Le fournisseur de services (jeu de services)
Le fournisseur de services qui est l’université est représenté par l’ensemble des services web (jeu de services) qui est proposé à la communauté universitaire. L’université est donc responsable du contenu des services qu’il héberge et propose.
(F) Annuaire privé
Implémenté par le fournisseur de services web et déployé aussi dans le serveur web, ce registre n’est accessible que par les acteurs internes c’est-à-dire n’est utilisé que localement.
C’est dans ce registre UDDI que les publications et les découvertes de services sont faites à travers les descriptions WSDL.
L’ensemble des services publiés dans l’annuaire sera disponible via le navigateur web qui dialoguera avec l’application choisie (plateforme web service Axis).
Le séquencement des opérations
(1) Publication d’un service web
Une fois le service web implémenté, il doit être publier dans le registre privé. Cette publication se fait à travers le WSDL et l’attribution d’un UUID (Universally Unique ID) qui permet d’identifier chaque service de manière unique. On parle encore en du déploiement du service.
(2) Requête de service
Lorsqu’un utilisateur accède au portail web de l’université et dans l’ENT après authentification, lorsqu’il veut utiliser un service web, il accède à l’interface correspondant à son pro l. A chaque type de pro l correspondant un ensemble de services. Lorsque l’utilisateur sélectionne un service web donné, une requête est envoyée au serveur web où est hébergé le site pour avoir accès aux données.
(3) Découverte de service
C’est la recherche et la localisation d’un service web particulier dans notre annuaire privé de services décrivant le nom du fournisseur, l’objectif de chaque service, etc. Donc, il s’agit de l’acquisition des descriptions (WSDL) des services web et leur utilisation.
(4) Découverte approfondie de service
Chaque école ou faculté pouvant disposer d’un annuaire, si le service recherché n’est pas présent le registre principal, alors le service correspondant à la requête formulée sera recherché dans les autres annuaires annexes (écoles ou facultés) interconnectés. Comme le prévoit la spécification UDDI, nos annuaires seront distribués. Cette réplication n’est pas obligatoire, notamment dans un cadre privé comme le nôtre, mais est fortement recommandée pour des raisons évidentes de disponibilité et de modularité.
(5) Résultat de la découverte de service
La réponse (résultat) de la requête formulée est renvoyée au serveur web. Cette réponse contient essentiellement les caractéristiques nécessaires à l’utilisation des services retrouvés correspondant à la demande (détails sur le fournisseur, type de connexion, adresse du service ect.).
(6) Invocation du service
Une fois le service web trouvé dans le registre, il sera invoqué ; puis les caractéristiques extraites lors de la découverte de service et du service en présence seront comparées. Si les caractéristiques du service en place correspondent à celles désirées alors sera déclenché l’utilisation du service en question. Sinon une erreur sera renvoyée.
(7) Livraison du service
Si le service est disponible alors l’échange de messages basé sur le protocole SOAP (au format XML) peut alors commencer. A partir de ce moment et durant toute la session, le serveur communique directement avec le fournisseur de services.
(8) Réponse à la requête
La réponse est donc transmise à l’interface de l’utilisateur qui ne devra pas avoir conscience de la complexité et des différentes transactions effectuées en back office.
Cet ensemble de processus constitue donc le fonctionnement et le traitement des informations réalisés de la recherche à l’invocation des services web. Mais alors pour que cette plateforme ainsi modélisée assure un accès aux services via les équipements à ressources limitées, quelques contraintes sont à prendre en compte lors de la mise en œuvre telle que l’adaptabilité. Aussi, il en résulte de cette architecture d’autres caractéristiques importantes.
3.3.3 Modularité des services dans l’architecture orientée services
Résultante du couplage faible entre les services, une architecture orientée services peut être conçue par une approche incrémentale, résultat de la combinaison de deux démarches de base qui sont l’agrégation et la dissémination de services [27]. La modularité est matérialisée par le fait que les différents services sont indépendants les uns des autres dans la plateforme de services et peuvent être accessibles par les applications distantes tournant dans des environnements hétérogènes. D’où la notion d’interopérabilité.
L’agrégation de services : Pour mieux comprendre cette notion d’agrégation de services, nous allons nous référer à un schéma d’exemple représentant le cas d’un service de bibliothèque virtuelle dans l’ENT de l’Université de Ngaoundéré, tout en sachant que chaque faculté dispose aussi d’une bibliothèque. Ce service de bibliothèque virtuelle est issue de la composition (ou de l’orchestration) des services atomiques (ici, service de bibliothèque virtuelle de chaque faculté). L’implémentation d’un service par agrégation d’autres services est inconnue du client qui utilise le service agrégeant. En e et, celui-ci ne connaît pas et n’a pas besoin de connaître l’éventuelle complexité de l’implémentation du service en ce qui concerne l’agrégation d’autres services. Du point de vue du client, le service agrégeant est un service atomique décrit de façon usuelle. En guise de rappel, l’agrégation de services peut se faire à l’aide des outils comme BPEL4WS (Business Process Evaluation for Web Service).
Fig. 3.12 Exemple d’agrégation de services dans la plateforme
La dissémination de services : Quant à la dissémination de services, elle permet d’effectuer la décentralisation des données. Comme on peut le voir sur la figure en dessous, plusieurs applications sont prestataires du même service sur des données différentes. L’on peut donc implémenter un ensemble de services modulaires à partir d’applications différentes. Le point essentiel est que le client d’un des services issus d’une démarche de dissémination bénéficie de la modularité du service sans que la question de la modularité de l’implémentation ne soit même posée.
Fig. 3.13 Exemple de dissémination de services dans la plateforme
Page suivante : 3.4 Single Sign On et profils d'utilisateurs