Travaux sur la gestion de la Qualité de Service

Télécharger le fichier pdf d’un mémoire de fin d’études

Architecture Orientée Service

Objet, composant et service

Objet L’ingénierie logicielle s’est fixée pour mission de concevoir des approches per-mettant de rationaliser la production des systèmes logiciels. Parce qu’ils évoluent, se complexifient et deviennent plus distribués, ces systèmes requièrent des outils de concep-tion et de développement assurant qualité et fiabilité, tout en oﬀrant plus de flexibilité et de réutilisabilité. Depuis une vingtaine d’années, la programmation par objets [Coi06] s’est imposée comme paradigme standard pour le développement des logiciels (Smalltalk, Java, C++). En particulier, les objets ont apporté un ensemble de principes de conception parmi lesquels l’abstraction (un objet possède un type de données et un com-portement bien spécifié), l’encapsulation (interface et implémentation sont séparés), le polymorphisme (capacité de prendre des formes diﬀérentes à l’exécution), l’héritage (possibilité d’enrichir un objet avec des extensions) et l’identité (capacité de distinguer un objet parmi les autres). Cependant l’approche objet présente certaines limitations parmi lesquelles la diﬃculté de donner de la structure aux logiciels pour en maîtriser la complexité, la maintenance et la distribution. Par ailleurs, d’un point de vue technique, les objets sont dépendants des langages et des environnements d’exécution.
Composant La prise en compte de ces limitations est à l’origine de l’émergence des composants [Szy98] : « Un composant est une unité de composition avec des interfaces spécifiées à l’aide de contrats et de dépendances au contexte seulement. Un composant logiciel peut être déployé indépendamment et est sujet à être composé par des tiers ». Techniquement, les composants (par exemple EJB, COM et FRACTAL) permettent des regroupements cohérents et réutilisables d’objets. Ils se déploient et s’exécutent dans des contextes qui leur sont spécifiques. Permettant d’isoler de manière plus nette la phase de production et celle de consommation des logiciels, leur apparition marque une étape dans l’industrialisation des systèmes logiciels. Ainsi, si la programmation à petite échelle est bien couverte par les objets, la programmation à grande échelle trouve sa brique fondamentale dans le paradigme de composant. Cette étape fait notamment apparaître la notion d’architecture logicielle visant à définir la manière d’assembler les composants. Conceptuellement, le composant possède une implémentation en boîte noire, ainsi qu’une interface en boîte blanche. Par ailleurs, l’approche composant permet de mettre en oeuvre certains paramètres d’exécution (sécurité, persistance, mécanismes transactionnels, etc). Le cycle de vie classique du composant fait intervenir la compo-sition statique, le déploiement, l’instanciation et l’exécution.
Service Tout comme les objets, les composants présentent un certain nombre de limitations, parmi lesquelles la dépendance au modèle de composant et au contexte d’exécution. Ces dépendances réduisent l’interopérabilité entre les diﬀérents types de composant et induisent des dépendances fortes entre les composants d’un même assem-blage. De fait, la composition s’eﬀectue majoritairement de façon figée entre contextes homogènes, souvent au sein d’une même organisation. C’est à ces limitations que la programmation orientée service(SOC 1) [HS05, Pap03] essaie de répondre. Une défini-tion de « service » peut être : « unité logicielle autonome et indépendante de toute plateforme, qui peut être décrite, publiée, découverte, orchestrée et programmée en utilisant des protocoles standards dans le but de créer des réseaux d’applications col-laboratives distribuées à très large échelle ». En particulier, les caractéristiques fonda-mentales des services sont le couplage faible, l’interopérabilité et l’autonomie, ainsi que les mécanismes de publication et de découverte (faisant intervenir de nouveaux rôles de consommateur et de fournisseur de service). Les interfaces et les données exhibées par le service sont exprimées en termes métier, par le biais de contrats et de schémas de données. Les aspects technologiques ne sont plus essentiels car les services sont au-tonomes, c’est-à dire qu’ils sont indépendants du contexte d’utilisation ainsi que de l’état des autres services, et interopèrent par échange de messages via des protocoles standardisés. De façon similaire aux approches par objet ou par composant, l’approche service cherche à fournir un niveau d’abstraction encore supérieur, en encapsulant des fonctionnalités et en permettant la réutilisation de services déjà existants. La propriété de couplage faible que cette approche induit est à l’origine des architectures agiles que sont les « Architectures Orientées Services ».
Architectures logicielles Les architectures basées sur composants requièrent un couplage fort entre les diﬀérents composants. Par exemple, il est quasiment impossible de faire communiquer des composants EJB et des composants COM. Leurs ressources et leurs traitements sont fortement liés, ce qui donne au système logiciel une grande sta-bilité et homogénéité. En eﬀet, les composants s’inspirent du modèle objet et se basent sur des librairies de classes interdépendantes (nécessité d’un environnement d’exécution homogène, d’une compatibilité sémantique, d’un format de fichier bien défini, etc.). Un des avantages non négligeable de ce type d’architectures à base de composant est qu’il est capable de mettre en oeuvre certains mécanismes (sécurité, transaction, etc.) diﬃ-ciles à mettre en place dans des environnements plus faiblement couplés et donc plus interopérables. L’accent est mis sur les performances de l’architecture.
Les Architectures Orientés Services forment un style d’architecture fondée sur la définition de services qui interagissent. Elles s’inspirent des intergiciels orientés messages et des concepts d’objets distribués, en cela que ces deux approches sont également basées sur des principes d’abstraction, d’encapsulation et d’échange de messages. Les services servent à promouvoir l’intégration logicielle via une compatibilité structurelle basée sur un partage de contrat (traitement) et de schéma (données). L’accent est ainsi mis sur la propriété de couplage faible entre services, qui de fait symbolisent à eux seuls de véritables applications. Les services sont autonomes et peuvent évoluer indépendamment les uns des autres, l’interopérabilité étant assurée par les schémas et les métadonnées autodescriptives. En outre, la propriété de couplage faible permet aux compositions de services de s’organiser sous la forme d’orchestrations. Ce procédé autorise une plus grande flexibilité dans le choix des services à composer ainsi que dans le moment de leur composition. L’accent est mis sur la flexibilité et l’interopérabilité du système.

Services Web

Technologie Dans le cadre de la programmation orientée service, un service peut être défini comme une entité fonctionnelle auto-contenue, auto-décrite, indépendante des plateformes, et pouvant être décrite, publiée, découverte, invoquée, composée à l’aide de protocoles standards. La technologie des services Web constitue une approche pour la concrétisation du paradigme de service sur le Web. Par le biais de cette techno-logie, il devient possible de délivrer et de consommer des services logiciels sur le Web, détournant l’usage premier de celui-ci qui ne consistait initialement qu’à publier et à lire des documents et des informations. Le W3C définit le service Web de la manière suivante : « A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface des-cribed in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. »
Cette définition est illustrée dans la figure 2.1.
Techniquement, les services Web se présentent comme des composants sans état dont l’enjeu majeur est de promouvoir un couplage faible. Pour cela les normes de communication associées aux services Web sont standardisées et entièrement spécifiées en XML, langage permettant une grande interopérabilité entre les systèmes. En par-ticulier, les documents, messages et données sont modélisés par des schémas XML, ce qui permet leur compréhension par la grande majorité des plateformes.
Web Service Architecture La large implication des industriels dans l’élaboration des normes témoignent de l’ambition collective de faire communiquer plus facilement les systèmes informatiques par le biais du Web. La WSA 2 [WSA] a pour objectif de guider la progression des spécifications liées aux services Web, en les organisant dans divers domaines techniques. Ces domaines, illustrée dans la figure 2.2, sont répartis dans plu-sieurs couches fondamentales. L’existence de chaque couche est rendue possible par la présence des couches inférieures, l’objectif final étant d’abstraire le plus possible les mé-canismes de communication et de rendre possible la création de véritables architectures d’applications distribuées basées sur les services Web.
La couche de transport est fondamentale et permet les échanges basiques de données (HTTP, SMTP, etc.). Elle a suscité de nombreux eﬀorts de recherche lors de l’émer-gence des réseaux, mais elle n’est plus l’objet d’études spécifiques en ce qui concerne les services Web. La seconde couche décrit la sémantique des spécifications essentielles (SOAP, WSDL et UDDI), ainsi que des spécifications plus avancées (sécurité, garantie de livraison, transaction et description). La dernière couche, située au sommet de l’organisation WSA, s’adresse à la gestion des services et à leur composition.
Spécifications élémentaires SOAP, WSDL et UDDI constituent les trois spécifi-cations élémentaires liées aux services Web :
– SOAP 3 est le protocole d’échange de messages permettant d’interagir avec les services Web. Ces messages sont délivrés sous la forme de documents XML qui sont structurés par : une entête (pouvant être vide) contenant les informations non fonctionnelles liées au message (par exemple la sécurité), ainsi qu’un corps contenant les informations fonctionnelles (données et opérations du domaine d’ap-plication). SOAP est générique et extensible puisque les autres spécifications sont définies par dessus en définissant par exemple de nouvelles entêtes (sécurité, ga-rantie de livraison). Ce protocole n’est pas lié à un type de protocole de transport de données particulier, mais il est fréquent qu’il soit associé à HTTP ou SMTP.
– WSDL 4 est le langage basé sur XML permettant de décrire les services Web. Il permet de générer des documents structurés en deux parties : une partie abstraite (le Quoi) décrivant l’interface fonctionnelle du service en termes d’opérations et de messages, ainsi qu’une partie concrète (le Comment) qui contient les détails des protocoles à utiliser et de l’adresse physique des opérations. En particulier, un port type désigne une collection d’opérations, un binding consiste en une association entre un port type ainsi qu’un protocole de transport et de format de données, un port définit l’adresse physique d’un binding, et un service constitue une collection de ports.
– UDDI 5 est une spécification et un service de registre permettant de publier et de découvrir des services Web. Un registre UDDI est un registre basé sur XML qui contient des informations à propos d’entités d’aﬀaire fournissant des services Web ainsi que des métadonnées concernant ces services (informations techniques ou légales). En outre, UDDI spécifie plusieurs API 6 pour interagir avec le registre, demander ou publier un service.
Spécifications avancées (WS-*) Les spécifications élémentaires permettent aux services Web de communiquer, de se décrire et d’être publiés. Elles forment une base pour que d’autres spécifications plus avancées puissent les étendre. Il s’agit de spécifica-tions WS-* fournissant notamment des mécanismes de QdS (par exemple WS-Security ou WS-ReliableMessaging), de description avancée, ou bien de composition. Les spé-cifications WS-* sont composables, faisant ainsi participer plusieurs traitements. Ci-dessous nous analysons les spécifications qui nous intéressent pour les travaux de la thèse :
– WS-Security : Cette spécification traite des multiples mécanismes permettant de sécuriser l’échange de messages SOAP entre clients et services Web. Elle fournit une extension à SOAP implémentant les principes d’intégrité, de confidentialité et d’authentification. Pour cela, WS-Security spécifie des entêtes SOAP de sé-curité contenant des constructions de type signature, clé, jetons, etc. Il existe encore d’autres spécifications de sécurité plus spécifiques permettant d’adresser la confiance (WS-Trust), les conversations sécurisées, les fédérations, etc.
– WS-ReliableMessaging : Entre l’envoi et la réception de messages SOAP, il peut se passer des erreurs de livraison, notamment lorsque des canaux de transmission ne sont pas fiables comme c’est parfois le cas avec Internet. Pour prévenir d’éven-tuelles pertes, la duplication ou bien garantir l’ordre de traitement des messages, la spécification WS-ReliableMessaging apporte des mécanismes de garantie de livraison. Pour cela, cette spécification utilise des éléments additionnels dans les entêtes des messages SOAP afin de mettre en oeuvre des mécanismes usuels tels que les messages d’aquittement.
– WS-Policy fait parti du domaine « description » des spécifications et se scinde en autant de sous spécifications (WS-SecurityPolicy, etc.) qu’il existe de spé-cifications de QdS (WS-Security, etc.). A l’instar du WSDL, les spécifications WS-Policy fournissent un moyen pour publier des informations concernant l’uti-lisation des services Web. Cependant, les WS-Policy adressent spécifiquement les exigences, capacités et préférences de QdS du service. Par exemple, un service peut déclarer qu’il supporte la garantie de livraison et qu’il requiert un méca-nisme de cryptage 3-DES 7 des messages. Pour cela, WS-Policy fournit une cadre permettant de spécifier des politiques consistant d’une ou plusieurs assertions agrégées à l’aide d’opérateurs. La politique décrite figure 2.1 annonce qu’une po-litique est définie, puis que la politique requiert l’utilisation d’un jeton de sécurité, et enfin que ce jeton est de type UsernameToken.

Séparation des préoccupations

Principes

Une préoccupation correspond à un sous-ensemble d’un système logiciel rattaché à la prise en compte d’un concept, d’un objectif ou bien d’un sujet particulier. Par exemple, dans le cas d’un serveur Web, il existe des préoccupations liées à la gestion des pages HTML ou à la gestion du protocole HTTP, ainsi que des préoccupations liées à la gestion de la sécurité ou du logging. Un problème inhérent à la définition de systèmes logiciels est que les multiples préoccupations des systèmes ne peuvent être représentées sans être disséminées dans les diﬀérentes composantes de ces systèmes. Autrement dit, les préoccupations ne sont pas encapsulées de façon adéquate tant au niveau des modèles de conception que des langages de programmation. Or, ce sont en particulier les interactions entre préoccupations qui sont responsables de la complexité des systèmes logiciels. Dans le cas du serveur Web Apache, il est montré [KLM+97] que le code implémentant la notion de session de connexion est disséminé dans une cinquantaine de classes diﬀérentes et ce malgré les mécanismes usuels de réutilisation tels que l’héritage. Le code obtenu est alors plus diﬃcile à lire, à maintenir et à réutiliser, ce qui a également pour eﬀet d’en réduire sa robustesse.
La séparation des préoccupations (Separation of Concerns) [Dij82, HL95] est un principe fondamental du génie logiciel. Son objectif est de permettre la maîtrise de sys-tèmes logiciels complexes en adressant, de façon isolée, les diverses préoccupations qui les composent. Il s’agit pour cela que la structure des logiciels reflète le plus fidèlement possible les relations intrinsèques entre leurs préoccupations afin de minimiser leurs interactions et, ainsi, de faciliter l’expression et la compréhension de ces interactions.
« Separation of concerns is a key guiding principle of software enginee-ring. It refers to the ability to identify, encapsulate, and manipulate only those parts of software that are relevant to a particular concept, goal or purpose. Concerns are the primary criteria for decomposing software into smaller, more manageable and comprehensible parts that have meaning to software engineers. » [EFB01] Bien que, pour être mis en oeuvre l’existence, ce principe nécessite des technolo-gies particulières, la séparation des préoccupations n’est pas une technologie en soi. Il s’agit d’un principe de conception qui a fortement influencé l’émergence de technologies permettant d’isoler les préoccupations à l’aide de stratégies plus ou moins eﬃcaces.
Un premier type de décomposition permet de découper les logiciels de façon hiérar-chique, selon une et une seule dimension. C’est ce type de décomposition que permettent d’eﬀectuer la programmation modulaire, par objets, par composants et orientée service à présent. Cependant, ce type de décomposition conduit au problème de la « tyrannie de la décomposition dominante » [OT99] : les concepteurs, ayant choisi de décomposer leur système selon une préoccupation principale (typiquement une préoccupation mé-tier), regroupent dans cette décomposition les autres préoccupations qui n’ont pas pu être modularisée. Ces préoccupations, qualifiées de « transverses » se retrouvent disper-sées dans le reste du code et mélangées avec les autres, ce qui rend le logiciel diﬃcile à comprendre, à maintenir et à faire évoluer. Certaines de ces préoccupations trans-verses peuvent être des préoccupations métier annexes, mais il s’agit pour la plupart de préoccupations dites « non-fonctionnelles » qui traitent par exemple de la sécurité ou encore des performances. Souvent, ces préoccupations ne sont d’ailleurs pas spéci-fiquement liées à l’application développée. Afin de modulariser ces préoccupations, le génie logiciel a développé de nouvelles techniques de programmation mettant en oeuvre le principe de séparation des préoccupations.
« When writing a modular program to solve a problem, one first divides the problem into sub-problems, then solves the sub-problems and combines the solutions. The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together. The-refore, to increase ones ability to modularise a problem conceptually, one must provide new kinds of glue in the progamming language. » [Hug89]

Réflexion et méta-programmation

« The most important contribution of the reflection community is to clearly illustrate the potential of separation of concerns. » [Tho02]
La réflexion réfère à la capacité d’un système à raisonner et à agir sur lui-même [Smi84, Mae87]. En particulier, un système réflexif est un système qui fournit une représentation de son propre comportement qu’il est possible d’inspecter et de modifier. Pour obtenir une telle caractéristique d’un système, il faut que celui-ci dispose de deux capacités :
– La capacité d’introspection, qui correspond à la capacité de pouvoir s’observer soi-même. C’est grâce à cette capacité que le logiciel peut raisonner sur lui-même. En particulier, cette capacité se concrétise par la réification des structures et des mécanismes du logiciel. Dans le cas d’un langage de programmation, il s’agit des classes, des méthodes, etc.
– La capacité d’intercession, qui correspond à la capacité de pouvoir se modifier soi-même. Dans le cas d’un logiciel, cette capacité correspond à la possibilité de modifier les entités réifiées et au fait que les modifications eﬀectuées sont prises en compte de façon immédiate (principe de connexion causale selon lequel la réification détermine le comportement du logiciel).
La réflexion met en relation les deux niveaux fondamentaux que sont le niveau de base et le niveau méta. Le niveau de base capture le sujet principal du logiciel d’une application (par exemple la réservation d’un hôtel ou la gestion de comptes bancaires). Le niveau méta désigne alors le code réflexif, c’est à dire le code agissant sur les réifications du code de base. C’est notamment à ce niveau plus élevé qu’il est alors possible d’introduire des mécanismes d’exécution modularisant des préoccupations transversales (transaction, sécurité, etc.).
Les langages à objet, de part leur structure et leur organisation, sont particuliè-rement adaptés à la mise en oeuvre du principe de reflexion. Dans ce contexte, les objets appartenant au niveau méta sont alors appelés méta-objets, et leur rôle consiste à contrôler le comportement des objets du niveau de base. La communication entre les objets du niveau de base et du niveau méta est alors gérée par un protocole à méta-objets (MOP) 10 qui constitue l’interface entre les diﬀérentes niveaux. L’un des MOP les plus représentatifs est le MOP de CLOS 11 [KdRB91].
En ouvrant l’implémentation des logiciels, la réflexion oﬀre une technologie particu-lièrement adaptée pour mettre en oeuvre le principe de séparation des préoccupations. En eﬀet, les diﬀérents niveaux (de base, méta et multiples méta de plus haut niveau) permettent d’isoler les diverses préoccupations du logiciel, tandis que le MOP prend en charge la mise en oeuvre de la recomposition des préoccupations.

Programmation par aspects

La programmation par aspects (AOP 12) [KLM+97, Aks96, MC96] représente un paradigme adressant spécifiquement la problématique de modularisation des préoccu-pations entrelacées dans un système logiciel complexe, et cherchant ainsi à répondre au problème de la tyrannie de la décomposition dominante.
Plusieurs approches pour le developpement de logiciel par aspects et basées sur une même modélisation sont présentées par Masuhara et Kiczales dans [MK03]. L’AOP introduit une nouvelle unité de modularité nommée « aspect » qui encapsule une pré-occupation entrelaçante. Un aspect se caractérise par les structures suivantes :
– Un langage de coupe (pointcut language) qui permet de désigner un ensemble de points d’exécution du programme de base, appelés points de jonction (join points). Selon la modélisation des points de jonction et des coupes, un langage d’aspect peut cibler de manière plus ou moins précise les points d’exécution du programme de base. Dans le cas de langage à objet, de tels points de jonction peuvent par exemple correspondre à l’appel d’une méthode ou bien à l’accès à une donnée, etc.
– Un langage d’action (advice) qui permet de spécifier la logique spécifique à la préoccupation modularisée par l’aspect. Généralement, le langage d’action cor-respond au langage de programmation de base. C’est cette action qui est mise en oeuvre aux points de jonction du programme de base identifés par la coupe de l’aspect. L’action est alors eﬀectuée avant, après ou autour des points d’exécu-tion, celui-ci étant alors réifié dans le langage d’action afin de pouvoir contrôler son exécution depuis l’aspect.
Un aspect consiste alors en un couple (coupe, action) implémentant une préoccupation et en injectant celle-ci de façon transparente dans le programme de base. Pour l’inté-gration de l’aspect dans le programme de base, l’AOP fait appel à un mécanisme de mise en oeuvre spécifique appelé « tissage » (weaving). Cette étape de mise en oeuvre peut être réalisée soit statiquement (par transformation de code source [KHH+01] au moment de la compilation programme de base ou de son chargement, soit dynamique-ment (généralement par le biais de la réflexion [PSDF01] à l’exécution du programme de base.

Plateformes adaptatives pour la composition de services

Dans cette section, nous étudions cinq travaux proposant des plateformes adapta-tives pour la composition de services.

AO4BPEL

Introduction Ce travail [CM04, CSHM06] se propose d’introduire le concept de pro-grammation par aspects dans les processus métier afin de pallier d’une part au manque de modularisation des préoccupations transverses, et d’autre part au manque de dy-namicité des adaptations. Les auteurs de ces travaux ont ainsi réalisé un modèle et une implémentation de langage d’aspect (AO4BPEL 1) basé sur le langage BPEL. Un moteur BPEL spécifique a également été conçu pour la gestion des aspects, ainsi que pour l’intégration de services middleware non fonctionnels usuels (sécurité, garantie de livraison, transaction) permettant de répondre à la problématique du manque de prise en charge des normes WS-* au niveau des compositions.
Langage Comme tout langage orienté aspect, le langage AO4BPEL possède un mo-dèle de points de jonction, un langage de coupe et un langage d’action. Il a cependant la particularité d’être entièrement rédigé en XML. Selon la modélisation AO4BPEL, chaque activité est un point de jonction potentiel et il existe également des points de jonction liés aux événements d’envoi et de réception de messages SOAP. Etant donné que le langage BPEL est rédigé en XML, chaque balise XML peut être identifiée à l’aide d’une expression XPath. Les auteurs de AO4BPEL ont ainsi basé leur langage de coupe sur le langage XPath 2. Une coupe consiste en une collection de points de jonction, c’est à dire d’expressions XPath pouvant être composées à l’aide des opérateurs d’union ou d’intersection. Quant au langage d’action, il s’agit du langage BPEL augmenté par des mots clés « <Proceed/> » et un mécanisme de réflexion (donnée « ThisJPInVa-riable » ou encore « soapmessageout »). Le contenu d’un aspect AO4BPEL consiste ainsi en une coupe et une activité BPEL devant être appelée à l’endroit de la coupe. De plus, il est possible d’assigner des ordres de priorité afin d’ordonner l’exécution d’aspects se déclenchant à un même point de jonction. Finalement, AO4BPEL intègre également un mécanisme d’introduction particulièrement approprié pour ajouter des partenaires ou encore des variables dans les processus BPEL. Le listing 3.1 exhibe un aspect AO4BPEL dont la coupe spécifie comme point de jonction les activités de type invoke placées comme descendants directs de l’activité process et dont l’opération porte le nom getFlight. L’action correspond à l’appel d’un service de logging avant l’exécution des points de jonction.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Liste des listings
1 Introduction
1.1 Evolution des architectures logicielles
1.2 Motivations liées à la gestion de la Qualité de Service
1.3 Limitations actuelles
1.4 Objectifs de la thèse
1.5 Contributions
1.6 Organisation du document
1.7 Liste des publications liées à cette thèse
I Contexte de l’Étude
2 Contexte logiciel spécifique à la thèse
2.1 Architecture Orientée Service
2.1.1 Objet, composant et service
2.1.2 Services Web
2.1.3 Composition de services
2.2 Séparation des préoccupations
2.2.1 Principes
2.2.2 Réflexion et méta-programmation
2.2.3 Programmation par aspects
2.2.4 Langages dédiés
2.3 Qualité de Service
2.3.1 Caractéristiques de Qualité de Service des Services Web
2.3.2 Contrats de service
2.3.3 Politiques
3 Travaux sur la gestion de la Qualité de Service
3.1 Introduction
3.2 Plateformes adaptatives pour la composition de services
3.2.1 AO4BPEL
3.2.2 DYNAMO
3.2.3 MASC
3.2.4 Trap/BPEL
3.2.5 eFlow
3.3 Plateformes de traitement spécifique de la QdS dans les compositions
3.3.1 AgFlow
3.3.2 ORBWork
3.3.3 WS-Binder
3.3.4 QoS-Optimised Web Service Compositions
3.3.5 Broker-based Framework
3.4 Conclusion
II Contribution
4 Orientation de la thèse
4.1 Mise en perspective
4.2 Positionnement de la contribution
4.2.1 Vers une meilleure séparation des préoccupations
4.2.2 Etude du domaine de la QdS
4.2.3 Approche langage dédié
4.2.4 Mise en oeuvre non intrusive
4.3 Orientation générale
4.3.1 Vue globale
4.3.2 Scenario fil conducteur
4.4 Conclusion
5 QoSL4BP : Un langage dédié pour la gestion de la Qualité de Service dans les compositions de services
5.1 Présentation générale du langage
5.2 Modèle de données
5.2.1 Vue globale
5.2.2 Données Activités BPEL
5.2.3 Données SLA
5.3 Traitements
5.3.1 Gestion des accords
5.3.2 Observation de la QdS
5.3.3 Gestion des mécanismes liés à la QdS
5.4 Modèle des politiques QoSL4BP
5.4.1 Structure
5.4.2 Cible des politiques
5.4.3 Traitements statiques
5.4.4 Traitements dynamiques
5.5 Propriétés du langage
5.6 Conclusion
6.1 Introduction
6.2 Etape de recherche des services de la composition
6.2.1 Transcription de la composition de services en arbre
6.2.2 Stratégie de décomposition
6.2.3 Planification des services
6.3 Etape de transformation de la composition de services
6.3.1 Tissage d’indirections dans la composition
6.3.2 Redirection des messages échangés entre partenaires
6.4 Etape de mise en oeuvre des règles
6.4.1 Synchronisation des règles QoSL4BP avec l’exécution du BPEL
6.4.2 Algorithme de traitement de la section RULES
6.5 Mise en oeuvre avec la plateforme ORQOS
6.5.1 Présentation fonctionnelle
6.5.2 Présentation des traitements
6.6 Bilan
7 Développement de compositions de services avec ORQOS
7.1 Introduction
7.2 Présentation du scénario « Dossier Médical Personnalisé »
7.2.1 Composition de services
7.2.2 Exigences liées à la gestion de la QdS
7.3 Développement de la composition DMP
7.3.1 Composition BPEL
7.3.2 Politiques QoSL4BP
7.3.3 Projet de composition
7.4 Etapes de mise en oeuvre de la composition DMP
7.4.1 Etape de mise en oeuvre statique
7.4.2 Etape de transformation
7.4.3 Etape de mise en oeuvre dynamique
7.5 Evaluation
7.6 Conclusion
8 Conclusion et perspectives
Bibliographie