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.
Architectures logicielles
Les architectures basées sur composants requièrent un couplage fort entre les diffé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 stabilité et homogénéité. En effet, 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.) difficiles à 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.
Politiques
Bien que n’étant pas uniquement applicable au domaine de la QdS ou des services Web, le concept de politique apporte des outils privilégiés dans le cadre de la mise en oeuvre de mécanismes de QdS dans le contexte des services Web. Conceptuellement, une politique est un moyen offert aux administrateurs pour définir et modifier l’organisation et le comportement d’un système. Elle se compose généralement de règles, dérivant de la description d’une stratégie et spécifiant au système les actions à entreprendre pour répondre à une situation donnée. « Policies are rules governing the choices in behavior of a system » [Slo94] Plus formellement, une politique peut être définie selon deux perspectives [Wes01] :
– une stratégie, des objectifs permettant de guider et déterminer les actions présentes et futures à exécuter au sein du système.
– un ensemble de règles permettant d’administrer, superviser et commander l’accès aux ressources du système.
Ces définitions mettent en évidence les différents niveaux d’abstraction introduits par la spécification de politiques, selon l’utilisateur concerné. Les abstractions au niveau business simplifient le travail des administrateurs en définissant leurs besoins en tant qu’objectifs globaux tandis que les règles entrent dans les détails de l’implémentation de la stratégie à utiliser pour atteindre ces objectifs. « Objectifs -> Règles -> Commandes de bas niveau » Ceci rend les systèmes plus flexibles et capables de se reconfigurer, pendant leur exécution si besoin, afin de respecter les règles prédéfinies. Les règles composant les politiques sont généralement décrites par des variantes du paradigme ECA 20 : « (on Event(s)) if Condition(s) do Action(s) » Pour de telles règles, la condition est évaluée lors de l’événement spécifié et l’action est exécutée si cette condition est vérifiée. La spécification d’une politique peut être effectuée à l’aide d’un langage dédié. Les langages utilisent différentes techniques de représentation (objet, logique, graphique, etc.). Une forme canonique [KFY+06] peut être dérivée, se composant des éléments suivants :
– sujet (subject) : désigne l’entité à laquelle s’applique la politique.
– cible (target) : identifie l’entité affectée par l’application de la politique.
– événement (event) : décrit l’événement qui déclenche l’évaluation de la condition.
– action (action) : définit les opérations exécutées sur la cible afin d’imposer la politique.
– condition (condition) : décrit l’état du système et les contraintes permettant d’activité l’action.
|
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
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 Modèle d’exécution du langage QoSL4BP
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
Télécharger le rapport complet
