Modélisation des services Web composite

Principe de fonctionnement des services Web composite

Un service web est dit composé ou composite lorsque son exécution implique des interactions avec d’autres services web afin de faire appel à leurs fonctionnalités. Cette interconnexion des services est vu par l’utilisateur (ou l’application cliente) comme un unique service. La modélisation de cette interconnexion se fait sous forme d’un processus métier. Ce processus spécifie quels services ont besoin d’être invoqués, dans quel ordre et comment gérer les conditions d’exception. Plusieurs implémentations ont été réalisées pour offrir un m oteur d’exécution de ces processus. Dans le cadre de ce mémoire, nous avons utilisé le moteur d’orchestration ActiveBPEL [21] pour déployer un exemple de processus métiers décrit en utilisant BPEL [9].

Le déploiement d’un processus métier sur le moteur d’orchestration se fait sous forme d’un service Web (ce service est le service qui représente le service Web composite). Ce service est décrit par un contrat WSDL [7], qui est une description basée sur le langage XML, qui indique quelles sont les opérations disponibles?, comment on y a ccède (adresse, protocole, …) ?, quel est le format de messages échangés entre le client et le moteur, pour invoquer le service et pour interpréter le résultat. Partie V : modélisation des services Web composite Mémoire DEA Informatique FST/UCAD Option : réseau et performance 74 Une fois que le service Web composite est déployé, il faut mettre à la disposition des utilisateurs des mécanismes pour que ces derniers puissent utiliser ces services. Cette phase s’appelle la publication .

Modèle d’essai

Nous pouvons envisager que nous sommes dans un cas où une entreprise possède deux sites (A et B) connectés à l’aide d’une liaison série. Il arrive que c ette entreprise ait besoin de développer une nouvelle application dans le site A pour répondre à des nouvelles exigences. Lors de la conception, le concepteur a remarqué qu’une partie de l’application qu’il doit développer tourne déjà sous forme d’un service Web sur le site B. Le concepteur sait que grâce aux technologies des services WEB, il est devenu possible de faire une composition des ces derniers en utilisant un l angage d’orchestration. I l décide donc, de concevoir e t de développer un nouveau service mais en ne considérant que les besoins qui ne sont pas pris en compte lors du développement du service Web B. Ensuite, il crée un processus métier qu’il déploie dans un moteur d’orchestration sous forme d’un service Web composite.

Enfin, la société décide de faire une étude de performance de sa nouvelle architecture pour assurer le bon fonctionnent du système et pour assurer encore que les exigences de performance sont toujours respectées. Les hypothèses Dans notre modèle d’essai nous supposons que toutes les configurations sont statiques. Nous supposons également que les messages des requêtes des clients ont une taille de 12 koctets, et que les réponses envoyées par le moteur d’orchestration est de 40 koctets. Les requêtes envoyées par le moteur et leurs réponses envoyées par les services Web unitaire ont la même taille (8 koctets). Pour calculer les paramètres d’entrées nous supposons également que le Moteur (CPU + Disk) peut traiter 1000 requêtes/s pour le CPU et 500 requêtes/s pour le Disk. Les serveurs qui traitent les requêtes du moteur peuvent traiter 600 requêtes/s pour le CPU et 500 requêtes/s pour le Disk.