WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Architecture soa (architecture orientée services)

( Télécharger le fichier original )
par Virginie ELIAS
CNAM Nantes - Pays de la Loire - Ingénieur en Informatique 2009
  

sommaire suivant

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

Centre Régional Associé de Nantes

MEMOIRE

présenté en vue d'obtenir

le DIPLOME D'INGENIEUR CNAM en INFORMATIQUE

Option: Systèmes d'information

Sujet

Architecture SOA (Architecture Orientée Services),

Quelle source de valeur pour le Groupe Terrena ?

Soutenu le 16 Juin 2009

par Virginie ELIAS

JURY

Présidente : Mme MÉTAIS, professeur CNAM Paris.

Responsable du cycle C : M. BRIAND, professeur École Polytechnique de Nantes.

Émetteur du sujet : M. HENRY, Responsable Méthodes, Service Informatique Terrena.

Tuteur Pédagogique : M. BELLEIL, maître de conférences, Université de Nantes.

« De l'architecture ; qualités de l'architecte.

1. L'architecture est une science qui embrasse une grande variété d'études et de connaissances ; elle connaît et juge de toutes les productions des autres arts. Elle est le fruit de la pratique et de la théorie. La pratique est la conception même continuée et travaillée par l'exercice, qui se réalise par l'acte donnant à la matière destinée à un ouvrage quelconque, la forme que présente un dessin. La théorie, au contraire, consiste à démontrer, à expliquer la justesse, la convenance des proportions des objets travaillés.

2. Aussi les architectes qui, au mépris de la théorie, ne se sont livrés qu'à la pratique, n'ont pu arriver à une réputation proportionnée à leurs efforts. Quant à ceux qui ont cru avoir assez du raisonnement et de la science littéraire, c'est l'ombre et non la réalité qu'ils ont poursuivie. Celui-là seul, qui, semblable au guerrier armé de toutes pièces, sait joindre la théorie à la pratique, atteint son but avec autant de succès que de promptitude. »

Vitruvius, -30

(Source : L'architecture de Vitruve, Tome I. Traduction nouvelle de M. Ch.-L. Maufras, Paris, éditeur C. L. F. Panckoucke, 1847,

pp. 29-43. Texte latin et français en regard.[MAU-VITR]).

Dessin 1 : Portrait, époque Renaissance

Marcus Vitruvius Pollio (-90 à -20)

(Source : www.theatre.ubc.ca)

Table des Matières

Table des Matières 3

Remerciements 7

Préalable 8

Introduction 9

1 Premier Volet : Etat de l'Art de l'Architecture SOA 12

1.4 Intégration des Systèmes d'Information 12

1.4.1 Point à point 13

1.4.2 ETL 15

1.4.3 EAI 17

1.4.3.1 Constitution de l'E.A.I. 18

La couche transport MOM 18

Le Message Broker 18

Les transformations 19

Les connecteurs 19

Le formatage 19

Les passerelles 20

1.4.3.2 Généralités 21

La gestion de Processus appelée aussi Workflow 21

L'intégration des applications Client/Serveur et 3-tiers 21

L'intégration des ERP 22

La sécurité 22

L'administration 22

1.4.4 ESB 24

1.4.4.1 Constitution de l'ESB 25

La JBI 25

Le Composant 25

Le Container 28

1.4.4.2 Généralités 29

Le Référentiel et le Registre de services (UDDI) : Le coeur de l'ESB 29

Le Routeur de message 30

1.4.5 Constat et principaux fournisseurs et solutions du marché 33

1.4.6 SOA 34

1.4.6.1 Constitution de la SOA 35

Le Service 35

L'opération 37

Le Processus 37

Le Composant 38

1.4.6.2 Généralités 39

Caractéristiques du Service 39

Caractéristiques du Composant 46

1.4.7 20 ans pour revenir au point de départ ? 47

1.5 Attentes d'une architecture SOA 49

1.5.1 Les bénéficiaires 50

1.5.1.1 Les utilisateurs 50

1.5.1.2 Les Services support des SI 50

1.5.1.3 Les Etudes Informatiques 50

1.5.1.4 L'entreprise 51

1.5.2 La mesure des gains 52

1.6 Quelle approche mettre en place ? 54

1.6.1 Des exemples d'urbanisation réussie (Top-Down) 55

1.6.1.1 AXA France Service (AFS) 55

1.6.1.2 AIR France - KLM 56

1.6.2 D'autres Exemples et d'autres approches (Bottom-up et Middleware Work Approach) 57

1.6.2.1 Magasins Harrods 57

1.6.3 La démarche MDA 58

1.6.3.1 Les Forces 60

Une plate-forme interopérable 60

Une aide au développement 60

1.6.3.2 Les Faiblesses 60

Une certaine complexité 60

1.6.3.3 Illustration simple 61

1.6.4 Les Gardes Fous 62

1.6.4.1 Modélisation MDA à travers les différents standards 62

UML 2.x, BPMN 62

XPDL, BPML, BPEL 63

Synthèse des standards 64

Interopérabilité des standards actuels 65

1.6.4.2 Méthodologie agile de conduite de projet 66

La méthodologie Lean 67

1.6.5 Décomposition des 3 principales couches SOA 75

1.6.5.1 La Couche Organisationnelle 75

1.6.5.2 La Couche Fonctionnelle 76

Bloc applicatifs 77

Règles de transformation 77

Processus métiers cibles 78

Agrégation des données à l'écran 80

1.6.5.3 La Couche Technique 81

L'exposition des services 81

Le service de localisation : UDDI 82

L'échange 83

Le Test 83

La Sécurité 83

Les zones implicites de confiance 84

Les zones explicites de confiance 84

La fédération d'identité 84

1.7 Quels outils ? 85

1.7.1 Les Web Services sont-ils suffisamment mûrs ? 86

1.7.2 XML : LE standard ? 87

1.7.2.1 Généralités 87

1.7.2.2 Applications du XML 88

1.7.2.3 Illustration des différentes couches de la famille XML 89

XML Schéma (XSD) 90

RDF 91

RDF Schéma (RDFS) 93

OWL 94

OWL-S 98

1.8 Les Faiblesses 103

1.8.1 Trop de standards tuent LE STANDARD 103

1.8.2 La méthodologie agile est-elle un préalable à l'architecture SOA ? 104

1.8.3 Un calcul ROI difficile 105

1.8.4 Un avenir incertain mais nécessaire 105

2 Second Volet : Modélisation de l'Architecture SOA 107

2.4 Le Groupe TERRENA 108

2.4.1 Présentation 108

2.4.2 L'expression du besoin 110

2.4.3 Définition du périmètre 111

2.4.3.1 Entité concernée : Les tiers 111

2.4.3.2 Volumétrie 112

2.4.3.3 Description du Processus actuel 112

2.4.3.4 Blocs applicatifs 112

2.4.3.5 Identification des ressaisies 114

2.4.3.6 Inventaire des activités du processus 114

2.4.3.7 XML Schéma de l'inventaire des activités du processus observé 115

2.4.3.8 Inventaire XML des activités du processus observé 116

2.4.3.9 Difficultés relevées au vu de l'inventaire et de la cartographie 117

Pas de supervision de la prise en compte des modifications tiers par les applications cibles 117

Pas de vue unique des règles de transformation 117

Un mode batch actuellement privilégié 117

Une orchestration statique 118

Pas de référentiel Métier 118

2.5 Modélisation de la problématique Terrena 119

2.5.1 L'objectif 120

2.5.2 La conceptualisation de notre monde clos 120

2.5.2.1 Les concepts 124

Les objets 124

Les états 124

Les actions 126

Les opérateurs 126

2.5.2.2 La coordination 127

2.5.2.3 La Modélisation de la communication actuelle 128

2.5.3 Urbanisation actuelle de notre SI 130

2.5.3.1 La Vue externe ou vue organisation 131

2.5.3.2 La Vue interne ou vue qualité de service (QoS) 131

2.5.3.3 La Vue Informationnelle 134

2.5.3.4 La Vue Applicative, fonctionnelle ou Vue Services 134

2.5.3.5 Les Faiblesses (Vue générale) 136

2.5.3.6 Les Faiblesses (Vue approfondie) 139

Intégrité des messages non respectée 139

Identification des messages compliquée et rigide 141

Un Protocole de transport unique et non sécurisé 143

Un processus qui s'arrête trop tôt 144

Les Données 145

Synthèse 146

2.6 Modélisation de la Cible 147

2.6.1 La démarche MDA 148

2.6.1.1 Rappel de l'articulation de la démarche MDA 148

2.6.1.2 Rappel du concept de Processus 150

2.6.2 Vue Métier ou la phase CIM de MDA 152

2.6.2.1 Définition de la cartographie cible 152

Zoom sur les composants de la cartographie 153

2.6.2.2 Modélisation des cas d'utilisation 154

2.6.2.3 Modélisation du Diagramme BPMN 155

2.6.3 Vue logique ou la phase PIM de MDA 156

2.6.3.1 Modélisation du Diagramme de Classes à partir du BPMN 156

2.6.3.2 Modélisation du Diagramme Etats-Transitions à partir du BPMN 157

2.6.3.3 Modélisation du Diagramme de Séquences à partir du BPMN 158

2.6.3.4 Modélisation du Diagramme d'activités à partir du BPMN 159

2.6.3.5 Synthèse de la modélisation UML 2.0 à partir du diagramme BPMN 160

2.6.3.6 Modélisation du diagramme de classes des entités Tiers, Rib et Adresse. 161

Ontologies Tiers du domaine public : l'INSEE, La Poste, ISO 163

Ontologie spécifique au monde rural : Le Projet GIEA 166

Spécificités Terrena 170

2.6.4 Vue Technique ou la phase PSM de MDA : de la modélisation technique à la génération du code 174

2.6.4.1 Le BPEL 174

2.6.4.2 Le document XSD du format Pivot 175

Mécanisme de transformation entre le profile UML standard et le Profil Xml 175

2.6.4.3 Le Wsdl 179

3 Troisième Volet : Réalisation 186

3.4 Etapes de la réalisation 187

3.4.1 L'environnement Technique 188

3.4.2 Première réalisation : Web Service / Polling fichier / Transformation / Transfert FTP 189

3.4.2.1 Web Service 189

3.4.2.2 Polling Fichier et Transformation 191

3.4.2.3 Transfert FTP 195

3.4.2.4 Assemblage global 199

3.4.3 Seconde réalisation : Polling fichier / Transformation / Transfert FTP 200

3.4.4 Résultats obtenus 201

3.4.4.1 Première réalisation 201

3.4.4.2 Seconde réalisation 203

Conclusion Générale 205

Et après ? 206

Bibliographie SOA (Services Oriented Architecture) 209

Ouvrage(s) 209

Thèse(s), Mémoire(s) ou exposé(s) de thèse(s) 210

Article(s) 210

Ressource(s) Internet 211

Sigles, Acronymes et Lexique de termes 212

Table des Illustrations 218

Table des Tableaux 221

Table des Dessins 221

Annexes 222

Enumérations 222

Package Oracle : Extraction 228

Illustration de la flexibilité apportée par le concept de service 233

Illustration de l'interopérabilité (traduction d'une source IBM) 235

Structures : Tiers, RIB et Adresses 239

SOAml 241

Résumé 245

Summary 245

Remerciements

Ce mémoire constitue la dernière page d'une longue formation vécue comme une chance et non comme une contrainte. Faire le choix de parfaire mes connaissances, une fois installée dans une vie familiale et professionnelle, toutes deux bien remplies, m'a permis de tirer ce qu'il y a de meilleur de la formation : l'envie de comprendre pour soi et pour les autres.

Cependant, cette longue traversée n'a pas été un apprentissage reposant, dénué de doutes car un peu à l'image de la jarre de Pandore, tout nouveau concept fut tout à la fois un enrichissement mais aussi une source de doutes quant à l'étendue du travail restant à couvrir. Un sujet de mémoire tel que l'Architecture SOA est à la fois riche et dangereux car la jarre renferme de nombreux concepts, et à peine en avons nous éclairci un, que se posent de nouvelles interrogations nécessitant davantage d'investigations. C'est pourquoi, à travers ce sujet s'en intercalent d'autres, tout aussi importants tels que l'urbanisation, les processus métiers, la méthodologie, la modélisation etc .... A l'image du concept d'Architecture de Vitruve, l'architecture SOA s'appuie sur un empilement de concepts plus ou moins anciens qu'il faut intégrer à la modernité du moment.

Je tiens à remercier tout particulièrement Claude BELLEIL pour ses cours du troisième cycle (et plus particulièrement celui concernant le « Web Sémantique ») et son soutien pédagogique pour cette dernière étape. A travers lui, je pense à tout le Corps Enseignant du CNAM qui sait donner, avec passion, le fruit d'un savoir prodigué au sein d'une belle institution qui séduit de plus en plus largement. Mais je n'aurais sans doute pas pu vivre cette expérience, et de cette manière, sans l'aide de mon entreprise, le Groupe TERRENA, qui depuis le début, m'a donné les moyens et le temps nécessaire; et plus particulièrement Etienne HENRY, responsable Méthodes Terrena qui a su être rassurant et me poser les questions qui m'ont aidées à construire ma réflexion. Ce chapitre ne serait pas complet si je ne réitérais pas à mon mari, Marc ELIAS, toute mon affection et ma réelle reconnaissance d'avoir accepté qu'autant de temps soit consacré à l'approfondissement des choses au détriment, parfois, de moments que nous aurions pu passer ensemble. Enfin, je dédie ce mémoire à mon fils qui restera ma plus belle réalisation. Je souhaite lui transmettre cette curiosité en tout, ce qui fait que chaque jour est apporteur de richesse.

À Antoine,

Préalable

Les Outils utilisés pour la réalisation de ce mémoire ont été choisis, soit parce qu'ils avaient peu d'équivalent dans leur domaine (XMLSpy pour la partie XML), soit parce qu'ils entraient dans le cadre UML 2.0, tout en pouvant être couplés à un IDE (MagicDraw comme Modeleur UML avec Netbeans). Les différents acronymes, cités dans ce paragraphe, seront bien entendu définis dans ce mémoire.

Tout chapitre significatif sera annoncé au lecteur par le biais d'un cartouche miniature. Les grandes phases déjà parcourues et celles à venir seront ainsi rappelées.

Introduction

Faiblesses

Etat de l'Art

Intégration

Approche

Outils

Gains

Modélisation

Expression

Du Besoin

Terrena

Modélisation Cible

Modélisation Problématique

Réalisation

Etapes

Résultats

Conclusion

Illustration 1 : Cartouche Mémoire

L'objectif de cette introduction est de présenter à la fois l'articulation du mémoire, et le concept d'Architecture dans sa forme originelle.

Introduction

Le mémoire d'Ingénieur CNAM consiste en la réalisation de tout ou partie d'un projet, en laboratoire ou en entreprise. La démarche suivie au travers de ce document doit permettre de présenter la problématique de mise en place d'une architecture SOA en termes techniques et fonctionnels. L'état de l'art, constitué à partir d'une bibliographie, servira de base à la définition et à la mise en oeuvre d'une solution chez Terrena. Il sera fait en sorte que cette démarche soit également transposable dans une entreprise aux activités différentes.

Ainsi la première partie sera consacrée à l'analyse des fondements d'une architecture SOA. Puis la Coopérative et le Groupe Terrena, feront l'objet d'une présentation permettant d'introduire la problématique d'une telle mise en place dans une entreprise dont l'histoire est ancienne et dont les activités sont multiples. La seconde partie aura pour but de modéliser ce qu'il faudra implémenter sur un périmètre restreint, et ce, tout en restant éloigné de l'aspect technique. Dans la troisième partie, seront exposés le choix et la mise en oeuvre de la solution ainsi que les résultats obtenus.

A

rchitecture :

Art de concevoir et de construire un bâtiment, selon des parties esthétiques et des règles techniques déterminées. Structure, organisation.

(Source : Le Petit Larousse 2003)

L'art de construire des édifices. Disposition, caractère architectural. Forme, structure. (Source : Le Robert 1995)

Il y a plus de 2000 ans, est né le concept d' « Architecture ». Vitruve, ingénieur et architecte romain (1er siècle av. J.C.), est l'auteur de 10 volumes consacrés à ce sujet. A la fin de sa vie, il achève ainsi son oeuvre « De Architectura » qu'il dédie à l'empereur Auguste. Il n'y aura pas d'autres legs de cette nature pour décrire l'architecture de l'Antiquité. Il y énonce entre autre que l'architecture est le fruit conjugué de la théorie et de la pratique scientifique, qu'elle cristallise l'ensemble des sciences d'une époque. Dans le troisième volume, il définit davantage ce qu'est l'architecture :

« Des parties dont se compose l'architecture.

L'architecture se compose de trois parties : la construction des bâtiments, la gnomonique et la mécanique. La construction des bâtiments se divise elle-même en deux parties : l'une regarde l'emplacement des remparts et des ouvrages publics ; l'autre traite des édifices particuliers.

Les ouvrages publics sont de trois sortes : la première a rapport à la défense, la seconde à la religion, la troisième à la commodité. Ceux qui concernent la défense sont les remparts, les tours et les portes de villes, qui ont été inventés pour servir perpétuellement de barrière contre les attaques de l'ennemi. Ceux qui regardent la religion sont les temples et les édifices sacrés, élevés aux dieux immortels. Ceux qui concernent la commodité sont les lieux consacrés à l'usage du peuple, comme les ports, les places publiques, les portiques, les bains, les théâtres, les promenoirs, tous les lieux, en un mot, qui ont cette destination.

Dans tous ces différents travaux, on doit avoir égard à la solidité, à l'utilité, à l'agrément : à la solidité, en creusant les fondements jusqu'aux parties les plus fermes du terrain, et en choisissant avec soin et sans rien épargner, les meilleurs matériaux ; à l'utilité, en disposant les lieux de manière qu'on puisse s'en servir aisément, sans embarras, et en distribuant chaque chose d'une manière convenable et commode ; à l'agrément, en donnant à l'ouvrage une forme agréable et élégante qui flatte l'oeil par la justesse et la beauté des proportions. »

Vitruvius, -30

(Source : L'architecture de Vitruve, Tome III. Traduction nouvelle de M. Ch.-L. Maufras, Paris, éditeur C. L. F. Panckoucke, 1847.

Texte latin et français en regard.[MAU-VITR])

Il serait quelque peu cocasse de s'interroger à quel point l'architecture informatique d'aujourd'hui, et la SOA en particulier, rejoignent les fondamentaux évoqués dans le précédent texte. S'essayer à l'illustration de la vision de Vitruve, pourrait donner la représentation suivante :

Illustration 2 : Libre interprétation de l'Architecture selon Vitruve

Un seul mot n'a pas été tiré du texte d'origine : « Règles». Il a été introduit dans le schéma en lieu et place du mot « Religion » car à l'époque de Vitruve, la Religion et l'Etat formaient la même entité (cf « religion politique »). Les règles religieuses sont tout autant des règles d'Etat.

« Rome n'est pas un État laïque, c'est un État sous la protection des dieux ; on parle donc de religion politique. Les dieux sont en effet avant tout les dieux de la cité. Les prêtres sont reconnus par l'État, et en font partie intégrante. Ils sont en quelque sorte des magistrats (...)»

(Source : www.etudes-litteraires.com/religion.php).

Illustration 3 : la Rome Antique

où l'ominiprésence de la religion

(Source : http://www.francebalade.com)

1 Premier Volet : Etat de l'Art de l'Architecture SOA

L'objectif de ce chapitre est de présenter les différentes strates technologiques ayant apporté à la fois des réponses aux besoins du moment mais aussi une certaine hétérogénéité au Système d'Information (SI).

1.4 Intégration des Systèmes d'Information

I

ntégration des systèmes d'information :

Vise à proposer un accès unique aux diverses fonctionnalités réparties entre les différentes solutions logicielles indépendamment de l'infrastructure technique sous-jacente (...). Elle garantit idéalement l'appel des fonctionnalités, les échanges sécurisés d'information et le support transactionnel.

(Source : « L'ingénierie des processus métiers - De l'élaboration à l'exploitation » [BRI-IPM] page 204)

Le Système d'Information (SI) est souvent constitué de sources de données et d'applications hétérogènes, obtenues suite à la fusion-acquisition1(*) avec d'autres services informatiques (rachat de sociétés) ou par la mise en place de solutions informatiques de nouvelle technologie. Aussi, les systèmes d'intégration évoluent à chaque « révolution technique ou fonctionnelle ». Nous allons voir combien ils ne cessent de se construire autour de concepts plus anciens, un peu à l'image de la ville de Vitruve. Enfin, lorsque sera plus précisément abordée l'Architecture Orientée Services (SOA), les concepts seront plus largement étudiés ainsi que la notion de valeur (dans le sens « gain »). Mais comment en sommes nous arrivés à mettre au devant de la scène la SOA ou autrement dit : Que s'est-il passé entre Vitruve et l'Architecture Orienté Services ?

1.4.1 1.4.1 Point à point

Avant les années 1990, les applications sont monolitiques. C'est ce que l'on pourrait appeler « l'age d'or » du développement spécifique. Un même mainframe propriétaire héberge bien souvent l'ensemble des applications métiers de l'entreprise (principalement des modules de gestion allant de la gestion commerciale jusqu'à la comptabilité, en passant par les achats et incluant souvent les applications de ressources humaines comme la Paie). Les interfaces entre modules s'exécutent alors sur la même machine.

Puis, de plus en plus de solutions informatiques se « progicialisent » et les fusions-acquisitions s'intensifient. Ainsi de nouveaux serveurs prennent place dans les salles informatiques. A cette époque les connecteurs et les protocoles ne sont pas construits sur des standards. Des applications de plus en plus hétérogènes sont interfacées, telles des briques posées les unes à côté des autres. Souvent, l'arrivée d'une nouvelle application nécessite une nouvelle machine, une nouvelle organisation des données ou une nouvelle technologie et de nouveaux développements vers tout ou partie des applications existantes.

Alors que les premières années ne se souciaient guère de l'aspect financier (la principale préoccupation étant la modernisation des services de l'entreprise pour une meilleure productivité), les considérations économiques s'installent progressivement à la table des DSI. La maintenance et les évolutions de l'intégration inter-applicative occupent beaucoup de monde et génèrent des coûts significatifs.

Outre l'aspect financier, il est également difficile de disposer d'une vision claire de l'ensemble des flux métiers circulant dans le SI. Les cartographies pas toujours à jour, illustrent bien souvent cet imbroglio de flux comme un plat de spaghettis.

Illustration 4 : Interfaçage Point à Point

Par exemple, pour un SI constitué de 7 applications où toutes sont amenées à échanger au moins un flux de données avec les autres, le nombre de liens mis en oeuvre est calculé de la manière suivante :

* 1 Les fusions-acquisitions représentaient dans le monde 200 milliards de dollars en 1990, contre près de 1200 milliards en 2000 (source Unctad, interactive Data : FDI Report : M&A [FOR-EAE] ) et 3610 milliards en 2006 [MON-RFA]. La crise mondiale actuelle devrait aussi apporter son lot de fusions-acquisitions.

sommaire suivant











9Impact, le film from Onalukusu Luambo on Vimeo.



Bitcoin - Magic internet money - Join us !