Soutenance mémoire
Concepts de base du paradigme orienté service
Évolution vers les approches orientées services
En génie logiciel, un certain nombre d’approches ont été proposées pour le développement de logiciels. Chaque nouveau paradigme proposé essaie de résoudre les limitations des paradigmes précédents en essayant de réutiliser certains principes et ajouter de nouveaux. C’est ainsi que les approches orientées objets [Taylor, 1998], orientées composants [Szyperski, 1998] et dernièrement les approches orientées services ont vu l’apparition. Pour dissimuler la complexité d’intégration d’applications autonomes et hétérogènes, trois architectures à base de composants ont été proposées [Vinoski, 2004], [Schantz et Schmidt, 2002] : EJB (Enterprise Java Beans), CORBA (Common Object Request Broker Architecture), et.NET. Cependant, le couplage entre les objets est relativement fort dans ces technologies à base de composants distribués. Par exemple, la norme CORBA permettant la manipulation des objets à distance avec n’importe quel langage, nécessite une connaissance de la structure des objets par les applications clientes et par les fournisseurs. Ceci implique que les différents partenaires doivent définir au préalable des règles de transformation objets/messages. En outre, on ne peut assembler que des objets CORBA (ou COM) entre eux, puisque chaque architecture propose sa propre infrastructure. Par conséquent, la mise en œuvre de ces architectures dans le cadre d’une infrastructure ouverte telle que Internet soulève des difficultés. Pour palier les limites de toutes ces architectures, les efforts de conception ont donné lieu au concept d’architecture orientée service (Service Oriented Architecture SOA)[Papazoglou et al., 2008]. Ainsi, les approches orientées services ont vu le jour.
Le paradigme orientée services est un paradigme interdisciplinaire destiné pour les applications distribuées. Son apparition a introduit une nouvelle manière dont les applications logicielles sont conçues, intégrées, fournies et utilisées. Les approches orientées services [Huhns et Singh, 2005] mettent en avant l’idée de composer des services indépendants pour réaliser des applications logicielles agiles faiblement couplées. Ces approches exploitent le concept de service comme élément fondamental autour duquel les applications complexes sont développées. L’idée de base est d’encapsuler les fonctionnalités offertes par les organisations sous forme de services. Par conséquent, l’intégration et la gestion des applications à base de services se focalisent au niveau des fonctionnalités sans tenir compte des technologies utilisées et en cachant les détails de l’implémentation. Les approches à base de services offrent la possibilité de réaliser une interopérabilité à grande échelle en garantissant la souplesse nécessaire afin de s’adapter à l’évolution des technologies et des besoins des utilisateurs (individus ou entreprises). Un des principaux bénéfices des approches à base de services est le couplage faible entre le fournisseur et le consommateur de service d’une part, et entre les différents services réunis dans une même application d’une autre part. le consommateur d’un service n’a pas besoin d’avoir connaissance des détails techniques tels que la technologie d’implémentation et la plateforme d’exécution d’un service [Dustdar et Papazoglou, 2008b]. Ce faible coupage permet le développement d’applications de façon parallèle et indépendante, ce qui entraine une réduction des coûts de développement et d’intégration des applications.
Les services
Le service représente la brique de base dans une architecture orientée services. Il est assez difficile de donner une définition précise au service car il est utilisé dans plusieurs domaines. Il peut être défini tout simplement comme suit : un service est une action réalisée par une entité au profit d’une autre. De manière intuitive, la notion de service correspond à une abstraction des fonctionnalités d’une entité. Cette entité peut être simple comme une donnée ou un objet sur le web. Elle peut aussi être complexe comme un système d’information adaptable d’une entreprise. Avant l’utilisation d’un service, il est nécessaire de connaitre ses fonctionnalités qu’il accomplit et même ses caractéristiques non-fonctionnelles comme sa performance ou sa disponibilité. Plus particulièrement, un service logiciel (qui représente une entité logicielle mise à la disposition d’autres applications) doit être décrit et publié. Ses capacités sont ensuite découvertes par les utilisateurs éventuels qui peuvent par la suite exécuter le service pour obtenir la fonctionnalité demandée.
Étudions maintenant certaines définitions précises qui ont été données pour le service. Selon [Dustdar et Papazoglou, 2008b], « Services are self-contained processes deployed over standard middleware platforms, e.g., J2EE, or .NET that can be described, published, located (discovered), and invoked over a network… Services are most often built in a way that is independent of the context in which they are used. This means that the service provider and the consumers are loosely coupled. ». Cette définition présente le service comme un processus autonome qui est décrit, publié, découvert et invoqué via le réseau. La conception du service est indépendante de sa technologie d’implémentation et sa plate-forme d’exécution. En plus, le service ne connaît pas le contexte dans lequel il va être utilisé. Cette indépendance caractérise fortement les services et elle facilite le faible couplage. Ceci permet d’utiliser des services réalisés avec des technologies d’implémentation différentes et de les déployer sur des plates-formes hétérogènes. OASIS, un consortium mondial travaillant sur le développement, la convergence et l’adoption de standards pour les applications informatiques, propose la définition suivante : « A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description… A service is accessed by means of a service interface where the interface comprises the specifics of how to access the underlying capabilities. » [Brown et al., 2006]. Cette définition présente un service comme un mécanisme permettant l’accès à une ou plusieurs fonctionnalités et dont l’accès est offert grâce à une interface définie. Cette interface décrit les fonctionnalités offertes par le service et un ensemble de contraintes et de politiques d’accès aux fonctionnalités offertes.
Arsanjani définit un service comme suit : « A service is a software resource (discoverable) with an externalized service description. This service description is available for searching, binding, and invocation by a service consumer. » [Arsanjani, 2004]. Dans cette définition, les principales interactions permettant l’utilisation des fonctionnalités d’un service sont identifiées. Un client de service passe par une étape de recherche pour découvrir la description du service correspondant à ses critères. Ensuite, cette description permet de faire la liaison avec le service et de réaliser l’invocation du service. [Han et al., 2009] considère un service comme une abstraction du niveau métier implémentant les processus métiers. Une définition du concept service est énoncée par [Cauvet et Guzelian, 2008], qui considère un service comme une unité réutilisable encapsulant un ou plusieurs fragments d’un processus métier et visant à satisfaire des buts métiers. A travers les différentes définitions, nous ressortons une idée principale, à savoir qu’un service permet d’exposer une ou plusieurs fonctionnalités décrites par une description de service. Cette description est utilisée par les clients du service pour rechercher, sélectionner et invoquer le service adéquat. Un ensemble de caractéristiques spécifiques aux services peuvent être distinguées [Bachtarzi, 2014] .
• Les services sont réutilisables puisque chaque fonctionnalité de service peut être utilisée plusieurs fois.
• Les services sont composables. En effet, un nouveau service peut être créé par composition de plusieurs services existants. La composition peut être vue comme une forme de la réutilisation puisqu’un service particulier peut participer dans plusieurs compositions.
• Les services sont faiblement couplés, ce qui permet de réduire les dépendances et d’assurer une meilleure flexibilité.
• Les services peuvent être vus comme des boites noires puisqu’ils ne sont accessibles qu’à travers leurs interface cachant les détails d’implémentation des fonctionnalités fournies.
Le service est l’élément de base de l’architecture orientée service introduite ci-après.
|
Table des matières
Introduction
1 État de l’art
1.1 Introduction
1.2 Concepts de base du paradigme orienté service
1.2.1 Évolution vers les approches orientées services
1.2.2 Les services
1.2.3 Architecture orientée service
1.3 La composition de services
1.3.1 Stratégies de composition de services
1.3.2 Composition statique vs composition dynamique
1.3.3 Composition manuelle vs automatique
1.3.4 Degrés d’automatisation/dynamicité
1.3.5 Points d’intérêt de la composition de services
1.3.5.1 Description de services
1.3.5.2 Matching des services
1.3.5.3 Combinaison de services
1.3.5.4 Sélection de services
1.4 Approches automatiques pour la composition des services
1.4.1 Techniques basées sur la planification IA
1.4.2 Techniques basées sur le chaînage
1.4.3 Approches basées règles
1.4.4 Approches basées connaissances
1.4.4.1 Approches basées patrons
1.4.4.2 Approches basées sur le raisonnement par cas (et/ou) apprentissage
1.5 Problématique
1.5.1 Besoin de flexibilité dans la construction de services composites adaptables
1.5.2 Difficultés pour la génération dynamique des schémas de composition
1.5.3 Inadéquation de la composition de service avec l’intention de l’utilisateur
1.6 Conclusion
2 Modèles sémantiques pour la composition des services
2.1 Introduction
2.2 Approche générale
2.3 Pré-requis de notre approche de composition de services
2.3.1 Introduction aux ontologies OWL/OWL-S
2.3.2 Les services abstraits
2.3.2.1 Définition et motivation
2.3.2.2 Spécification des services abstraits
2.3.2.3 Mise en œuvre des services abstraits avec OWL-S
2.3.3 Formalisation des intentions
2.3.3.1 Background sur les intentions
2.3.3.2 Représentation des intentions
2.3.4 La notion de contexte
2.4 Conclusion
3 Approche basée sémantique pour la composition des services
3.1 Introduction
3.2 Le processus de composition automatique
3.2.1 Enrichissement du graphe des intentions
3.2.2 La génération du schéma de composition initial
3.2.2.1 La construction du flux de contrôle
3.2.2.2 La sélection des services abstraits
3.2.3 La génération du schéma de composition final
3.2.3.1 Matching sémantique
3.2.3.2 Utilisation du contexte
3.2.4 Génération du plan d’exécution
3.3 Conclusion
4 Implantation et évaluation de notre approche de composition des services
4.1 Introduction
4.2 Mise en œuvre de l’environnement de composition
4.2.1 Architecture de l’environnement de composition
4.2.2 Outils, langages et technologies utilisés
4.3 Cas d’étude
4.3.1 Description de l’environnement
4.3.2 Graphe initial des intentions du cas d’étude
4.4 Application de l’approche sur le cas d’étude
4.4.1 Application des règles d’enrichissement
4.4.2 Génération du schéma de composition initial
4.4.3 Génération du schéma de composition final
4.5 Évaluation
4.5.1 Évaluation du temps d’exécution
4.5.2 Qualité des résultats
4.6 Conclusion
Conclusion générale
