Réingénierie et restructuration d’applications existantes vers des architectures à base de services

Réingénierie et restructuration d’applications
existantes vers des architectures à base de services

Concepts et notions de base

L’architecture orientée service

Une architecture orientée service est un style architectural qui se base sur la notion de service, c’est une approche qui répond aux exigences d’une informatique distribuée faiblement couplée, basée sur des normes , et indépendante des protocoles [12], elle permet de construire une application qui fournit des services soit à des applications d’utilisateurs finaux, soit à d’autres services distribués dans un réseau, en s’appuyant sur des interfaces publiées et découvrables [13]. Nous pouvons constater que la base de la SOA est bien le service. La notion de service est une notion qui est mieux définie dans un contexte d’entreprise que dans un contexte technique. Il peut être décrit comme la façon de spécifier des fonctionnalités commerciales (business) encapsulées indépendamment de toute implémentation technique. Dans ce contexte, un service est davantage un concept commercial qu’un concept informatique [14]. La signification de SOA varie selon le public visé. Il n’existe pas de définition standard pour la SOA, mais en contrepartie, de nombreuses définitions sont de plus en plus répandues (Tableau 2.1), toutes tournent autour de l’idée d’un contrat bien défini, rempli par un prestataire et utilisé par des consommateurs. Les prestataires et consommateurs peuvent résider dans la même organisation ou dans des organisations séparées distantes. Chapitre 2 : L’architecture orientée service et ses technologies 8 Il existe plusieurs perspectives qui se partagent la définition de SOA : (1) la perspective métier ou affaire, (2) la perspective de la conception d’architecture et (3) la perspective de développement [15]. Dans le cadre de notre travail, nous accordons une attention particulière aux perspectives : métier et architecture. Le point de vue métier d’une SOA doit fournir un ensemble de services qu’une unité d’entreprise met à la disposition de ses clients et l’alignement métier-IT est le principal objectif de cette perspective. En ce qui concerne le point de vue architecture de conception SOA, c’est un ensemble de décisions qui respectent les principes du paradigme orienté services afin de permettre une activité de conception réutilisable. Pour la SOA, aucune forme particulière de technologie pour la mise en œuvre n’est spécifiée, les services SOA devraient demeurer indépendants de leur implémentation sous-jacente. Le choix des technologies et des outils reste secondaire.

La SOA, Pourquoi ?

L’architecture orientée services (SOA) rend le développement d’applications plus flexible et adaptable que les applications créées à l’aide d’architectures traditionnelles. Par conséquent, les applications SOA sont plus faciles à modifier et à adapter. La SOA peut également permettre un meilleur alignement entre les processus métier et les services ou applications informatiques. Cet alignement a pour effet d’un coté de minimiser l’écart sémantique entre les modèles de processus métier et les logiciels des applications réels et d’autre coté d’optimiser l’efficacité et l’agilité de l’entreprise. De nombreux avantages ont été détaillés par Erl [10], l’Open group [21], ou encore Grigoriu [22]. Nous citons ceux résumés par Pant et Juric [23]: • Réduire au minimum le fossé informatique et le temps nécessaire pour modifier les informations en réponse à l’évolution des processus d’entreprise. • Rendre le système d’information plus flexible et adaptable au changement par une approche faiblement couplée • Enfin, rendre l’entreprise plus agile, plus flexible, et faciliter son adaptation à diverses pressions, telles que pressions concurrentielles, nouvelles opportunités, changements du marché mondial, etc. 

Le service

Une architecture orientée services repose principalement sur le concept de service qui est l’unité atomique de cette dernière, dans ce contexte tous les éléments du système d’information sont considérés comme des services qui interagissent pour offrir un ensemble de fonctionnalités. Nous n’avons pas de définition standard pour les services, mais il existe de nombreuses définitions, qui varient selon le domaine et le contexte. Par conséquent, nous trouvons des définitions liées aux domaines des métiers, de la technologie, de l’économie ou du marketing et du management. Prenons quelques définitions à titre d’exemples, ces définitions sont plus orientées vers nos domaines d’intérêt, à savoir les solutions informatiques et applicatives. Définition 1 : Un service est simplement un ensemble d’opérations reliées entre elles. C’est donc la logique encapsulée par les opérations individuelles qui doit être considérée comme réutilisable pour justifier la représentation comme un service réutilisable [18]. Définition 2: Un service est une ressource abstraite qui effectue une tâche cohérente et fonctionnelle[24] Définition 3 : Un service est considéré comme un processus qui a une interface ouverte, et une granularité grossière. Il peut être facilement décomposé et composé pour mettre en œuvre divers flux de travail [25]. Définition 4 : Un service représente certaines fonctionnalités (application fonctionnelle, transaction commerciale, un service du système de base, etc.) exposées sous la forme d’un composant au sein d’un processus métier. [26]. Nous pouvons ainsi retenir que le service encapsule une logique métier et l’expose sous forme d’un ensemble d’opérations dont les interfaces sont publiées et accessible à distance. Il doit disposer de toutes les informations et ressources nécessaires pour s’exécuter de façon autonome, il peut être codé dans n’importe quel langage et s’exécuter sur n’importe quelle plate-forme, il doit aussi assurer le respect d’un ensemble de caractéristiques qui raffinent sa définition et que nous détaillerons dans ce qui suit.

Les caractéristiques des services

Erl [10], a spécifié huit caractéristiques principales pour les services comme étant des principes à respecter pour se conformer rigoureusement à l’orientation service, à savoir : • Contrat standardisé : Les services partagent un contrat formel qui leur permet d’interagir, ce dernier décrit chaque service et définit les termes de l’échange d’informations. • Couplage lâche : Les services doivent être conçus pour interagir sans qu’il soit nécessaire d’établir des dépendances étroites et croisées. • Abstraction : La seule partie d’un service qui est visible par le monde extérieur est celle qui est exposée via le contrat de service. La logique sous-jacente, au-delà de ce qui est exprimé dans les descriptions qui composent le contrat, est invisible et sans pertinence pour les demandeurs de services. • Réutilisabilité : les services sont conçus pour soutenir une réutilisation potentielle, ils doivent encapsuler une logique de traitement suffisamment générique pour être utilisés en tant que ressource réutilisable. • Composabilité : Les services peuvent composer d’autres services. Cela permet de représenter la logique à différents niveaux de granularité et favoriser la réutilisation et la création de couches d’abstraction. • Autonomie : Le service doit avoir le contrôle de son environnement et de ses ressources, il ne doit pas dépendre d’autres services pour l’exécution de sa gouvernance. On doit pouvoir le remplacer ou le déplacer sans que cela affecte d’autres services. Il doit aussi pouvoir évoluer indépendamment des autres services • Sans état (stateless) : Les services ne devraient pas être tenus de gérer les informations de l’état, car cela peut entraver leur capacité à rester faiblement Chapitre 2 : L’architecture orientée service et ses technologies 11 couplés. Ils devraient être conçus de façon à maximiser l’indépendance aux données d’état, même si cela implique de différer la gestion de l’état ailleurs. Une fois les opérations réalisées, le service ne retient aucune information sur l’état des messages ou du consommateur. • Découvrabilité : Les services devraient être facilement découverts et compris par les demandeurs de services qui peuvent être en mesure de les interpréter de façon effective.

Le service métier

La notion de service a principalement évoluée dans un contexte d’entreprise plutôt que dans un contexte informatique [6]. Tous les travaux liés à la classification des services ont évoqué la séparation entre les services de niveau métier (entreprise) et les services de niveau informatique. Le service métier doit décrire les aspects métiers et opérationnels liés à sa mise en œuvre. Il est totalement indépendant des implémentations techniques. Un service métier est la représentation d’une activité métier élémentaire ou complexe, il fournit des capacités commerciales par le biais de regroupements logiques d’opérations . Ces opérations seront implémentées par un ou plusieurs services informatiques.

Table des matières

1. Introduction générale
1.1 Contexte du travail
1.2 Problématique et contribution
1.3 Organisation du document
Première partie : Etat de l’art
2. L’architecture orientée service et ses technologies
2.1 Introduction
2.2 Concepts et notions de base
2.2.1 L’architecture orientée service
2.2.2 La SOA, Pourquoi ?
2.2.3 Le services
2.2.4 Les caractéristiques des services
2.2.5 Le service métier
2.3 Les Technologies de mise en œuvre de la SOA
2.3.1 Le service web
2.3.2 XML (Extensible Markup Language)
2.3.3 SOAP (Simple Object Access Protocol)
2.3.4 WSDL (Web Services Description Language)
2.3.5 UDDI (Universal Description, Discovery and Integration)
2.3.6 Les acteurs d’une architecture à base de services web
2.4 Conclusion
3. Réingénierie logicielle et migration vers SOA
3.1 Introduction
3.2 Modernisation des systèmes patrimoniaux vers la SOA
3.3 Les systèmes patrimoniaux
3.4 Réingénierie et migration logicielle
3.4.1 Réingénierie logicielle
3.4.2 Migration des logicielles
3.5 Stratégies d’évolution vers une architecture orientée service
3.5.1 Approches d’identification des services
3.5.2 Les approches d’évolution des systèmes patrimoniaux vers SOA
3.5.3 Discussion des stratégies d’évolution vers SOA
3.6 Classification des approches d’évolution des SPs vers SOA
3.6.1 Approches décisionnelles
3.6.2 Approches partielles
3.6.3 Approches techniques
3.6.4 Critères de comparaison
3.7 Positionnement des choix effectués par rapport aux approches étudiées
3.8 Conclusion
4. Modélisation par les processus métiers
4.1 Introduction
4.2 L’approche processus
4.3 Processus
4.4 Processus métier
4.5 Business Process Management (BPM)
4.6 Cycle de vie du BPM
4.7 BPMN (Business Process Model and Notation)
4.8 Les systèmes de modélisation des processus
4.9 Les éléments graphiques de BPMN
4.10 Pourquoi choisir le BPM pour migrer vers SOA ?
4.11 Conclusion
5. Processus d’identification des services
5.1 Introduction
5.1.1 Définition des termes récurrents
5.2 Caractéristiques de la solution proposée
5.3 Processus d’identification des services
5.3.1 L’analyse de l’application existante
5.3.2 Modélisation des processus BPMN
5.3.3 Exportation des diagrammes BPMN vers un Format XPDL
5.3.4 Analyse des diagrammes BPMN
5.3.5 Identification des services candidats
5.3.6 Règles d’identification
5.3.7 Gestionnaire des règles
5.3.8 Les Fonctions du gestionnaire des règles
5.4 Validation des services candidats
5.4.1 Evaluation par les experts
5.4.2 Evaluation par les métriques de qualité
5.5 Choix de la granularité du service
5.6 Conclusion
6. Etude de cas sur les systèmes e-learning
6.1 Introduction
6.2 Travaux connexes
6.3 La démarche suivie
6.4 Identification des services d’une plateforme e-learning
6.4.1 L’analyse de l’application existante
6.4.2 Modélisation des fonctionnalités
6.4.3 Conversion des diagrammes BPMN vers le format XPDL
6.4.4 Identification des services candidats
6.5 Les services du LMS identifiés par le Framework
6.5.1 Service candidat de Test du Niveau Initial (TNI)
6.5.2 Service candidat Gestion des cours distants (GCD)
6.5.3 Service candidat Aide au Tuteur (AT)
6.5.4 Service candidat Gestion de la Bibliothèque (GB)
6.5.5 Service candidat de la Gestion de la Collaboration (GC)
6.5.6 Service candidat Regroupement des Apprenants (RA)
6.6 La mise en œuvre des services identifiés
6.6.1 La partie principale du LMS (Service Client)
6.6.2 Les services web
6.7 Conclusion
7. Conclusion générale et perspectives
8. Liste des productions scientifiques
9. Références

projet fin d'etudeTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *