Soutenance mémoire
Evolution des architectures logicielles
La prolifération et la complexification des systèmes d’information poussent les entreprises à rationaliser leurs développements logiciels. Pour cela, une des caractéristiques recherchées pour la conception de systèmes logiciels est l’agilité, c’est à dire la capacité d’une architecture à évoluer afin d’intégrer certains changements. Par exemple, il existe des changements « organisationnels » (avec la création de filiales ou la restructuration des organisations en place), des changements « métier » (c’est à dire relatifs à l’évolution de l’activité tels que la mise en oeuvre d’une gestion de relation clients), des changements dûs aux évolutions de la réglementation (tels que l’ouverture à la concurrence des marchés publics), des évolutions technologiques (prise en compte du legacy) ou encore la maîtrise des coûts (réduction des délais de « time to market »). Parce que les systèmes informatiques sont amenés à évoluer de manière certaine, leur agilité constitue une exigence majeure. Les architectures logicielles doivent donc promouvoir une réelle flexibilité et réutilisabilité pour s’adapter au changement. De multiples paradigmes et techniques de programmation logicielle ont émergé pour répondre à cette problématique. C’est notamment dans ce contexte que l’approche objet [Coi06] puis le paradigme de composant ont fait leur apparition. L’approche objet a apporté un ensemble de principes de programmation (tel que l’encapsulation), tandis que le paradigme de composant a permis le regroupement cohérent et réutilisable des objets. Se définissant comme une « unité de composition dont les interfaces sont spécifiées, et qui peut être déployée indépendamment du reste de l’application », le composant a pour caractéristiques fondamentales l’encapsulation forte, la contractualisation des interactions et la composition par des tiers [Szy98]. De nombreux modèles de composant ont ainsi émergé aussi bien dans l’industrie que dans le milieu académique (J2EE, CORBA, COM+ ou encore FRACTAL). Parallèlement à l’évolution des architectures d’applications à base de composants, l’émergence d’Internet a permis de mettre en place un environnement hautement ubiquitaire favorisant l’accès permanent à n’importe quelle ressource, et ce depuis n’importe quel point d’accès. Cependant, Internet n’a pas été conçu à son origine comme une infrastructure pour les applications distribuées riches, ce qui le rend initialement impropre à l’utilisation d’une vaste classe d’applications industrielles qui requièrent certaines propriétés de sécurité, de robustesse ou encore de transaction. Le paradigme de « service » vise à permettre au concepteur d’architectures réparties sur Internet de manipuler des entités logicielles d’une granularité équivalente à celle des composants et offrant un couplage lâche entre le client et le fournisseur de service. En particulier, un service fournit un point d’accès vers une ressource logicielle se trouvant sur Internet et garantit un haut niveau d’interopérabilité entre plateformes en réalisant l’abstraction de toutes les informations liées au traitement de cette ressource. Avec ce nouveau paradigme, émerge un nouveau type d’architecture, appelées « Architectures Orientées Service » [SN98], qui exploitent la propriété de couplage faible des services et permettent de composer de manière flexible et réutilisable des services. Ces architectures visent à répondre de manière pertinente aux challenges liés à l’agilité des systèmes d’information.
Motivations liées à la gestion de la Qualité de Service
Avec l’émergence des services dans les architectures logicielles, apparait un nouveau modèle relationnel entre les acteurs du monde informatique puisque les clients deviennent dorénavant de véritables consommateurs de service. En effet, grâce à la propriété de couplage faible, les Architectures Orientées Service simplifient la procédure de découverte et d’utilisation des services, permettant ainsi aux clients de substituer aisément un service par un autre selon leur convenance. D’autre part, la prolifération de services aux fonctionnalités sensiblement équivalentes sur Internet offre un vaste choix de produits auxquels les clients peuvent faire appel ainsi qu’une concurrence accrue pour les fournisseurs de service. En outre, le caractère ubiquitaire d’Internet rend plus opaque l’identité des divers acteurs. Par conséquent les acteurs réclament certaines garanties sans lesquels un client peut être amené à dialoguer avec un service dont les ressources varient significativement, ou bien inversement un fournisseur peut voir son service subitement utilisé par un nombre important de clients et peut ne plus pouvoir faire face à leurs demandes. Dans ce contexte relationnel hautement dynamique, la notion de QdS , qui s’intéresse à la qualité de la relation entre un service et son client, devient un enjeu crucial. Plus précisement, cette notion [ISO, ISO98] fait référence à de multiples propriétés telles que la performance, la disponibilité, la robustesse ou encore la sécurité. Dans le contexte des Architectures Orientées Service où les acteurs se connaissent peu, la garantie de ces propriétés est tout aussi fondamentale que le traitement fonctionnel du service. Par exemple, un service permettant de passer des ordres d’achat/vente d’actions en bourse serait tout aussi inutilisable s’il modifiait les ordres donnés par les clients que si ses performances étaient faibles. Ainsi, à l’instar des traitements métiers, les caractéristiques de QdS des services doivent faire rencontrer l’offre et la demande. Toutefois, contrairement aux standards bien établis du domaine fonctionnel (tels que SOAP [SOA] ou WSDL [WSD]), il n’existe pas de spécification ni de mécanisme officiellement reconnu par la communauté service en ce qui concerne la spécification et le traitement de la QdS des services. Cependant, poussée par les enjeux liés à la QdS, la communauté service a fait émerger plusieurs travaux permettant la réalisation et la mise en oeuvre de contrats de QdS entre un client et un service. Ces travaux ont abouti à la spécification de divers modèles de contrat, de protocoles de gestion associés et d’infrastructures (tels que le modèle WS-AGREEMENT [ACD+07] avec la plateforme CREMONA [LDK04]). Ainsi, un client souhaitant avoir des garanties de performance ou encore de sécurité d’un service peut établir un contrat de service avec son fournisseur.
Limitations actuelles
La propriété de couplage faible des services facilite leur composition. En particulier, la création aisée et flexible de services de plus haut niveau par composition de services existants est une capacité fondamentale des Architectures Orientées Service. Pour cela, des langages tels que BPEL4WS [Dub02] et des plateformes éprouvées comme les moteurs d’orchestration sont apparus pour la spécification et la mise en oeuvre des compositions de services. Cependant l’expressivité du langage BPEL4WS vise uniquement les aspects fonctionnels des compositions et ne prend pas en compte la gestion de la QdS. Or, il n’existe ni langage ni infrastructure pour la gestion de la QdS dans les compositions de services. Les enjeux liés à la garantie de QdS des compositions de services sont aussi importants que les enjeux liés à l’assemblage fonctionnel des services. En particulier, la gestion de la QdS des compositions de services montre des limitations lors des étapes statique et dynamique de gestion des compositions de services :
Traitement statique Le traitement statique de la QdS s’effectue à un moment antérieur au déploiement de la composition et a pour enjeu de garantir les propriétés de QdS de l’assemblage (i.e. du service composite issu de la composition). Ce traitement suppose d’une part d’être capable de trouver un ensemble de services dont les offres de QdS satisfont aux exigences de QdS potentiellement portées par les divers éléments de la composition, et d’autre part de pouvoir déduire la QdS de l’assemblage à partir des offres provenant des services de la composition. En ce qui concerne la sélection des services entrant dans la composition [ZBN+04], si les services fonctionnellement équivalents restent encore relativement peu nombreux sur Internet, l’émergence de « l’orientation service » devrait permettre à moyen terme la création de vastes écosystèmes de services qui fourniront un choix conséquent d’offres. Dans un tel contexte, la sélection de multiples services entrant dans la composition parmi des ensembles de services aux multiples offres, chacune possédant de multiples contraintes de QdS, donne lieu à une explosion combinatoire. En ce qui concerne le problème de garantie de la QdS de l’assemblage en fonction de la QdS des services sous-jacents, des méthodes appropriées permettant d’agréger efficacement la QdS des services de la composition [CSM+04] sont requises. En outre, certains paramètres inconnus au pré-déploiement a priori (tels que le nombre d’itérations de certaines activités ou encore la sélection de certains chemins pour l’exécution de la composition) doivent être pris en compte [CPE+06]. Il se peut également que certains services n’exposent pas explicitement leur QdS, auquel cas des estimations de QdS doivent pouvoir être utilisées au lieu des offres.
Les architectes manquent de solutions pour effectuer leur vérification de QdS et la sélection des services. Les solutions proposées par les travaux récents [ZBN+04, CSM+04] sont également limitées quant à l’expressivité de la QdS qu’elles permettent de spécifier. En effet, les compositions de services sont souvent vues par ces méthodes telles des boîtes noires et il n’est pas possible d’envisager leur application sur certaines parties de la composition uniquement. Ces limitations font qu’il est souvent plus intéressant pour un architecte de sélectionner les services et d’effectuer les calculs de QdS manuellement.
Traitement dynamique Le traitement dynamique de la QdS s’effectue lors de l’exécution de la composition de services. A l’instar du traitement statique, il s’agit de garantir les propriétés de QdS de l’assemblage, la différence étant qu’à cette étape, les services ont déjà été identifiés. Cependant, à l’exécution, certains paramètres sont susceptibles de varier tels que la QdS des services appartenant à la composition. Or, si le service composite ne se montre pas capable de maitriser ses capacités de QdS, alors le client pourra préférer utiliser le service d’un concurrent. Il est donc fondamental de pouvoir observer les paramètres de QdS des diverses parties de la composition et de pouvoir réagir afin de préserver la QdS globale garantie initialement. La détection des variations de QdS fait appel à des mécanismes de type monitoring tandis que l’adaptation peut se traduire par une replanification de certains services de la composition. A l’exécution, seules des techniques de planification automatisées et efficaces en termes de performance peuvent être envisagées pour le traitement dynamique de la QdS. Or, les moyens de spécifier et de mettre en oeuvre l’adaptation de la QdS dans les compositions de services sont encore relativement limités et ne proposent souvent que des techniques de replanification de services soit globales soit locales [ZBN+04].
|
Table des matières
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 Conclusion
Télécharger le rapport complet
