BNGR-HASS
Sélection de services web composites pour un groupe de clients
Approche d’un groupe de clients pour la sélection de services web composites à base de communautés 4.1 Architecture de notre approche Notre architecture de communautés de services web est représentée dans la figure 6.3. Les composants de cette architecture sont le fournisseur de services web, le registre UDDI des services web simples,
la configuration des communautés, le re gistre UDDI des services composites et le client de services web. Les communautés sont crées et détruites selon des contraintes spécifiques détaillées dans la section 4.3.
Le fournisseur de services publie son service dans le registre UDDI; UDDI permet de conserver les services web dans un annuaire. Ces informations sont transparentes pour les clients et peuvent être utilisées pour créer des services web composites (com munautés). Deux configurations de communautés sont montrées dans la figure 6.3.
Il peut s’agir, par exemple, d’un service de réservations de voyages ou d’un service de ventes en ligne . Les informations sur les configurations et les communautés sont sto ckées et publiées dans un nouveau registre UDDI dédié à la composition; le client de services exprime son processus métier et ses exigences pour trouver son service com posite dans le nouveau registre UDDI.
La manière de publier et d’appeler des services web composites est similaire à l’architecture standard orientée service bien que les services web soient maintenant associés en communautés pour offrir un bon service composite dans des délais acceptables. Le nouveau registre UDDI garde l’historique des demandes clients afin de mieux cibler les exigences d’un profil client
Modèle formel de communautés Certaines tâches complexes nécessitent l’exécution de plusieurs tâches plus simples, chacune pouvant être déléguée à un service spécialisé. Ce service peut être fourni par un ou plusieurs fournisseurs.
Tous ces services web offrant les mêmes fonctionnalités peuvent être rassemblés dans une classe de services notée sc : tout service de cette classe peut être remplacé par un autre service de cette même classe pour exécuter cette tâche.
Les services peuvent toutefois varier en qualité de service. Pour des rai sons de simplicité, nous ne considérons que deux critères de qualité : le coût, noté sco, et la réputation, notée srep. Un client d’un service préfère un coût associé inférieur,
mais une réputation plus élevée à ses exigences. Définition 1(Service). Un service est un quadruplet identifiant unique, sc est sa classe de services, srep est son cout. sc srep sco ou estson est sa réputation, et sco
L’ensemble de tous les services est noté . Bien quelesservices offrent une grande flexibilité, certaines classes de services sont souvent combinées pour proposer des ser vices composites. Nous considérons que la composition de services nécessite exacte ment des classes de services dans l’ensemble .
Nous notons l’ensemble des services web présents dans une classe de services : sc . Le but d’une communauté est de prendre un (et un seul) service web par classe afin de fournir une composition dynamique limitée par un budget donné : Définition 2 (Communauté). Une communauté notée identifiant unique et une contrainte de coût cons .
Télécharger le document complet
