Soutenance mémoire
ARCHITECTURES ORIENTEES SERVICES
INTRODUCTION AUX ARCHITECTURES ORIENTEES SERVICES
Ce chapitre a pour ambition d’établir une revue de littérature sur les architectures orientées services; sans prétendre à l’exhaustivité, notre objectif est que ce chapitre soit suffisamment complet pour qu’une personne non initiée aux architectures des systèmes d’information (SI) perçoive les motivations de notre travail. Une première partie de ce chapitre sera consacrée à la présentation des architectures orientées services (SOA) et de leurs principes de base. Nous nous intéresserons ensuite à la présentation des avantages et des limites de SOA. Nous allons exposer par la suite les principaux aspects d’une architecture SOA réalisée à base de web services. Avant de clore ce chapitre, nous montrerons le lien qui relie les architectures orientées services à la modélisation des processus d’affaires. 1.2 Architecture Orientée Services SOA, ou architecture orientée services, est un concept qui a pris beaucoup d’ampleur cette dernière décennie (à partir des années 2000). Cette architecture est le résultat de l’évolution exponentielle qu’ont connu les systèmes informatiques au court des quarante dernières années. L’idée de concevoir des architectures orientées services est venue avec l’apparition des solutions Client / Serveur, au début des années 1990. Les architectures traditionnelles (basées sur l’orienté objet et l’orienté composant) ont atteint leurs limites en termes de capacité, alors que les besoins des organisations demeurent en perpétuelle augmentation. Plusieurs architectures ont été conçues afin d’assurer des traitements distribués. Des langages de programmation destinés à être exécutés sur n’importe quelle plateforme et une myriade de produits de connectivité ont vu le jour pour assurer une 5 intégration rapide et efficace des applications. Toutefois, les coûts et les délais de cette intégration deviennent de plus en plus inacceptables, surtout que les systèmes d’information deviennent de plus en plus complexes. SOA est une approche évolutive qui contribue à mettre en place un système d’information flexible, assurant ainsi une interopérabilité intrinsèque et une meilleure agilité pour l’entreprise. Diverses définitions ont été avancées sur le compte de SOA, chacune a sa propre vision sur ce concept. Malgré cette diversité, ces définitions partagent le même point de vue sur ce que SOA ne peut pas l’être. En effet, SOA ne peut pas être considérée, ni comme un produit, ni une solution, ni une technologie comme le croient certains. Les définitions trouvées dans la littérature peuvent être classées suivant le niveau d’abstraction qu’elles adoptent pour décrire SOA. Dans un niveau d’abstraction plus haut, Girish et al. (2007) décrivent SOA comme un paradigme permettant l’organisation et l’utilisation de capacités distribuées qui pourraient être sous le contrôle de différents propriétaires de domaines. Dans un niveau d’abstraction moindre, Sandy (2007) définit SOA comme une approche architecturale orientée métier permettant la mise en place d’un système d’information qui sera alignée avec les objectifs métiers de l’entreprise. La clé de voûte de SOA est le service qui n’est autre qu’un composant ou une tâche métier qui se répète fréquemment dans les processus d’affaires de l’entreprise. Dans un niveau d’abstraction plus pragmatique, SOA peut être définie comme étant une architecture d’applications au sein de laquelle toutes les fonctions sont spécifiées en tant que services indépendants, comprenant des interfaces qui peuvent être sollicitées dans des séquences bien déterminées pour créer des processus d’entreprise (Kishore et al., 2004). 6 Cette multitude de niveaux d’abstraction adoptés pour définir SOA a influencé considérablement les architectures orientées services contemporaines, qui sont très souvent organisées en couches, offrant ainsi plusieurs niveaux d’abstraction. Cette organisation multicouche a pour objectif de : • lier le niveau métier, qui est plutôt abstrait, au niveau applicatif, qui est très technique, • réduire la complexité de l’architecture, • apporter une plus-value en termes de flexibilité et de couplage faible (loose-coupling) à l’échelle de l’entreprise, • permettre une modélisation d’affaires orientée services, • et assurer une meilleure agilité organisationnelle. La couche de services d’application : cette couche établit le niveau d’abstraction le plus bas, qui peut exister dans une SOA. Elle a pour rôle d’exprimer des fonctionnalités spécifiques au système d’information de l’entreprise. Les services qui résident au sein de cette couche peuvent être simplement appelés des services d’application. Le but de ce type de services est de fournir des fonctions réutilisables, liées aux traitements techniques réalisés sur les données, dans les environnements applicatifs. • La couche de services d’affaires : Les services d’affaires sont la pierre angulaire des architectures SOA contemporaines. Leur unique but consiste à représenter la logique d’affaires en sa forme la plus pure. Ces services peuvent englober soit des entités ou des tâches métiers. • La couche d’orchestration de service : elle introduit le niveau d’abstraction le plus élevé dans SOA. Cette couche vient pour répondre aux besoins d’avoir des services, intitulés les services de processus (process services), qui gèrent les interactions entre les opérations d’autres services, ceci afin d’assurer l’exécution de ses dernières (les opérations) dans un ordre bien déterminé. Les services de processus sont créés à partir de la composition d’autres services, qui offrent un ensemble spécifique de fonctions, indépendamment des règles d’affaires et de la logique des scénarios, requis pour l’exécution d’un processus. L’implémentation d’une architecture orientée services multicouche présente un défi pour l’entreprise, surtout qu’il n’existe pas une approche standard pour la mise en place d’une telle architecture. Cependant, il y a un ensemble de principes de base à respecter dans le processus de conception d’une architecture orientée services. Parmi ces principes, nous pouvons citer : le couplage, l’abstraction, la réutilisabilité, l’autonomie, la découvrabilité et la composabilité (Erl, 2008). Dans ce qui suit, nous allons décrire chacun de ces principes, tout en commençant par définir le concept de service. 8 1.2.1 Le concept de service Le service est la brique de base de l’architecture orientée services. La granularité d’un service peut varier selon le choix du concepteur du système d’information. Un service peut se réduire à une simple tâche élémentaire comme il peut englober tout un processus métier, d’ordre de complexité plus ou moins importante. Un service doit disposer d’une interface qui permet de dialoguer avec lui. Par analogie, cette interface joue le rôle d’un contrat entre le fournisseur et le consommateur de service. Le contrat indique notamment la liste des opérations disponibles, la manière de les employer (entrées/sorties attendues), ainsi que la ressource physique (le serveur) sur laquelle se trouve le service (Rouillard, Vantroys et Chevrin, 2007) . Les caractéristiques d’un service peuvent parfois faire illusion au concept d’« Objet » du paradigme orienté objet, cependant une grande différence existe. Un objet est basé sur le principe d’encapsulation d’un ensemble de données et de méthodes manipulant ces données. Afin d’exploiter l’objet, ce dernier doit être initialement instancié. Un service, quant à lui, traduit une tâche ou un processus d’affaires et tant qu’il est publié, il peut être invoqué et exploité. 1.2.2 La notion de couplage La définition du terme « couplage » est assez simple dans le vocabulaire informatique : toute entité qui peut se connecter à une autre entité a un couplage. Les entités couplées peuvent former des dépendances entre elles (Erl, 2008). L’ambiguïté dans le terme « couplage » est introduite en ajoutant les termes « lâche » et « fort ». Dans les architectures orientées services, il existe des formes de couplage inévitables et qu’y sont présentes par nature (Figure 1.2). En effet, la logique du service est, par nature, fortement couplée (Heubès, 19 mars 2009) : 9 • à son implémentation physique (Figure 1.2 lien 1), • aux technologies sur lesquelles s’appuie son implémentation (Figure 1.2 lien 2), • aux services qui le composent (dans le cas de services composites) • aux processus qui lui font appel
|
Table des matières
INTRODUCTION GENERALE
CHAPITRE 1 INTRODUCTION AUX ARCHITECTURES ORIENTEES SERVICES
1.1 Introduction
1.2 Architecture Orientée Services
1.2.1 Le concept de service
1.2.2 La notion de couplage
1.2.3 Le principe d’abstraction
1.2.4 La notion de réutilisabilité
1.2.5 L’autonomie d’un service
1.2.6 La découvrabilité de services
1.2.7 La composabilité de services
1.3 Avantages de l’architecture SOA
1.4 Limites de l’architecture SOA
1.5 Web services : une réalisation de SOA
1.6 SOA et la modélisation des processus d’affaires
1.6.1 Notation de modélisation unifiée (UMN)
1.6.2 Langage d’exécution des processus d’affaires BPEL
1.7 Conclusion
CHAPITRE 2 APPROCHES D’IDENTIFICATION DE SERVICES DANS L’ARCHITECTURE SOA
2.1 Introduction
2.2 Cycle de vie de SOA
2.2.1 Phase d’analyse
2.2.2 Phase de conception orientée service
2.2.3 Phase de développement
2.2.4 Phase de test
2.2.5 Phase de déploiement
2.2.6 Phase de gestion des services
2.3 Approches d’identification de services
2.3.1 Approche descendante (Top-Down)
2.3.2 Approche ascendante (Bottom up)
2.3.3 Approche mixte
2.4 Analyse critique des différentes approches d’identification de services
2.5 Conclusion
CHAPITRE 3 PROPOSITION D’UNE APPROCHE D’IDENTIFICATION DE SERVICES
3.1 Introduction
3.2 Principes de l’approche proposée
3.3 Description détaillée de la démarche proposée 3.3.1 Identification des services entités
3.3.1.1 Sélection des activités sujettes d’étude
3.3.1.2 Identification des informations clés
3.3.1.3 Sélection des informations les plus récurrentes
3.3.1.4 Sélection des activités les plus sollicitées et des informations qui leur sont corrélées
3.3.1.5 Identification des services entités
3.3.2 Identification des opérations des services entités
3.3.3 Identification des services d’application
3.3.4 Identification des opérations des services d’application
3.3.5 Identification des services centrés-tâche
3.3.5.1 Identifier les activités candidates à être des services centrés-tâche
3.3.5.2 Définir la logique des candidats de service centrés-tâche
3.3.6 Définir la couche d’orchestration
3.3.6.1 Identification des processus à orchestrer
3.3.6.2 Orchestration des processus d’affaires
3.3.6.3 Transformation d’un modèle métier en un modèle intermédiaire
3.3.6.4 Génération automatique d’un BPEL à partir d’un modèle intermédiaire
3.4 Conclusion
CHAPITRE 4 VALIDATION DE L’APPROCHE PROPOSEE
4.1 Introduction
4.2 Identification des services entités
4.2.1 Sélection des activités sujettes d’étude
4.2.2 Identification des informations clés
4.2.2.1 Sélection des informations les plus récurrentes
4.2.2.2 Sélection des activités les plus sollicitées et des informations qui leur sont corrélées
4.2.3 Identification des services entités
4.3 Identification des opérations des services entités
4.4 Identification des services d’application
4.5 Identification des opérations des services d’application
4.6 Identification des services centrés-tâche
4.6.1 Identifier les activités candidates à être des services centrés-tâche
4.6.2 Définir la logique des candidats de service centrés-tâche
4.7 Définir la couche d’orchestration
4.7.1 Identification des processus à orchestrer
4.7.2 Orchestration des processus d’affaires
4.7.2.1 Transformation d’un modèle métier en un modèle intermédiaire
4.7.2.2 Génération automatique d’un BPEL à partir d’un modèle intermédiaire
4.8 Conclusion
CONCLUSION GENERALE
ANNEXE I LISTE DES ACTIVITÉS AUTOMATIQUES ET SEMIAUTOMATIQUES
ANNEXE II OCCURRENCES DES INFORMATIONS MÉTIERS
ANNEXE III LISTE DES ACTIVITÉS LES PLUS SOLLICITÉES
ANNEXE IV DESCRIPTION DES OPÉRATIONS BASIQUES DES SERVICES ENTITÉ
ANNEXE V DESCRIPTION DÉTAILLÉE DES OPÉRATIONS DES SERVICES D’APPLICATION
ANNEXE VI DIAGRAMMES DE DEPENDENCE POUR LES SERVICES CENTRÉS-TÂCHE
ANNEXE VII DIAGRAMMES DE SÉQUENCE DES SERVICES CENTRÉS-TÂCHE
ANNEXE VIII ANALYTICAL HIERARCHY PROCESS (AHP)
ANNEXE IX MATRICES DE PONDÉRATION
BIBLIOGRAPHIE
Télécharger le rapport complet
