Architecture SOA (Architecture Orientée Services ). Quelle source de valeur pour le Groupe Terrena?

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-acquisition^1(*) 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 :

n(n-1)

2

où n représente le nombre d'applications, soit dans ce cas (7 applications) : 21 liens.

Ce syndrome dit « spaghetti » est d'autant plus fort qu'il est constitué de technologies bien différentes (Transfert de fichiers, Echange de messages, Alimentation de Datawarehouse, Réplication de données etc ...). Il illustre diverses problématiques : codage de la transcodification des données et de la transformation de leur structure, redondance des données dans plusieurs référentiels, vue d'ensemble difficile à obtenir, sécurisation inexistante des flux, difficulté à passer en temps réel ...

1.4.2 ETL

_

Illustration 5 : ETL : le plat de spaghettis semble plus organisé

Une fois le « business Model » en place, les DSI sont amenées à justifier davantage le retour sur investissement des nouvelles solutions à déployer. Les impacts sur les développements, la maintenance et le déploiement sont alors regardés à la loupe. Les années se succédant, il faut aussi se soucier de l'intégration du « Legacy system »^2(*) dans une architecture en pleine mutation. La cartographie macroscopique des applications permet au Directeur Informatique d'optimiser et de construire sa stratégie tout en l'expliquant à la Direction Générale. Les applications de gestion ne sont plus suffisantes pour répondre au besoin des utilisateurs et il faut y ajouter de la valeur, c'est à dire des outils de pilotage car la vue verticale de l'entreprise ne permet pas d'analyser transversalement les différentes activités ou métiers. C'est pour répondre à ce dernier besoin, qu'ont été conçus les datawarehouses^3(*). En conséquence, les échanges de données deviennent plus importants et nécessitent des outils capables de gérer le référentiel des données hétérogène de l'entreprise. C'est dans ce contexte que s'installent dans notre quotidien les ETL^4(*) (en 1997, date du premier brevet déposé) mais dans la première moitié des années 90 pour d'autres solutions non brevetées. Leur vocation est de traiter de gros volumes d'échanges en mode différé, souvent la nuit ou tout au moins, pendant les heures creuses, en mode batch. La problématique des données hétérogènes est prise en charge par les nouvelles fonctionnalités graphiques de mapping de données et par des modules de connaissance internes permettant tout aussi bien d'interagir sur des bases de données différentes (Oracle, Sybase, SQL Server ...) que sur des fichiers à plat (CSV) ou propriétaires (EBCDIC, RMS...). Chaque application est connectée à l'ETL et forme un tout, sans avoir à connaître la topologie globale du système. La responsabilité est laissée à la couche broker qui gère la connexion de chaque application. Le développeur d'interfaces commence à disposer d'une vue unique, toute modification dans un des modèles de données pouvant faire l'objet d'une mesure d'impact sur l'ensemble du système. Les premiers scénarios d'intégration^5(*) sont mis en oeuvre, permettant d'encapsuler des modules de traitement



de façon « intelligente » (notion d'interfaces packagées, avec boucles et conditions).

Illustration 6 : Constitution d'un ETL

1.4.3 EAI

Les besoins de la fin des années 90 tendent vers une accélération des flux afin de décloisonner virtuellement les applications et de permettre des prises de décision plus rapides. L'EAI^6(*) apporte sa touche de simplification à l'architecture du SI, en fluidifiant les échanges d'informations, cette fois-ci au fil de l'eau, dans un mode évènementiel. Contrairement à l'ETL, l'EAI traite principalement de faibles volumes et n'opère que de légères transformations de données.

_

Illustration 7 : EAI : le plat de spaghettis semble plus ordonnancé et mieux distribué

De nouveaux concepts sont introduits tels que les messages en mode quasi-temps-réel, le workflow^7(*) et la prise en charge de ces messages dans une couche de transport appelée « Message Oriented Middleware » (MOM)^8(*) en mode asynchrone^9(*) ou Object Request Broker (ORB)^10(*) en mode synchrone11(*), ressemblant tous deux à une file d'attente. La première solution (MOM) offre l'avantage de pouvoir assurer une reprise d'activité propre en cas de panne réseau par exemple car le mode asynchrone est plus souple. Il permet à certaines applications de ne pas être disponibles au moment de l'alimentation du MOM.

1.4.3.1 Constitution de l'E.A.I.

La couche transport MOM

Le MOM fonctionne en mode « Publish and Subscribe » qui s'apparente à un mode d'abonnement où le bus d'échanges met les informations à disposition des applications abonnées. Les applications dites « publicatrices » ne font qu'alimenter ce bus sans avoir à connaître les applications « abonnées » à leur message. Le système d'échange présente l'avantage de la flexibilité, de la fluidité et de la robustesse. La qualité de service s'invite dans l'argumentaire des Editeurs d'EAI puisque de ce point de vue, les temps d'intégration d'un nouvel outil s'en trouvent diminués et que les flux sont davantage sécurisés. Mais le MOM reste un modèle d'échange point à point dans le sens où une application émettrice poste un message dans la file d'attente pour une et une seule application destinataire abonnée qui viendra, selon sa disponibilité, « consommer » ce message. Si le même message doit aussi être consommé par une autre application, alors il devra avoir été posté une seconde fois, d'où le risque d'un nouveau syndrome spaghetti.

Le Message Broker

C'est pour cela que le Message Broker, qui peut fonctionner en mode centralisé, trouve tout son sens dans l'architecture MOM. Il est constitué d'un hub^12(*) qui détient la connaissance des publicateurs et des abonnés. Aussi, un message devant être consommé par deux applications différentes, pourra n'être posté qu'une seule fois (principe de « content-based routing »). Ce Message Broker propose des services complémentaires permettant de simplifier la communication entre les applications.

Les transformations

Un outil « parse »^13(*) les messages afin de définir des champs sur lesquels des règles peuvent être définies, et donc de construire de nouveaux messages. Le référentiel « Méta-données »^14(*) s'enrichit de toutes les règles de transformation des flux de l'entreprise. La connaissance « métiers » commence à être centralisée en un seul lieu et un vocabulaire commun se construit.

Les connecteurs

Les connecteurs deviennent de plus en plus nombreux afin de pouvoir intégrer les ERP^15(*) (SAP par exemple), pour lesquels un développement spécifique serait coûteux mais aussi des standards pour l'industrie tels que : EDIFACT^16(*), EDI^17(*), pour la finance (Fix^18(*)), la santé (HL7^19(*)), le transport.

Le formatage

L'idée est d'introduire un formatage normalisé et commun via l'« eXtensible Markup Language »20(*) (XML), afin de limiter le nombre de transformations. Cette solution ajoute à l'EAI le caractère d'interopérabilité^21(*) qui lui faisait défaut dans les premières années de son lancement. De plus, XML est une norme de codification permettant de faciliter les échanges entre entreprises : catalogues, commandes, factures...

Les passerelles

Outre les passerelles classiques vers les SGBDR tels qu'Oracle, DB2, SQLServer, Sybase, ODBC, JDBC ..., les serveurs d'application, les moniteurs TP comme Tuxedo^22(*) et les transferts de fichiers, certaines portes s'ouvrent vers d'autres EAI tels que IBM WebSphere^23(*), BEA MessageQ^24(*). Les points forts du MOM sont :

q La possibilité de gérer des priorités de message,

q La prise en compte systématique du message par le système (consommé par le destinataire, ou une fois sa durée de vie terminée, transmis à une file d'attente spécifique),

q La possibilité de passer en mode synchrone par l'ajout d'une attente de réponse,

q Le déclenchement de traitements, un peu à la façon des triggers, dès qu'un message particulier arrive dans la file d'attente.

Données ERP Service MainFrame



Illustration 8 : Constitution d'un E.A.I.

1.4.3.2 Généralités

La gestion de Processus appelée aussi Workflow

Le Message Broker présente quelques failles que le Workflow s'efforce de gommer : l'impossibilité de gérer N flux vers 1 cible (avec besoin de synchronisation) et la difficulté à manipuler des scénarios complexes intégrant par exemple des branches conditionnelles. Pour ce faire, le Workflow est une couche supplémentaire placée au-dessus du Message Broker où sont définis les flux métiers. Autant les ETL étaient orientés « données », autant les EAI sont orientés « métier » en s'appuyant pour cela sur le référentiel des règles métiers. Ainsi la mise à disposition d'une vision unique est précieuse pour une administration globale des processus. Le concept d' « Orchestration »^25(*) de processus métiers commence à apparaître. Ce couplage est rendu possible par l'utilisation du « Business Process Management »^26(*) (BPM) qui permet de représenter les échanges entre les différents services de l'entreprise.

L'intégration des applications Client/Serveur27(*) et 3-tiers

Les messages sont gérés dans des procédures stockées « appelables » via des trigger. C'est ainsi que l'application peut ouvrir et fermer les files de messages ainsi que prendre ou déposer un message dans la file ouverte. Une autre solution est de répliquer certaines tables de l'application et de s'appuyer sur la surveillance d'un agent qui déclenche, sous condition, un événement lui-même générateur d'un flux pris en charge par le MOM. L'intégration d'une application 3-tiers^28(*) devient plus simple, car elle est articulée autour d'Application Programming Interface^29(*) (API) propriétaires, en C/C++^30(*), Java^31(*), Cobol etc.... ou de composants COM^32(*), JMS^33(*) et EJB^34(*) connectées au MOM.

L'intégration des ERP

Ces solutions offrent en général deux possibilités d'intégration :

q L'API aussi appelée connecteur lourd,

q Le Message que l'on peut comparer à un connecteur léger.

Depuis quelques années, une troisième solution se développe grâce au format XML qui devient le format d'intégration des ERP.

La sécurité

La sécurité est placée sous la responsabilité du MOM, dans les couches basses de l'architecture et donc éloignée de la couche métiers. Elle n'est pas la couche la plus mature de l'EAI (et c'est pourquoi nous verrons, au chapitre concernant l'Architecture SOA, que la sécurité a été considérablement enrichie).

L'administration

Administrer l'intégration consiste à configurer les flux (routage et paramétrage), les superviser au travers d'indicateurs de qualité de service, tout en donnant la possibilité à l'exploitation de relancer un service, de déclencher les sauvegardes etc.... Chaque connecteur qui relie une application au bus EAI constitue un lieu à partir duquel le monitoring est possible via les consoles de supervision « Business Activity Monitoring »^35(*) (BAM).

Le principal reproche que l'on a pu faire il y a quelques années aux outils d'EAI est leur aspect « propriétaire ». A cette époque, les connecteurs, les transformateurs de données ainsi que l'orchestration des processus sont rarement standardisés. Lors de rapprochement de deux entreprises toutes deux dotées d'un EAI, l'interopérabilité n'est pas toujours réalisable. L'entreprise, alors très liée à l'éditeur, est impactée en termes de coût et peut s'interroger sur la pérennité de la solution implémentée.

En 2001, l'architecture J2EE Connector Architecture^36(*) (JCA), mise en avant par BEA à travers sa solution Weblogic Intégration Server 1.0, vient ébranler le monde de l'EAI. Cela marque le début de la standardisation (Java, XML, les Web Services^37(*)) des EAI qui se dotent dès lors de connecteurs B2B^38(*) et B2C^39(*) sortant du A2A^40(*) originel (Application vers Application). En 2003, nous passons d'un EAI dit « tactique », pouvant se résumer à la couche technique, à un EAI « stratégique », ouvrant la communication entre toutes les strates horizontales et transversales de l'entreprise mais aussi et surtout vers l'extérieur.

1.4.4 ESB

Depuis la fin des années 90, le monde des logiciels libres n'a eu de cesse de vouloir gagner ses lettres de noblesse auprès des entreprises qui les ont accueillis de prime abord avec une certaine méfiance. L'ESB^41(*) est souvent représenté comme l' « héritier » de l'EAI, à la différence près qu'il s'appuie sur des standards lui permettant, par exemple, de pouvoir communiquer avec d'autres ESB. Il constitue, en quelque sorte, la colonne vertébrale d'un système d'information agile car les applications amenées à communiquer ensemble, peuvent être très hétérogènes allant jusqu'à inclure des ERP et des plates-formes Web, le tout sur la base de protocoles très différents (HTTP^42(*), SOAP^43(*) ...).

Les principaux concepts de l'ESB sont les services Web, le routage intelligent basé sur le contenu, la traçabilité, les transformations et l'échange de messages asynchrones, ainsi que la centralisation de la sécurité. L'interopérabilité est très forte car la mise en oeuvre d'un ESB passe avant tout par l'utilisation systématique de standards comme XML, JMS pour les services. Le monitoring de l'activité de l'ESB est assuré par le BAM (Business Activity Monitoring) et la modélisation des processus métiers orchestrés par l'ESB est rendue possible par l'utilisation du BPM (Business Process Management). Cette standardisation de l'intégration rend son coût plus attractif que celui des EAI.

Et déjà les communautés libres proposent des solutions ESB. Nous pouvons citer par exemple le projet Petals soutenu par le consortium OW2^44(*). C'est par l'arrivée des ESB que s'accélère la prise en compte des standards par les outils EAI stratégiques, amenant ces derniers à revoir leur politique tarifaire. EAI et ESB finissent alors par se rejoindre et il n'est pas rare de trouver une solution se targuant de la mention « EAI/ESB ». Mais la ressemblance entre EAI et ESB n'est que de façade.

1.4.4.1 Constitution de l'ESB

La JBI

La norme JSR-208^45(*) définit le fonctionnement de la « Java Business Intégration »^46(*) (JBI) et fournit le mode de fonctionnement des composants ainsi que le mode de routage des messages XML vers ces derniers. C'est là que se situe le socle du bus ESB.

Le Composant

Les composants sont, soit externes au bus (dits «Binding Componant» ou BC) et servent de connecteurs avec les applications métiers, ou alors internes (dits «Service Engine» ou SE) car ils sont invoqués à l'intérieur du bus.

Chaque Composant est soit Fournisseur (« Provider ») car il fournit un service interne au bus, soit Client ou aussi appelé Consommateur (« Consumer ») car il se place dans une position d'écoute de l'extérieur, prêt à déclencher un service interne. Un Binding Componant peut ainsi être Provider et/ou Consumer, par contre, un service engine ne peut être que Provider.

Les instances de service sont placées dans un fichier zip appelé le Service Assembling Artifact (SA), en autant de Service(s) Unit (SU). A chacun de ces niveaux de services est associé un fichier jbi.xml contenant la description du fonctionnement du service et les points d'entrée et de sortie (les Endpoints^47(*)). Le SA correspond au Use Case UML^48(*).

_

Illustration 9 : Cas d'utilisation / Services

Si le Endpoint du service « VérifierActifs » est favorable alors le service « CréerPrêt » pourra être instancié pour la demande de prêt. Si le Endpoint du service « CréerPrêt » est valide alors l'accord de prêt sera transmis.

Un service peut être utilisé à la demande d'un utilisateur, ou en masse, par un traitement batch. Il y a deux types de services : les services métiers qui répondent à une fonction métier (exemple : calcul d'un taux de marge) et les services d'infrastructure ou services techniques qui sont utilisés par les services métiers mais qui représentent des fonctions transverses du SI (exemple : gestion des comptes utilisateurs).

L'exemple ci après est extrait d'une maquette qui m'a servi à la compréhension des principes de base d'un ESB. Il s'agit de la mise en place d'un flux FTP dans l'ESB Petals^49(*) (soutenu par le consortium OW2).



Illustration 10 : Service SU - Get FTP



Illustration 11 : Service SA pointant sur un SU FTP

Il s'agit là de la description de deux niveaux de services JBI : un service unitaire chargé de produire un GET FTP, et l'enveloppe de ce service, appelée « service assembly » ou « SA ». C'est en XML, langage de l'interopérabilité par excellence, et à partir sa grammaire structurante (Xml Schema) que les composants de l'ESB sont définis.

Le Container50(*)

Les services sont positionnés au sein de containers. Un container peut ainsi accueillir un ou plusieurs services (une transformation suivie d'un routage par exemple). Le but est de rapprocher les containers des applications avec lesquelles ils vont travailler. Ainsi pour un processus, la consommation d'un premier service est suivie de la consommation d'un second service de façon naturelle, sans avoir à revenir sur le bus. Cette haute distribution soulage la charge du système.



Illustration 12 : Constitution d'un ESB

1.4.4.2 Généralités

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

L'UDDI^51(*), spécification OASIS^52(*), constitue un registre XML de services Web qui permet de localiser le service recherché. C'est une des clefs de voûte de la sécurité WS-*^53(*) car c'est par lui que sont gérées les autorisations d'accès des utilisateurs aux services. Souvent associé à une solution Intégrée (IDE^54(*)), le référentiel via un framework permet de gérer au mieux et de déployer les services. Aussi les outils permettant de gérer le versioning ainsi que le travail collaboratif sont autant de facteurs à ne pas négliger au moment du choix d'un ESB.



Illustration 13 : Articulation Référentiel / UDDI

(http://www.bull.com/fr/bulldirect/N7/expert.html)

Illustration 14 : Diagramme de séquence d'exécution d'un service



Le consommateur et le fournisseur sont ici des objets UML composites. Le consommateur écoute les messages venant de l'extérieur et initie les échanges JBI à partir de ces derniers. De plus, il s'adresse au serveur proxy qui traite la requête. Une fois la réponse reçue, le serveur met en cache la réponse et la retourne au consommateur. Le fournisseur peut quant à lui fournir un service de transformation mais aussi un service d'agrégation faisant appel à N services unitaires. L'utilisation d'un UDDI n'est pas obligatoire. Mais dans ce cas, le client (appelé « Consommateur ») doit connaître l'emplacement physique des services, qu'il s'apprête à invoquer. Cela rend l'architecture rigide, en termes d'utilisation car elle ne profite pas de l'UDDI, réel médiateur d'invocation des services.

Le Routeur de message

Un Routeur de Message Normalisé (NMR) établit la communication entre les composants du JBI. Il est constitué de trois éléments :

q Le Normalized Message, qui est la structure standard des messages d'entrée, de sortie et d'erreur ainsi que les éventuelles propriétés et attachements,

q Le Message Exchange qui représente l'échange (message d'entrée et de sortie, le statut, l'émetteur, le destinataire),

q Le Delivery Channel car chaque composant est affecté à un canal de communication propre.

Les échanges entre les composants peuvent être de quatre types :

q In-Only (Aller Simple) : Envoi du message au destinataire sans être sûr qu'il arrivera,

q Robust In-Only (Aller Simple) : Envoi du message au destinataire avec un A/R ,

q In-Out (Aller et Retour) : Envoi d'un message au destinataire, demandant une réponse,

q

_

In Optional-Out (Aller et peut être Retour) : Envoi d'un message au destinataire qui peut retourner une réponse.

Illustration 15 : Diagramme de séquences d'un échange In Out se terminant normalement

(Source : http://blog.xebia.fr/2008/08/01/servicemix-32x-introduction-a-jbi/#more-537)

_

Illustration 16 : Diagramme de séquences d'un échange In Out se terminant en erreur

(Source : http://blog.xebia.fr/2008/08/01/servicemix-32x-introduction-a-jbi/#more-537)

Ces concepts sont communs à tous les ESB, mais pour autant, s'ils sont construits autour de standards dont les performances ne sont pas toutes équivalentes. Les capacités de sécurité, de tolérance vis à vis des pannes, les kits de développement (IDE libres comme Eclipse^55(*) ou Netbeans^56(*)), les modules de monitoring ainsi que « la scalabilité »^57(*) sont autant de points qu'il est important d'étudier lorsque l'on doit faire le choix d'un ESB. Au-delà même de la mise en place technique, force est de constater que l'industrialisation du développement est une condition majeure de réussite d'un projet global. La gestion de la qualité (phases de test, identification des modifications, traçabilité des versions), le respect des procédures internes (processus de validation), mais aussi la capacité à capitaliser par la réutilisation des composants et le référentiel (règles de transformation et de routage) sont incontournables pour la réussite d'une telle mise en place.

_

Illustration 17 : ESB + BPM + BAM + IDE : les Clefs de l'agilité ?

1.4.5 Constat et principaux fournisseurs et solutions du marché58(*)

Depuis l'ère du Mainframe, les décennies se sont succédées apportant de nouvelles strates technologiques (micro, client-serveur, ETL, EAI, Internet ...) et de nouveaux protocoles (FTP, HTTP, SOAP ...). Le système d'information s'est complexifié car rarement une technologie a totalement remplacé une autre, plus ancienne. La cohabitation du nouveau et de l'ancien est une obligation, un peu à l'image de nos vieux centres urbains. Néanmoins, il est demandé aux DSI de stabiliser leurs budgets informatiques tout offrant plus de services. C'est une des raisons pour lesquelles la SOA devient une réelle préoccupation et que les offres foisonnent :

ETL

q Ascential Software

q Hummingbird

q Informatica

q Information Builders

q Business Objects (via l'acquisition d'Acta)

q CrossDataBase Technology (Data Exchanger)

EAI

q WebMethods (SAG)

q Seebeyond (SUN)

q Tibco

q BEA (WebLogic Integration) (Oracle)

q Microsoft (Biztalk)

q IBM (WebSphere Integration)

q BlueWay (Net.EAI)

q Sunopsis (racheté depuis peu par Oracle : solution ODI)

MOM

q WebSphere MQ (ex MQSeries) d'IBM

q MSMQ de Microsoft

q SonicMQ de Sonic

q FioranoMQ de Fiorano

ESB

q WebMethods (SAG)

q Tibco

q BEA (WebLogic Integration) (Oracle)

q Microsoft (Biztalk)

q IBM (WebSphere Integration)

q Sonics

q Netbeans (SUN)

1.4.6 SOA

La démarche SOA n'est pas nouvelle et ne peut se résumer à de simples briques techniques. Elle trouve néanmoins ses racines dans l'ESB qui constitue son épine dorsale, et à travers lui, les architectures plus anciennes. Les besoins d'intégration restent actuels, malgré la mise en oeuvre des ESB car les technologies « e-business » arrivent à maturité : serveurs J2EE et .Net, Web Services (SOAP et WSDL). Mais l'enjeu est tout autant de faire communiquer toutes les typologies de serveurs (nouvelles, anciennes, progiciels ou legacy system) que d'intégrer des applications parfois partiellement redondantes en termes de fonctions et/ou de données.

L'enjeu est de répondre à un besoin de plus en plus exprimé par les utilisateurs : celui d'un accès dit « sans couture » aux différents services du SI, c'est à dire sans l'obligation de changer de poste de travail, ou d'application, et sans avoir à sortir sa calculatrice pour agréger des données éparpillées sur plusieurs systèmes. L'idée est de pouvoir accéder aux services internes et externes de la façon la plus transparente possible pour l'utilisateur. La notion d'Entreprise s'étoffe et devient tantôt Entreprise Reseau, Entreprise Etendue, Entreprise e-transformée, Entreprise Plug-and-play, Entreprise Agile. Pour ce faire, trois leviers permettent d'oeuvrer dans ce sens : la transversalité, la granularité et la réactivité. La transversalité vise, par exemple, à présenter une vue unifiée du client ou du stock. La granularité permet de tendre vers la mutualisation des fonctions. Ce n'est plus une application qui engendre des fonctions mais l'utilisation de certaines fonctions communes qui constituent un processus. La réactivité est le liant des deux premiers leviers (notion de zero latency^59(*) ou latence zéro).

ESB et SOA se confondent en termes techniques dans le sens où l'ESB est un des modules de base de la SOA et dans la mesure où des outils complémentaires ont déjà été greffés aux ESB pour les rendre plus agiles : BAM, BPM, IDE, UDDI ...Il est difficile de trouver une définition précise de ce qu'est la SOA. Aussi, dans un premier temps, l'accent peut être mis sur les concepts de base de l'architecture SOA.

1.4.6.1 Constitution de la SOA

Le Service

Le « S » de SOA annonce le concept de Service. La question, que beaucoup se posent en abordant ce premier concept est de savoir s'il s'agit de « service » dans le sens Web Service, ou autrement dit, s'il est possible de mettre en oeuvre une architecture SOA sans Web Service. L'occasion est donc donnée de préciser que « Service » est à prendre ici dans le sens logique du terme et non pas dans le sens physique.

Service : Niveau Logique

Composant : Niveau Physique

Illustration 18 : Différentiation Service / Composant



Le service, dans le cadre d'une architecture SOA, a souvent une connotation de « service métier ». Par contre, le service compris dans le sens physique, est appelé « composant » : un EJB, un javabeans, une servlet dans une architecture J2EE, un exécutable sur un legacy système, un composant ETL, EAI, ... L'ITIL^60(*), depuis 2004, liste les bonnes pratiques pour donner le moyen aux Directions Informatiques de jouer un rôle de fournisseur de services informatiques plutôt que celui de fournisseur de ressources techniques. Longtemps assimilé à un centre de coûts, l'informatique peut aussi se transformer en créateur de valeur par les services mis à disposition des activités.



S

ervice:

Moyen de fournir de la valeur à un client pour lui permettre de satisfaire ses objectifs métiers, sans porter toute la responsabilité des risques et des investissements additionnels^61(*). (Source : ITIL v3, Service Design, page 11).

S

E

R

V

I

C

E

Consommateur

Fournisseur

Illustration 19 : Service



Le service n'a de raison d'être que s'il est consommé. Le cycle de la qualité de service décrit par ITIL passe par un contrat liant le consommateur et le fournisseur du service. Ce contrat définit le contexte dans lequel le service peut être consommé. La notion de service encapsule donc celle du contrat d'utilisation de ce service.

Illustration 20 : Cycle de vie des services ITIL^62(*)

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

Ce contrat formalise la qualité de service (QoS^63(*)) attendue dans un contexte donné. Itil énonce le concept de « Service Level Agreement » (SLA) pour lequel sont précisés les niveaux de disponibilités du service, les performances attendues pour chaque opération, la facturation et, dans certains cas, les pénalités en cas de manquement à cet engagement SLA. Des mesures ont donc été définies pour qualifier ce SLA.

Par exemple, pour un centre d'appel, quatre mesures sont proposées :

q ABA : (Abandon Rate) : pourcentage d'appels interrompus pendant la mise en attente.

q ASA : (Average Speed to Answer) : temps moyen pour répondre à un appel.

q TSF : (Time Service Factor) : pourcentage de réponses dans une période.

q FCR : (First Call Resolution) : pourcentage d'appels pouvant être résolus en une seule fois.

L'opération



Méthode UML : Comportement d'un objet, c'est-à-dire l'ensemble des actions (appelées opérations) que l'objet est à même de réaliser.

Opération SOA : Activités constituant le périmètre fonctionnel que l'on souhaite exposer aux consommateurs.

Un service métiers peut être constitué d'une ou plusieurs opérations (traitements) mise(s) à disposition d'un contrat mais pas systématiquement toutes appelées par le contrat (en raison des pré et post conditions du SLA). La version touche le service et non pas l'opération. Ainsi une modification d'opération engendre la création d'une nouvelle version de service.

AnalyserStockProduit

AnalyserDelaisProduit

Contrat de Service

_

MettreajourStockreserve

Illustration 21 : Extrapolation de la représentation des cas d'utilisation pour illustrer les Opérations

Le Processus

Le diagramme d'activités UML permet de mettre en lumière les opérations autour desquelles le consommateur et le fournisseur s'inscrivent dans un jeu de rôles. Des « pré » et « post » conditions peuvent être définies par opération. Cette modélisation concerne deux types de processus : Les processus d'orchestration entre consommateur et fournisseur (« chorégraphie »), Les processus d'orchestration privés, internes au consommateur ou interne au fournisseur. L'orchestration peut s'illustrer de diverses manières (réseau de pétri, diagramme d'état, diagramme d'activité ...).



Illustration 22 : Phases d'orchestration vues au travers d'un diagramme d'activités réalisé sous Magicdraw

Le Composant



Le périmètre du composant est celui d'un programme qui s'exécute en exploitation, par exemple : un EJB, une servlet dans une infrastructure J2EE. La modélisation traduit par un composant, chacun des concepts logiques (moteur d'orchestration, catégorie, service).

Illustration 23 : Diagramme de Composants réalisé sous Magicdraw

1.4.6.2 Généralités

Caractéristiques du Service

Couplage faible

La communication directe entre deux services est interdite sauf si ces derniers appartiennent à la même « catégorie » ou « domaine », concept étudié plus loin. Cette fonction est à la charge du moteur d'orchestration. L'activation est réalisée à partir des messages XML.

S2

S1

S2

S3

S4

S1

Orchestration

XML

S3

XML

S4

XML

XML


Illustration 24 : Couplage fort

Illustration 25 : Couplage faible

Un des avantages du couplage faible est d'alléger le service en règles de pré-condition car elles sont prises en charge par le moteur d'orchestration. Cela permet d'augmenter la réutilisabilité du service car il devient plus « standard ». Les messages XML sont constitués :

q d'une entête (données d'infrastructure : adressage comme l'identité complète du consommateur et du fournisseur, sécurité, version, qualité et transport),

q d'un corps (données applicatives),

q d'attachement(s) (données binaires : images par exemple).

Asynchronie

Un service est asynchrone puisqu'il ne monopolise pas le consommateur pendant qu'il s'exécute. Ceci est intéressant pour diminuer les goulets d'étranglement et ainsi améliorer la performance et la robustesse.

Exposition un contrat d'utilisation

Deux volets (le premier volet est dit « abstrait » et le second « concret ») constituent ce contrat :

q un premier volet qui définit le nom du traitement et les paramètres du message d'entrée et de réponse, ainsi que les « pré » et « post » conditions,

q un second volet qui précise le format technique des messages et leur protocole de transport.

Pour illustrer ce concept de contrat, l'exemple des conditions de services^64(*) de la société de livraison UPS, décrit les éléments qui définissent à la fois l'authentification des intervenants, la garantie de livraison des paquets et l'information de bonne exécution dans un délai contractualisé (« Destinataire », « Expéditeur »,  « Trois tentatives de livraison », « Suivi et Preuve de la Livraison») . On y trouve tout autant les éléments constituant la qualité de service (« disponibilité des services », « Nombre de jours ouvrés de livraison », « Nombre de tentative de livraison ») que ceux énonçant les conditions du service (« Ramassage quotidien », « Ramassage sur appel », « Limites de dimensionnement et de poids», « conditions de facturation », « Restrictions de service »).

Erreur consommateur Erreur fournisseur

Pré-condition 1a

Post-condition 1

Pré-condition 1b

Post-condition 2

Requête

Pré-condition 2

Réponse

Illustration 26 : Pré et post conditions d'un service

Les erreurs sont intégrées à la structure des échanges entre le consommateur (le Client) et le fournisseur.

<?xml version='1.0' ?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soapenvelope">

<env:Header/>

<env:Body>

<env:Code>

<env:Value>env:Receiver</env:Value>

</env:Code>

<env:Reason>

<env:Text xml:lang="fr-FR">Le compte est débiteur</env:Text>

<env:Text xml:lang="en-GB"> The account is debtor </env:Text>

</env:Reason>

</env:Body>

</env:Envelope>

Illustration 27 : Erreur véhiculée dans un message SOAP

Les types d'erreurs SOAP <env:Value> sont :

q env:VersionMismatch,

q env:MustUnderstand,

q env:DataEncodingUnknown,

q env:Sender,

q env:Receiver.



Les pré et post conditions peuvent être exprimées en Object Constraint Language^65(*) (OCL) Uml et permettent de définir en quelque sorte le banc de test du service.

Illustration 28 : Pré et post conditions d'un service

Dans le cas d'une opération « débiter », la somme doit être positive pour que le service puisse se déclencher. Puis, le nouveau solde doit être calculé (solde avant l'invocation du service soustraite de la somme débitée). Ces contraintes permettent de traduire des réalités pas toujours simples à modéliser (Exemple : il est tellement plus facile dans un diagramme de classes d'utiliser OCL pour préciser qu'un candidat, au moment de l'examen du permis de conduire, doit avoir sa majorité). Ces contraintes sont ensuite traduites dans le code Java ou en XML.



Illustration 29 : Traduction XML des contraintes via MagicDraw

Modèle d'architecture SOA 66(*)

Le pattern d'architecture SOA est basé sur la constitution de groupes de classes appelés «  catégories » (exemple ci dessous : « Gestion commerciale »). Les traitements sont traduits en services et sont rattachés aux catégories qui disposent d'une interface (port). Comme précédemment, les services ne peuvent interagir entre eux qu'à condition qu'ils se situent dans la même catégorie. Si cela n'est pas le cas, il faut alors passer par un moteur d'orchestration qui assure un découplage.

_

Message

Message

Message

Service Exposé



Illustration 30 : Données d'échange et Format pivot XML (Master Data Managment)

Illustration de la « réuitisabilité »

Le trigramme SOA apparaît en 1996 dans une note de recherche du Gartner Group :

« Service-oriented architecture (SOA) is a client/server software design approach in which an

application consists of software services and software service consumers (also known as clients

or service requesters). SOA differs from the more general client/server model in its definitive

emphasis on loose coupling between software components, and in its use of separately standing

interfaces ».

Gartner Group, 1996.

(Sources: SSA Research Note SPA-401-068, 12 Avril 1996, "'Service Oriented' Architectures, Part 1"

SSA Research Note SPA-401-069, 12 Avril 1996, "'Service Oriented' Architectures, Part 2")

Dans cette note, le groupe Gartner met l'accent sur le découplage et la réutilisabilité des services à l'image de ce qui existe au niveau des ESB.

Lorsque la notion de service est évoquée, il faut penser au service métier (par exemple : « Calculer un taux de marge nette ») mais il existe un autre type de services dits « d'infrastructure » ou « techniques » permettant aux services métiers de fonctionner au sein du SI (« Création de compte utilisateur » par exemple, ou « transfert de fichier » ...). Ils reflètent un besoin transverse et peuvent ainsi répondre à la même problématique de plusieurs métiers.

Les services sont classés en granularité fine (règles métier, fonctions, comme par exemple : le « calcul de marge », la « recherche d'une adresse ») ou grosse (la « gestion des comptes »). C'est sur cette base que se construit la réutilisation des services, car si les services de granularité fine ne peuvent pas se suffire à eux même, ils permettent quant à eux de définir et d'utiliser des règles de gestion stables pour l'ensemble des métiers de l'entreprise, quelque soit la manière dont ils ont été utilisés (portail, batch etc....). L'exemple si dessous tente de montrer simplement combien le concept de service apporte de la lisibilité au code mais aussi des possibilités de réutilisation.

En annexe, est illustrée la flexibilité apportée par le concept de service.

Typologie des services

Ces typologies sont au nombre de trois et proposent un niveau d'abstraction de plus en plus élevé :

q Interne à une catégorie : implémentation physique des données (domaine privé),

q Rattaché à la catégorie : proche du modèle conceptuel de données, appartient au domaine privé (ce niveau d'abstraction est atteint par les EAI),

q Métier : c'est ce niveau de service qui est exposé au consommateur. Le modèle d'échange Pivot XML se situe sur cette dernière couche, dans un domaine publique (niveau d'abstraction atteint par les ESB).

Consommateurs

Minerais

Famille

Mouvements

Solde

Catégorie Comptes Tiers

Catégorie Produits

Domaine Privé

Métiers

Domaine Publique

S2

S3

Exposition des services

S1

Logique

Illustration 31 : Répartition entre domaine privé et domaine public

Caractéristiques du Composant

Typé N-Tiers

Le traitement ne concerne qu'une couche du modèle N-Tiers. Cette architecture reste articulée autour des 3 niveaux : présentation (IHM), applicatif  (Métier) et données (Persistance). Mais à la différence d'une architecture 3 tiers, le N tiers distribue l'application sur des services de différentes natures : métiers, persistance, session. Ceci rend l'architecture plus souple et donc évolutive. Seul le composant de type façade rend possible la transversalité au niveau des couches N-Tiers. Quelque soit la distribution du composant sur le réseau, son code ne doit pas en être « impacté ».

Exposition une interface de services

Expose une interface localisée dans le périmètre du composant.

Caractéristiques : Service Vs Composant

	Service	Composant
Couplage	OUI	-
Contrat	OUI	OUI
Modèle d'architecture	OUI	OUI
Entité Physique	NON	OUI
N-Tiers	NON	OUI
Distribuable	FACULTATIF	FACULTATIF

Tableau 1 : Services Vs Composants

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

Depuis les années 90, que d'eau passée sous les ponts. Les mini révolutions informatiques se sont succédées : dans le domaine du langage de développement (les L4G devaient redonner la main aux utilisateurs), ou de la modélisation (UML et CORBA étaient sensés organiser simplement les objets), ou encore de l'échange entre applications (il fallait faire disparaître le plat de spaghettis, et pour cela les ETL furent la première marche du long escalier menant à l'EAI, juste au dessous du palier de l'ESB).

Ces « mini révolutions » n'ont su que répondre à la problématique d'un moment. Les architectures matérielles se sont succédées, les applications et les machines sont devenues de plus en plus nombreuses et hétérogènes, amenant nos équipes à plus de spécialisation. C'est ainsi que l'image de notre premier mainframe rassembleur a jauni au fil de ces années. Alors nous avons cherché à réutiliser plutôt que de continuer à ajouter de la redondance au SI. Nous avions presque oublié le nom donné à notre premier mainframe que de nouveaux concepts renvoient certains d'entre nous aux premières années de leur carrière.

Avec l'architecture SOA, l'abstraction physique et d'interopérabilité des applications et des outils supportés, est venue accompagner, en quelque sorte, la démarche de virtualisation déjà mise en place au niveau des machines.

Le type d'architecture SOA est sensé rendre de l'agilité au SI. La différence entre ESB et SOA ne se situe donc pas véritablement sur le terrain de la technique (sauf peut être en ce qui concerne le sujet de la sécurité). Ce qui différencie ESB de SOA touche essentiellement aux aspects organisationnels et fonctionnels.

Ainsi l'architecture SOA rassemble et rapproche. Elle rassemble par des normes et des standards qui permettent aux applications de garder leur identité propre tout en les faisant communiquer avec le SI tout entier, mais elle rapproche aussi les équipes qui s'intègrent davantage dans une démarche de projet métier, plus détachées des spécifications techniques.

SOA est aussi annoncée comme une nécessité vis à vis des métiers, parfois changeant (concurrence, contraintes légales ...) et toujours exigeants (coûts, délais, qualité ...). De même le SI est perçu parfois comme rigide et difficilement accessible (de part la méconnaissance de son contenu et de la logique applicative pas toujours compréhensible par les métiers). La réponse des DSI repose aujourd'hui sur 2 axes : la réutilisabilité et l'interopérabilité (dont le liant reste la standardisation).

Dans la première partie d'étude de ce premier chapitre, l'accent a été davantage mis sur la réutilisation des services que sur l'interopérabilité du SI. C'est pourquoi il serait maintenant intéressant d'aborder l'agilité sous l'angle de la méthodologie et des gains attendus d'une telle mise en oeuvre. Ou autrement dit : En quoi le `A' de la SOA peut faire que ce nouveau concept ne constitue pas qu'une mini révolution de plus.



A

rchitecture :

Structure d'éléments définissant un système complexe. Dans le langage courant, l'architecture est "l'art de concevoir et de construire un bâtiment selon des règles techniques». (Source : Le Petit Larousse 2003)

Architecture selon OSI (Open System Interconnection), est décrite au 7ème chapitre de ISO 7498-1 :

q «physique» chargée de la transmission de signaux entre les interlocuteurs.

q «liaison de données» gère les échanges entre 2 machines adjacentes.

q «réseau» gère les communications (routage des paquets).

q «transport» gère les échanges de bout en bout entre les processus

q «session» gère la synchronisation des transactions.

q «présentation» est chargée du codage des données applicatives

(conversion, reformatage, cryptage, compression).

q «application» est le point d'accès pour l'utilisateur aux services réseaux.

(Source : http://www.iso.org/iso/home.htm)

L'objectif de ce chapitre est de s'attaquer à la question incontournable : Qu'est ce que cette « nouveauté » va nous faire gagner ? Ceci est encore plus d'actualité, dans les temps de crise que nous traversons.

_

1.5 Attentes d'une architecture SOA



I

nteropérabilité^67(*) :

Capacité qu'ont les systèmes des technologies de l'information et de la communication (TIC), ainsi que les processus de fonctionnement qu'ils permettent, d'échanger des données et de permettre le partage des informations et des connaissances. 

Au sens de la décision 2004/387/CE du Parlement européen et du Conseil du 21 avril 2004.

(Source : http://www.marche-public.fr/Terminologie)

Capacité d'établir avec succès une communication de bout en bout entre utilisateurs finaux au travers d'un environnement comprenant divers domaines, réseaux, aménagements, équipements, etc. provenant de différents constructeurs et/ou fournisseurs. Dans ce contexte, la communication est supposée établie entre utilisateurs finaux ou entre un utilisateur final et un fournisseur de service.

Norme STF228 de l'ETSI - Institut européen des normes de communications.

(Source : http://www.marche-public.fr/Terminologie)

La démarche SOA au niveau de l'application n'a pas de sens : les applications sont produites depuis des années par des équipes familiarisées avec leurs outils et leurs procédures. Et le tout semble fonctionner. C'est pourquoi la démarche SOA s'inscrit davantage au niveau macroscopique : celui du SI.

1.5.1 Les bénéficiaires

1.5.1.1 Les utilisateurs

Les premiers bénéficiaires d'une architecture « réactive » conçue autour de services réutilisables et interopérables, sont les utilisateurs et en premier lieu, les métiers pour lesquels nous concevons et mettons en place des solutions informatiques. Ces dernières doivent permettre, si ce n'est pas de gagner du temps ou d'économiser des ressources, d'être d'une façon ou d'une autre, génératrices de valeurs. De même, nos partenaires ont besoin d'interagir avec notre SI et de bénéficier de processus maîtrisés. Chiffrer le gain engendré par une réactivité accrue n'est pas chose simple, mais il est compréhensible d'intégrer le fait qu'écrire un format d'échange XML commun aux applications amenées à communiquer ensemble, est un début de source de valeur.

1.5.1.2 Les Services support des SI

Les services support tirent aussi bénéfice de ce type d'architecture. La gestion des comptes par exemple est un service transverse au SI. Il et très consommateur en énergie puisque constamment mis à jour suite à l'arrivée de nouveaux salariés ayant accès au SI ou au départ d'autres utilisateurs quittant l'entreprise. A grande échelle, les rotations de personnel peuvent être consommatrices de ressource et justifier la mise en place d'un service adapté.

1.5.1.3 Les Etudes Informatiques

Les Etudes Informatiques se trouvent aidées dans l'intégration de nouveaux projets par l'interopérabilité et gagnent en productivité grâce à la réutilisation des services (impression, échange, composant appelé à la fois par un ou plusieurs batchs et/ou un programme transactionnel) et qui, par le fait, peuvent être recettés^68(*) plus aisément. La conduite de projet peut s'en trouver bouleversée (cf. chapitre « La Conduite de Projet »).

De plus, l'intégration classique en mode batch a montré ses limites :

q Orientation davantage tournée vers les données que vers les processus,

q Logique point à point,

q Fortes exigences avec l'existant,

q Difficulté à toucher une brique sans perturber l'ensemble de l'édifice,

q ... Formation du fameux « plat de spaghetti ».

Avec une zone d'échanges, l'ambition est de désigner un îlotier du système d'information dont le rôle est de centraliser l'ensemble des règles d'intégration des applications et de manipuler des processus et non des échanges techniques de données point à point. Ce nouveau mode d'intégration est complet dans le sens où il intègre le design fin du processus métier (routage, transformation des données).

1.5.1.4 L'entreprise

La mise en place de standards offre à l'entreprise toute entière l'espoir d'une pérennisation accrue des solutions implémentées, mais aussi une capitalisation des connaissances métiers et du savoir faire. De plus, la mise en place de processus métier décloisonne les services de l'entreprise et démultiplie les vues dynamiques de pilotage offertes aux décideurs. L'agilité, objectif clef de la SOA, doit permettre à l'entreprise qui fait face à d'intensifs changements, de maintenir sa compétitivité et de pouvoir répondre à des problématiques transverses.

1.5.2 La mesure des gains



Une enquête de 2005 concernant l'architecture SOA, de l'AMR Research^69(*), liste les objectifs opérationnels pour les départements informatiques, selon un panel d'entreprise ayant mis en place une architecture SOA ou l'ayant planifiée.

Illustration 32 : Gains pour le département Informatique

(Source : ftp://ftp.software.ibm.com/software/soa/pdf/amr_files.pdf)

Cette perspective de gains se résume donc à un constat/espoir à hauteur de :

q 48 % pour une rapidité de reconfiguration et la flexibilité des processus d'affaire,

q 28 % pour une réduction des frais opérationnels de l'informatique,

q 15 % pour un niveau de service sécurisés et fiables,

q 5 %  pour une implémentation possible « à la volée » des produits,

q 3 %  pour un système prêt à l'emploi de multiples fournisseurs technologiques.

Malgré tout, la mesure de ces gains n'est pas chose facile et peut difficilement se justifier à court terme. Les premiers éléments mesurables mis en avant sont principalement la rapidité de développement, les aides au debbuging, la documentation complète et automatisée, la maniabilité des flux, leur maintenance et supervision centralisée. Plus la montée en charge s'opère et plus ces gains peuvent être significatifs.

« L'ingénierie des processus métiers rassemble les disciplines économiques, sociales et techniques de mise en oeuvre de solutions appropriées respectant la stratégie de l'entreprise. »

Patrice Briol, 2008.

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

Cette mesure des gains est fonction du contexte de l'entreprise qui met en oeuvre un tel chantier et ne repose pas uniquement sur une approche essentiellement technique. D'autres facteurs peuvent être mis en avant, tels que des gains de productivité grâce à la diminution des ressaisies, à la qualité des données et au référentiel unique. Dans l'argumentaire des éditeurs SOA, souvent l'agilité de l'entreprise toute entière est soulignée, car dans cet idéal, ses flux sont parfaitement maîtrisés (gestion d'alertes) et permettent à l'organisation de faire les bons choix au bon moment.

La sécurité, dans un contexte où les échanges informatiques entre partenaires se généralisent, fait elle aussi partie de l'argumentaire SOA. Les enjeux sont larges : architecturaux, financiers et organisationnels. Contrairement aux architectures précédentes, SOA fait figure d'un projet transversal à l'entreprise, reléguant la dimension technique au second plan, et ce, même si une véritable politique de sécurité se met en place progressivement (axe de sensibilisation fort au niveau de nos dirigeants).

L'objectif d'une architecture SOA est de référencer et de faire appliquer les bonnes pratiques en matière d'urbanisation et d'intégration du SI. Elle n'est donc ni une technologie, ni une méthode, encore moins un outil du marché.

Elle peut ainsi se ramener à un mode de penser et une façon de concevoir le SI. La problématique organisationnelle et humaine est bien souvent plus délicate à gérer que la problématique technique. La mesure du gain (financier ou qualitatif) ne s'en trouve pas facilitée car SOA n'est qu'un type d'architecture. Encore faut-il en préciser l'approche conceptuelle et la méthodologie d'accompagnement.

Avant même de parler d'outil, la question est de savoir comment aborder la SOA dans l'entreprise. Pour cela, nous illustrerons par des exemples, quelques projets SOA réussis.

1.6 Quelle approche mettre en place ?

_

Couramment, les SI sont constitués de briques applicatives hétérogènes tant au niveau fonctionnel qu'au niveau technique, donnant ainsi à l'interopérabilité sa raison d'être. Deux démarches opposées sont proposées :

q Légaliste ou « Top-Down » (du haut vers le bas), c'est à dire l'analyse globale de l'urbanisation du SI sur la base de la décomposition de ce dernier en blocs fonctionnels de plus en plus fins (« allégorie de la cité », « POS^70(*) », « PLU^71(*)» etc ...),

q Organique ou « Bottom-Up » (du bas vers le haut), c'est à dire une intégration en partant des blocs applicatifs indépendants et hétérogènes appelés à communiquer entre eux et par là même à fournir des services liés aux projets. Dans les faits, un Projet est choisi parmi le portefeuille de projets et sert de modèle aux suivants. Les équipes se fédèrent progressivement autour de la nouvelle approche, puis les questions d'urbanisation et de gouvernance sont abordées lors de la rencontre des premiers problèmes dits « structurants ».

La première approche est intellectuellement séduisante mais elle soulève quelques pièges :

q Une cartographie détaillée finement pour un SI complexe et dense peut s'avérer coûteuse en terme de maintenance, au regard du gain escompté. Autrement dit, il vaut mieux rester sur une forte granularité que sur une fine, impossible à maintenir. Pour ce faire, un outil est incontournable. Actuellement sur le marché, peu de solutions permettent de véritablement construire cette cartographie (Trois solutions se détachent : ARIS, MEGA et CASEWISE). Ces outils sont appelés des Enterprise Architecture Modeling^72(*) (EAM). Ils permettent aux architectes de modéliser complètement le fonctionnement de l'entreprise : des processus métiers aux composants informatiques en passant par l'organisation et l'architecture de l'infrastructure,

q Le système d'information est constitué de blocs applicatifs, qui peuvent beaucoup évoluer contrairement à d'autres beaucoup plus stables,

q Les applicatifs sont désormais très nombreux et ont pu nécessiter leur prise en charge par des équipes différentes et implantées pas forcément sur les mêmes lieux géographiques, la cartographie ne s'en trouve pas simplifiée,

q Cette approche convient particulièrement dans le cas de rapprochement d'entreprises ou de services informatiques (cf. chapitre suivant).

La seconde semble plus pragmatique et semble être préférée lorsque la culture « SOA » n'est pas encore une réalité dans les entreprises concernées. Cette démarche n'est pas vécue comme une révolution car elle consiste à intégrer l'existant par des petites touches ça et là sans bascule de type «One Shot».

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

1.6.1.1 AXA France Service (AFS)

1990 : fusion AXA - UAP avec pour objectif un environnement unique qui a nécessité une cartographie.

2001 - 2004 : Volonté de Réduction des frais généraux qui a amené la création d'un département d' « Architecture applicative » (mise en place de normes de développement et de conception, choix d'une architecture technique) et fonctionnelle (« cible d'urbanisme »).

Depuis 2004 : Ce département continue à exister et à apporter une assistance fonctionnelle et technique aux nouveaux projets dans le respect des règles et de la cible définie. Il incite les métiers à prendre conscience progressivement de cet urbanisme.

Les apports de cette démarche sont d'ordre qualitatif :

q Le SI est intelligible, pilotable, et permet de diffuser les « bonnes pratiques » à l'ensemble des métiers en créant ainsi une « intelligence collective »,

q Des ponts de communication sont crées entre les différents acteurs du SI,

q Le rôle de chacun est reconnu,

q La mise en mouvement est mesurable,

q L'alignement du SI se fait sur la stratégie de l'entreprise,

q La rationalisation est une réalité.

1.6.1.2 AIR France - KLM

2003 : fusion AIR France - KLM avec pour objectif de rapprocher les parcs applicatifs en 5 ans (70% des applications devant alors être communes). Le contexte initial d'Air France est marqué d'une forte empreinte de développement spécifique alors que, chez KLM, les 500 applications sont principalement issues du monde progiciel. Les différences ne s'arrêtent pas là entre ces deux mastodontes : les projets Air France sont pilotés par un binôme de collaboration MOA/MOE alors que les projets KLM sont à la charge d'un chef de projet, maître d'oeuvre global et respectant l'équilibre : coût - délais - fonctionnalités. Le volume d'économie de cet objectif est chiffré à 73 millions d'euro (chiffre à comparer aux 2 budgets informatiques fusionnés des compagnies  de 690 millions d'euro), soit plus de 10% du budget global.

AXA et AIR France KLM ont tous deux mis en oeuvre une architecture SOA :

q AXA : avec SOA Fastrack, solution de réutilisation des applications sous forme de services.

q Air France KLM : mise en place d'une approche SOA «sous forme de services métiers normalisés et réutilisables » selon J-B Ceccaldi^74(*).

L'approche « par le haut », c'est à dire par l'urbanisation, présuppose un degré de maturation effectif a été atteint en terme de référentiels par l'entreprise qui va la mettre en application. C'est souvent le chemin qu'empruntent les grosses entités structurées. Car pour que l'entreprise adhère à une démarche, quelle qu'elle soit, il faut qu'elle puisse en retirer un bénéfice mesurable et être certaine d'aboutir à un résultat, tout en conservant une cohérence structurée, épurée des réplications de données et de tout désordre latent. Le soutien de la Direction Générale doit être réel sans quoi ce type de projet n'abouti pas.

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

Lors d'un forum organisé en octobre 2006 à Paris, Microsoft a présenté sa vision "pragmatique" de la SOA consistant en une approche « Bottom-up ». Sur les cinq dernières années, les réussites seraient obtenues par des entreprises ayant avancé à « petits pas » vers la SOA.

L'approche « par le bas », c'est à dire par le choix d'un projet dit « pilote », semble adapté aux Entreprises moins structurées. Mais les problèmes liés au défaut de gouvernance et d'urbanisme rationnel peuvent apparaître au bout d'un certain temps et faire capoter le projet en démultipliant sa complexité, sa durée et donc les coûts associés.

1.6.2.1 Magasins Harrods

Par ailleurs, le Gartner Group a annoncé la guerre des processus entre ces deux camps (Bottom-Up et Top-Down) dans une note^75(*) de 2006. Mais « Le mieux étant l'ennemi du bien », une démarche empruntant la voie du Milieu (« Middleware Work  approach») pourrait peut être envisagée

C'est ainsi qu'une autre approche (appelée « Meet in the Middle ») a été prise par les Magasins Harrods. La situation de départ, c'est à dire avant l'architecture SOA mise en place, n'était pas des plus favorables (cf. parution^76(*) en 2006 par le Directeur Informatique d'Harrods) : duplication de données, données incompatibles, informations non partagées, pas d'historique, ni d'analyse pour les managers, impossibilité de reconnaître un client sur les différents points de vente... Aussi l'objectif de « réorchestration du système » était ambitieux. Les axes de travail ont été de créer un Repository unique et propre à tous les clients, d'intégrer les systèmes d'information autour d'une architecture « scalable », puis d'améliorer l'efficacité marketing par des analyses croisées, et de générer un Reporting. Cette approche par le milieu, c'est à dire par les données dans un axe transversal au SI, peut être une approche intéressante en matière de SOA.

1.6.3 La démarche MDA

La démarche appelée Model Driven Architecture^77(*) (MDA) permet de découpler la modélisation de l'implémentation technique. Basée sur UML, cette approche définit plusieurs étapes dont les principales sont : Le Platform Independent Model (PIM) et le Platform Specific Model (PSM). L'exemple qui illustre cette méthode est souvent celui de la modélisation UML, réalisée sous Rose^78(*) par exemple qui, une fois convertie via des templates de génération UML vers un code source, aboutit à un squelette de code. C'est souvent de cette manière que les plates-formes de développement intégré sont articulées (Netbeans pas exemple) ainsi que certains modeleurs (Magicdraw, Together etc...). L'objectif de cette démarche est de stopper l'empilement technologique récurent. Pour cela le point de départ est une représentation UML logique du métier observé (CIM). L'OMG a défini 4 modèles standards : le CIM^79(*), le PIM, Le PDM^80(*) et le PSM.

Projection technologique

Génération de Code

PIM

PSM

CIM

Code

......

....

PDM

Retro-enginerie

Retro-enginerie

Raffinement

Raffinement

Illustration 33 : Etapes de la démarche MDA

CIM : Vue Métier par excellence, elle rassemble la MOA et la MOE atour d'un diagramme de processus Métiers modélisé sous les spécifications BPMN^81(*).

PIM : Cette étape place le concepteur à un haut niveau d'abstraction, de façon indépendante des plates-formes techniques (EJB, CORBA, DotNet, XML ...).Elle s'appuie sur la construction de modèles tels que le diagramme de classe UML 2 .0 et représente la logique du métier.

PSM : Cette étape est fortement liée à la plate-forme technique. On y trouve les modèles techniques. Suite à quoi le code exécutable peut être généré.

La démarche MDA est souvent associée au « double Y ». Encore jeune, elle fait l'objet de nombreux projets, tels que le projet JOnES^82(*) et de thèses de J. Touzi^83(*), de V.Rajsiri^84(*) et celle en cours de S. Truptil^85(*).

Thèse S. Truptil (2007-2010)

Thèse J. Touzi (2004-2007)

Thèse V. Rajsiri (2005-2008)

Projet JOnES (2006-2008)

Branche Technique

Branche Logique

Branche Métiers

CIM

Modèle BPMN

PI

M

Modèle UML 2.0 stéréotypés SOA

PS

M

Modèle Technique : WSDL

Code

Illustration 34 : Articulation MDA

1.6.3.1 Les Forces

Une plate-forme interopérable

Les sociétés qui entrent dans ce type de modélisation peuvent plus facilement combiner des systèmes hétérogènes. Cette affirmation doit néanmoins être nuancée du fait que les plates-formes intégrées à ce type de transformation sont, sommes toutes, limitées. Cependant, on peut aisément imaginer que les éditeurs de logiciel mettant en oeuvre cette approche puissent tirer profit de cette souplesse, qui leur permet d'étoffer leur offre produit.

Une aide au développement

Même s'il ne s'agit que d'un squelette, il apparaît néanmoins que cette aide est réelle et donne encore plus de sens à la conception et à la collaboration entre concepteurs et développeurs.

1.6.3.2 Les Faiblesses

Une certaine complexité

Le préalable à la mise en place d'une telle méthode est que les analystes et les développeurs aient tous, de réelles compétences en termes de modélisation UML, ce qui est rarement le cas dans la réalité. Ce problème est d'autant plus vrai lorsque la problématique est posée au niveau de petites structures.

1.6.3.3 Illustration simple

A partir d'un diagramme de classe, un des objectifs est de générer le code d'un XML Schéma.

_

Transformation UML vers XML





(...)

<complexType name="Homme">

<complexContent>

<extension base="Humain">

<all/>

</extension>

</complexContent>

</complexType>

<complexType name="Humain">

<all>

<element name="Nom"/>

<element name="Prénom"/>

</all>

</complexType>

<complexType name="Femme">

<complexContent>

<extension base="Humain">

<all>

<element name="Nom_jeune_fille"/>

</all>

</extension>

</complexContent>

</complexType>

</schema>

Illustration 35 : Réalisation Model Driven Architecture (MDA)

Cette réalisation a été obtenue à partir de Magicdraw version 16 Enterprise et de XmlSpy version 4.3. La transformation obéit aux règles de mappage^86(*) par défaut à l'outil MagicDraw. Il aurait été possible de les modifier avant de lancer la transformation. Il est tout aussi possible de procéder à l'opération inverse (dit « reverse engineering » ou retro-enginerie) et de générer un modèle Uml à partir de code Java, C, XML etc.

Ce mémoire montrera que la démarche MDA va beaucoup plus loin en terme de modèles et donc de génération de code.

1.6.4 Les Gardes Fous

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

UML 2.x, BPMN

Ces deux langages sont dédiés à la conception des processus métiers.

UML est la voix naturelle de modélisation pour la SOA. Pour preuve, SOAml^87(*) en cours de spécification par l'OMG, s'appuie sur UML 2 et est annoncée comme une spécification UPMS^88(*) (UML Profile and Meta model for Service). Cependant, le contexte spécifique du service Terrena et notamment sa culture largement orientée vers la modélisation Merise n'est pas pour autant antinomique avec la conception des processus métiers. Autrement dit le choix fait d'UML n'est pas une obligation. Dans le cas d'un choix merisien, il faudrait substituer le diagramme d'activité UML par le Modèle de Traitement, et le modèle de classe UML par le Modèle Conceptuel de données Merise. UML 2.x est souvent préféré pour des raisons de facilité de formalisme notamment au niveau des diagrammes de composants et des diagrammes de séquences, mais aussi (objet de ce chapitre) pour des raisons de processus de génération de code WSDL^89(*) et BPEL.

Tout d'abord UML, dans ses versions 1.X (1.1, 1.2, 1.3, 1.4, 1.5), disposait d'un modèle d'activité qui présentait certaines fonctionnalités pour la modélisation des processus. Il offrait à la fois un méta modèle, une notation et un format d'échange pour les modèles avec XMI^90(*) 1.x. La version 2 d'UML a apporté de nouveaux concepts et quelques modifications mais le modèle d'activité d'UML 2.0 ne peut pas fournir, tel quel, un support d'analyse et de communication pour les processus « métier ». L'OMG^91(*) a donc lancé une initiative complémentaire appelée le BPDM^92(*). Un autre outil de notation graphique BPMN soutenu par le BPMI^93(*), autre organisme très actif en matière de standards de modélisation de processus métier, est utilisé pour représenter les processus métiers en séparant les informations métier des informations techniques. Il fournit une correspondance vers des langages d'exécution. Ainsi une modélisation basée sur BPMN peut ensuite être traduite en BPML ou en BPEL. L'OMG et BPMI se sont considérablement rapprochés depuis 2005 même si chacun d'entre eux garde son indépendance.

XPDL94(*), BPML95(*), BPEL96(*)



Ces langages de modélisation de processus métier sont dédiés exclusivement à l'exécution de processus. XML est la syntaxe habituellement retenue.

Illustration 36 : BPEL : Demande de Prêt réalisé avec Netbeans 6.5



Illustration 37 : Traduction XML du BPEL (extrait des Acteurs)

Synthèse des standards

	Standard	Organisme	Méta modèle	Notation	Échange de modèle	Remarques
1997	UML 1.1	OMG	OUI	OUI	OUI	Langage d'analyse de processus automatisé dans le sens où le modèle d'activités présente certaines fonctionnalités pour la modélisation des processus. Il inclut le méta modèle, la notation et le format d'échange XMI. Mais des limites subsistent
2001	BPML	BPMI	OUI	NON	OUI	Langage d'exécution.
2002	XPDL 1.0	WFMC	OUI	NON	OUI	Langage d'exécution.
2003
2004	BPMN 1.0	BPMI	NON	OUI	NON	Analyse des processus automatisés. Apparition des notions de flux et de messages
Juin 2005 - Fusion de l'OMG et de BPMI
Nov 2004	UML 2.0	OMG	OUI	OUI	OUI	Analyse des processus automatisés
Oct 2005	XPDL 2.0	WFMC	OUI	NON	OUI	Langage d'exécution.
2007	BPEL 2.0	OASIS				Langage d'exécution devenu le standard, soutenu aussi par le BPMI. Nombreuses contributions venant du BPML.
2007	BPMN 2.0	OMG	OUI	OUI	OUI	Analyse des processus automatisés et des chaînes de valeur. En cours de spécifications.
2008	BPDM	OMG	OUI	OUI	OUI	Analyse des processus automatisés, de l'organisation et des chaînes de valeur. Elle inclut la notation BPMN tout en s'appuyant sur les modèles d'activité d'UML 2.0.

Tableau 2 : Richesse des standards en matière de processus Métiers

Une des difficultés est de choisir un standard. C'est aussi une des raisons pour lesquelles l'interopérabilité est un facteur de grande importance.

Interopérabilité97(*) des standards actuels



Il est tout autant possible de générer du code BPEL à partir de BPMN qu'à partir d'UML 2.0. Dans le premier des cas, un des outils utilisés pour ce type d'opération est Intalio BPMS, dans l'autre, Rational Rose (Rational Architect aujourd'hui). Tous deux utilisent XML.

Mapping^98(*) et transformation Sérialisation

Illustration 38 : D'UML vers BPEL et WSDL



Illustration 39 : Mise en place d'un processus

En annexe, est illustrée l'interopérabilité (Tutorial IBM) à partir d'un exemple.

1.6.4.2 Méthodologie agile de conduite de projet

« Deux tendances majeures dans le monde de l'IT en 2007 : l'une, (technique), concerne la mise en oeuvre des architectures orientées service, l'autre, d'ordre (méthodologique), introduisant les principes du lean management à la gestion des centres informatiques »^99(*)

MacKinsey ^100(*)

(Source: http://www.mckinseyquarterly.com/article_page.aspx?ar=1892&L2=13&L3=13&srid=17&gp=0)

Les niveaux d'incertitude des différents secteurs de l'économie mais aussi les incertitudes techniques (bon nombre des fusions-acquisitions concernent également le secteur des éditeurs informatiques), ont justifié les méthodes dites « agiles » afin de pouvoir répondre aux besoins accrus de flexibilité. L'agilité semblerait être le trait d'union entre SOA et la méthodologie. Certains échecs SOA mettent en évidence que l'approche purement orientée urbanisation, sans remettre en cause la conduite de projet ne permet pas de dégager suffisamment de valeur. Trois réussites en matière de SOA: Google, Ebay et Amazone ont toutes trois opté pour une méthodologie agile.

Le cabinet d'études Forrester Research annonce la corrélation entre agilité méthodologique et architecturale depuis fevrier 2006^101(*) comme étant les deux faces cachées d'une même pièce; d'un côté : la livraison efficace d'outils par une équipe projet réactive, maîtrisant son produit; et de l'autre : la réutilisabilité du code lui même. Forrester ajoute dans la même parution que les courbes d'adoption de ces deux thématiques se confondent (aux Etats Unis tout au moins).

Parmi ces méthodes agiles, la méthode « Lean » qui, une fois traduite littéralement, signifie « sans gras », s'intéresse à la productivité et à la qualité. D'autres méthodes agiles fleurissent dans l'esprit du Lean (eXtreme Programming, SCRUM ...). Pour le Lean, qui est issu du monde de l'entreprise (Toyota), la performance est le résultat de la diminution du gaspillage (dans le sens générique) et de l'amélioration continuelle des processus. D'après le même cabinet MacKinsey, l'application des principes du Lean apporterait une productivité de 40% de certains processus.

La méthodologie Lean

q Eliminer les 7 sources de gaspillage : travail non terminé, processus inutiles, excès de fonctionnalités, changement de tâche, attente et retard, transmission d'information, défauts,

q Favoriser l'apprentissage : connaissance pour soi et pour l'équipe, mise en place de cycles itératifs, apprentissage de ses propres erreurs, démarche transparente privée du bouc émissaire,

q Reporter la décision : ne pas discuter ou toute autre perte de temps sur des éléments dont on n'a pas encore la maîtrise, attendre le dernier moment raisonnable pour décider afin de garder un maximum de liberté d'action,

q Livrer vite : définir des itérations de livraisons (par exemple tous les mois). Chaque cycle fait l'objet d'un feedback qui permet de consolider les fonctionnalités proposées aux utilisateurs finaux et de mettre de côté des fonctionnalités jugées superflues,

q Responsabiliser l'équipe : les cycles décrits ci-dessus diluent le stress des équipes dans le temps et pas uniquement en fin de projet, et offrent un challenge au fil de l'eau,

q Construire la qualité : le feedback continuel (équipe de développement, utilisateurs) et le développement itératif, construisent de façon continuelle la qualité,

q Optimiser le système dans son ensemble : ce principe est basé sur la valeur : temps de cycle, ROI et satisfaction client.

En 2003, Mary & Tom Poppendieck définissaient le « Lean Software Developement »[POP-LEA] sur la base du Lean. Mais avant d'aborder cette méthode sous l'angle de la valeur, il peut être intéressant de faire un focus sur la réalité des conduites de projets informatiques.

Projet



P

rojet :

Ensemble d'activités qui sont prises en charge, dans un délai donné et dans les limites de ressources imparties, par des personnes qui y sont affectées dans le but d'atteindre des objectifs définis.

Norme AFNOR/Z 67-100-1.

(Source : http://www.afnor.org/portail.asp)

Une réalité ?

50 % des fonctionnalités développées ne sont pas utilisées. 

Jim Johnson, président du cabinet d'études Standish Group^102(*) énonce^103(*) que sur 100 fonctionnalités développées, 7 sont constamment utilisées, 13 le sont souvent, 16 sont appelées de temps en temps, et que par contre, 19 sont rarement utilisées et 45 ne le seront jamais. Si la réussite d'un projet est fonction du délai, du coût, et de la satisfaction client, qu'en est-il alors de la réussite de nos projets informatiques ?

Une part importante des fonctionnalités finales ne correspondent pas à celles du cahier des charges de départ

Selon cette même étude, l'écart serait à hauteur de 42% pour les grosses sociétés et 75% pour les PME.

Un taux de réussite de projet faible

La 10^ème édition du Chaos du Standish Group, publiée en 2004^104(*), rafraîchit les chiffres communiqués dix ans plutôt, en 1994^105(*) (« 31 % des projets informatiques sont arrêtés en cours de route, 52 % n'aboutissent qu'au prix d'un important dépassement des délais et du budget et en offrant moins de fonctionnalités qu'il n'en était demandé ; seuls 16 % des projets peuvent être considérés comme des succès ».). En 2004, 29 % peuvent être considérés comme un succès, 18% sont arrêtés en cours de route et 53% aboutissent au prix d'un dépassement budgétaire important). Le dépassement budgétaire est chiffré en 2004 à 56% et le pourcentage avancé pour le dépassement de délais est de 84%.



Illustration 40 : Sous Estimation de la charge par Todd Little^106(*)

(Source: «Context-Adaptive Agility: Managing Complexity and Uncertainty» [LIT-CAA])

L'estimation de la charge initiale d'un projet a 10% de chances d'être respectée, mais dans la plupart des cas il faudrait multiplier au moins par deux, voire par trois ces estimations, afin de se rapprocher du temps réellement passé.

Explication de ces chiffres par le Lean Software Management

Les équipes informatiques passeraient donc deux fois plus de temps que l'estimation initiale à développer deux fois trop de choses (la moitié des fonctionnalités n'étant jamais utilisées). Ce raccourci rapide peut trouver un début d'explication dans le compartimentage de la conduite de projet. Car, entre l'instant où l'idée du projet a germé et le moment où la solution est mise à disposition des utilisateurs, plusieurs mois se sont écoulés.



Illustration 41 : Conduite de projet classique, diagramme de Timing UML 2.0

(Source: «Lean Software Development «, Chapitre « Eliminate Waste », [POP-LEA], p10)

Dans le cas du Lean, les cycles itératifs sont encouragés afin de produire en priorité les fonctionnalités à plus forte valeur pour l'utilisateur. Ce dernier peut rapidement matérialiser la solution en cours de construction, et apporter ses remarques. Le feedback est source d'amélioration et d'élimination des demandes superflues détectées au vue des 1ères livraisons.



Illustration 42 : Projet Lean, diagramme de Timing UML 2.0

(Source: «Lean Software Development «, Chapitre « Eliminate Waste », [POP-LEA], p11)

Cette méthode de conduite de projet permet aussi de lisser le stress qui n'est pas un des facteurs de réussite d'un projet. Habituellement, dans le cadre d'un nouveau projet, les premiers mois ne sont pas particulièrement facteurs de stress. Partagés entre les choix techniques et l'étude détaillée, les équipes informatiques savent qu'il reste du temps. Dans cette première phase, l'utilisateur n'a pas encore pu se rendre compte de l'interprétation faite de son expression de besoins par la MOA.

Puis le temps passe, et s'approche alors la date de mise en recette auprès des utilisateurs. Il s'est passé plusieurs mois depuis les premiers échanges, et pendant ce temps (l'entreprise étant une entité vivante), les besoins ont pu évoluer (nouvelle stratégie, nouvelles personnes, changement des priorités, crise etc ...). Cette réalité fait que bien souvent, des fonctionnalités non prévues au cahier des charges de départ, doivent être intégrées au processus de développement. La sous-estimation initiale des charges s'en trouve impactée. Le retard sur les prévisions est d'abord tu, puis avoué, lorsqu'il n'est plus possible de faire autrement.

Ce sentiment de stress et d'échec est alors partagé par l'équipe toute entière. Des reports sont négociés et sont parfois accompagnés de coupes fonctionnelles.

C'est toujours pareil, si ça ne marche pas ce n'est pas de ma faute

Surtout : Ne rien oublier. Anticipons les besoins auxquels il n'a pas encore pensé

Voilà ce dont j'ai besoin aujourd'hui

Comment exprimer ma demande alors qu'elle encore floue ?

Désolé, on est déjà en retard



Spécifications détaillées

....

.....

Je vais essayer

Expression de besoin





Utilisateur MOA MOE

Illustration 43 : Interactions au sein d'un projet

« Lorsque la réaction de stress est inexistante,

l'efficacité est nulle. Au fur et à mesure que le

stress croît, la performance augmente pour

se stabiliser à un niveau maximal.

Cette partie ascendante de la courbe peut être

Considérée comme le « bon stress »

(le eustress en anglais). Ce stress continuant

de croître, la performance, pour sa part, va au

contraire décroître. C'est le « mauvais stress »

(ou distress en anglais qui signifie «détresse»). »

L'idée du Lean est de conduire le projet par cycles itératifs de deux à quatre semaines. Un « backlog » recense les fonctionnalités à plus forte valeur ajoutée. Chaque cycle se décompose en 3 étapes (préparer, faire, adapter) et aboutit à un produit stable sur un périmètre réduit, pour l'utilisateur. Ainsi le stress ne se concentre pas deux mois avant la fin de projet, mais est dilué à chaque itération de cycle.



Docteur Patrick LÉGERON ^107(*)

(Source : Le stress au travail :

De la performance à la souffrance [LEG-LST])

Illustration 44 : Courbe du stress

Ce challenge mensuel et partagé est source de motivation et l'objectif à atteindre est limité. Il est donc plus facile de se concentrer sur l'essentiel. Les cycles réussis ajoutent à la motivation et à la confiance générale. Ils rapprochent ceux qui travaillent ensemble vers un but commun. Chaque cycle produit un lot stable et testé. Le risque est plus maîtrisé que lors d'un « One-Shot ».



2





1 : Préparer

2 : Faire

3 : Adapter

Fonctionnalités à plus forte valeur

3

1

Produit final

Illustration 45 : Le Cycle itératif

Comment le Lean apporte de la valeur



V

aleur :

Jugement porté sur le produit/service sur la base des attentes et des motivations de l'utilisateur, exprimé par une grandeur qui croît lorsque la satisfaction du besoin de l'utilisateur augmente et/ou que la dépense afférente au produit/service diminue.

Norme AFNOR NF X 50-150, 1990.

(Source : http://www.afnor.org/portail.asp)

o Meilleure compréhension du besoin

La première partie de l'approche est de partager un vocabulaire métier commun indépendant de du SI en faisant intervenir ensemble : la MOA, la MOE et les groupes utilisateurs.

Meilleure communication => compréhension fine => résultats

o Responsabilité partagée entre équipes utilisateurs, MOA et MOE

Les méthodes agiles amènent un fort changement de mentalité (co-pilotage avec le client, équipe et responsabilité collective, certains parlent « de partage du pouvoir » avec les autres fonctions de l'entreprise.). La responsabilité du projet s'en trouve naturellement partagée.

Co-responsabilité du projet avec les équipes utilisateurs => confiance => résultat

o Flexibilité, Agilité

Avec l'agilité, l'informatique n'est plus centre de coût mais source de valeur dans le sens où les contraintes de l'écosystème (légales, marchés, crise) doivent pouvoir être prises en compte rapidement par le SI. Les cycles rapprochés autorisent la flexibilité des choix et des priorisations.

o Mise en place d'une gouvernance

Cette gouvernance gère les tâches de transitions vers la cible ainsi que les processus métiers stratégiques en limitant le nombre de versions des services et en développant l'axe de la « réutilisabilité ». Elle participe à l'innovation continue et construit un leadership autour du produit. La visibilité est améliorée par des indicateurs, les outils de mesures en temps réel, les alertes. Le BPM est un des outils qui permet de mettre en oeuvre cette gouvernance.

o Suivi d'indicateurs

La mesure de l'agilité a été introduite en 2007 par IBM : la Key Agility Indicator^108(*) (KAI). Ces indicateurs ont été conçus à partir d'études menées sur un panel de 400 clients dans 31 pays pour le KAI des ressources humaines, et un panel de 9000 clients répartis sur 71 pays pour le KAI logistique. Depuis cette introduction, c'est près de 300 indicateurs KAI qu'IBM a mis en place pour mesurer l'agilité. Mais revenons aux indicateurs de valeur qui trouvent leur racine dans le LEAN.

o Mesure de la vélocité

La vélocité est une mesure de capacité de production (et non pas de productivité) d'une équipe et une seule dans le contexte spécifique d'un projet, à savoir dans un cycle. Le but n'est jamais de comparer plusieurs équipes entre elles. La vélocité répond à trois objectifs :

q Rendre la planification agile en estimant les temps de réalisation,

q Rendre l'engagement plus simple : dans le sens où quand on se connaît mieux, il est plus facile de s'engager sur le contenu d'une itération,

q Pouvoir être alerté le plus rapidement quand la vélocité d'une équipe diminue afin d'appréhender le problème le plutôt possible.

Vélocité = Somme des points de fonctionnalité atteint avec succès lors de la revue de fin de cycle.

o Visualisation du Management 



Le Lean propose des indicateurs très proches de la production en milieu industriel. Ces indicateurs sont difficilement transposables à la production d'information. Malgré tout, le principe de pouvoir suivre au plus près la réalité est décliné dans une série de tableaux mis à jour à la fin de chaque cycle. Ceux ci ajoutent de la transparence et donc participent à la confiance entre les différents acteurs du projet. « Suivi du reste à faire », « Backlog », « suivi des anomalies », « productivité » sont ainsi suivis à chaque cycle.

Illustration 46 : Bilan de fin d'itération

(Source : http://www.valtech.fr/etc/medialib/pdf/itc/fr/seminairesAgiles)

Là n'est pas le sujet du mémoire, mais ce chapitre mériterait une investigation plus poussée notamment vis à vis du TQM (Total Quality Managment) qui met en oeuvre toutes les strates de l'entreprise afin de mieux satisfaire les clients dans le respect de valeurs éthiques et économiques. La méthodologie agile peut paraître quelque peu hors sujet par rapport au sujet de la SOA, mais force est de constater que l'itération fait partie prenante de la démarche SOA. Elle permet de réutiliser au mieux l'existant tout en construisant de façon responsable l'architecture du système d'information. Elle met aussi l'accent sur la notion de responsabilité partagée entre l'informatique et les métiers amenés à le construire ensemble. Cette coresponsabilité est elle aussi recherchée au tout début de la démarche de construction SOA, au travers des modèles BPMN.

1.6.5 Décomposition des 3 principales couches SOA

1.6.5.1 La Couche Organisationnelle

Qui mieux que les experts fonctionnels détient la connaissance technique et métier ? La mise en commun de ce savoir est un des moyens possibles pour mettre en mouvement une cellule transverse dédiée à la gestion des services métiers.

Application Comptabilité

Application Contrôle de Gestion















Application Service aux Coopérateurs







Services Métiers

Normalisation

Assistance

Illustration 47 : Cellule transverse chargée de gérer les services

Cette organisation ne nécessite pas la constitution d'une équipe uniquement dédiée à cette tâche et cela ne remet pas non plus en cause l'organigramme de l'entreprise. Cette cellule est vivante dans le sens où elle peut varier de taille et de constitution en fonctions des enjeux stratégiques ou des nouveaux projets. Dans le cas où le SI est constitué de bloc applicatifs nombreux, il peut être envisagé de faire grossir cette cellule qui, peu à peu, redessine les rôles des équipes projet. Elle devient la plaque tournante vis à vis des projets dans le sens où elle se charge de gérer la partie technique qui met à disposition les services aux consommateurs, mais aussi dans le sens où elle apporte aux developpeurs les éléments pour mettre en oeuvre ces services. Enfin, cette cellule constitue les procédures, les normes permettant d'identifier les services, les outils à utiliser, les modèles, un vocabulaire commun, et tout arbitrage concernant les services. Elle aura en charge, la mise à jour de la nomenclature de services afin de disposer à chaque nouvelle étude d'une vue exhaustive et fiable. Ainsi la cartographie macroscopique doit être complètée d'une vue complète des services disponibles.

1.6.5.2 La Couche Fonctionnelle

Cette couche est l'occasion de partager certains modèles UML avec les métiers, tels que les diagrammes de classe (cf le langage de contrainte), d'activité, les cas d'utilisation de Jacobson109(*), et donc de renforcer le travail de modélisation ... Mais avant le déploiement de nouveaux services, il faudrait connaître le budget alloué et calculer le gain escompté. Même si aucun déploiement de service n'est prévu, il est important que soient notifiées dans les futurs appels d'offre ce qui est jugé comme faisant partie des «bonnes pratiques SOA» et ne pas renoncer, aux solutions d'échange XML par exemple. Cette démarche repose sur l'utilisation d'outils collaboratifs dont ceux nécessaires au suivi des contrats de service. Avant une nouvelle écriture, il faut vérifier si le référentiel peut ou non fournir le service recherché.

Fiche Service

Nom du service

Version

Description fine

Cas d'usage

Responsable

Date de création

Date de dernière modification

Nombre d'invocation depuis l'origine

Nombre d'invocation depuis le début de l'année

Nombre d'invocation des 30 derniers jours

Horaire de disponibilité

Performance attendue

Sécurité

Fraîcheur de l'information

Opération N

Format entrée / sortie

Exceptions

SLA (performance, sécurité)

Illustration 48 : Proposition de fiche de service

Bloc applicatifs

La première étape consiste à isoler les blocs applicatifs du SI de façon très macroscopique, puis pour chacun de ces blocs, de séparer les grandes fonctions de communications des fonctions internes. Ainsi, la réutilisation de service interne à un bloc applicatif pourra être mise en oeuvre.

_

Illustration 49 : Cartographie macroscopique réalisé sous Netbeans

L'approche SOA consiste à modéliser une cartographie des données sous forme de Catégories^110(*), en rapport avec le concept UML de package, émis par Grady Booch111(*). Chaque catégorie représente un groupe d'objets métiers à partir duquel les services seront construits. Autrement dit, un service sémantiquement ne peut concerner qu'une seule catégorie. Une fois administrés, il est alors possible de réutiliser les services et de les enrichir au fur et à mesure de la vie du SI. Cette classification permet d'ajouter de la stabilité à la cartographie d'autant plus qu'il répond aux diverses règles (non chevauchement, classe maîtresse (ici : Client, Produit) etc ...).

Règles de transformation

La seconde étape consiste à cibler les règles de transformation permettant les échanges d'information entre blocs applicatifs. Il n'est pas rare que la codification d'un tiers par exemple ne soit pas structurée de la même manière entre deux applications d'un même système d'information. Ces règles de transformation constituent la connaissance métier du SI et va permettre de ne pas dupliquer les mêmes données sous différentes formes.

Pour ce faire, le langage devenu universel en la matière, le XML, est largement utilisé, car littéralement «langage à balises extensible », il repose sur un système de balises que l'on peut adapter selon le secteur d'activité. C'est donc sur la base d' XML schémas ou de DTD que la communication inter-applicative va pouvoir être mise en oeuvre.

Grace à cela, les différents blocs applicatifs peuvent évoluer indépendemment, à leur propre rythme, tout en assurant leur rôle dans la construction du référentiel d'information de l'entreprise, un peu à l'image d'un arbre. Par exemple, l'interface d'un tiers issu d'une l'application A est encodée en XML. Ce message peut ensuite être distribué à une ou plusieurs applications B et C, abonnées à cette interface, sur la base de la connaissance des règles de transformation. Chacune de ces applications décode le message pour alimenter son référentiel selon sa propre structure. Le format d'encodage n'est réalisé qu'une seule fois pour les applications consommatrices présentes ou futures.

Processus métiers cibles

"L'individu change avec l'utilisation du langage

et le langage avec son utilisation par les individus."

Winograd et Flores, 1986.

(Source: New Rules for Computer Design)



P

rocessus :

Ensemble d'activités corrélées ou interactives qui transforme des éléments d'entrée en éléments de sortie. ISO9000

(Source : www.iso.org/iso/fr/iso_catalogue)

Ensemble de phénomènes conçus comme actifs et organisés dans le temps.

(Source : Le Robert, 1995)

Ces deux définitions du processus enoncent certains concepts de base tels que les activités, le temps, les entrées, les sorties... L'élément métier apporte quant à lui une autre notion composite : celle d'un individu détenant une certaine connaissance de son métier, amené à mener des actions en interaction avec d'autres individus. Cette interaction se fait selon des règles, une connaissance collective et un langage commun. Un modèle peut alors être créé.

Souvent les méta-modèles de processus font apparaître les classes de tâches et parfois même de sous-tâches. Mais la norme ISO10006 caractérise l'activité comme étant «la plus petite tâche identifiée dans un processus de projet»^112(*). C'est pour cela que l'illustration précédente préfère la vision anglo-saxonne d'»activity» reflexive et donc sans limite de niveaux, à la représentation francaise sémentiquement plus riche mais plus rigide. Le processus passe par plusieurs états une fois que son moteur d'orchestration a été activé. L'acteur est une personne physique ou un groupe d'individus ou encore une machine qui prennent part aux activités du processus. La ressource est quant à elle un moyen consommé sans transformation par l'activité.



Illustration 50 : Méta-modèle du Processus

La troisème étape doit définir les processus métier à intégrer à la démarche SOA. Ainsi pour chaque processus choisi, les règles métiers sont identifiées et décrites autour des multiples cas d'usage envisagés. Un langage graphique à haut niveau d'abstration a été conçus pour cela : le BPMN.

Le Business Activity Monitoring (BAM) est une extension des outils BPM puisqu'il supervise en temps réel le bon déroulement des processus. Sa mission est de récolter et d'analyser des indicateurs. Après 5 années d'existence, les outils BAM sont moins répandus que les outils BPM.

Les processus choisis pour être modélisés sont principalement axés sur la stratégie de l'entreprise. Ils s'appuyent souvent des principes d'automatisation et ont pour objectifs des gains de productivité, un résultat ou une aide au pilotage. Le retour sur investissement est d'autant plus important que les processus répondent à cette problématique. Ils peuvent être transverses ou non à plusieurs applications et tantôt gérés par un EAI ou par un Workflow. Par opposition, les processus liés à l'alimentation des datawarehouse sont davantage des processus de synchronisation pris en charge par des outils d'infrastructure : ETL et EAI. Les BPM sont quant à eux davantage associés à des processus de nuit de type séquentiel (extraction, alimentation ...). Si SOA ne signifie pas outils, citons néanmoins quelques éditeurs BPM et BAM du marché :

Editeur		Solution
LOMBARDI Software		Teamworks
METASTORM		Metastorm BPM
ORACLE		Oracle BPEL Manager, Oracle BPA Suite
TIBCO SOFTWARE		Tibco iProcess Suite
W4		W4 BPM Suite
M1l		Agilium
Editeur	Solution
C-LOG INTERNATIONAL	Workey
SOFTWARE AG	webmethods BPMS
BANCTECH	eFirst Process
ULTIMUS	Ultimus BPM Suite
IBM	FileNet P8 Business Process Manager

Tableau 3 : Principaux Outils BPM

Editeur		Solution
AXWAY		Synchrony Sentinel
Oracle		Oracle BAM
Editeur	Solution
SOFTWARE AG	WebMethods Optimize
SYSTAR	BusinessBridge
TIBCO SOFTWARE	BusinessEvents et BusinessFactor

Tableau 4 : Principaux Outils BAM

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

La dernière étape permet d'agréger les données à l'écran. Cette fonction est rendue possible par ... des services soit :

q Orientés données (aussi appelés CRUD: «C»reate, «R»ead, «U»pdate, «D»elete) où seul le résultat du service est renvoyé, laissant la charge de la présentation à l'application,

q Orientés présentation : il s'agit de services chargés de présenter les données. Ils sont ensuite intégrés à l'application appelante un peu à l'image d'un copier-coller.

1.6.5.3 La Couche Technique

L'exposition des services

Le Proxy

Le proxy est un accès donné à un utilisateur pour atteindre un objet distant (ex : CORBA, EJB, .NET Remoting, DCOM), un traitement transactionnel (ex : TUXEDO, CICS^113(*)), une procédure stockée ou un progiciel. (Exemple : PeopleSoft, SAP, SIEBEL). L'exposition du service n'est que le moyen de le déclencher « à distance », ce n'est pas le service lui-même. Souvent, dans le cadre du proxy, il s'agit de services unitaires. Les Web Services permettent un découplage fort entre le traitement et l'interface d'utilisation, contrairement aux technologies plus anciennes telles que CORBA, EJB ...Les appels RPC^114(*) permettent de développer des clients d'un Web Service dans une technologie différente. Ceci est appelé un « couplage technique lâche ».

La façade

La façade est ce qui permet de combiner et d'organiser plusieurs services métiers avec plus ou moins de services d'infrastructure qui peuvent être de 5 natures :

q Orchestration : elle permet l'ordonnancement des tâches avec ou sans l'introduction de mécanisme conditionnel selon l'état du processus,

q Validation : il s'agit par exemple de la mise en oeuvre d'un parsing qui analyse les données reçues et les injecte dans une structure. En cas d'erreur, une exception est émise,

q Transformation : les langages dédiés à ce type d'opération (comme XSLT) peuvent être préférés à l'utilisation d'ETL ou d'EAI,

q Routage : il s'agit d'un aiguillage de la demande qui s'opère de façon dynamique ou statique (dans le cas où le service est connu à l'avance). Pour cela il est possible d'avoir recours à des langages spécialisés dans le rôle de routage (exemple : DSL),

q Enrichissement : le but étant d'ajouter au message reçu des informations complémentaires avant de passer à l'étape suivante.

Le service de localisation : UDDI

Ce service n'est pas obligatoire dans une architecture SOA, mais force est de constater qu'il peut être très utile. Grâce à lui, le consommateur n'a pas à savoir où se trouve le ou les services exposés. C'est ce référentiel, aussi appelé « annuaire » qui va jouer ce rôle. Mais il reste facultatif d'autant plus qu'il impacte forcément les performances. Il propose les mécanismes suivants :

q Un enregistrement statique ou dynamique des services,

q Une IHM de recherche de service,

q Une gestion de la taxonomie^115(*) des services,

q Une notification du changement,

q Une console d'administration,

q Une génération automatique d'identification des services,

q Une gestion intelligente du cache.

La mise en oeuvre de ce type d'outil n'est pas simple et il ne peut être pris à la légère tant elle impacte la politique de sécurisation, les règles de nommage, le cycle de référencement des services, le processus de mise en production (publication) etc ...

Version	Année		Apports	1.0
2000	pages blanches (identification), pages jaunes (nomenclature des produits offerts), pages vertes (services, protocoles et Models).		2.0
2002	amélioration de la description des organisations, gestion de l'internationalisation, fonctions de recherche, public assertions par lesquelles des partenaires s'engagent, par exemple quant à la qualité d'un service.		3.0
2003 et pris en compte en 2005 par quelques Editeurs	support de la signature électronique, nouvelle interface d'abonnement, améliorations dans la gestion du répertoire, introduction de l'operational info, c'est à dire à la mise à jour automatique d'un registre UDDI à partir d'autres.

Tableau 5 : Versions UDDI

Editeur		Solution	APACHE
JUDDI		ORACLE/BEA
AquaLogic Registry Repository		NOVELL
Novell Nsure

Editeur		Solution	MICROSOFT
UDDI Services		ORACLE
ServiceRegistery		SOFTWARE AG
CentraSite

Tableau 6 : Principaux UDDI

L'échange

Le point à point

Le point à point reposant sur un adressage explicite peut être mis en oeuvre dans une architecture SOA. Ce mode d'échange peut être synchrone (appel RPC, Web service) ou asynchrone (FTP).

Le publish and subscribe

Le publish and subscribe de l'ESB est tout autant repris par l'architecture SOA. Il permet de diffuser un service vers N applications abonnées et consommatrices. Souvent pris en charge par un Hub, ce mode d'échange est souvent de type asynchrone.

Le Test

Plateformes d'homologation

Il s'agit de la dernière étape avant la mise en production et permet de valider, après les tests unitaires, le nouveau service qu'il soit interactif (synchrone ou asynchrone) ou batch. Ce type de validation se réalise dans un environnement d'homologation proche de celui de la production afin de bénéficier des mêmes volumétries. Cette contrainte peut engendrer des coûts significatifs.

La Sécurité

« Les services Web XML vont rouvrir 70% des chemins d'attaques

fermés par les pare-feu116(*) lors de la dernière décennie.

Ils peuvent transporter virtuellement toutes les données utiles sur le port 80

et le pare-feu ne peut les arrêter. »

Gartner Group^117(*), 2003.

(Source: http://www.soa-architect.net/publications/soa/soa/securite-pourquoi.php)

Cela aurait pu être sous l'angle de la sécurité, que la nécessité de l'architecture SOA peut aussi se justifier en dehors de l'interopérabilité car l'ESB, a lui seul, ne propose pas une sécurité multi niveaux.

Or, les services Web se développent aussi bien en B2B qu'en B2C (et G2C vis-à-vis des administrations) ce qui oblige les architectures à plus de sécurité au niveau des différentes couches :

q Transport : Firewall, non-répudiation, cryptage, authentification,

q Message : jetons de sécurité pour identifier le consumer (consommateur ou client) du service, assertions d'autorisation pour les accès,

q Données : cryptage des messages,

q Applications : sécurisation des composants,

q Environnement : Monitoring, audit, log afin de tracer l'activité.

Les zones implicites de confiance

Il s'agit de la mise en oeuvre la plus simple. Le but est de positionner les services dans une zone de sécurité avec contrôle d'accès. Le référentiel de sécurité peut être paramétré par rapport à l'adresse IP et du port, par rapport à la session via le protocole SSL ou en mettant en place un portail au niveau de l'application. Une fois l'authentification (identification et mot de passe) validée, l'ensemble des services de la zone peuvent être invoqués.

Les zones explicites de confiance

Cette fois le référentiel de sécurité est sollicité à chaque accès à un des services de la zone. L'identification et l'habilitation sont alors vérifiées par le service qui se trouve enrichi d'un module de sécurité. Ce mode de sécurisation est adapté aux services transverses souvent éloignés du frontal qui a permis à l'utilisateur de s'authentifier.

La fédération d'identité

Il s'agit de la mise en oeuvre d'une table de jointure permettant l'utilisation de différentes identités pour un même consommateur de services (SSO). Ce principe, largement soutenu par WS-Federation^118(*) et Liberty Alliance^119(*), nécessite que chaque application ait son propre gestionnaire de sécurité et que chaque consommateur complète lui-même ses différentes identités.

_

1.7 L'Architecture SOA se caractérise par une modélisation et une méthodologie orientées vers la « réutilisabitée » et l'interopérabilité des composants du SI Néanmoins les outils sont indispensables mais découlent naturellement de l'approche SOA.

Quels outils ?

Même si l'architecture SOA ne peut se résumer en termes d'outil, elle ne peut s'en passer :

q Outils UML orienté MDA pour générer automatiquement les schémas XML, les WSDL pour les services, le BPEL pour le moteur d'orchestration,

q Annuaire des services métiers (UDDI), (pas obligatoire au démarrage),

q

_

Outils de sécurité : WS-Security,

q IDE : Plate-forme de conception / développement intégré,

Illustration 51 : Constitution d'une Architecture SOA (clin d'oeil à Vitruve)

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



S'il est possible de mettre en place une architecture SOA, sans avoir recourt systématiquement aux Web Services, de nouveaux projets les y introduiront tôt ou tard. Or les spécifications ne cessent de fleurir en matière de Web Service. C'est pourquoi le WS-I^120(*) tente d'apporter une certaine stabilité en mettant à disposition une suite de logiciels gratuits. Ils permettent de vérifier la conformité aux profils WS-I (sur la base de l'interopérabilité entre les différentes briques SOA) : Une console permettant d'intercepter les messages SOAP et les entêtes HTTP, un analyseur pour vérifier les différentes briques : WSDL (définition du service) et UDDI (localisation du service), des cas d'utilisation et le code source associé. Depuis 2002, les WS-* se sont mis à fleurir pour consolider le triptyque (WSDL, SOAP, UDDI) des Web Services. L'illustration ci dessous permet de matérialiser ces spécifications qui ne cessent de s'ajouter les unes aux autres sans réellement être finalisées. L'unification d'une couche Web Service est pour l'instant une grande illusion.

Illustration 52 : Standardisation des Web Service

(Source : architectes.capgemini.com/evenement/XemeSymposium/Pleniere/Microsoft)

1.7.2 XML : LE standard ?

1.7.2.1 Généralités

API

XHTML

(2000)

Pages Web

Transmission

Par message

_

XML (1998)

DTD

XML SCHEMA

(1998)

XPATH

(1999)

XPOINTER

(2003)

XLINK

(2001)

RDF

(1999)

RDFS

(2000)

SWRL

(2004)

XSL

XSLT

(1999)

XSL-FO

(2001)

XML Signature

SOAP 1.2

(2002)

XQUERY

(2007)

Vocabulaire

Logique

de description

Règles

Outils d'interrogation

de document

Service Web

Description de

Document (grammaire)

Transformation

Mise en Forme

Liens intra-inter documents

SAX

(1998)

DOM

(1998)

En 1989 le World Wide Web est mis sur pieds par Tim Berners Lee. A cette époque HTML est réduit à des feuilles simples (HTML version 1). Jusqu'en 1998, un phénomène de « balkanisation du Web » se produit : chacun assiste alors à une explosion du nombre de pages Web. Naquit alors le XML, fruit du travail du W3C^121(*) dont le président est ... Tim Berners Lee. En parallèle, HTML poursuit son évolution (aux versions 2.0 de 1995, 3.2 et 4 de 1997 s'ajoute la version 4.01 en 1999). Un temps abandonné au profit de XHTML, HTML renaît de ses cendres en 2007 et propose sa version 5 aux éditeurs de navigateurs Web. Pendant ce temps, Microsoft et Netscape introduisent des balises « propriétaires ». XML continuent d'enrichir son offre : RDF pour les données sur le Web, suivi en 2004 d'OWL qui apporte sa logique de classification de données (« Ontologie^122(*) »).

Illustration 53 : La Galaxie XML

A cette galaxie, s'ajoutent régulièrement de nouveaux standards qui continuent de répondre à des problématiques précises. Même si ces standards ne sont pas visités dans ce mémoire, il peut être intéressant d'en avoir un bref aperçu :

q MathML, langage pour définir des formules mathématiques,

q VoiceXML, pour les interactions vocales,

q SVG, Scalar Vector Graphic, langage des graphiques du Web en Mode vectoriel,

q SMIL, Synchronized Multimedia Integration Language, pour définir les objets multimédia,

q XFORMS, pour créer des formulaires en ligne destinés à être utilisés avec HTML, XHTML, SVG

q .../...

1.7.2.2 Applications du XML

q Echanges B2B, B2C, EDI, e-Adm, e-Commerce, ... et A2A (Intégration des données hétérogènes),

q Dictionnaire des données XML,

q Conversion de et vers les bases de données relationnelles,

q Stockage dans des bases de données natives en XML (exemple : Oracle 11g et son noyau XML DB)

q Le monde de plus en plus important du Web Mobile,

q Les nouvelles technologies basées sur les « profils mobiles »: XHTML Basic, SVG Tiny et Basic, SMIL Basic, XForms Basic . Cela concerne tout autant les PDA, que les téléphones mobiles par exemple,

q Les Services Web,

q Le Web Sémantique,

q .../...

1.7.2.3 Illustration des différentes couches de la famille XML

_

Illustration 54 : Grid XML des Animaux de la Ferme, réalisé avec XmlSpy

<?xml version="1.0" encoding="UTF-8"?>

<!--Sample XML file generated by XMLSpy v2008 rel. 2 sp2 (http://www.altova.com)-->

<Ferme xsi:schemaLocation="http://www.xmlspy.com/schemas/orgchart ferme.xsd" xmlns="http://www.xmlspy.com/schemas/orgchart" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<Atelier>

<Espèce>Vache laitière</Espèce>

<Nom_atelier>Bovin</Nom_atelier>

<Aliment>

<Nom_Aliment>herbe</Nom_Aliment>

</Aliment>

<Aliment>

<Nom_Aliment>fourrage</Nom_Aliment>

</Aliment>

<Aliment>

<Nom_Aliment>viande</Nom_Aliment>

</Aliment>

<Apport>

<Nom_Apport>lait</Nom_Apport>

</Apport>

<Apport>

<Nom_Apport>oeuf</Nom_Apport>

</Apport>

</Atelier>

(...)

</Ferme>

Illustration 55 : Extrait XML du 1ère Atelier

Pour ce faire, le XML Schéma (XSD^123(*)) permet entre autre de définir des contrôles sur les champs (exemple : l'aliment doit être choisi parmi une liste prédéfinie). Il est fait référence à ce XSD, au sein même de la feuille XML.

(xsi:schemaLocation= http://www.xmlspy.com/schemas/orgchart ferme.xsd)

XML Schéma (XSD)

Les animaux sont classés selon une espèce (alphanumérique). Chaque espèce consomme des aliments (liste : herbe, viande, grains, fourrage) et produit au moins un type d'apport à la coopérative (liste : Lait, viande, oeuf).

<xsd:simpleType name="liste_aliment">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="herbe"/>

<xsd:enumeration value="viande"/>

<xsd:enumeration value="grains"/>

<xsd:enumeration value="fourrage"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="liste_apport">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="lait"/>

<xsd:enumeration value="viande"/>

<xsd:enumeration value="oeuf"/>

</xsd:restriction>

</xsd:simpleType>



Illustration 56 : Illustration et extrait XSD, réalisés avec XmlSpy

RDF 

RDF a été crée en 1999. L'objectif est alors de pouvoir définir des méta-données. Exemple de métadonnée :

« Virginie Elias est l'auteur de ce mémoire »

Ensemble d'informations, de données.

Avec l'interopérabilité des langages, arrive l'interopérabilité des connaissances (il est alors possible de combiner plusieurs savoirs car l'information devient interprétable par la machine).

RDF est fondé sur le triplet : {sujet, prédicat, objet}.

[Domaine] [Propriété] [Range]

Sujet

Objet

prédicat

<rdf:Description about="T:\ETUDES\SOA\mémoire/">

<prefixe:auteur>Virginie Elias</prefixe:auteur>

</rdf:Description>

Illustration 57 : Triplet RDF

Cette relation peut être décrite de la façon suivante :

q Le sujet représente une ressource à décrire (dans notre modèle de la Ferme : vache et poule),

q Le prédicat représente un type de propriété applicable à cette ressource (« consomme », « produit »),

q L'objet représente une donnée ou une autre ressource. C'est donc la valeur de la propriété (les aliments sont les valeurs de la propriété « consomme » et les apports sont les valeurs de la propriété « produit »).



Cette modélisation n'est possible que si toutes les ressources sont connues. Cette identification est opérée par l'utilisation d'un URI^124(*) constitué de la façon suivante :

q Le protocole (http, mailto, ftp, news, telnet, etc.),

q Le domaine (par exemple espece.dom),

q Le chemin (par exemple /mondictionnaire/index.html).

Illustration 58 : URI

(Source : http://fr.wikipedia.org/wiki/Image)

L'URI permet de localiser (URL) et de proposer une ressource (URN) définissant un espace de nom XML. Cela permet de lever les ambiguïtés (par exemple un identifiant produit pourrait être nommé ID_NUM de la même façon que l'identifiant d'un tiers).

Espace de noms pour RDF

<?xml version="1.0"?>

<rdf xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

Espace de noms pour le préfixe

xmlns:prefixe="http://source_mémoire/schema">

<rdf:Description about="T:\ETUDES\SOA\mémoire/">

<prefixe:auteur>Virginie Elias</prefixe:auteur>

</rdf:Description>

</rdf>





Illustration 59 : Extrait RDF, réalisé avec XmlSpy

RDF Schéma (RDFS)

RDFS définit les éléments de base pour la définition d'ontologies légères. Il permet de constituer un «schéma » de métadonnées en s'appuyant pour cela sur des classes rdfs:Class (« une Poule » est granivore) et une hiérarchie de classes rdfs:subClassOf (un « granivore » est un « animal »). Mais cela ne suffit pas, car le régime alimentaire est propre à chaque espèce (la vache et la poule ne consomment pas de viande). De même, la production (les apports faits à la coopérative) de la ferme est fonction de l'espèce (les oeufs sont produits par les poules etc...). La Logique RDF/RDFS est somme toute limitée, et n'offre pas beaucoup de possibilité d'expression. Principalement il n'est pas possible de préciser la relation entre les différentes ressources du schéma, on ne peut pas fixer les cardinalités d'un objet, ni d'indiquer une unicité, une transitivité (plus petit que) ou même une propriété inverse (« Consomme » : La poule consomme des grains/ La poule « Est consommé par » le cochon). Pour ce faire, OWL apportera un niveau supérieur en termes de richesse de construction.

<rdfs:class rdf:ID=`Oiseau'/>

<rdfs:class rdf:ID=`Poule'>

<rdfs:subClassOf rdf:resource=`#Oiseau'>

<rdfs:subClassOf rdf:resource=`#Granivore'/>

<rdfs:class rdf:ID=`Granivore'>

<rdfs:subClassOf rdf:resource=`#Animal'>

</rdfs:Class>

<rdf:Property rdf:ID=`estapparenté'>

<rdfs:domain rdf:resource=`#Cocotte'/>

<rdfs:range rdf:resource=`#Poule'/>

</rdf:Property>

Alors (Cocotte, est, granivore) est une spécialisation induite, inutile à spécifier.

Animal

Insectivore

Granivore

Omnivore

Poule

est

Poule

Granivore

Cocotte

Poule

Cocotte

+

Granivore

est apparenté

est

Illustration 60 : RDFS

Blé

Consomme

Poulet

RDFS propose le concept « réification^125(*) » sur la base de triplets pouvant s'encapsuler : {sujet, prédicat, {triplet}}, par exemple : {l'enfant apprécie {le poulet consommant du blé}}.

Enfant

Apprécie

Illustration 61 : Réification

OWL

OWL est davantage associé au concept d'ontologie que RDF car il est beaucoup plus riche en expressivité.



O

ntologie :

Doctrine ou théorie de l'être (philosophie) Encyclopédie Universalis.

Formalisation d'une conceptualisation dans le but de définir le sens des termes employés dans une organisation ou un métier.

Il est possible de définir les propriétés de classe équivalente (Homme, Femme), d'identité de deux ressources, des associations complexes entre deux ressources, de contraire (« Consommé » et « Est Consommé »), de symétrie, de transitivité, sans oublier la définition de cardinalités. OWL permet ainsi de définir des rapports complexes entre les différentes ressources. Trois niveaux d'OWL sont spécifiés par le consortium W3C : OWL Lite, DL et Full (dans l'ordre croissant de la richesse d'expressivité).

Caractéristiques du schéma RDF : · Class (Thing, Nothing) · rdfs:subClassOf · rdf:Property · rdfs:subPropertyOf · rdfs:domain · rdfs:range · Individual	(In)égalité : · equivalentClass · equivalentProperty · sameAs · differentFrom · AllDifferent · distinctMembers		Caractéristiques de propriété : · ObjectProperty · DatatypeProperty · inverseOf · TransitiveProperty · SymmetricProperty · FunctionalProperty · InverseFunctionalProperty	Restrictions de propriété : · Restriction · onProperty · allValuesFrom · someValuesFrom
Cardinalité restreinte : · minCardinality (seul 0 ou 1) · maxCardinality (seul 0 ou 1) · cardinality (seul 0 ou 1)	Informations d'en-tête : · Ontology · imports		Intersection de classe : · intersectionOf
Versionnage : · versionInfo · priorVersion · backwardCompatibleWith · incompatibleWith · DeprecatedClass · DeprecatedProperty	Propriétés d'annotation : · rdfs:label · rdfs:comment · rdfs:seeAlso · rdfs:isDefinedBy · AnnotationProperty · OntologyProperty		Types de données : · types de données xsd

Illustration 62 : Langage OWL Lite

(Source : owl-features-20040210 du W3C : www.w3c.org)

Axiomes de classe : · oneOf, DataRange · disjointWith · equivalentClass (s'applique aux expressions de classe) · rdfs:subClassOf (s'applique aux expressions de classe)		Combinaisons booléennes d'expressions de classe : · unionOf · complementOf · intersectionOf	Cardinalité arbitraire : · minCardinality · maxCardinality · cardinality
Information d'appoint : · hasValue

Illustration 63 : Langage OWL DL et Full

(Source : owl-features-20040210 du W3C : www.w3c.org)

Une ontologie est sérialisée dans un fichier RDF et/ou OWL constitué de :

q L'espace de nommage :

xmlns = " http://domain.tld/path/humanite#"

xmlns:humanite= " http://domain.tld/path/humanite#" xmlns:base = " http://domain.tld/path/humanite#" xmlns:vivant = " http://otherdomain.tld/otherpath/vivant#" xmlns:owl = " http://www.w3.org/2002/07/owl#"

xmlns:rdf = " http://www.w3.org/1 999/02/22-rdf-syntax-ns#" xmlns:rdfs = " http://www.w3.org/2000/0 1/rdf-schema#" xmlns:xsd = " http://www.w3.org/2001/XMLSchema#">

q L'entête où l'ontologie est spécifiée :

<rdfs:comment>Ontologie décrivant l'humanité</rdfs:comment>

<owl:imports rdf:resource="http://domain.tld/otherpath/vivant"/>

q



Les classes et sous classes :

<owl:Class rdf:ID="Humain">

<rdfs:subClassOf rdf:resource="&etre;#EtreVivant" /> </owl:Class>

<owl:Class rdf:ID="Homme">

<rdfs:subClassOf rdf:resource="#Humain" />

<owl:Class rdf:ID="Femme">

<rdfs:subClassOf rdf:resource="#Humain" />

<owl:Class rdf:ID="Ville">

<rdfs:subClassOf rdf:resource="#Pays" />

q Les propriétés :

<owl:ObjectProperty rdf:ID="Habite">

<rdfs:domain rdf:resource="#Humain" />

<rdfs:range rdf:resource="#Ville" />

</owl:ObjectProperty>

q Les assertions de faits :

<owl:ObjectProperty rdf:ID="EstMariéA">

<rdfs:subPropertyOf rdf:resource="#estDeLaFamilleDe" />

<rdf:type rdf:resource="&owl;SymmetricProperty" />

<rdfs:range rdf:resource="#Humain" />

<rdfs:domain rdf:resource="#Humain" />

_

</owl:ObjectProperty>

Illustration 64 : Diagramme de classe correspondant à l'ontologie décrite en exemple

Une Ontologie permet à deux utilisateurs qui ont leur propre vocabulaire de se comprendre. Chacun n'a connaissance que de son propre dictionnaire. Une zone de médiation permet aux deux dictionnaires de converger l'un vers l'autre, il s'agit d'une zone de correspondance sémantique.

M

E

D

I

A

T

I

O

N

Passerelle

Sémantique

Passerelle

Sémantique





Utilisateur Activité Céréales

Utilisateur Activité Volailles

Tiers

Partenaire

Client

Fournisseur

Coopérateur

Fournisseur Collecte

Client

Relation 1 1

Relation

N 1

Illustration 65 : Correspondance sémantique de deux ontologies

Une relation entre 2 ontologies peut être de 1 à 1, de 1 à n, de n à 1, de n à m. Une troisième ontologie peut être proposée spécifiquement pour tel ou tel besoin (de présentation par exemple) :

Tiers

Coopérateur

Fournisseur Collecte

Client

Illustration 66 : Ontologie de présentation déduite des deux autres ontologies

Mais l'utilisation d'OWL soulève quelques problèmes :

q La production des ontologies,

q Leur partage,

q Leur exploitation.

Pour ce faire des outils tels qu'Altova (module SemanticWorks) et Protégé permettent de créer des classes et de définir leurs propriétés.

OWL-S

Les services Web sémantiques ont été conçus dans le but de trouver, d'invoquer et de gérer les services web de la manière la plus automatique possible, sans recourt à l'intervention manuelle. Pour se faire, les services Web sémantiques sont décrits à partir du langage OWL-S^126(*), lui-même extension du langage OWL détaillé précédemment. Pour tendre vers cette automatisation, il a fallu définir finement l'ontologie du service et ainsi déterminer trois zones d'informations distinctes :

q le profil (ServiceProfile), pour répondre à la question : que fait le service ou plus précisément quelles informations sont gérées par le service ?

q le modèle de processus (ServiceModel), pour savoir comment il fonctionne c'est à dire toutes les informations concernant les entrées et les sorties ainsi que les « pré » et « post » conditions du service,

q les liaisons avec le service (ServiceGrounding), pour connaître le moyen d'y accéder (protocole, port ...).



Le W3C propose la représentation suivante de l'expression fine d'un service :

Illustration 67 : Ontologie des services

(Source : http://www.w3.org/Submission/OWL-S)

ServiceProfile

La classe ServiceProfile donne les informations permettant à un agent de publier ou trouver un service souhaité. Il s'agit là du premier tamis par lequel la recherche d'un service Web passe. A l'issue du passage au travers de ce premier tamis, il est possible de savoir si le service convient ou ne convient pas. Le terme de « matching » est parfois utilisé pour évoquer cette comparaison qui se fait sur trois axes :

q Le service et son fournisseur : le nom du service, sa description, le nom de son fournisseur, son adresse physique, d'adresse web, etc.

q Le comportement fonctionnel du service : les entrées et les sorties du service, les pré et post conditions,

q



Les attributs fonctionnels utiles en termes de contrat de service : le temps de réponse, le coût du service.

Illustration 68 : Ontologie du ServiceProfile

(Source : http://www.w3.org/Submission/OWL-S)

ServiceModel



Le ServiceModel permet d'analyser plus finement l'éligibilité du service ayant passé avec succès la première maille du tamis (cf. ServiceProfile). Cette classe permet aussi d'expliquer comment le service fonctionne. Pour cela, il est représenté comme un processus (sous classe Process) et peut constituer lui-même un processus composite constitué de séquences d'enchaînement diverses.

Illustration 69 : Ontologie du ServiceModel

(Source : http://www.w3.org/Submission/OWL-S)

Structure	Description
Sequence	Exécute une liste de processus dans un ordre donné
Concurrent	Exécute les activités d'un ensemble de processus
Split	Invoque les activités d'un ensemble de processus
Split+Join	Invoque les activités d'un ensemble de processus avec synchronisation
Unordered	Exécute tous les processus sans souci de l'ordre d'exécution
Choice	Choisit parmi plusieurs alternatives et execute l'activité choisie
If-Then-Else	Condition classique : si...sinon
Repeat-Until	Réitère tant que
Repeat-While	Réitère jusqu'à ce que

Tableau 7 : Mots clefs permettant la construction d'un process composite

ServiceGrounding

Le ServiceGrounding exprime l'invocation, c'est à dire les règles d'accès au service : le protocole qu'il faut utiliser, le format précis du message, la sérialisation, le transport, le mode d'adressage à employer. Cela nous renvoie à WSDL.



Illustration 70 : Correspondance entre OWL-S et WSDL

(Source : http://www.w3.org/Submission/OWL-S)

Les Ressources

Les Services Web ont besoin de ressource pour s'exécuter (tout comme le processus) : Les ressources consommées et celles qui restent réutilisables après l'exécution du service.

UDDI

UDDI constitue le référentiel des services web. Il n'offre qu'un nom de service et un pointeur, c'est à dire la façon d'accéder à ce service (adresse et port par exemple). Cela reste donc très rudimentaire par rapport à l'ontologie des services présentée dans ce chapitre OWL-S. Pour mettre en oeuvre cette richesse descriptive, il faut en quelque sorte greffer un moteur de matching à l'UDDI qui effectuera la recherche puis traduira le résultat de telle manière à ce que l'UDDI puisse reprendre la main.

Exemple d'expressions

<owl:Class rdf:ID="Input">

<rdfs:subClassOf rdf:resource="#Parameter"/>

</owl:Class>

<owl:Class rdf:ID="Output">

<rdfs:subClassOf rdf:resource="#Parameter"/>

</owl:Class>

Illustration 71 : Expression d'une définition de paramètres OWL-S

(Source : http://www.w3.org/Submission/OWL-S/#service_class)

<Description rdf:about="#process2">

<hasPrecondition>

<expr:KIF-Expression>

<expr:expressionBody>

(!agnt:know_val_is (!ecom:credit_card_num ?cc) ?num)

</expr:expressionBody>

</expr:KIF-Expression>

</hasPrecondition>

</Description>

Illustration 72 : Expression d'un pré condition OWL-S

Source : http://www.w3.org/Submission/OWL-S/#service_class)

L'Architecture SOA se caractérise par une modélisation et une méthodologie orientées vers la « réutilisabitée » et l'interopérabilité des composants du SI. Néanmoins les outils sont indispensables et doivent répondre à ce même besoin.

_

1.8 Les Faiblesses

1.8.1 Trop de standards tuent LE STANDARD

Au travers de la sécurité (WS-*), mais aussi des N versions de l'UDDI, des différentes possibilités de modélisation MDA, du WSDL, du BPM, et d'autres spécifications en cours d'écriture, la fuite en avant des standards est palpable. Une étude^127(*) réalisée début 2007 par le Groupe Tests^128(*) témoigne de ce manque de maturité ressentie par les décideurs sondés (#89), même si, trois quarts d'entre eux s'accordent à penser que leur SI en sera impacté dans les deux ans à venir. C'est là toute l'ambiguïté de SOA : « Prometteur » dans le sens où ce mode de pensée repose sur l'ouverture, mais c'est cette même ouverture « tous azimuts » qui constitue peut être une de ses principales faiblesses. Certains ajoutent qu'une couche technique de plus (par exemple la couche BPM) est source de code supplémentaire et donc un risque d'instabilité de plus.

C'est une des raisons pour laquelle un nouveau consortium est né en 2004 « Open SOA »^129(*) réunissant les éditeurs majeurs tels que : BEA, IBM, ORACLE, SYBASE, SUN, RED HAT, SAP, IONA , PROGRESS, SOFTWARE ag etc... Une publication, fin 2006, apporte deux nouvelles spécifications :

q SCA (Service Component Architecture) : Le but est de simplifier la création et la composition des services en les rendant indépendants de leur implémentation. Cette spécification a été finalisée en mars 2007 et repose sur l'idée qu'un service de niveau N est construit par l'assemblage, l'agrégation ou l'orchestration de services de niveau N ou N-1.

q SDO (Service Data Objects) : L'objectif est d'exploiter de façon homogène les données de sources différentes.

Un autre consortium est très actif en matière de langage universel : le W3C. Même si le développement de XML date de 1996, et qu'il est devenu norme du W3C il y a dix ans, il ne s'agit pas là d'une technologie novatrice. Avant XML, SGML avait été développé au début des années 80 et était devenu norme ISO, 6 ans plus tard. SGML a été reconnu et intégré à de nombreux projets de documentation de grande taille. Les bases de XML reprennent à la fois les fondamentaux de SGML et de HTML, tout en rendant son utilisation plus simple.

Opter pour les standards du W3C est une sécurité de plus pour garantir un maximum d'interopérabilité parmi les trop nombreux standards. XML est libre de droit comme les autres spécifications du W3C aujourd'hui, il est le socle sur lequel repose RDF (norme de métadonnées, définissant formellement les terminologies de certains domaines (comme la distribution) permettant une communication sur la base d'une ontologie^130(*)) et OWL.

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

Quelques échecs en matière d'architecture SOA mettent l'accent sur la nécessité de changer radicalement de mentalité en matière de conduite de projet, comme si la méthodologie agile était le préalable naturel et inévitable à une architecture SOA. Aussi ne faut il pas commencer par la sensibilisation des équipes par le biais d'une méthode agile, pour s'atteler ensuite à la construction de l'architecture SOA ? A première vue, le retour sur investissement serait peut être plus facile à mesurer si la méthodologie agile constituait la première étape de la démarche vers SOA.

1.8.3 Un calcul ROI difficile

Il n'est donc pas étonnant que dans ce contexte, fin 2007, « Seules 37% des entreprises ayant mis en oeuvre un projet SOA ont obtenu un ROI positif  »^131(*) d'après le Nucleus Research^132(*).

Mariano Boni^133(*) affirme que 75% des décideurs sondés^134(*) n'ont pas réalisé de calcul de ROI d'une démarche SOA. D'après lui, cela ne traduit pas leur oubli mais plutôt leur difficulté à calculer un retour sur investissement. Selon M. Boni, ce n'est qu'à la 3ème réutilisation d'un composant, qu'un gain est mesurable pour l'entreprise. A la 1^ère itération le coût est supérieur, et à la seconde itération le coût reste identique à auparavant.

1.8.4 Un avenir incertain mais nécessaire

« Avant 2008, plus de 75% des applications seront soient nativement SOA

ou exposeront une interface SOA via un portail (Probability : 0.8)»^135(*)

Gartner Group, 2003.

(Source: http://www.gartner.com/DisplayDocument?doc_cd=114358)

Ainsi, selon Gartner, plus de 75% des projets d'entreprises reposeront sur les SOA en 2008 et comme toujours, une des premières questions que seront amenées à se poser 75 % des DSI sera de savoir à quel moment il faut se mêler à cette bataille, mais aussi qui doit la mener.

Toute la difficulté repose sur la communication de ce qu'il est tentant d'appeler une « stratégie d'entreprise », tant SOA constitue une couche de rencontre et d'échange entre l'informatique et les métiers. Convaincre les équipes en sensibilisant, sans faire peur, tout en espérant être soutenu par la Direction de l'entreprise : tel est le préambule. Beaucoup, pensent que leur modèle en place est adapté aux demandes métiers ou que le modèle SOA est trop complexe à mettre en oeuvre. Se pose en quelque sorte la question de la maturité de l'entreprise vis à vis de cette démarche.



C'est pourquoi la valeur SOA reste au centre des préoccupations de ce mémoire car elle représente un des principaux arguments pour arriver à un consensus interne. A ce titre, Forrester a mis au point un modèle économique afin d'évaluer la valeur Métier SOA : le Total Economic Impact^136(*) sur la base de questionnaires. Les résultats obtenus de cette calculatrice Forrester sont monétisés et traduits en gains de temps potentiels ainsi qu'en productivité. Mais où se trouve la frontière entre l'argumentaire marketing et la réalité économique ? Les budgets alloués aux DSI informatiques ne sont pas extensibles. Si l'innovation doit avoir sa place (réalité concurrentielle oblige) cela passera en partie par l'industrialisation de la production informatique et par l'intégration du Legacy System tout en laissant une large place aux métiers, d'où une nécessité d'abstraction supplémentaire. SOA devra répondre à ce besoin pour ne pas être assimilée à un « buzz » de plus.

Illustration 73 : Comparaison BEA des coûts selon une approche traditionnelle et SOA

(Source : http://kr.bea.com/news_events/white_papers/BEA_SOA_Domains_WP.pdf)

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

L'évolution, pas toujours maîtrisée ou anticipée, des besoins des entreprises en terme de système d'information (SI) conduit les services informatiques à gérer des processus et des données de plus en complexes et hétérogènes. Ceci a pour effet d'augmenter les délais et les coûts de maintenance, dans un contexte où les Directions Générales exercent une pression forte sur les coûts informatiques et où les Directions Métiers expriment des exigences accrues. Des démarches, dites « SOA », articulées autour de services entre clients et fournisseurs, sont arrivées à maturité et peuvent être une solution pour mieux répondre à la problématique posée au paragraphe précédent. La Direction Générale de Terrena souhaite obtenir des tableaux de bord et des résultats consolidés de l'ensemble des activités du groupe dans des délais sensiblement raccourcis. Or, les systèmes d'information des différentes activités sont gérés historiquement par des équipes distinctes, dans des environnements technologiques et applicatifs différents. Les applications sont autant de « pièces en mouvement » indépendantes. C'est ainsi que l'administration des flux s'en trouve complexifiée, rendant coûteuse la résolution d'un dysfonctionnement. Parallèlement à cela, les différentes activités Terrena expriment-elles aussi des besoins pour lesquels le service informatique doit répondre de façon réactive. C'est pour cela que les silos verticaux en place nécessitent la mise en oeuvre de processus transversaux souples.

Aussi, la DSI Terrena souhaite trouver un moyen de gérer son hétérogénéité technologique, de rationaliser son système d'information sur les thématiques transverses aux métiers de la Coopérative (référentiel Terrena), tout en accélérant et en sécurisant les flux et les évolutions de son système d'informations. Il s'agira de rendre ce dernier plus agile en bâtissant une unification et une convergence au travers d'une « vue de Services » tout en cherchant à en mesurer le bénéfice (en valeur). La montée en charge de cette architecture, c'est à dire la migration de flux existants, sera progressive. Ce stage effectué chez Terrena n'aura pas pour objectif de redessiner l'ensemble du SI, mais de construire une architecture via une méthode éprouvée par l'implémentation d'un modèle réel de la problématique actuelle : « La GRC ». Pour cela, la démarche consiste à présenter le Groupe Terrena, ce qui permettra d'exprimer le besoin, puis de modéliser la problématique. L'analyse de cette problématique sous l'angle SOA devra aboutir à une proposition de modélisation cible, socle de la réalisation.

_

La modélisation ne peut être réalisée qu'après avoir exposé la richesse des métiers qui constituent le Groupe TERRENA. De cette richesse mais aussi par son histoire, le SI Terrena est devenu complexe et hétérogène.

2.4 Le Groupe TERRENA

2.4.1 Présentation

Ce projet répond aux besoins de la DSI de la coopérative Terrena qui, avec un chiffre d'affaires de 912 Millions € et 1200 salariés, constitue un acteur majeur de l'agriculture. Le Groupe Terrena qui pesait quant à lui 3,3 milliards d'euros en 2007, pour un effectif de 10 200 salariés, est un leader du secteur agro-alimentaire, se caractérisant par la diversité de ses productions et la polyvalence de ses activités.

Le 27 janvier 2009, la Direction Générale du Groupe Terrena, nous informe d'un projet de création d'une D.S.I. Groupe, présenté le même jour aux instances du personnel. Dans les grandes lignes, ce projet est motivé par :

q Un environnement économique difficile,

q Une multiplicité des systèmes d'information,

q La nécessité de se structurer comme un vrai Groupe,

q La volonté que les systèmes d'information soient la « colonne vertébrale » de cette structuration.

Ce projet d'organisation va amener les trois équipes informatiques qui fonctionnement aujourd'hui de façon indépendante, à fusionner au sein d'une même organisation. Un organigramme présentant les fonctions et les articulations entre les différentes spécialités informatiques laisse entrevoir de nouveaux postes motivés par des besoins de gestion de processus, de SOA etc... Aussi, le présent mémoire, au sein de mon entreprise, peut-il prendre un peu plus de sens.



Illustration 74 : Productions de la Coopérative Terrena en 2006

(Source : www.terrena.fr)

Chacune de ces activités dispose de ses propres outils et de sa propre codification tiers et produits. Chacun de ces pôles est géré par des équipes et des technologies séparées.

Illustration 75 : Organisation par pôles des Productions de la Coopérative

(Source : www.terrena.fr)

2.4.2 L'expression du besoin

De par sa structure et l'historique de sa construction, le système d'information de Terrena présente un fonctionnement « en silo », chaque silo étant plus ou moins autonome et isolé en termes de processus, d'interface homme/machine et de socle technique. Les solutions métiers sont regroupées au travers de domaines et communiquent via une aire d'échanges afin d'alimenter les outils comptables. Deux Couches sont à l'étude au budget 2009 : La GRC et l'EXTRANET.

Illustration 76 : Echanges inter-outils

Il a été décidé par la Direction Informatique d'intégrer à ce mémoire la modélisation et l'alimentation de la GRC (solution Selligent). Un périmètre restreint a été défini par l'équipe projet en place : le processus d'alimentation des tiers Terrena.

2.4.3 Définition du périmètre

L'objet central de la présente étude est l'entité TIERS. Ce sera notre point d'entrée dans la présentation de l'existant. Puis une cartographie du système d'information actuel va être proposée afin d'aider le lecteur à visualiser la complexité des flux actuels et de mettre l'accent sur un premier niveau de difficultés.

2.4.3.1 Entité concernée : Les tiers

Actuellement les tiers sont gérés via une application transactionnelle appelée GCAT. La base oracle 9i en assure la persistance. Grace à l'application appelée « GCAT », les utilisateurs peuvent créer ou modifier un tiers.

Un tiers est associé à une typologie :

q CLNT : Client,

q FOUR : Fournisseur,

q CLIG : Client intra-groupe,

q FOIG : Fournisseur intra-groupe,

q COOP : Coopérateur,

q FCOL : Fournisseur de Collecte.

Son identification se fait par le biais d'une clé composite dans GCAT, où chacune des informations est obligatoire :

q Société : 4 caractères numériques,

q Typologie : 4 caractères Alphabétiques,

q Code tiers : 5 caractères Alphanumériques,

q Sous-Compte : 2 caractères numériques issus d'une liste de sous compte autorisés (on parle d' « énumération »).

Les informations du tiers sont réparties sur plusieurs tables, dans plusieurs applications, sur des serveurs différents et éloignés géographiquement. Des fichiers CSV sont échangés selon un certain rythme entre GCAT et l'ensemble des applications métiers.

2.4.3.2 Volumétrie

Cette vue rassemble 200 000 tiers. Le nombre de modifications est en moyenne de 250 par jour.

2.4.3.3 Description du Processus actuel

Actuellement, toutes les heures (de 8 heures à 20 heures) d'un jour ouvré et travaillé, les tiers qui ont fait l'objet d'une modification ou d'une création, sont transmis :

q aux gestions commerciales par un flux spécifique,

q à l'application SIPAL (application d'agrofournitures),

q à la comptabilité par une interface de base à base,

q à Webpart par le rafraîchissement d'un SnapShot Oracle.

Tous les soirs, le Datamart Céréales est lui aussi alimenté par un flux spécifique, tout comme l'application du Reporting et les Mémos de Gestion (pour ceux là, la source des tiers provient des données de comptabilité).

Aujourd'hui, il nous est demandé de réfléchir à l'alimentation des tiers dans la future GRC. Mais tôt ou tard il pourrait nous être demandé d'alimenter d'autres applications où comme aujourd'hui les tiers sont saisis manuellement (par exemple l'application des Immo qui ne bénéficie pas d'interface Tiers) et peut être aussi le futur Datawarehouse Terrena qui devrait également bénéficier d'une vue des informations Tiers. Le processus à bâtir ne doit donc pas se cantonner au domaine de la GRC et doit être suffisamment ouvert pour être mutualisé à d'autres besoins.

2.4.3.4 Blocs applicatifs

La cartographie doit mettre en évidence les blocs applicatifs actuels concernés par le processus d'alimentation des tiers. Celle-ci paraît complexe et encombrée mais elle est avant tout le reflet d'une réalité qu'il ne faut pas simplifier sous prétexte de la rendre plus lisible. Il est vrai que UML 2.0 n'est pas vraiment orienté « cartographie ».





Illustration 77 : Cartographie actuelle façon Package UML

C'est pour cette raison, qu'apparaissent des outils spécifiques au domaine de la cartographie, comme Mega. La vision se construit sur 3 niveaux : La zone qui regroupe des quartiers, eux même constitués de blocs. Nous reviendrons sur les avantages et inconvénients de ces outils.



Illustration 78 : Cartographie actuelle, façon MEGA

2.4.3.5 Identification des ressaisies

Certaines applications ne bénéficient pas d'interface automatique soit pour des raisons de faible volumétrie, soit parce que cette fonctionnalité n'a pas été offerte aux utilisateurs :

q Immo (Catégorie Patrimoine), 

q Lapins (Catégorie Productions Animales),

q Suivi des Lots (Catégorie Productions Animales),

q Gestion Technique des éleveurs (Catégorie Productions Animales).

2.4.3.6 Inventaire des activités du processus

Plusieurs possibilités sont offertes pour modéliser les activités. Dans le chapitre « Trop de standards tuent LE STANDARD », proposition était faite de s'appuyer sur les standards XML du W3C. Voyons comment la problématique de l'inventaire des activités peut être abordée sous cet angle. Pour une alimentation d'un tiers dans une application, un traitement (une activité) est identifié de façon unique. Son mode est soit transactionnel ou batch. Il est exécuté soit à une fréquence donnée ou alors suite à un autre traitement. Cette alimentation passe par, au minimum, une activité, pour laquelle une ou plusieurs ressources sont nécessaires (table ou fichier). Ces ressources sont localisées quelque part, et peuvent être de type ascii, binaire ou xml. Le nom des tables n'est pas toujours connu (bases propriétaires). Enfin, une alimentation est faite au profit d'un acteur : un service en général.

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

Préalable retenu : Utiliser les langages universels et standards du W3C : XML, XSD ...



Illustration 79 : XSD du processus d'alimentation des tiers réalisé avec XmlSpy

Rappel : La définition de la structure peut être réalisée soit à l'aide d'une DTD^137(*) ou d'un XML Schema^138(*) (XSD). La structure d'un document XSD permet de contrôler la validité des documents XML relatifs à la structure attendue. XSD qui est lui aussi un document XML rempli la fonction de la DTD, d'origine SGML, à la différence qu'il définit également des contrôles de valeurs sur les champs.

2.4.3.8 Inventaire XML des activités du processus observé

<?xml version="1.0" encoding="UTF-8"?>

<!-- edited with XMLSpy v2008 rel. 2 sp2 (http://www.altova.com) by elias (terrena) -->

<Processus xsi:schemaLocation="http://www.xmlspy.com/schemas/orgchart flux.xsd"

xmlns="http://www.xmlspy.com/schemas/orgchart"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<Activité>

<Activité_intitulé>GCAT.MFF</Activité_intitulé>

<Activité_type>transactionnel</Activité_type>

<Evènement_Déclencheur>A la demande</Evènement_Déclencheur>

<Activité_compo>

<Acteur>Services Centraux</Acteur>

<Parametre>GCAT</Parametre>

<Parametre>PROD</Parametre>

<Parametre>GCAT_PROD</Parametre>

<Parametre>Fiche Adherent</Parametre>

<Ressource>

<Localisation>TABTERRENA</Localisation>

<Ressource_intitulé>PQADHERENTS</Ressource_intitulé>

<Ressource_type>table</Ressource_type>

<Entrée_Sortie>io</Entrée_Sortie>

<Ressource_structure>

(.../...)

</Ressource_structure>

</Ressource>

<Ressource>

<Localisation>TABTERRENA</Localisation>

<Ressource_intitulé>SQARCOINTF_USER</Ressource_intitulé>

<Ressource_type>table</Ressource_type>

<Entrée_Sortie>io</Entrée_Sortie>

<Ressource_structure>

(.../...)

</Ressource_structure>

</Ressource>

(.../...)

</Activité_compo>

(.../...)

</Activité>

(.../...)

Illustration 80 : Extrait de l'inventaire XML des activités d'alimentation de tiers

L'inventaire dénombre 23 activités entrant dans le processus d'alimentation des tiers. Chaque activité correspond concrètement à un traitement constitué de diverses opérations (ou programmes).

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

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

Chaque gestion commerciale consomme le fichier CSV à son rythme. Aujourd'hui, personne ne peut s'assurer, de façon centralisée, du niveau de mise à jour de telle ou telle gestion commerciale, de la comptabilité, de Webpart (Web pour les partenaire), de Sipal (Agrofournitures) ou des Immo ou d'une autre application alimentée par un flux tiers. Cela peut poser un problème dans le cas d'un PRA^139(*).

Pas de vue unique des règles de transformation

Il n'existe pas non plus de vue unique à partir de laquelle les règles de transformation sont accessibles, car celles ci sont à la charge des applications qui intègrent les tiers modifiés. La mesure d'impact de la modification d'une information existante doit se faire dans chaque application cible. L'inventaire des alimentations actuelles recueille près de 30 programmes différents. Lorsque la structure des Tiers évolue cela impacte donc toute ou partie de ces programmes. De plus, l'intégration de nouveaux fichiers (d'une de nos filiales par exemple) ne peut être envisagée sans adaptation.

Un mode batch actuellement privilégié

Les interfaces se font au plutôt dans un cycle horaire, ou au plus tard dans un cycle journalier. Demain, avec la GRC, il faudra être capable de pousser les informations modifiées vers la GRC dès la base GCAT mis à jour, c'est à dire au fil de l'eau. Il sera aussi demandé de pouvoir rafraîchir la GRC sur un mode à la demande et d'accéder à des informations liées au Tiers non interfacées à ce jour (Solde Comptable).

Une orchestration statique

Les flux suivent strictement les étapes définies par un script alors que les différents systèmes de sont pas toujours disponibles. Les solutions alternatives ne sont pas définies et ne permettent pas à l'orchestration transverse de choisir le « meilleur chemin » pour atteindre son but.

Pas de référentiel Métier

Le système actuel ne propose pas de référentiel Métier ce qui impacte les processus d'agrégation multi-activités. Concrètement, un même tiers peut être codifié de diverses manières en fonction du bloc applicatif dans lequel il est géré. Cette connaissance est aujourd'hui éparpillée et complexifie les processus transverses. En résumé, il est possible de dire que seule la vue par silo est privilégiée.

Il s'agit là peut être d'un des deux chapitres les plus importants du volet de « Modélisation ». Le but est de représenter le système actuel de manière à pourvoir en extraire les faiblesses, et proposer ce qu'il est commun d'appeler des « Bonnes pratiques ».

_

2.5 Modélisation de la problématique Terrena

Modéliser est en quelque sorte représenter la réalité d'un système et des objets qui le constituent.

L'Architecture Orientée Services s'articule principalement autour du concept de processus métier. Ce dernier est constitué d'une séquence de services indépendants (on parle de couplage faible) et interopérables gérés le plus souvent par un annuaire UDDI. Un service répond à un besoin du métier. A cette fonction, dite de « grosse maille », est attaché un contrat qui régît la relation « Consommateur-Fournisseur ». Il est important de rappeler que les Web Services ne sont qu'une implémentation des services, et qu'il est possible de parler de SOA sans mise en oeuvre de Web Services. Autrement dit, la problématique Terrena doit être perçue au travers de plusieurs vues complémentaires : informationnelle, processus, services et qualité de service.

2.5.1 L'objectif

La question que l'on doit se poser avant tout est : Quelle est la stratégie que le Groupe Terrena souhaite atteindre au travers de cette expression de besoin ? Pour répondre à cette question un diagramme en forme d'arrêtes de poisson peut servir d'illustration. Ce diagramme a pour vocation de définir les causes et les effets. La flèche au centre rappelle l'objectif principal. Les causes sont représentées par les flèches transverses orientées vers l'axe central. Les effets s'imbriquent sur ces flèches obliques. Les causes placées au-dessus de l'axe central concernent les métiers, et celles placées sous l'axe central correspondent à celles de la D.S.I.

Fluidifier les flux

Eviter les ressaisies

Automate au fil de l'eau

Offrir des solutions de type Web Service

Homogénéiser les pratiques

Objectif stratégique

Sécurisation, Fluidification Clarification des flux Tiers

Tracer les

Messages

Format pivot

Optimiser les pratiques,

Trouver des plans alternatifs

Maîtriser les flux et règles métiers Tiers

Sécuriser des outils informatiques utilisés

Assurer le plan de Reprise d'activité

Illustration 81 : Diagramme Causes-Effets d'Ishikawa^140(*)

2.5.2 La conceptualisation de notre monde clos

La problématique n'est pas tant de mutualiser ou de rationaliser des fonctionnalités qui seraient réparties sur plusieurs systèmes (la richesse fonctionnelle de ce processus est somme toute relative), mais clairement de coordonner de façon optimisée des systèmes autonomes, ici au nombre de 18, afin de limiter les désynchronisations de codification entre les différents blocs applicatifs. Nous en profiterons pour construire une architecture, qui permette également de répondre aux besoins transversaux nécessitant un référentiel métier. Ce souci d'une meilleure coordination est une problématique qui se trouve souvent au centre des systèmes dits « multi agent »^141(*). Ce concept « SMA » a été introduit en 1980. Un agent y est défini comme une entité autonome qui interagit avec d'autres agents pour le compte d'un groupe d'utilisateurs. Il est constitué d'une connaissance partielle et peut accéder à des données ou à des ressources. SMA^142(*) semble approprié lorsqu'il s'agit d'aborder le sujet de la tolérance aux pannes, les problèmes de disponibilité réseau etc ... Il bénéficie d'informations du monde clos^143(*) qui l'entoure (« perception planning »), et interagit (« motion planning ») avec ce dernier. Les agents communiquent entre eux par le biais de messages asynchrones. Pour que SMA soit assimilable à une architecture SOA, il doit être déterministe dans le sens où dans un contexte donné, l'agent produit toujours la même action (les connaissances de l'agent restant identiques). Un agent combine des observations obtenues par ces capteurs (indicateurs : nombre de messages dans la pile par exemple) avec des actions spécifiques à un contexte donné (pré et post conditions). La prise de décision conduit à une séquence d'actions dans le but de réaliser un objectif.

Ces systèmes multi-Agents font l'objet d'une modélisation propre appelée : AUML (UML for Agent). Elle repose sur des diagrammes UML tels que : le diagramme de Classes d'Agent, le package pour ce qui touche aux protocoles, les diagrammes d'Activités, de Séquence, de Collaboration et d'Etats-Transitions pour tout ce qui concerne les échanges entre agents. Malgré les failles d'AUML (notion d'historique non gérée, descriptions temporelles difficilement traduisibles ...), cette approche est intéressante car l'agent est autonome comme l'est le composant d'un ESB. Par ailleurs le concept d' « Agent » est apparu dans la spécification SOAml parue le 13 janvier dernier (extrait ci-dessous).



Illustration 82 : Extrait SOAml

(Source : http://www.omg.org/docs/ad/08-11-01.pdf, page 43)

Connaissances

Pré et Post Condition => Liste ordrée d'actions

Agent

Objectif

N Actions

Observations

Système

Évènements

Illustration 83 : Architecture logicielle de l'agent

L'illustration à venir montre un système de transition d'états impliquant les objets suivants : un message qui peut prendre plusieurs formes, une file d'attente capable de recevoir et de supprimer le message, des agents capables de transporter le message, de le transformer après détection sur certains lieux (répertoires) dans un périmètre d'intervention (bloc applicatif). Notre système d'information est constitué de plusieurs blocs applicatifs qui communiquent entre eux par échange de messages.

q L'ensemble S est un ensemble fini et énumérable d'états. Il est noté :

S = {S0, S1, S2, S3, S4, S5}

q L'ensemble des actions A est un ensemble fini et énumérable d'activités ou actions noté :

A= {préparer, supprimer, détecter, transformer, transmettre, ignorer, consommer}

q L'ensemble des évènements E est initialement vide. Il représente un ensemble fini et récursivement énumérable : E = {}

L'illustration suivante met en évidence les différents états dans lesquels se trouve l'objet message. Elle précise les « compensations^144(*) », c'est-à-dire l'action à mettre en oeuvre pour défaire ce qui a été fait précédemment et ainsi "revenir" dans un état stable.

File F2

Agent 4

Agent 3(Prépare)

Agent 3

Lieu L1

Lieu L2

S2

S3

Message M1

M2

File F1

File F1

Lieu L1

Agent1(Ignorer)

Agent1(Détecter)

File F1

S4

S5

M2

M2

File F1

Lieu L1

Lieu L2

Lieu L2

S0

S1

Message M1

File F1

Lieu L2

Lieu L1

Lieu L1

Lieu L2

File F1

Lieu L2

Agent 4

Agent 2

Agent 3

Agent 2

Agent 1

Agent 1

Agent3(Supprimer)

File F2

File F2

Agent 4

Agent 4

Agent1(Transformer)

Agent 3

Agent 2

Agent 2

Agent 1

Agent1(Transformer)

Agent2(Transmettre)

Agent2(Transmettre)

File F2

File F2

Agent 4

Agent 3

Agent 2

Agent 2

Agent 1

Agent4(Consommer)

File F2

Agent 3

Agent 1

Agent4(Détecter)

Agent 3

Agent 4

Agent 1

Lieu L1

Agent4(Ignorer)

Agent4(Supprimer)

Illustration 84 : Système de transition d'états appliqué à notre échange de fichier Tiers

Nous nous apprêtons ainsi à modéliser le processus actuel d'alimentation de tiers. Il devrait s'agir en quelque sorte d'une communication coordonnée entre plusieurs agents. A partir de cette représentation, il va être possible de souligner les faiblesses ou les éventuels manques. De ce constat, il faudra ensuite être capable de proposer des solutions alternatives, tout en gardant à l'esprit que cette approche de modélisation devrait être transposable à une toute autre problématique.

2.5.2.1 Les concepts

Les objets

q Message : dans le sens générique, ici il s'agit de différentes structures de fichiers,

q Lieu : base de données, répertoires,

q File d'attente : Zone tampon, utilisée pour stocker provisoirement les messages (le premier qui entre est aussi le premier qui peut ressortir de la file d'attente),

q Agent : automate évoluant dans différents lieux, à l'écoute des états dans son monde clos, et prêt à effectuer une séquence d'actions.

Les états

Objet Message

Lorsqu'un tiers est créé ou modifié par un utilisateur, un message est préparé. A cet instant, il est connu du bloc applicatif central (« Le Fournisseur »), mais pas encore des applications périphériques (« Les consommateurs »). Ce message est ainsi en attente d'une prise en compte par des agents qui le transformeront et le transmettront vers un ou plusieurs lieux. Enfin, selon le rythme propre à chaque application cible, le message est consommé par celle ci. Il disparaît ainsi perdant du même coup son état. Notons que le message peut prendre plusieurs formes selon l'application qui va le consommer.

E(Message) = {préparé, transformé, transmis, consommé}



Illustration 85 : Diagramme Etat-Transition de l'objet Message

Objet Lieu

Le « lieu » est un emplacement du système par lequel passe des messages. Ce lieu peut être soit « disponible » soit « indisponible » vis à vis de ce SI en fonction de critères horaires ou d'événements particuliers liés aux interventions techniques de l'équipe réseaux et systèmes.

E(Lieu) = {disponible, indisponible}

Objet File d'attente

Ici est appelée « file d'attente », un container d'un lieu, dont le rôle est d'entreposer de façon ordrée les messages que lui déposera l'agent. Concrètement, cette file d'attente est aujourd'hui un répertoire de fichiers. Elle peut être vide ou non(vide).

E(File) = {vide, non (vide)}

Objet Agent

Est appelé «agent», l'automate qui est capable tout aussi bien d'observer un monde clos constitué de lieux que d'effectuer des actions. Cet agent peut être « actif » soit « inactif».

E(Agent) = {actif, inactif}

L'état ne concerne pas un objet par rapport à lui-même, mais il permet également de le positionner dans le monde clos, par rapports aux autres objets. Pour déterminer l'ensemble fini des prédicats d'un état S, une matrice permet de s'interroger sur l'ensemble fini :

	Message	Lieu	File		Agent	Message
Préparé Transformé Transmis Consommé		Contient	Prépare Transforme Transmet Consomme		Lieu
	Disponible Indisponible	Est_abrité	Scrute		File
Est_contenu	Abrite	Vide Non(Vide)			Agent
Est_Préparé Est_transformé Est_transmis Consommé	Est_scruté		Actif, Inactif

Tableau 8 : triplet RDF

S3

M2

File F2

File F1

Agent 1

Lieu L1

Lieu L2

Illustration 86 : Exemple de représentation d'un état

S3 = {disponible(L1), disponible(L2), abrite (L1, F1), abrite (L2, F2), est_préparé(M2),

est_contenu(M2,F1), vide(F2), actif(1), est_scruté(1,L1)}

Les actions

Les actions sont l'oeuvre d'opérateurs et sont pré-conditionnées positivement ou négativement par un état. Par exemple : « non (disponible (lieu A))» signifie que si l `état du lieu A n'est pas disponible alors la pré-condition est remplie et l'action peut se déclencher. L'action est génératrice de changement d'état. Par exemple, l'action « transmettre» peut provoquer le changement d'état de la file d'attente de destination qui passe de « vide » à l'état  « non vide ».

Les opérateurs

Un opérateur se défini par le quadruplet (nom, pré-condition, faits à créer, faits à supprimer). Par Exemple : « L'agent 2 sur le lieu X transmet le Message M1 de la File F1 vers la file F2 du lieu Y» se traduit en :

q Transmettre (2,X,M1,M2,F1,F2,Y)

q Precondition (precond) : actif(1), disponible(X), disponible(Y), est_abrité(F1, X), Est_contenu(M1, F1)

q états généré : est_contenu(M1, F2), non(est_contenu(M1, F1)) 

q états si retour arrière : est_contenu(M1, F1), non(est_contenu(M1, F2))

Cette description permet d'entrevoir comment il va être possible de gérer les retours arrières mais aussi de proposer des solutions alternatives dans le cas où des pannes seraient détectées (comme une indisponibilité d'un serveur hébergeant un lieu par lequel les messages transitent). Un opérateur est ensuite « encapsulé » de façon ordrée avec d'autres opérateurs, dans ce qui est appelé une méthode. Un nom et des pré-conditions viennent compléter la description de cette dernière. Ainsi, pour illustrer ce concept, la méthode « Transmettre un message M1 de F1 à F2 », ou autrement dit « Transmettre (M1,F1,F2) », peut être exprimée de la manière suivante :

-- transmet un message M1 de F1 à F2 (avec l'agent 1)

transmettre (M1,F1,F2)

precond: disponible(F1), est_contenu(M1,F1), est_accessible(M1,F1), actif(1),

reduction: lit(1,M1,F1), transmet(1,M1,F2), supprime(1,M1,F1)

La réduction définit la séquence d'opérateurs à réaliser et permet d'imaginer les plans de retour arrière en cas de panne. Cela nous renvoie aussi au concept de processus composite d'OWL-S et à la nécessité d'une coordination complète gérant les échecs.

2.5.2.2 La coordination

Dans le cadre de notre SI hétérogène, l'objectif est de pouvoir répondre à des buts communs et transversaux aux différents blocs applicatifs, qui le constituent. Deux modes de coordination sont envisageables : soit la planification est collective et centralisée (elle repose alors sur un agent coordinateur), soit elle est distribuée et répartie sur plusieurs systèmes (où chaque agent construit son plan de solutions de façon indépendante puis tente de le synchroniser avec ceux des autres agents). En quelque sorte, ces agents nous renvoient au concept des services WEB dont la modélisation peut être prise en charge par OWL-S. Il fait partie d'un ensemble avec lequel il se trouve en interaction. Chacun des agents joue un ou plusieurs rôles dans le système. Chaque rôle accède à un certain nombre de méthodes et chaque méthode fait appel à des opérations conditionnées.



Illustration 87 : Diagramme de classes de l'Agent, réalisé sous magicdraw

Quatre rôles distincts ont été déterminés précédemment : la préparation, la détection-transformation d'un message, la transmission et la consommation d'un message. Le « Fournisseur » prépare le message. Le « Consommateur » est le nom donné au système cible qui attend le message afin de l'intégrer à son rythme dans son propre référentiel de données. L' « orchestrateur » exécute un script d'exploitation basé sur la détection puis la transformation (d'un contenu Oracle vers un format fichier CSV), suivie de la transmission du fichier. Mais avant de proposer ce diagramme d'activité, encore faut-il modéliser la communication actuelle.

2.5.2.3 La Modélisation de la communication actuelle

Les deux diagrammes suivants (de communication et de classes) représentent la structure spatiale de la communication actuelle. Ils décrivent l'échange de fichiers entre un système dit « le Fournisseur » et un autre, appelé « le Consommateur ». Le premier diagramme (de communication) est composé de :

q agent émetteur/ agent récepteur : dans la réalité les agents prennent les deux rôles,

q agent superviseur : dans notre cas ce superviseur est l'outil de coordination, notre orchestrateur OPEN PROCESS dont le comportement est guidé par des scripts d'exploitation,

q agent observateur : il n'existe pas en tant que tel aujourd'hui mais dans l'absolu il peut représenter toute personne (du service exploitation ou autre) souhaitant être informée des différentes étapes d'un fichier,

q objet de la communication : cela représente les informations Tiers à transmettre au(x) consommateur(s),

q message : les messages échangés dans ce processus sont des fichiers au format fixe Csv,

q code : le code utilisé ici représente la structure de message échangé entre les deux partenaires. Le format de message doit être connu des deux protagonistes,

q canal : le canal utilisé pour véhiculer le message entre les deux partenaires, ici FTP RFC959,

q localisation : la localisation du message est l'emplacement où est positionné le fichier.



Ainsi cet échange est orchestré par un outil de planification. Ce dernier est appelé « Open Process ». Il joue un rôle de « superviseur » de façon distribuée (en ce sens qu'il n'est pas localisé que sur le système central, mais il est réparti sur l'ensemble des systèmes protagonistes de cet échange). Il détecte l'arrivée de nouveaux fichiers tiers au format Csv assimilables, dans la représentation, à des messages. Les appels FTP gérés par Open Process donnent au fournisseur et au consommateur un rôle d'« émetteur » et de « récepteur » d'informations. L'agent récepteur dispose d'une boite à outils, puisqu'une fois reçu, le message doit être transformé et intégré. L' « observateur » représente le technicien d'exploitation amené à traiter manuellement des fichiers rejetés par le superviseur.

Illustration 88 : Diagramme de communication, réalisé sous Magicdraw

Le diagramme de classe quant à lui présente la structure du modèle actuel :



Illustration 89 : Diagramme de classes, réalisé sous Magicdraw

Le premier constat est peut être l'aspect rigide de cette communication (un seul canal, des règles de transformations non intégrées au processus de communication, seule la dernière version de code du message peut entrer dans le processus, des interventions manuelles sont requises pour traiter les rejets etc...). Mais avant de poursuivre davantage l'analyse des faiblesses, il faut présenter les différentes vues afin de rendre lisible le SI, un peu à la façon d'un urbaniste qui souhaiterait faire évoluer ou moderniser tout ou partie d'un système d'information.

2.5.3 Urbanisation actuelle de notre SI

Dans la démarche d'urbanisation, l'objectif est de décrire différentes vues :

q la vue externe ou « vue organisation » afin de décrire de façon générale l'organisation en place,

q la vue interne dont le but est de cartographier le processus métier d'alimentation des tiers en précisant les aspects non fonctionnels tels que les performances, la sécurité. Cette vue prend parfois le nom de « vue qualité de services (QoS) »,

q la « vue informationnelle » pour décrire l'information manipulée, les objets métiers (ici, les tiers),

q la vue applicative ou fonctionnelle où le but est de décrire les fonctionnalités ou autrement dit les « services » offerts par le système d'information pour assurer le processus métier. Cette vue inclut la vue informatique qui décrit l'infrastructure permettant le fonctionnement des briques logicielles du système informatique. Cette vue est aussi appelée « vue des services ».

2.5.3.1 La Vue externe ou vue organisation

L'objectif est de formaliser la mission de l'organisation constituée des utilisateurs et des agents (fournisseurs, consommateur, superviseur, observateur) sous l'angle des échanges concernant le périmètre de l'étude. La question qui est posée à cette étape est le : « Pourquoi ?». Pour répondre à cette question, la modélisation par les cas d'utilisation UML peut servir d'illustration.



Illustration 90 : Cas d'utilisation UML de la communication actuelle

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

La vue interne permet de visualiser les agents qui réalisent un certain nombre d'activités ou d'actions dans l'objectif de répondre à des sollicitations (« évènements métiers »). Ils collaborent à un objectif commun à partir de ces activités qui constituent le processus métier. Cette vue doit répondre à la question du « Qui » et du « Comment ». Pour cela le diagramme des processus métier UML (BPMN) peut servir de support. Le processus vu sous l'angle BPMN met en évidence les événements déclencheurs du processus. Ici le déclencheur est la saisie mais aussi l'événement horaire. Le processus est constitué d'activités (cadres arrondis et orangés) consommant des entrées et générant des sorties. Entrées et sorties constituent des objets métiers appartenant à la vue informationnelle. Ces différentes activités sont à la charge d'acteurs référencés par la vue d'organisation. Ces acteurs sont représentés en « swimlanes » ou en couloirs, en français.



Illustration 91 : Processus métier actuel, BPMN réalisé avec Magicdraw

Les termes de Consommateur et de fournisseur sont très génériques et cela nécessite probablement plus d'explications. Le fournisseur représente l'application centrale GCAT qui gère le référentiel Terrena. C'est par cette application qu'il est possible de créer et de modifier les informations relatives aux Tiers. Les consommateurs représentent les applications qui gravitent autour de ce référentiel. Elles sont alimentées grâce au superviseur Open Process qui transmet ou rejette tout message lui étant présenté (« message » étant un terme générique pour nommer les informations tiers réunies dans un fichier dans un format Csv). La photographie de l'existant ne serait pas complète, s'il n'était pas précisé que le message échangé entre fournisseur et consommateur n'est pas homogène. L'histoire du SI Terrena fait que cohabitent plusieurs formes d'interfaces de tiers et donc plusieurs structures de messages.

Arcole Comptabilité

Sipal Agro Fournitures

Reporting

Portail Web Partenaire

Céréales

GCAT Gestion centrale des Tiers

Mémos de Gestion

Distribution spécialisée

Datamart Céréales

Fioul

Semences

Illustration 92 : Les Consommateurs et le Fournisseur

Les couleurs mettent en évidence la spécificité de certains flux Tiers (au nombre de 6 sur ce schéma). De plus, les applications, non dotées d'une alimentation automatique, n'ont pas été intégrées à cette illustration (dans ces cas, il s'agit d'un mode dégradé, totalement manuel).

Deux axes marquent la démarche de construction d'une architecture SOA : la réutilisation de services (de fonctions) et l'interopérabilité au sens large. Dès à présent, il est possible de souligner que réorganiser des services dans le but de les regrouper et les rendre plus rationnels est limité lorsqu'il s'agit de s'attaquer à un processus d'alimentation comme le notre (contrairement à des processus de gestion où il est plus aisé de trouver des fonctionnalités multiples et parfois redondantes). L'axe de l'interopérabilité est quant à lui plus évident pour ce type de problématique.

Les Consommateurs sont autant de systèmes d'information hétérogènes qui doivent collaborer entre eux. De façon générale, il faut bien comprendre qu'une application est bien souvent à la fois « Consommateur et Fournisseur » d'information pour le SI tout entier.

2.5.3.3 La Vue Informationnelle

Cette troisième vue met en lumière l'information qui se trouve au centre du processus décrit précédemment. Elle est très importante à la démarche, car elle doit répondre à la question du « Quoi ? ». Pour cela les informations manipulées doivent être décrites qu'elles soient structurées ou non.

En annexe, sont représentées les structures des Tiers, Rib et Adresses.

Ces informations proviennent de tables de l'application GCAT (le Fournisseur) et sont ventilées dans trois fichiers (ou enveloppes) séparés. Le Superviseur contrôle chaque nom d'enveloppe (chaque fichier) et décide s'il faut transférer l'enveloppe au consommateur ou la mettre en quarantaine (ce qui correspond à un rejet du fichier). Nous portons le focus sur les applications consommatrices qui reçoivent toutes la même structure de message. Ces dernières ont aujourd'hui la responsabilité de la transformation de ces données, avant leur intégration définitive. Les informations listées pèle mêle dans le fichier TIERS ne sont pas simples à organiser. Lors de la construction de la médiation cible, nous reviendrons certainement au concept d'ontologie, c'est-à-dire, à la définition d'une hiérarchie de classes et des propriétés de celles ci. Rappel : La couche OWL, dédiée aux ontologies s'appuie sur la couche XML. OWL est le fruit d'un travail du W3C.

2.5.3.4 La Vue Applicative, fonctionnelle ou Vue Services

La cartographie actuelle est le point d'entrée de l'analyse de la problématique sous l'angle applicatif. A partir de celle ci, un diagramme d'activités présentera les différentes actions et rôles mis en oeuvre afin d'atteindre l'objectif. Le diagramme d'activité doit être le moyen à partir duquel il va être possible d'illustrer les plans alternatifs en cas de panne diverses (réseau ou serveur indisponible etc ...) ainsi que les manques du processus actuel. Ainsi le diagramme à venir représente la situation actuelle des flux d'alimentation des tiers pour ce qui est des transferts de fichiers à plat. Rappel : il en existe d'autres, tels que des transferts base à base pour la comptabilité ainsi que de la saisie directe par les utilisateurs. Ces derniers sont écartés de l'analyse de l'existant, sans que cela ne rende impossible leur prise en compte dans le modèle cible. A partir de ce diagramme d'activités, nous allons donc étudier les manques et faiblesses du système actuel afin de construire ce modèle futur, permettant lui, de répondre à la stratégie précédemment énoncée. Ce chapitre doit faire ressortir un certain nombre de préconisations et de conseils, ce que l'on appelle communément des « bonnes pratiques ». Afin de déterminer le niveau d'importance du respect de ces bonnes pratiques, la terminologie RFC 2119 (qualifiant les différents niveaux d'exigence depuis 1997) sera utilisée en français dans le mémoire :

q MUST, SHALL : DOIT (exigence absolue de la spécification.)

q MUST NOT, SHALL NOT : NE DOIT PAS (prohibition absolue de la spécification.)

q REQUIRED : EXIGE (nécessite)

q SHOULD : DEVRAIT (c'est à dire qu'il peut exister des raisons valables, dans certains cas, pour ignorer cet item particulier. Les conséquences doivent être bien étudiées.)

q SHOULD NOT : NE DEVRAIT PAS (signifie que cela est interdit mais qu'il peut toutefois exister des raisons valables, dans certains cas, pour ne pas suivre cette recommandation. Les conséquences doivent être bien étudiées.)

q RECOMMENDED : RECOMMANDE

q MAY : PEUT (FACULTATIF)

q OPTIONAL : FACULTATIF Terminologie RFC 2119.

(Source : www.ietf.org/rfc/rfc2119.txt)



Illustration 93 : Diagramme d'activité actuel

2.5.3.5 Les Faiblesses (Vue générale)

Deux colonnes sont utilisées pour expliciter ces faiblesses. La colonne de gauche « Observation réduite au cas d'utilisation » met en lumière la problématique de notre modèle d'alimentation. Et la colonne de droite, « Observation générale », tente de donner plus de hauteur et propose une réponse vue de l'Architecture SOA, constituant ce qui est appelé les « bonnes pratiques ». 

Observation réduite au cas d'utilisation	Observation générale (bonnes pratiques)
Entre le moment où le tiers est créé ou modifié, il peut parfois se passer une heure avant que le processus d'alimentation ne commence. De plus, certaines applications consommatrices ne traitent les fichiers que la nuit ce qui repousse à J+1 la mise à disposition de l'information	Les zones tampons doivent être limitées. Un ESB fonctionne dans un mode au fil de l'eau. Les liaisons inter-applicatives DEVRAIENT être de type Bus (ESB).
Cette tâche d'extraction n'est pas publiée car intégrée dans un script Python sans réelle pré et post condition. La réutilisation est en rendue moins évidente.	Les services (dans le sens générique) DOIVENT pouvoir être invoqués grâce à une interface d'accès de la famille des Services Web.
Les tiers sont extraits en Lot et rassemblés dans un même fichier à plat. Sans recherche manuelle, il n'est pas possible de savoir dans quel fichier se trouve la modification de tel ou tel tiers.	Xquery permet d'interroger aisément le contenu d'un document XML. Une couche d'administration peut être construite par ce biais. XQUERY DEVRAIT être utilisé pour les recherches dans les documents / Base de données XML.
Si le système d'information GCAT s'enrichit au niveau du référentiel tiers, la tâche d'extraction doit être retravaillée afin d'intégrer les nouveautés.	L'utilisation de formats de balisage (XML) est moins impactante en termes de maintenance qu'un format fichier. Le format d'échange DOIT être construit en XML.
La copie sur le FTP n'est pas sécurisée (RFC-959). Les comptes et mots de passe peuvent être aisément captés sur le réseau.	FTP propose une version davantage sécurisée : SFTP. De plus les protocoles SOAP, WSDL et UDDI renforçant la sécurité. Le mode sécurisé DOIT être préféré au mode non sécurisé.
Le fichier est très difficilement lisible sans accès à la description formelle. Le contenu du fichier n'est pas contrôlé avant qu'il ne soit transmis au consommateur.	Le contenu d'un document XML est compréhensible grâce aux balises utilisées. Ce contenu est contrôlé par un Schéma XML qui constitue la « grammaire » des informations transmises. Le format d'échange DOIT utiliser XML.
La transmission est mono-protocole. Quel que soit le consommateur, il n'est pas possible de transmettre le message d'une autre manière qu'en FTP.	Un système hétérogène peut rassembler potentiellement divers protocoles (FTP, SFTP, HTTP ...). Un des rôles de l'ESB est de transformer des protocoles (rôle de médiation). Les liaisons inter-applicatives DEVRAIENT être de type bus ESB.
L'algorithme d'attente est basé sur la comparaison d'une taille de fichier photographié deux fois, à 5 secondes d'intervalles. Dans les faits, cela fonctionne dans 99% des cas. Mais il arrive que certains noeuds du réseau soient saturés. Dans ce cas la photo est identique alors que le transfert de fichier n'est pas achevé. Cf diagramme de séquence	En mode fichier : Il faudrait procéder à un nommage intermédiaire de telle façon à ce qu'il ne soit pas récupérable par l'automate le temps du transfert. Une fois achevé, le renommage du fichier le rendrait visible aux yeux de l'automate car il en retourne de la responsabilité de l'émetteur. En mode message le problème de se pose pas car l'ESB garantit le bon acheminement et n'enchaîne une nouvelle tâche qu'une fois la précédente terminée. La spécification WS-ReliableMessaging appliquée à SOAP garantit le bon acheminement des messages. Dans le cadre des Services, SOAP DOIT être utilisé.
L'algorithme de test est complexe et ne concerne que le nom du fichier, c'est-à-dire le contenant et non le contenu. Les 2 premières positions du nom, puis les 3, les 4, les 5, les 6, les 7 et les sont comparées avec une liste de racines, stockée dans un fichier ascii non crypté. De cette chaîne est déduite l'application consommatrice vers qui il faut transférer le fichier. Cf diagramme de séquence	Les règles de routage internes à un ESB DOIVENT répondre à cette problématique. Le routage doit se faire sur le contenu (CBR) et non pas sur le contenant.
L'archivage consiste aujourd'hui à copier le fichier dans un répertoire d'historisation. Tout traitement ultérieur sur la base de ces fichiers est purement manuel et donc sujet à erreur.	Les règles de routage internes à un ESB DOIVENT répondre à cette problématique. La définition d'un Processus métier intègre les actions correspondant aux plans alternatifs en cas de plantage ou de rejet. Cette gestion DEVRAIT être davantage intégrée au processus métier d'alimentation des Tiers.
De façon générale, il n'existe aucune statistique automatique permettant de visualiser les « pics » de transfert, les performances des différentes actions...	Les indicateurs SAM et BAM permettent d'avoir une première idée de la réalité des échanges. Un outil BAM PEUT être mis en place pour donner ce premier niveau d'information.
Chaque consommateur gère ses transformations. Le vocabulaire tout comme les règles de transformation ne sont pas visibles de façon centralisée.	Un format pivot permettrait de centraliser les règles de transformation ainsi que la sémantique des informations Tiers des applications consommatrices. C'est aussi le rôle du « Repository » qui DEVRAIT être mis en place.
Les tiers qui n'auraient pas pu être intégrés par une application consommatrice ne sont pas connus de façon centralisée sans une recherche approfondie.	Les liaisons inter-applicatives DEVRAIENT être de type ESB du début à la fin du processus.
La réponse du consommateur se limite à la bonne réception ou non du fichier sur le répertoire d'accueil. Si le consommateur n'est pas accessible le fichier est mis en quarantaine ce qui supposera ultérieurement une manipulation du service exploitation. De plus, ce répertoire, vu du SI, est une boite noire : après recherche manuelle en lisant les fichiers trace, on peut savoir ce qui a été transmis, mais il est extrêmement difficile de savoir à quel moment un tiers lambda a été intégré à l'application consommatrice. Se pose là un des problèmes de mise en oeuvre d'un PRA (plan de reprise d'activité).	Dans un ESB le message a comme attribut une durée de vie qui lui permet d'attendre un certain temps avant d'être déposé dans une file d'attente dite « de fin de vie ». En gérant tout le processus d'alimentation via un ESB, la connaissance des messages est réelle depuis leur création jusqu'à leur intégration par le consommateur. Dès lors il est plus aisé de rejouer les messages entre deux instants T dans le but de synchroniser plusieurs noeuds du système d'information. Les liaisons inter-applicatives DEVRAIENT être de type ESB.
Le processus est limité dans le sens où seul l'événement de saisie utilisateur déclenche une alimentation des applications consommatrices. Or, nous traversons une phase de réorganisation. Dans le cas où le référentiel Terrena deviendrait le référentiel de l'ensemble des filiales il faudrait que les tiers puissent aussi être transmis électroniquement (au format XML par exemple) d'une filiale par exemple à l'application centrale qui deviendrait cette fois une application consommatrice.	L'évènement déclencheur est aujourd'hui de type timing dans le sens où c'est le temps qui fait qu'une extraction des modifications et créations Tiers se déclenche. Le fichier, résultant de cette extraction, est ensuite travaillé par le processus actuel. Demain, le déclencheur pourrait être plus proche des évènements perçus par le Système. Ainsi, à chaque saisie d'un utilisateur, un service constituerait un message qui serait l `élément déclencheur du processus. Cette nouvelle porte pourrait aussi être empruntée par les filiales qui souhaiteraient transmettre leurs informations au système central GCAT. L'évènement déclencheur DEVRAIT être choisi parmi les objets en lien direct avec le processus ce qui rend plus aisée l'articulation entre plusieurs processus.
Seuls les tiers nouvellement créés ou modifiés alimentent les applications consommatrices. Il n'est pas possible aujourd'hui de procéder à un rafraîchissement qui fonctionnerait à la demande (via un Web Service).	Un ESB offre la possibilité d'accéder aux informations de diverses manières. Les Web Services font partie de cette offre.
Un tiers ne se définit pas seulement par ses informations générales, ses RIB et ses Adresses. L'ensemble des données de sa relation commerciale et financière avec la Coopérative fait partie de son identité. Aujourd'hui, les gestions commerciales, consommatrices de l'interface de Tiers, n'ont pas accès à cette vue complète.	Un ESB offre la possibilité d'accéder aux informations de multiples systèmes Fournisseurs.
Le référentiel de Structure, c'est à dire l'identification des ressources (Serveurs, répertoires, authentification) au travers du SI est géré dans des fichiers Csv non cryptés.	Un référentiel de la structure DEVRAIT être intégré à l'architecture et être sécurisé.
La liaison inter-applicative est de type « Point à Point ».	Les liaisons inter-applicatives NE DOIVENT PAS être de « point à point » mais DEVRAIT être de type ESB dans le sens « un message pour N applications consommatrices abonnées au processus ».
Le référentiel Client, c'est à dire l'identification des tiers au travers de tout le SI n'existe pas en tant que tel. Il est dispersé dans autant d'applicatifs qui constituent le SI.	Un référentiel métier DEVRAIT être intégré à l'architecture.

Tableau 9 : Bonnes pratiques SOA

2.5.3.6 Les Faiblesses (Vue approfondie)

L'objectif de ce chapitre est d'approfondir par le biais d'une modélisation adaptée, les noeuds qui concentrent certaines difficultés.

Intégrité des messages non respectée

_

Illustration 94 : Diagramme de séquence de l'activité d' « Attente de fin de transfert »

L'agent superviseur (Open Process) joue le rôle d'intermédiaire entre le fournisseur (émetteur) et le consommateur (récepteur) de fichier tiers. Le fichier est transmis de l'émetteur au superviseur (1^er flux), puis du superviseur au récepteur (2^nd flux) qui consommera le fichier. Un problème de synchronisation entre la fin du premier flux et le début du second peut parfois se produire. La raison est liée au fait que certains débits de réseaux de sites éloignés soient tels que les Taille1 et Taille2 restent identiques alors que le transfert (c'est-à-dire le premier flux) n'est pas terminé. Le fichier entrant qui est toujours en cours de transfert est alors aussitôt contrôlé et transféré au consommateur qui ne saura jamais qu'il ne dispose pas de l'intégralité des enregistrements.

Les ESB assurent la garantie d'acheminement des messages grâce au WS-ReliableMessaging (spécification OASIS). Ce dernier intègre dans les messages Soap les mécanismes classiques d'accusés de réception et permet de ré émettre le message en cas d'incident. Il est alors certain qu'un message Soap transporté sur HTTP est bien arrivé à destination. Dans le cas contraire, il est possible de le réémettre jusqu'à ce que la réception ait été correctement réalisée. La spécification WS-ReliableMessaging est en concurrence avec WS-Reliability (spécification SUN). IBM, dans son outil Websphere, propose le connecteur HTTP-R, qui décrit les mécanismes équivalents, directement au niveau HTTP.



Identification des messages compliquée et rigide

Illustration 95 : Diagramme de séquence de l'activité « Contrôle du contenant »

Cet algorithme rigide aurait pu être évité si l'on avait utilisé d'autres techniques d'identification. Le Hash-coding^145(*) fait partie de ces solutions.

Dans un ESB, l'identification des messages peut être réalisée sur la base des spécifications du WS-Addressing. SOAP qui intègre dans sa partie entête (header) un ID, une adresse pour l'accusé de réception et un destinataire du message.

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">

<S:Header>

Id Message

<wsa:MessageID>

uuid:6B29FC40-CA47-1067-B31D-00DD010662DA

</wsa:MessageID>

Destinataire de la réponse

<wsa:ReplyTo>

<wsa:Address>http://business456.example/client1</wsa:Address>

Destinataire du message

</wsa:ReplyTo>

<wsa:To> http://fabrikam123.example/Purchasing </wsa:To>

<wsa:Action>http://fabrikam123.example/SubmitPO</wsa:Action>

</S:Header>

Illustration 96 : Entête d'un Message SOAP

_

Un Protocole de transport unique et non sécurisé

Illustration 97 : Couche Transport

Le script actuel ne propose qu'une porte d'échange entre les différentes plateformes : le mode FTP. De plus, les comptes et mots de passe ainsi que les noms de machines et les répertoires sont stockés dans un fichier Csv non crypté. L'arrivée d'une nouvelle plate-forme dans le SI suppose, en cas de participation aux échanges, la modification de ce script et l'alimentation des fichiers de « paramétrage ».

Une architecture orientée services est avant tout une architecture de médiation permettant d'assurer l'interopérabilité au niveau des données mais aussi au niveau des techniques de transport telles que : HTTP, HTTPS, SOAP + WS-Security, SMTP, SMTPS, FTP, SFTP, RMI, etc ...), tout en sécurisant les échanges.

Pour cela, l'ESB joue un rôle de médiateur entre les différents systèmes, grâce à ses composants internes. Au moment de la génération du message, les consommateurs ne sont pas connus à l'avance. Le bus doit donc être souple, c'est à dire permettre à plusieurs systèmes hétérogènes de communiquer sans que le processus ne soit décliné autant de fois qu'il y a de technologies dans le SI. La spécification WS-Security (OASIS) vient renforcer la sécurité des échanges de messages.

Dans le cas présent, la cardinalité devrait être multiple, et le canal devraient, si possible, être sécurisé (SFTP au lieu de FTP tout au moins).

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

_

Illustration 98 : Diagramme de séquence de la distribution

Actuellement, si un consommateur n'est pas disponible, alors le message (le fichier) est systématiquement mis en quarantaine, ce qui implique une action manuelle de la part d'un technicien d'exploitation. De plus, si une nouvelle application doit entrer dans le processus d'alimentation, cela suppose également un paramétrage spécifique et des modifications à plusieurs niveaux des scripts actuels. Ceci peut être source d'erreur et ne semble pas très « agile ». De plus, le processus actuel ne sait pas à quel moment tel ou tel fichier a été intégré. Il n'y a pas de retour du consommateur au superviseur quand un fichier a été consommé, ni lorsque que tout ou partie de ces enregistrements présentent des erreurs de codification. Aujourd'hui, les dernières branches du processus sont manuelles.

Les Données

L'organisation des données au sein d'un fichier Csv fragilise l'agilité du système, puisque tant pour l'extraction, que pour les N programmes de transformation et de chargement (ou d'intégration), il faudra opérer des adaptations plus ou moins coûteuses. De plus, la mise en lot des données de plusieurs tiers ne facilite pas le suivi unitaire, cette notion de lot n'étant pas réellement identifiée au niveau du Fournisseur.

Les règles de transformation ne sont pas connues de façon centralisée car elles sont réparties sur autant de systèmes Clients distants. Les mesures d'impact en cas de modification n'en sont pas aisées. Pour illustrer cette difficulté supplémentaire, nous pouvons citer le problème auquel nous avons dû faire face en début d'année : le nombre de positions (5 caractères numériques) qui permet d'identifier le code tiers n'était plus suffisant, au autrement dit : « la boucle était bouclée ». Il a fallu se rapprocher de chaque Chef de projet pour connaître la longueur et le type de code Tiers dans chaque application, puis se lancer dans une phase de recette complète pour mesurer l'impact de l'utilisation alphanumérique des 5 positions de ce code. Plusieurs semaines ont été ainsi nécessaires pour commencer à avoir certains retours sur un dossier pourtant jugé « urgent ».

Les agrégations de données sur des entités comme le tiers, pour lesquels il existe des tables de transcodification sur certaines applications, sont rendues très délicates : nulle-part, de façon centralisée, nous ne pouvons connaître l'ensemble des identifications d'un tiers. Invoquer des services sur des systèmes différents dans le but de réaliser un processus transverse (exemple : Suivi des montants des livraisons par Tiers) devient une chose difficile.

Le vocabulaire utilisé aujourd'hui n'est pas uniforme (chaque application consommatrice désigne l'adhérent selon son métier : « Fournisseur collecte », « Adhérent », « Coopérateur », « Eleveur »). La codification peut être propre à l'application (on l'a vu précédemment via une transcodification), ou identique ou presque. Quelques transformations (le sous-compte par exemple dans l'application Céréales est amputé du premier chiffre) sont parfois utilisées. Ces règles ne sont pas connues de façon centralisée.

Synthèse

Le superviseur actuel s'appuie essentiellement sur des déclenchements de type « horaire », ce qui n'aide pas à la fluidité de l'information.

La traçabilité des messages ne permet pas aujourd'hui de reconstruire de façon fiable et performante le paramétrage des tiers sur l'ensemble des systèmes à un instant donné (cf. problématique du PRA).

Les échanges sont compartimentés ainsi que la codification et les transformations réalisées.

Globalement, il s'agit de traitements batch placés bout à bout, dans le but de reconduire un fonctionnement jugé fiable dans le passé. Cette vision est devenue réductrice vis à vis d'un SI actuel, qui s'est enrichi des multiples couches et qui s'est peu à peu étendu, sans pourvoir offrir de vue unifiée.

L'ESB, épine dorsale de l'Architecture Orientée Services, est une infrastructure dont la base est l'orchestration des services sur la base d'événements et de messages. Comme il a été exprimé dans la partie « Etat de l'Art », un des avantages de l'ESB est d'avoir été construit sur les standards du marché tels que SOAP, WSDL, XML et les Web Services.

Le Référentiel Métier est lui aussi une pièce incontournable à la proposition d'architecture qui va faire l'objet du prochain chapitre.

Plusieurs approches ont été présentées dans le chapitre de l'Etat de l'Art (Bottom-up, Top-down et Middleware Approach). Un article paru mi décembre 2008 annonce une sortie prochaine d'une nouvelle spécification UML pour la SOA : SOAML. Ce mémoire tentera d'intégrer cette nouveauté autant qu'il en sera possible. La démarche MDA permettra d'orienter cette modélisation.

_

2.6 Modélisation de la Cible

Un article paru en décembre 2008 annonce de prochaines spécifications UML propres aux architectures SOA :

« UML s'adapte aux SOA.

SoaML, extension du langage de modélisation pour les architectures orientées services,



devrait être validé d'ici un mois, a affirmé un représentant de l'OMG

(Object Management Group),

qui tient une conférence sur le sujet en ce moment à Santa Clara. »^146(*)

Olivier RAFAL, 11 décembre 2008.

(Source : http://www.lemondeinformatique.fr/actualites/lire-soaml-pour-decrire-les-soa-avec-uml-27629.html)

SOAml s'appuie sur la modélisation UML 2.0 et met l'accent sur la modélisation des services (incluant la notion de contrat de service) entre consommateurs et fournisseurs.

En annexe, sont présentés des extraits du méta modèle SOAml.

2.6.1 La démarche MDA

La démarche MDA est intéressante car, comme il a été expliqué dans la première partie, elle reste indépendante de la plate forme technique et du type d'architecture (SOA ou autre).

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



La démarche MDA consiste, pour ce mémoire, à modéliser la branche métier à partir d'un diagramme BPMN. Une fois validé, ce diagramme peut d'ores et déjà faire l'objet d'une génération BPEL (orchestration de l'ESB). Dans cette partie CIM de la démarche MDA, une cartographie est également nécessaire afin de camper les principaux composants de l'architecture SOA cible. Toute la difficulté de la modélisation cible est de générer les diagrammes UML 2.0 de la partie PIM, alors que l'éditeur de MagicDraw n'envisage d'intégrer le nouveau profil SOAml paru en janvier 2009 dédié aux architecture UML, que dans sa prochaine version. C'est donc en se basant sur les travaux de thèse de J. Touzi^147(*), que ce chapitre doit être capable de présenter les diagrammes de Classes, d'Etats-Transitions, de Séquences et d'Activités de façon graduelle et ce, toujours en relation avec le diagramme de processus métier. Suite à quoi, la partie PSM de la démarche MDA peut être appréhendée sous l'angle des spécifications techniques de l'ESB. C'est dans cette partie que seront modélisés par exemple les WSDL et autres diagrammes nécessaires à la génération du code.



Le domaine récent de la Cartographie et de l'Urbanisme profite de nombreux ouvrages réalisés par Christophe LONGEPE qui est devenu une des références en la matière.

Le diagramme BPMN est le diagramme pivot de cette démarche.

La modélisation logique se construit sur la base des diagrammes UML de structure (classe) et dynamiques (états-transition, activités, séquences). Le profil UML standard est utilisé auquel est ajouté le profil SOA, c'est-à-dire les stéréotypes : « Service » (correspondant au stéréotype « Control » d'UML standard), « Interface » (pour le stéréotype « Boundary » du profil standard) et « XML » (pour les objets métiers stéréotypés « Entity »).

Les modèles sont complétés manuellement et certains diagrammes personnalisés (WSDL) sont construits afin d'enrichir la génération de code.

Illustration 99 : Composants de la démarche MDA aboutissant aux étapes de réalisation

2.6.1.2 Rappel du concept de Processus

Le processus est un outil de communication entre la MOA et la MOE. Les interfaces sont autant de composants qui permettent aux acteurs métier d'accéder à l'information. Pour ce faire, des solutions de type « portail » sont utilisées. Ces interfaces accèdent aux processus métier, qui entremêlent à la fois des tâches humaines et automatiques (domaine de prédilection des outils BPEL). Ces interfaces d'accès listent les opérations exposées par les services métiers, tout en restant indépendantes des ressources applicatives (domaine des outils WSDL). Ces opérations utilisent les objets pivots comme paramètres de travail. Les services dits de « données » ou CRUD, accèdent aux ressources applicatives en mode Create, Read, Update, Delete. Ceux sont les CRUD qui interagissent sur les objets métier typés « Entity ». Les ressources sont à la fois des bases de données, des mainframes ... Pour ce faire, les connecteurs adaptés servent de passerelle entre ces ressources et les services (exemple : connexion JDBC pour accéder à une base Oracle). D'autres services, cette fois appelés « services techniques », dont la granularité est plus fine et souvent transverse, permettent par exemple de gérer l'authentification, les appels à la messagerie, les besoins d'impression, les transferts FTP... Il est possible de combiner des services techniques avec des CRUD, on parlera alors de services composés.

La zone d'échange que représente l'ESB permet quant à elle aux différents composants de s'articuler et de communiquer les uns avec les autres. Dans ce mémoire, nous ne nous cantonnons pas à l'appel des services par la seule zone d'échange qu'est l'ESB. Depuis quelques années, de nouveaux concepts d'architectures apparaissent dans la mouvance de la SOA : WOA, Saas, Cloud Computing, Mashup... Même si techniquement ces nouvelles offres se distinguent, la philosophie SOA reste bien présente au travers de ces services en ligne. Dans cet esprit, le composant OWA d'Oracle permet à partir d'un browser d'appeler n'importe qu'elle procédure exposée nativement (protocole REST) d'un quelconque gisement de donnée en version 11G. La modélisation à venir doit aussi intégrer les services en ligne en dehors de l'ESB.



Illustration 100 : Composants SOA : Objets pivots et métiers, interfaces et services

Le langage de modélisation des processus métier est le BPMN. Le diagramme permet de déterminer l'ordre d'exécution des tâches ainsi que les messages échangés. Cette vue macroscopique correspond à la toute première étape de la démarche MDA. Cependant, une cartographie cible permet de définir les composants majeurs tels que les participants et les composants de l'architecture SOA cible.

2.6.2 Vue Métier ou la phase CIM de MDA

2.6.2.1 Définition de la cartographie cible

Une cartographie de la cible permet de camper les fondamentaux retenus. Elle doit respecter les règles d'urbanisation définies par Longépé^148(*) [LOG-PUR] :

q Une architecture fonctionnelle comporte une zone échange représentant la prise du SI,

q Toute architecture fonctionnelle comporte une zone gisement de données : elle regroupe les informations dynamiques ainsi que les services d'accès à ces données,

q Toute architecture fonctionnelle comporte une zone « référentiel de données » regroupant les informations communes aux différents éléments stables du système d'information,

q Toute architecture fonctionnelle comporte une zone de pilotage unique,

q Toute architecture applicative comporte une zone d'ordonnancement qui assure l'interface entre le front office, le back office et le middle office.



Illustration 101 : Cartographie cible Selon les règles de Longépé

Il s'agit de l'objet « métier » c'est-à-dire des informations durables et persistantes.

Cet objet de contrôle assure la coordination d'autres objets : entre objet <<Boundary>> et <<Entity>>) et les extractions en base et les calculs nécessaires.

L'objet d'interface se trouve à la frontière entre le système et un participant au processus. Certaines de ses propriétés sont publiées.

Les objets sont stéréotypés en trois responsabilités distinctes :



Illustration 102 : Les trois types d'objets selon Jacobson^149(*)

Les gisements de données peuvent jouer deux rôles : Fournisseurs et/ou Consommateurs. Ils constituent des objets composites dans le sens où ils sont constitués de CRUD (Services de données), de composant de transport (FTP par exemple), c'est-à-dire autant d'objets « Control » et de données ou objets dits « Entity ». Les CRUD sont multiples et peuvent jouer eux aussi de multiples rôles : extraction, chargement, suppression, mise à jour etc ... La zone d'échange peut être un ESB, ou demain un nuage de service ou toute autre solution dans la mouvance SOA. Le Portail propose les objets d'interface, c'est-à-dire de type « Boundary ». Lorsque deux objets « Control » sont assemblés, cela signifie l'existence d'une interface entre ces deux objets communiquant.

Zoom sur les composants de la cartographie

Rappel sur les composants :

On dit qu'un composant est réutilisable dans le sens où il fournit un service précis sans être lié à un projet déterminé. La notion de composant est en soi un niveau supplémentaire d'abstraction. Il peut ainsi s'agir de traitements applicatifs qui se transforment en entité capable d'exposer ses « services », de services transverses et techniques comme un Framework, des outils de communication. De façon générale ces composants peuvent correspondre à des données, des outils permettant de transformer ces données, ou alors à des outils de connexion.

2.6.2.2 Modélisation des cas d'utilisation

La cartographie cible est volontairement ouverte car, tout en respectant les règles d'urbanisation de Longépé, elle rend possible l'intégration aujourd'hui des Tiers, et demain, de toute autre entité dans le processus global d'alimentation applicatif.

La zone d'échange, ici un ESB, est constituée principalement de deux composants :

q Un composant de transformation qui a la responsabilité de valider le contenu d'un document entrant, quelle que soit sa nature, et de le transformer à partir d'une zone de médiation entre le format source et les différents formats cibles,

q Un composant de transmission qui déterminera le routage de chaque message.

Les participants à cette cartographie sont « le fournisseur », la zone d'échange « ESB » et « le consommateur ».



Illustration 103 : Cas d'utilisation obtenu par lecture de la cartographie cible

L'ESB est également amené à couvrir l'ensemble des besoins d'échange futurs entre les applications du SI. Ainsi d'autres composants pourront venir s'y ajouter au fil du temps. La cartographie doit rester extensible aux services des solutions logicielles d'avant garde (GRC par exemple).

2.6.2.3 Modélisation du Diagramme BPMN

Ainsi, BPMN constitue la seule notation normalisée qui rend possible le dialogue entre MOA et MOE. Ce modèle de processus métier est en quelque sorte l'esperanto du processus. Outil graphique, il nécessite que des règles de collaboration entre MOA et MOE soient bien définies. Il s'agit là d'une vue métier très orientée « Système d'information ». La disponibilité de la ligne est prise en compte dans le scénario de transfert.

Un diagramme BPMN est composé d'un ensemble de tâches, de sous processus, de différents types d'évènements intermédiaires ou non, de passerelles, de flux de séquence, de flux de messages, de flux de compensation, et de participants.



Illustration 104 : Diagramme BPMN réalisé sous Magicdraw

Une fois ce diagramme obtenu, il est d'ores et déjà possible de générer une ossature BPEL (cf Vue Technique) à condition qu'il soit valide. Pour cela, il doit respecter certaines règles, une grammaire spécifiée dans le document du BPMN^150(*).

2.6.3 Vue logique ou la phase PIM de MDA

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

Le diagramme de Classes donne une représentation statique d'un système constitué d'objets logiques assimilables à des classes, en lien les uns avec les autres.

Il est composé de packages, de classes, d'attributs et d'opérations de classes, d'associations, de compositions, d'agrégation et de généralisation entre classes. Le passage du BPMN au diagramme de Classes intègre que :

q Les participants du diagramme BPMN se répartissent les tâches du processus. Ils constituent en quelque sorte l'organisation du processus. Ce rôle d'organisation est pris en charge du côté UML par les packages.

q Les flux de message échangés entre participants sont porteurs d'entités, d'objets métiers tels que les Adresses, les Rib, les Tiers ... La structure de ces objets peut évoluer entre le fournisseur et le consommateur du flux de message. C'est pourquoi, ce dernier est traduit en deux classes distinctes dans le diagramme de Classes UML.





Illustration 105 : Diagramme de classe obtenu à partir du BPMN

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

Le diagramme d'Etats-Transitions décrit les changements d'états d'un objet métier. Il est constitué d'un et un seul état initial et de plusieurs états finaux. Chaque changement d'état correspondant à un changement d'une de ces caractéristiques internes.

Il est constitué d'un ensemble d'états, de transitions, de passerelles ouvrantes et fermantes, de choix, d'un état initial et d'états finaux. Pour générer le diagramme d'Etats-Transitions :

q L'exécution d'une tâche du BPMN, fortement liée à un objet métier, peut modifier une des caractéristiques de ce dernier. Les tâches permettent de créer l'objet, de le modifier, de l'acheminer et constituent donc un état du diagramme UML d'Etats-Transitions,

q Les passerelles de condition « OR » ou « XOR » dans le diagramme BPMN, correspondent à des possibilités de transitions en fonction de certaines conditions, et donc à des choix,

q Les flux de messages BPMN entre tâches fortement liées à un objet sont eux aussi assimilables à des transitions d'états,

q



Les passerelles « AND » BPMN correspondent au niveau du diagramme d'Etats-Transitions à des unions (si fermantes) ou des bifurcations (si sortantes).



Illustration 106 : Diagramme d'Etats Transitions obtenu à partir du BPMN

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

Le diagramme de Séquences illustre les messages échangés entre participants qui collaborent ensemble afin de réaliser un objectif. Il présente de façon séquentielle, de haut vers le bas, ces messages échangés. Les participants sont représentés dans ce diagramme par un trait vertical appelé « ligne de vie ».

Le diagramme de Séquence est composé d'un ensemble de lignes de vie, de messages synchrones ou asynchrones, d'exécution et de signaux. Pour générer un diagramme de séquence à partir d'un diagramme BPMN :

q Un flux de message entre deux tâches BPMN met en oeuvre deux ressources du système. Ces tâches correspondent à des lignes de vie et le flux de message entre elles. Ces flux jouent le rôle de message synchrone ou asynchrone du diagramme de Séquences.







Illustration 107 : Diagramme de Séquences obtenu à partir du BPMN

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

Le diagramme d'Activités ressemble beaucoup au diagramme BPMN car il illustre l'enchainement ordonné des différentes activités du processus. Il utilise des unités organisationnelles, des « partitions », afin de classer les activités par participant, et des opérateurs de choix qui permette de définir des branches d'activités spécifiques à certains contextes. Le début et la fin du diagramme d'activité sont traduits par des opérateurs d'évènements. Entre ces deux objets, s'enchainent un ensemble d'activités, de choix, d'unions, de bifurcations, de flux de contrôle, de commentaires et ce, pour un ensemble de partitions. La génération d'un diagramme d'activité se fait donc sur la base d'un formalisme très proche du BPMN :

q L'élément BPMN « typé » qui ne se retrouve pas à l'identique dans le diagramme d'activité:





q Correspondance sémantique avec le diagramme d'Activités pour les autres éléments BPMN.





Illustration 108 : Diagramme d'Activités obtenu à partir du BPMN

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

Ce qui caractérise les diagrammes UML est leurs fortes dépendances les uns vis-à-vis des autres. Pour que la cohérence soit garantie entre les branches métier et logiques de la démarche MDA, la conception doit pouvoir être réalisée sur la base de règles de transformation inter-diagrammes. Cela revient à impacter le méta modèle sur la base de règles de transformation propre à chaque « passerelle » BPMN - diagramme UML concerné (par exemple : BPMN - Diagramme de Classes, BPMN - Diagramme de Séquences etc ...). Cet impact est variable selon l'affinité sémantique entre le modèle source (BPMN) et le modèle cible (un des diagrammes UML). Il apparaît alors un début de concept d'interopérabilité sémantique associé aux modèles. Il s'ajoute aux autres types d'interopérabilités propres à la SOA : ceux des outils et des données.

Interopérabilité des Modèles

SOA

Interopérabilité technique

Interopérabilité des Données

Illustration 109 : SOA, une architecture interopérable

Cependant, ce concept est loin d'être abouti, car d'une part, l'isomorphisme n'est pas complet et d'autre part, les diagrammes générés peuvent parfois paraître pauvres : les attributs des classes, les règles de gestion n'apparaissant pas dans le BPMN, et ne figurent pas dans les diagrammes découlant du modèle BPMN. Il faut alors revenir sur ces diagrammes consécutifs et les enrichir pour obtenir un niveau d'information satisfaisant. C'est pour cette raison que dans ce mémoire, le terme d' « ossature » est souvent utilisé, ceci faisant appel à un besoin d'enrichissement à posteriori. Néanmoins, des moteurs de règles (aussi appelés BRMS) apparaissent dans les offres du marché. Nul doute que BPM et BRMS^151(*) trouverons rapidement des axes de convergence afin d'offrir des solutions permettant d'offrir une vue métier exhaustive. Pour ce qui est de la problématique des attributs, il faut maintenant explorer la modélisation des entités à partir desquelles sont constitués les messages : Tiers, Rib, Adresse, Solde ... puis impacter les règles de gestion au sein de cette modélisation.

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

On aurait pu s'interroger sur les types de données qui constituent aujourd'hui l'entité « Tiers ». Comme le montre la cartographie du processus d'alimentation des Tiers, plusieurs tables temporaires, situées au niveau du référentiel Terrena (GCAT), rassemblent une partie des informations : SQGCTIERS, SQGCINTF (et *_user), SQGCARCO (et *_USER), SQGCTIERS etc ...). Une des tables qui semble rassembler la vue la plus complète d'un tiers est probablement la table SQGCTIERS. Cette table fait l'objet d'une génération d'un fichier à plat, transféré par FTP sur les serveurs et répertoires où viennent les consommer les applications principalement de gestion commerciale. Cependant, les données tiers ne se limitent pas aux informations générales, aux relevés d'identité bancaire (RIB) et aux adresses, et donc au référentiel Terrena appelé GCAT. C'est ainsi que des informations liées à l'activité économique du tiers sont gérées dans d'autres applicatifs : comme Terpart (comptabilité auxiliaire des partenaires de la Coopérative) qui tient à jour la notion de solde de tout partenaire. Mais on s'aperçoit vite de la multiplicité des sources d'information de l'entité aussi transversale qu'est la notion de TIERS. Ces différentes ressources applicatives représentent autant de Fournisseurs. On peut rappeler que l'exposition du service offerte au client n'indique pas la provenance des informations livrées. C'est le rôle de l'orchestration de veiller au bon déroulement du processus.

Processus

Ressources

Composants









Illustration 110 : Interaction Processus-Composants-Ressources

Aussi faut il faire table rase de l'existant et construire le format pivot des tiers Terrena.

Constituer une ontologie Groupe pour les Acteurs permettra par la suite de faire cohabiter et correspondre plusieurs ontologies issues des filiales. En effet, les échanges de données mixeront une information structurée spécifiquement en fonction de chaque système d'information. L'introduction de classes équivalentes permet de mapper les noeuds des N ontologies et rend possible leur intégration dans un référentiel commun. Ce vocabulaire et les propriétés associées constituent une partie de la connaissance commune et facilitent les échanges avec l'extérieur. Se construisent alors un vocabulaire métier et une sémantique Groupe.



Illustration 111 : Début d'ontologie réalisée avec Protégé^152(*)

Ici le référentiel commun est l'ontologie Acteur de Terrena sur laquelle a été mappée l'ontologie Tiers de la filiale Gastronome. Ainsi les tiers « CLNT » de Gastronome sont équivalents sémantiquement aux acteurs « Client_identifié » de Terrena, traduit dans le document Owl par :

<Ontology xmlns="http://www.w3.org/2006/12/owl2-xml#"

xml:base="http://www.w3.org/2006/12/owl2-xml#"

xmlns:owl2xml="http://www.w3.org/2006/12/owl2-xml#"

xmlns:xsd="http://www.w3.org/2001/XMLSchema#"

xmlns:Gastronome="http://www.semanticweb.org/ontologies/2009/3/Ontology/Gastronome.owl#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:terrena="http://www.semanticweb.org/ontologies/2009/3/Ontology/terrena.owl#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:owl="http://www.w3.org/2002/07/owl#"

xmlns:="http://www.w3.org/2006/12/owl2-xml#"

URI="http://www.semanticweb.org/ontologies/2009/3/Ontology/terrena.owl">

<EquivalentClasses>

<Class URI="&Gastronome;CLNT"/>

<Class URI="&terrena;Client_identifi&#233;"/>

</EquivalentClasses>

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

_

La démarche consiste à rechercher les schémas W3C déposés par des organismes reconnus. Quand on aborde la notion de tiers, il vient immédiatement à l'esprit deux typologies distinctes : la personne physique (Monsieur Dupont) et la personne morale (Dupont et Fils). Aussi, rechercher un schéma qui ferait l'unanimité en termes de personnes morales et physiques, revient à chercher un espace de nom reconnu. Parmi ceux là il est possible de retenir les schémas W3C de l'INSEE^.

Illustration 112 : Extrait xml de la personne morale

(Source : http://xml.insee.fr/schema/)

_

Il en va de même pour l'adresse, dont le schéma est lui aussi déposé sur le site de l'INSEE mais dont les spécifications ont été élaborées par La Poste. En la matière, cet organisme définit plusieurs typologies d'adresse (à noter qu'une adresse géo postale peut être soit une adresse géographique ou postale).

Illustration 113 : Typologies d'adresse référencées par l'INSEE présentées via XmlSpy

Le site de l'INSEE a élaboré son schéma à partir de modules propres ou eux-mêmes déposés par d'autres organismes (ISO par exemple) :

q Module commun : définition de types de base utilisés par les autres modules,

q Module SIRET : identification des entreprises et des établissements (numéros SIREN et SIRET),

q Module NIR : identification des personnes physiques (numéros NIR et dits "de sécurité sociale"),

q Module ISO : identification des pays et territoires, et ISO - énumération qui offre la liste des valeurs acceptables pour les différents codes,

q Module COG (Code officiel géographique) : codes du Code Officiel Géographique (codes des régions et départements), et COG - énumération qui offre les listes des valeurs acceptables pour les différents codes,

q Module NAF : codes de la Nomenclature d'Activités Française (NAF), et NAF - énumération qui offre la liste des valeurs acceptables pour les différents codes,

q Module CJ (Catégories juridiques) : codes des catégories juridiques des entreprises, et CJ - énumération qui offre la liste des valeurs acceptables pour les différents codes,

q Module PCS (Professions et catégories socioprofessionnelles) : codes de la nomenclature des professions et catégories socioprofessionnelles 2003, et PCS - énumération qui offre la liste des valeurs acceptables pour les différents codes,

q

_

Module Adresse : types et éléments permettant de représenter des adresses géographiques ou postales, spécifications de LA POSTE,

q Module Individu : types relatifs à l'état civil des personnes physiques.

Illustration 114 : Inclusion de Module d'information

(Source : http://xml.insee.fr/schema/)

Les énumérations complètent la définition des différents modules en précisant les listes des valeurs acceptées. Cela concerne les données géographiques telles que les codes postaux, les communes, les pays mais aussi les formes juridiques, modes de communication et toute autre information de référence liée à l'individu.

_

Illustration 115 : Représentation XmlSpy d'un Xml Schema de la Personne Physique selon l'Insee

Certaines classes de ce modèle seront intégrées en l'état dans le format pivot cible telles que les adresses (pays, localité, codes postal), les activités, les Siret, les catégories juridiques et l'individu.

Mais la réalité de la coopérative requiert une recherche approfondie en termes de classes de données.

Ontologie spécifique au monde rural : Le Projet GIEA

Terrena est une coopérative qui entretient des échanges tout aussi bien avec des personnes physiques (exemple : la livraison de Fuel) qu'avec des personnes morales appartenant principalement au monde rural (exemple : la vente de Semences). Aussi, une recherche de brique sémantique propre au monde agricole a été opérée afin de définir un modèle proche de la réalité de la Coopérative Terrena. Pour répondre à cette problématique, le projet GIEA^153(*) semble avoir cherché à répondre au même besoin en 2006. Ses objectifs sont énoncés de la manière suivante :

q « Fédérer et coordonner les travaux de standardisation menés par les différents organismes et institutions de la sphère agricole,

q Définir un cadre cohérent de définition (format et contenu) des informations pour les agriculteurs,

q Rendre « interopérables » les systèmes d'information publics et privés existants ».

Les partenaires de ce projet visant à définir les données permanentes de l'exploitation sont à la fois le Ministère de l'agriculture et de la pèche, les Chambres d'Agricultures, le Cemagref, l'Ademe, l'INRA, AgroEdi, Coop de France etc ... Ensemble, ils ont défini l'exploitation agricole et ses activités.

Bon nombre de classes de ce modèle GIEA ont été reprises dans le diagramme de classe du processus d'alimentation des Tiers Terrena. Cependant, les spécificités de la Coopératives ont quant-à elles fait l'objet d'ajouts et de complément d'attributs afin de répondre à l'ensemble des besoins.

L'objectif est de proposer un diagramme de classe qui va présenter le modèle de données du SI Tiers.

Analyse des Classes du référentiel Tiers

La classe maîtresse à l'ensemble du diagramme est sans nul doute la classe Tiers. Ce tiers est rattaché à une personne physique ou morale. Dans le cas d'une personne morale, il peut s'agir d'une exploitation agricole ou d'une entreprise non agricole.

Définition de l'exploitation agricole



E

xploitation Agricole :

Dans le recensement agricole, l'exploitation agricole est définie comme une unité de production remplissant les trois critères suivants :

- Produire des produits agricoles,

- Avoir une gestion courante indépendante,

- Atteindre un certain seuil en superficie, en production ou en nombre d'animaux.

Ce seuil a été défini de la façon suivante :

- une superficie agricole utilisée au moins égale à un hectare,

- ou une superficie en cultures spécialisées au moins égale à 20 ares,

- ou une activité suffisante de production agricole, estimée en cheptel, surface cultivée ou volume de production. INSEE.

(Source : http://www.insee.fr/fr/methodes/default.asp?page=definitions/exploitation-agricole.htm)

Attributs et principales relations définissant l'exploitation agricole

Note sur les attributs de classes :

q Les attributs en italique sont hérités d'un concept générique.

q Le statut des attributs est de deux types : O = obligatoire. F = facultatif.

q Le format des attributs est de cinq types : A = alphanumérique. N = numérique. B = booléen. D = date. DH = date et heure.

q Longueur de caractères : A..9 (jusqu'à neuf caractères) ou A9 (exactement neuf caractères).

Remarque : Quatre attributs dits « de traçabilités » sont systématiquement associés à toute classe : Date-heure de création, utilisateur de création, Date-heure de dernière modification, utilisateur de dernière modification.

En annexe, se trouvent les listes, c'est-à-dire les énumérations de valeur (exemple CJ).

Un tiers est soit une personne morale, soit une personne physique. Dans le cas d'une personne morale, il faudra préciser la nature agricole ou non agricole de la personne.

Nom attribut de l'exploitation	Statut	Format	Liste
Forme juridique	O	N..4	CJ
Date de création	F	D
Date de clôture	F	D
Nationalité	F	A..2
Effectif salarié	F	N..6

Le Nom de l'exploitation est un attribut obtenu par héritage de la classe de généralisation « TIERS ».

Relations de la classe Exploitation

q Adresse : un partenaire, une exploitation agricole ou non agricole, une personne physique dispose d'au moins une adresse. Le module de l'adresse géo postale (retenue par La Poste et validée dans la norme AFNOR XPZ 10-011) sera utilisé dans notre diagramme de classe :

Nom attribut	Statut	Format		Liste	Type adresse
O	A..20	TA		Point de remise
F	A..38			Complément au point géographique
F	A..38			Voie
F	A..38			Lieu-dit
F	A..38			Code postal
O	N5	CP		Localité
O	A..32	LL		Pays
F	A..2	LP

q Moyen de communication: un partenaire, une exploitation agricole ou non agricole, une personne physique peuvent être contactés à l'aide d'un ou de plusieurs moyens de communications (téléphone, fax, E-mail, Site, etc ...).

Nom attribut	Statut	Format		Liste	Type de moyen
O	A..30	TC		Identifiant
O	A..255

q Lien fonctionnel : une personne morale (agricole ou non agricole) est liée à une ou plusieurs personnes physiques par un lien fonctionnel (contact coopérative, technicien, représentant légal, etc ...). De même deux personnes physiques peuvent être liées ensemble (apparenté à, associé de ...).

Nom attribut	Statut	Format		Liste	Type de lien
O	A..100	TL		Date de début du lien
F	D			Date de fin du lien
F	D

q Lien historique : une personne morale peut être liée à une ou plusieurs personnes morales par un lien historique (exemple : cédant, cessionnaire pour les exploitations agricoles),

Nom attribut	Statut	Format		Liste	Nature du lien
O	A1	NL		Date d'effet
O	D

q Activité : une exploitation agricole peut exercer une ou plusieurs activités (céréales, élevage, vin etc ...). L'Article L331-1 du Code Rural définit une activité agricole de la façon suivante : « Sont réputées agricoles toutes les activités correspondant à l'exploitation d'un cycle biologique de caractère végétal ou animal (...) ainsi que les activités exercées par un exploitant agricole qui sont dans le prolongement de l'acte de production ou qui ont pour support l'exploitation (...) ».

Nom attribut	Statut	Format		Liste	Activité
O	A..20	CA		Produit
F	A..20			Mode de production
F	A..20			Date de début de l'activité
O	D			Date de fin de l'activité
F	D

Le produit est un attribut qui permet de préciser l'activité. S'il est multiple, il faudra définir autant d'occurrences activités que de produits.

q Immatriculation : une personne morale ou physique est identifiée par une immatriculation (SIRET/SIREN) faite auprès de l'INSEE ou d'une autre immatriculation obtenue auprès d'autres organismes (ONIC, ONIOL, COOPERATIVE) ou applications internes (Paie, Comptabilité). Les immatriculations d'une personne peuvent être multiples (code INSEE : Siret et Siren, Code Tva Intra communautaire, Code Onic, etc ...).

Nom attribut	Statut	Format		Liste	Identifiant
O	A..20			Code organisme
O	A..20	CO		Date de début de validité
F	D			Date de fin de validité
F	D

q Mesure : un tiers peut être associé une ou plusieurs mesures (Capital, SAU, STH...) facultatives.

Nom attribut	Statut	Format		Liste	Valeur
O	A..255			Méthode de mesure
F	A..255			Code Groupe Mesure
O	A..20	GM		Code Unité de Mesure
O	A..20	UM

Spécificités Terrena

q Partenaire : Un partenaire est une entité supérieure regroupant plusieurs tiers appartenant à la même organisation. Ces tiers peuvent être à la fois des personnes physiques et des personnes morales, agricoles et/ou non agricoles.

Nom attribut	Statut	Format		Liste	Identifiant
O	A..20			Nom
O	A..100			Date de début de validité
F	D			Date de fin de validité
F	D

q Accès : un partenaire peut être détenteur d'un compte lui permettant d'accéder à l'extranet par exemple, mis à disposition des adhérents (un compte peut lui permettre de jouer un ou plusieurs rôles).

Nom attribut	Statut	Format		Liste	Identifiant
O	A..20			Rôle
O	A..20			Date de début de validité
F	D			Date de fin de validité
F	D			Adresse
O	A..100

q Relais approvisionnement, Relais céréales: La coopérative associe un lieu appelé Relais à tout tiers de type « exploitation Agricole ». Ce lieu est en soit une adresse à laquelle se rend le tiers pour effectuer ses dépôts de céréales ou ses achats de matières premières. Il serait ainsi géré comme une adresse géo postale d'un type particulier (Relais Appro ou Relais Céréale).

q Les conditions de règlement sont considérées comme des mesures.

q Le solde, c'est à dire la situation comptable d'un tiers à un instant donné, est elle aussi, une mesure. Contrairement aux autres données, la ressource applicative ayant la connaissance de ce solde n'est pas le référentiel Terrena GCAT mais l'application Terpart.

On distingue ainsi trois niveaux d'ontologie :

q un niveau « public » partagé par des organismes reconnus tels que l'ISO, l'INSEE, La Poste,

q un niveau «métier » spécifique au monde rural et agricole en particulier (projet GIEA)

q et enfin un dernier niveau « privé », relatif à la connaissance et à la gestion applicative des mouvements agricoles Terrena.

L'objectif va consister à modéliser un diagramme de classe UML regroupant ces trois niveaux ontologiques.

Ontologie Publique

Tiers

Ontologie Privée (Terrena)

Ontologie Métier (GIEA)

Illustration 116 : Tiers, une Ontologie à trois niveaux



Illustration

Illustration 117 : Diagramme de Classe des Tiers réalisé sous MagicDraw

Ce diagramme de classe concerne les « données » de notre étude de cas. Il rassemble l'ontologie propres aux organismes publics (Adresse, Personne Morale, Personne Physique, Activité) ainsi que l'ontologie métier, liée au monde rural (Lien fonctionnel, Mesure, Immatriculation) et l'ontologie pribée, propre à nos applicatifs (Accès, Moyen de communication). Les énumérations correspondent aux valeurs possibles de certains type ou nature d'information (exemple : la civilité peut prendre trois valeurs : Mme, M ou Melle)...Elles sont, quand cela est possible, extraites des énumérations officielles (Insee par exemple).

Remarque : Les classes d'association concernant les liens fonctionnels et historiques ne font pas l'objet de génération de code (au niveau du schéma XML). Les deux classes correspondantes ont été ajoutées pour intégrer ces attributs au XSD.

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

2.6.4.1 Le BPEL

Ce langage d'exécution pour l'orchestration du processus. Il est constitué de balises dont l'une d'elles « <SEQUENCE> » permet de contenir des actions et leur structure. Il est directement issu du diagramme BPMN.

<sequence>

<receive createInstance="yes" name="Arrivée d&#39;un message" operation="dfltOperation" partner="" partnerLink="dfltPartnerLink" portType="dfltPortType" variable=""></receive>

<receive createInstance="no" name="Polling" operation="dfltOperation" partner="dfltPartner" partnerLink="dfltPartnerLink" portType="dfltPortType"></receive>

<invoke inputVariable="VQTIERS.xml" name="To_grc" operation="dfltOperation" outputVariable="GRC.xml" partner="dfltPartner" partnerLink="dfltPartnerLink" portType="dfltPortType"></invoke>

<switch name="Erreur ?">

<case condition="oui">

<invoke inputVariable="" name="Alerter" operation="dfltOperation" outputVariable="" partner="dfltPartner" partnerLink="dfltPartnerLink" portType="dfltPortType"></invoke>

<throw faultContainer="" faultName="" name="Erreur de transformation"></throw>

</case>

<otherwise>

<receive createInstance="no" name="FileTrigger" operation="dfltOperation" partner="dfltPartner" partnerLink="dfltPartnerLink" portType="dfltPortType"></receive>

<invoke inputVariable="GRC.XML" name="FtpTransfert" operation="dfltOperation" outputVariable="req_GRC.XML" partner="dfltPartner" partnerLink="dfltPartnerLink" portType="dfltPortType"></invoke>

<switch name="">

<case condition="ko">

<empty name="Ftp secouru"></empty>

<otherwise/>

<empty name="Archiver"></empty>

<invoke name="GRC%d.xml" operation="dfltOperation" partner="" partnerLink="dfltPartnerLink" portType="dfltPortType"></invoke>

</case>

</switch>

</otherwise>

</switch>

</sequence>



Illustration 118 : BPEL réalisé sous Magicdraw à partir d'un diagramme BPMN valide

2.6.4.2 Le document XSD du format Pivot

La sortie au format XMI du méta modèle UML s'obtient nativement par l'utilisation d'une fonctionnalité proposée par l'outil de modélisation (ici : MagicDraw V15). Ensuite il faut parser le document XMI afin de générer un fichier XSD. Le XMI peut aussi être utilisé pour transmettre ce travail de conception à un outil plus élaboré permettant de chaîner des opérations de transformation et de génération de code. Une autre solution, plus simple, consiste à profiter d'une fonctionnalité de transformation parfois offerte par les modeleur UML. Par exemple, il est possible de bénéficier d'une fonctionnalité de Transformation d'UML vers XML à partir de la version Enterprise de MagicDraw. Un mapping des primitives UML avec les primitives XML rend possible cette transformation du modèle UML vers le modèle XML (MOF uml). Un code d'ingénierie est alors créé et rend possible le déploiement des objets dans un des environnements supportés, tels que Java, C+, C#, Corba, DDL, XML, ou WSDL... Ce code ne constitue qu'une ossature, qu'un squelette qu'il faut ensuite habiller (préciser les occurrences minimum et maximum, l'ordre de regroupement des éléments ...)

Mécanisme de transformation entre le profile UML standard et le Profil Xml154(*)

L'attribut UML :

q Si sa multiplicité minimale = 0 alors il est optionnel, ce qui correspond à la valeur par défaut.

q Si sa multiplicité minimale = 1 alors il est obligatoire.

q Si sa multiplicité minimale > 1 alors il correspond à une liste dont le nombre de valeurs obligatoire correspond à la multiplicité minimale.

q Si sa multiplicité maximale = 1 alors il n'a qu'une seule valeur (valeur par défaut).

q Si sa multiplicité maximale > 1 alors il correspond à une liste de valeurs.

Un attribut UML est traduit en attribut (lorsqu'il est simple) ou un élément XML (lorsqu'il est multiple). Ces multiplicités sont exprimées en XML par les éléments minOccur et maxOccur. Le caractère optionnel d'un attribut XML se traduit par « use= « optional » » contrairement au caractère obligatoire « use = « required » » ou à l'appel d'une liste « use = « moyen_type ». Une liste XML peut être limitée en terme d'occurrences par « maxLength value = «n» » où « n » représente la longueur maximal de la liste (un critère « minLength » permet inversement de préciser la longueur minimale de la liste).

Et pour le reste de la transformation :

q La valeur par défaut UML se traduit par le critère « default » dans la représentation XML.

q Les annotations UML trouvent aussi leurs places dans la représentation XML grâce au critère « documentation ».

q Les types de données hérités par la classe sont de type primitif string.

q La contrainte {xor} définit une exclusion entre deux associations (l'une ou l'autre est vraie, mais pas les deux pour le même élément). Le critère XML « Choice » permet de gérer cette alternative

q La contrainte {Simultanéité} entre deux associations définit que l'activation d'une des deux associations entraîne l'activation de l'autre obligatoirement (par exemple dans notre cas, l'ouverture d'un accès internet ne se fait qu'à condition d'une adresse Email ouverte pour le tiers afin de lui communiquer les éléments de connexion). C'est le critère « Group » XML qui permet de prendre à charge de contrainte de représentation.

La limite de cette transformation assistée est probablement la notion d'ordre des éléments qui fait partie de la vérification des documents XML par les Schémas XML. Cette notion ne connaît pas d `équivalence dans le modèle UML dont l'ordre naturel correspond tout d'abord aux éléments de généralisation, aux attributs et aux associations. Cette contrainte fera ainsi l'objet d'une retouche manuelle du modèle XML. Pour résoudre ce problème, le critère « SequenceOrder » sera appliqué au modèle XML.



Illustration 119 : Diagramme XML réalisée à partir d'un diagramme de classes au profil UML standard

Les balises « use », permettant de définir le caractère obligatoire ou facultatif d'un élément, ne sont pas générées automatiquement par le modeleur utilisé. Aussi cette manipulation s'ajoute à celle concernant les balises d'occurrence, à l'ordre des séquences et aux annotations non répercutés dans le code.



Illustration 120 : Adaptations manuelles impactées au modèle XML

<?xml version='1.0' encoding='windows-1252'?>

<schema xmlns="http://www.w3.org/2001/XMLSchema">

<simpleType name="Moyen_type">

<restriction base="string">

<enumeration value="FTP"/>

<enumeration value="Telephone_mobile"/>

<enumeration value="Telephone_fixe1"/>

<enumeration value="Fax"/>

<enumeration value="URL"/>

<enumeration value="Email"/>

<enumeration value="Telephone_fixe2"/>

</restriction>

</simpleType>

<complexType name="Moyen_communication">

<sequence/>

<attribute default="Telephone_fixe1" name="Type_moyen" type="Moyen_type" use="optional"/>

<attribute name="Identifiant" type="string" use="optional"/>

</complexType>

</schema>

2.6.4.3 Le Wsdl

Les WSDL constituent les interfaces des services. Ils découlent naturellement des diagrammes d'Activités. Les activités peuvent être stéréotypées « Service » ou « Interface » dans le cadre d'une architecture SOA. Une interface fait appel à un service, mais un service n'est pas forcément exposé et donc objet d'une interface (exemple : service interne tels qu'un service de transport). Cibler les WSDL revient donc à identifier les besoins d'interface.



Illustration 121 : Exposition d'un service pour le consommateur

Ici, le consommateur dispose d'une interface d'accès au service d'extraction de données qui constitue un CRUD. Cette interface propose toutes les opérations disponibles pour cet accès. Le fournisseur quant à lui, détecte l'appel et exécute le CRUD correspondant à l'opération choisie (extraction de tiers par exemple).



Illustration 122 : Interface entre le composant de détection de fichier et le composant de transformation

Ici, l'ESB doit combiner l'action de deux composants : le premier composant détecte la présence d'un message, et le second le transforme. Ce couple est plus complexe puisqu'il renferme une transformation et donc une structure source et une structure cible différente. Mais il renferme aussi une interface car : « composant A » assemblé « composant B » => une interface.

Pour modéliser une interface de service, il faut donc d'abord s'intéresser aux services eux-mêmes.

Modélisation d'un WSDL pour un service CRUD

Les CRUD, ou services de données, détiennent les règles de gestion propres à un ou plusieurs objets métier (Tiers, Adresse, Solde ...) pour lequel ils détiennent la responsabilité d'accès. Ils renferment les opérations qui vont permettre de lire, de supprimer, de modifier ou de créer des données, mais également d'effectuer d'autres opérations plus complexe (recherches, mise en forme, agrégations etc ...). A ce stade il faut s'assurer que les CRUD soient les plus standardisés possible par rapport au Système d'information, afin de ne pas reproduire les travers connus au niveau des silos de données (la multiplicité des objets plus ou moins redondants est un frein à l'agilité).



Illustration 123 : Exemple de modelisation d'un service de données ou CRUD

Il a été décidé que les opérations de préparation (PreparerAdresse, preparerInfo_Generales, PreparerRIB) soient réunies dans un seul service d'extraction qui, enrichi de paramètres d'entrée, pourra tantôt préparer les adresses, tantôt les RIB ou les Information générales d'un tiers. Ce service fait l'objet d'une fiche comme tout autre service afin de constituer le catalogue des services disponibles.

Entête
Nom	EXTRACTION
Définition	A partir d'un objet tiers Pivot correspondant au paramètre P1, extraire l'ensemble des information de l'entité respectant la clause Where (P7), dans l'ordre précisé par le paramètre P8.
Type (Crud ou service Composé)	CRUD
Objet(s) utilisés	P1
Version	1.0
RACI
« Responsible » en charge des modifications à apporter aux services
« Accountable » en charge de la gestion du contrat
« Consulted » à consulter avant d'apporter une modification au contrat
« Informed » à informer de la modification du contrat.
Opérations
Nom	EXTRACTION
Objets Pivots (paramètres)	P1
Règles de Gestion	Nom not null
Traitement	Procédure oracle EXTRACTION(P1,P2,P3,P4,P5,P6,P7,P8)
Propriétés
Mode d'appel	WSDL
Contraintes de sécurité	Aucune
Niveau de tolérance aux pannes	Gcat disponible
Temps moyen d'exécution attendu (SLA)	2 secondes

Tableau 10 : Fiche Service

Magicdraw propose dans sa version entreprise un diagramme WSDL qui, à condition d'être familiarisé avec cette famille de diagramme, permet de constituer l'ossature des WSDL. Ainsi, comme les autres diagrammes du même outil, il est possible générer le code correspondant.



Illustration 124 : Diagramme WSDL du CRUD d'extraction réalisé sous MagicDraw

<?xml version="1.0" encoding="UTF-8"?>

<definitions name="EXTRACTION"

targetNamespace="http://extraction-table/EXTRACTION.wsdl"

xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:tns="http://extraction-table/EXTRACTION.wsdl"

.../...

<message name="extractionTableInput">

<part name="param0" type="xsd:string"/>

<part name="param1" type="xsd:string"/>

<part name="param2" type="xsd:string"/>

<part name="param3" type="xsd:string"/>

<part name="param4" type="xsd:string"/>

<part name="param5" type="xsd:string"/>

<part name="param6" type="xsd:string"/>

<part name="param7" type="xsd:string"/>

.../...

<operation name="extractionTable">

<soap:operation soapAction="urn:extraction_table-EXTRACTION/extractionTable"/>

<input>

<soap:body use="encoded" encodingStyle= http://schemas.xmlsoap.org/soap/encoding/ namespace="urn:extraction_table-EXTRACTION"/>

</input>

<output>

<soap:body use="encoded" encodingStyle="http://s hemas.xmlsoap.org/soap/encoding/" namespae="urn:extraction_table-EXTRACTION"/>

</output>

</operation>

</binding>

.../...

</definitions>



Illustration 125 : Code WSDL du CRUD d'extraction

Cette modélisation de CRUD a été testée jusqu'à la phase de déploiement. Pour ce faire, un package Oracle « EXTRACTION » en Version 9i a été réalisé et exposé comme service grâce au module OC4J (Oracle Componant for J2ee) qui construit un WSDL à partir du package et le déploie. Il est intéressant de comparer le WSDL constitué à partir de la modélisation UML avec le WSDL généré par le module OC4J.

Des différences existent. Elles se situent par exemple au niveau de :

q L'encoding (UTF-8 pour le WSDL généré sur la machine unix implémentée de l'OC4J, contre Windows-1252 pour le Wsdl généré à partir d'une autre machine XP),

q La balise de documentation renseignée sur le WSDL construit à partir de l'OC4J.

Le reste est très comparable et cela permet d'affirmer que la phase de déploiement via le modeleur MagicDraw correspond au déploiement OC4J des package Oracle.

Rappel : dans la version 11g d'Oracle, les packages sont nativement exposés. Un Data Access Descriptor (DAD) permet de réunir plusieurs paramètres (utilisateur, mot de passe, chaîne de connexion, pool de connexion, compatibilité SSO etc ...). A partir de ce DAD, de l'addresse machine hébergeant le service WEB, le domaine, le numéro de port et le chemin d'accès à la procédure, il est possible d'appeler la procédure cataloguée à partir d'un simple browser (http://myserveur :77/pls/DADVELIAS/extraction).

Modélisation d'un WSDL pour un service technique

La transformation s'appuie sur plusieurs composants de l'ESB :

q La détection d'un nouveau message,

q L'appel du service de transformation,

q Les structures XSD (XML Schema Definition) du message (message entrant et sortant de cette activité de transformation).

Il s'agit donc ici, d'un assemblage de deux composants de l'ESB : un composant de détection et un composant de transformation.



Illustration 126 : Modélisation d'un composant selon les spécifications UML 2.0, réalisé sous MagicDraw



Composant Connecteur Port

Client Interface Fournisseur

Illustration 127 : Notation UML 2 pour l'assemblage des composants

L'assemblage de ces deux composants passe par une interface qui permet, une fois le message détecté, de lancer la tâche de transformation, en lien avec les XML schema.



Illustration 128 : Diagramme WSDL du service de transformation réalisé sous MagicDraw

<?xml version="1.0" encoding="UTF-8"?>

<definitions name="to_grc" targetNamespace="http://j2ee.netbeans.org/wsdl/to_grc"

.../...

<xsd:schema targetNamespace="http://j2ee.netbeans.org/wsdl/to_grc">

<xsd:import namespace="http://xml.netbeans.org/schema/Cpy" schemaLocation="Cpy.xsd"/>

<xsd:import namespace="http://xml.netbeans.org/schema/VQTIERS" schemaLocation="TIERS.xsd"/>

</xsd:schema>

</types>

<message name="to_grcOperationRequest">

<part name="input" element="ns:TIERS"/>

</message>

<message name="to_grcOperationResponse">

<part name="output" element="ns0:Cpy"/>

</message>

.../...

<binding name="to_grcBinding" type="tns:to_grcPortType">

<file:binding/>

<operation name="to_grcOperation">

<file:operation/>

<input name="input1">

<file:message use="literal" fileName="TIERS.xml" pollingInterval="1000"/>

</input>

<output name="output1">

<file:message use="literal" fileName="GRC.xml"/>

</output>

</operation>

</binding>

.../...

</definitions>

Illustration 129 : Code WSDL du service de transformation

3 Troisième Volet : Réalisation

La réalisation va être réalisée autour d'un ESB acquis en 2007 et non encore déployé  sur deux plateformes NETBEANS puis WEBSphère afin d'illustrer l'interopérabilité. Nous tenterons de respecter le cadre modélisé dans le chapitre précédent et nous appuierons sur l'architecture suivante :

q l'utilisation de langages universels et standards du W3C : XML, XSLT, Xquery, SOAP,

q l'exposition des procédures stockées,

q un Repository,

q des Application découplées du modèle de données,

q Un ESB, chef d'orchestre des échanges inter-application.

Peu importe l'émetteur du document

?

OE

Document XML

Document Csv

Procédures

Repository

Application Semences

Datamart Céréales

GCR

_

Document XML

SOAP Request

(Web Service)

Legacy

Document XML

Document XML

Illustration 130 : Cycle de vie d'un document XML Tiers

_

Les étapes de ce volet de réalisation vont être de constituer le format Pivot Terrena, puis de rassembler tant, les règles de transformations, que le vocabulaire commun.

Puis les composants modélisés précédemment tel que les Web Service, les transformations, le routage et les chargements seront réalisés et orchestrés dans notre architecture choisie.

3.4 Étapes de la réalisation 

La stratégie adoptée pour la constitution de notre format pivot a consisté à convenir d'un format issu d'un balisage normalisé, si possible du domaine public comme ceux de la Poste ou de l'INSEE, de l'ISO etc ... et d'y greffer le balisage spécifique au monde coopératif (Projet GIEA), tout en y intégrant des balises « privées », propres à nos applicatifs métiers.

Des services agissant comme des passerelles sur ce format pivot pourront répondre à deux types de besoins : la conversion du format pivot vers un format propriétaire, la conversion d'un format propriétaire vers le format pivot.

Ces passerelles seront matérialisées par des transformations de nature XSLT quand il s'agira de transformation de et vers XML, et java quand il s'agira de transformations sur des formats source et cible hétérogènes.

Le routage s'appuiera sur le référentiel afin d'alimenter les applications Clientes qui consommeront les documents XML transmis.

3.4.1 L'environnement Technique

La persistance des données est assurée par un noyau Oracle 11g. Ce choix a été fait en raison des atouts multiples de cette version :

q Web Service natifs pour accéder à toute procédure ou fonction de la base oracle. La version précédente imposait l'utilisation d'un OC4J (Oracle Componant for J2ee) pour les déployer.

q La gestion des données XML et des schémas XML via le paquetage XML DB,

q L'indexation possible des documents Xml avec XMLIndex et B-Tree,

q La gestion interne des schémas à partir du type de donnée XMLType,

q Le développement possible en Xpath et disponibilité de paquetages HTP.

L'ESB retenu est celui de SUN : OpenESB mis à disposition depuis décembre 2008 au sein d'une nouvelle plateforme d'intégration SOA. Cette dernière est constituée de l'assemblage des solutions arrivées à maturité chez SUN : Glassfich Application Server 2.1 R2, l'IDE Netbeans 6.5.1. et l'ESB OpenESB. Il est ainsi possible de :

q Modéliser et exécuter des processus BPEL d'orchestration de services,

q D'architecturer (Wsdl) et d'orchestrer (Bpel),

q De développer en respectant les exigences d'interopérabilité (XML, XSLT, XPATH ...),

q D'exécuter des applications composites dans le souci de réutilisation des services (Service Assembly et Service Unit).

L'explorateur à partir duquel les web Services sont invoqués est IE. Cependant il sera vérifié que FireFox produit le même résultat.

Deux réalisations distinctes seront réalisées : une première, simple, afin de construire et d'assembler les composants de base à notre architecture cible, une seconde plus élaborée intégrant les notions de contrat de service par exemple, ainsi que les récentes spécifications SOAml. L'orchestration sera abordée dès la première réalisation.

Afin d'illustrer l'interopérabilité, la seconde réalisation sera réalisée sur une autre plate-forme (WebSphère d'IBM). Les composants de la première réalisation devront pouvoir être transposés dans la seconde architecture (modélisation et technique).

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

L'objectif de cette première réalisation est de constituer les premiers composants de base nécessaire à notre architecture cible. L'ensemble de ces composants sont réalisés à partir du framework Netbeans 6.5.1 couplé à MagicDraw (pluging) afin de tirer profit de la modélisation XML du chapitre précédent.

Le jeu d'essai sera élémentaire : un document XML généré suite à une demande HTTP (Web Service) déposé dans un répertoire scruté par un composant ESB de polling, puis transformé dans un format propre à la GRC avant d'être finalement déposé sur un serveur FTP distant.

3.4.2.1 Web Service

Une procédure Oracle est implémentée sur une base 11G exposant nativement celle-ci.

La procédure Oracle se trouve en Annexe.

Cette procédure convient à toute demande d'extraction mono-table ou mono-vue. Pour faciliter son utilisation, quelques paramètres ont été créés : Nom de la table, Racine des fichiers de sortie, Répertoire. D'autres paramètres facultatifs ont été ajoutés afin de pouvoir apporter de la souplesse dans l'interrogation (clauses « Where » et « Order By »).

Par exemple, si l'on souhaite extraire le tiers COOP-00796 de la vue VQTIERS, il sera possible d'invoquer la procédure « extraction_table » à partir du browser IE :

http://pc13972.terrena.fr/terrena/ extraction_table?P$TABLE=VQTIERS&P$FICHIER=VQTIERS&P$REPERTOIRE=FICHIERS_OUT&P$WHERE=tiersnum='00796'%20and%20tierstyp%20='COOP'%20and%20rownum%20=%201

Cette procédure génère un document XML (ainsi qu'un fichier Csv pour répondre au besoin existant). Dans l'absolu, cette procédure Oracle sera probablement sollicitée par un trigger interne à la base, ou alors par un traitement batch. Mais il est tout aussi possible d'utiliser une exposition HTTP afin d'offrir la possibilité de forcer le rafraîchissement d'un tiers dans la GRC. La procédure est unique et réutilisable par des points d'appels, quant à eux multiples.

Il est aussi possible de contourner cette possibilité offerte par Oracle 11g et de générer un WSDL à partir de l'option d'engineering offerte par Magicdraw. Cet appel au Web Service se fera via la commande suivante tapée au niveau du browser :

http://pc13972.terrena.fr:1158/wsdl/extraction

Les fenêtres suivantes s'ouvrent alors afin de proposer l'accès au service d'extraction et la saisie des paramètres :





_

Extrait de Document XML généré :

Illustration 131 : Document XML VQTIERS

Ce document est déposé dans un répertoire scruté par les composants suivants : « Polling Fichier et Transformation ». En même temps, l'affichage des enregistrements correspondant à la demande (dans un format brut) est retourné à l'utilisateur ayant invoqué la procédure.

3.4.2.2 Polling Fichier et Transformation

.../...

<service-assembly>

<identification>

<name>Polling_transformation</name>

<description>Represents the Service Assembly of Polling_transformation</description>

</identification>

<service-unit>

<identification>

<name>Polling_transformation-VQTIERS</name>

<description>Represents this Service Unit</description>

</identification>

<target>

<artifacts-zip>VQTIERS.jar</artifacts-zip>

<component-name>sun-xslt-engine</component-name>

</target>

</service-unit>

<service-unit>

<identification>

<name>Polling_transformation-sun-file-binding</name>

<description>Represents this Service Unit</description>

</identification>

<target>

<artifacts-zip>sun-file-binding.jar</artifacts-zip>

<component-name>sun-file-binding</component-name>

</target>

</service-unit>

<connections>

<connection>

<consumer endpoint-name="to_grcPort" service-name="ns1:to_grcService"/>

<provider endpoint-name="to_grcPortTypeRole" service-name="ns1:to_grc"/>

</connection>

</connections>

.../...

La seconde activité du processus étudié est double, dans le sens où il s'agit d'un assemblage de services unitaires. Plus précisément, à cette étape, il va falloir solliciter un composant interne à l'ESB, chargé de scruter un répertoire spécifique (d'où le terme de polling), afin de déclencher un second service à bon escient, c'est-à-dire lorsqu'un certain type de fichier se présentera. Ce second service est dédié à la transformation d'un document XML dans un format cible spécifique (ici : le format des Tiers pour la GRC).

Illustration 132 : Assemblage de la transformation pour la JBI (Jbi.xml)

On retrouve dans ce fichier d'assemblage le nom de deux fichiers d'exécution (.jar). Le premier, VQTIERS.jar, est un programme Java obtenu suite à la construction du projet construit graphiquement (le terme de « build » est souvent utilisé). Il s'appuie sur un composant interne à l'ESB « sun-xslt-engine », chargé de transformer un document XML. Le second, sun-file-binding.jar, est un programme java construit de façon à déclencher le précédent composant. En effet, une transformation XSLT s'appuie sur une technologie de communication : message SOAP, File, FTP etc ... A chaque technologie de communication correspond un composant interne spécifique. La richesse d'un ESB, en termes de composants internes, est fonctionnellement importante, car elle constitue les limites de ce qui sera possible ou non d'implémenter. A titre d'exemple, l'ESB de SUN propose les composants suivants :

q File (utilisé dans la première réalisation),

q FTP (utilisé dans la première réalisation),

q HTTP Soap,

q JMS,

q Bpel (utilisé dans la première réalisation),

q Java EE,

q SQL,

q XSLT (utilisé dans la première réalisation).

La connexion entre ces deux services (EndPoint) est également précisée dans le JBI.xml. Elle peut également être concrètement visualisée via le framework.



Illustration 133 : Représentation graphique de la connexion des deux services unitaires, réalisé sous Netbeans

Le contrat de service entre le fournisseur et le consommateur se positionne sur une échelle à quatre niveaux^155(*). Le premier niveau concerne la vérification de la définition des types d'opérations et des paramètres. Le second niveau contrôle le comportement des opérations. Le troisième niveau s'intéresse aux contraintes de synchronisation des opérations. Et enfin le quatrième niveau, appelé Quality of Service « Qos », s'attache à définir le cadre de disponibilité, de sécurité et de performance du service. Le Qos est extérieur au service unitaire alors que les trois autres niveaux sont internes à l'interface. Ce volet fera l'objet d'un approfondissement dans le cadre de la seconde réalisation. Comme le montre la représentation graphique précédente, un WSDL indique la manière de communiquer pour utiliser le service « to_grcService ». Le WSDL se matérialise en un fichier XML, qu'il est possible d'afficher de façon graphique grâce à certains outils comme XmpSpy de l'éditeur ALTOVA).



Illustration 134 : Représentation graphique du WSDL, réalisé sous XmlSpy

Les paramètres du Port d'écoute sont également précisés dans le WSDL :

<service name="to_grcService">

<port name="to_grcPort" binding="tns:to_grcBinding">

<file:address fileDirectory="D:\Fichiers\out" lockName="filebc1.lck" workArea="filebc1_tmp" seqName="filebc1.seq"/>

</port>

</service>

Illustration 135 : Paramètre du service

Le message « input » respecte la structure du XML schéma VQTIERS et le message « output », après transformation, est structuré à partir du XML schéma Cpy, propre à la GRC de l'éditeur Selligent. Ces deux schémas sont associés au namespace « http://xml.netbeans.org/schema ». Les schémas ont été définis à partir de MagicDraw et ont été intégrés à la plate-forme Netbeans au moment de la définition des XML schéma. Quelques retouches ont été opérées après coup, directement dans Netbeans.

Le service de transformation « To_grc » est matérialisé lui aussi par un fichier de type XML : « to_grc.xsl ». Là aussi, existent des solutions pour représenter graphiquement le mapping entre le message input (source) et le message output (cible). La réalisation de cette transformation a également été prise en charge par Netbeans. Les règles de transformation peuvent y être intégrées de façon lisible. Par exemple, une balise CpyBlackList doit porter la valeur `1' lorsque la situation du partenaire est inactive (valeur = `X') ou lorsque le compte est fermé (valeur = `X').



Illustration 136 : Mapping de transformation XSLT entre le message Input et Output, réalisé sous Netbeans

La traduction XML de ce mapping est la suivante :



Illustration 137 : Traduction XML dans le fichier to_grc.xsl

3.4.2.3 Transfert FTP

Une fois le document XML transformé, il doit être détecté puis transmis à un serveur FTP distant : AIX6 (10.1.101.113 port 21).



Illustration 138 : Représentation graphique du transfert du fichier XML par FTP, réalisé sous Netbeans

Pour construire ce transfert, il faut s'appuyer cette fois sur deux WSDL. Le premier permet d'attendre l'arrivée de certains fichiers dans un répertoire particulier (à l'image du service To_grc précédant) et le second permet d'enchaîner directement sur le transfert FTP vers AIX6. Les paramètres nécessaires à ces deux opérations sont spécifiés dans les WDSL (l'adresse du port d'écoute, le nom des fichiers attendus pour le premier WSDL, l'adresse du port FTP, le répertoire cible, le nom du fichier cible pour le second WSDL). Les composants sont, cette fois, au nombre de trois : un composant de type File pour le polling, un autre de type FTP pour le transfert et un troisième, central, pour orchestrer les deux autres.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

.../...

xmlns:ns2="http://j2ee.netbeans.org/wsdl/SendInventory/ftpTransfer" xmlns:ns3="http://j2ee.netbeans.org/wsdl/SendInventory/fileTrigger" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" xsi:schemaLocation="http://java.sun.com/xml/ns/jbi ./jbi.xsd">

<service-assembly>

<identification>

<name>PUT_GRC</name>

<description>Represents the Service Assembly of PUT_GRC</description>

</identification>

<service-unit>

<identification>

<name>PUT_GRC-PUT_GRC</name>

<description>Represents this Service Unit</description>

</identification>

<target>

<artifacts-zip>PUT_GRC.jar</artifacts-zip>

<component-name>sun-bpel-engine</component-name>

</target>

</service-unit>

<service-unit>

<identification>

<name>PUT_GRC-sun-file-binding</name>

<description>Represents this Service Unit</description>

</identification>

<target>

<artifacts-zip>sun-file-binding.jar</artifacts-zip>

<component-name>sun-file-binding</component-name>

</target>

</service-unit>

<service-unit>

<identification>

<name>PUT_GRC-sun-ftp-binding</name>

<description>Represents this Service Unit</description>

</identification>

<target>

<artifacts-zip>sun-ftp-binding.jar</artifacts-zip>

<component-name>sun-ftp-binding</component-name>

</target>

</service-unit>

<connections>

<connection>

<consumer endpoint-name="OutboundOneWayMessagingPortTypeRole_partnerRole" service-name="ns1:PartnerLink2"/>

<provider endpoint-name="OutboundOneWayMessagingPort" service-name="ns2:OutboundOneWayMessagingService"/>

</connection>

<connection>

<consumer endpoint-name="fileTrigger_InboundPort" service-name="ns3:FileInboundService"/>

<provider endpoint-name="FileInboundPortTypeRole_myRole" service-name="ns1:PartnerLink1"/>

</connection>

</connections>

</service-assembly>

</jbi>

Illustration 139 : Assemblage du transfert FTP pour la JBI (Jbi.xml)

L'orchestrateur central permet de définir les règles d'exécution des deux actions (polling et transfert). BPEL est le langage communément utilisé pour réaliser cette orchestration. Il est un dérivé de XML et est devenu depuis sa version 2, une spécification du consortium OASIS en mars 2007. Le choix d'un ESB doit également se faire de façon à ce que BPEL soit supporté dans sa version 2.0. Cette version est bien celle de la plate-forme de réalisation choisie.



Illustration 140 : Représentation graphique de l'orchestration, réalisée sous Netbeans

BPEL définit ainsi le processus, c'est à dire la logique d'enchaînement des actions (ici : attente et transfert de fichiers XML vers un serveur FTP). Sa construction est balisée à l'image d'un fichier XML :

q La balise <Process> constitue la racine du fichier BPEL. L'attribut « name » permet de nommer le processus,

q La balise <Import> permet d'importer les fichiers WSDL (un WSDL pour détecter les nouveaux fichiers, et un autre pour le transfert FTP),

q La balise <PartnerLinks> sert à lier le rôle de chaque WSDL au BPEL,

q La balise <Variables> définit les variables utiles au BPEL,

q La balise <Sequences> liste des actions du processus, elles-mêmes balisées :

<Receive> pour réceptionner le signal du Partenaire détectant un nouveau fichier,

<Assign> pour véhiculer le message,

<Invoke> pour appeler un Web Service.



Illustration 141 : Actions du processus BPEL (extrait du PUT_GRC.bpel)

Le BPEL PUT_GRC s'appuie sur deux services unitaires. Le premier service est dédié à la technologie de communication (File) correspondant un document XML généré dans un répertoire en attente de transfert. Le second service est le service FTP faisant appel à une méthode PUT afin de pousser le fichier détecté dans le répertoire, vers un autre répertoire sur le serveur FTP. A cet instant, il est important de s'assurer que le composant interne FTP de l'ESB retenu, offre les possibilités de sécurisation SSL (RFC 2228) et non la simple spécification RFC 959 sans cryptage. Cette condition est bien vérifiée par rapport à la plate-forme de réalisation.

3.4.2.4 Assemblage global

Une fois les tests effectués de façon unitaire, il paraît intéressant de réunir l'ensemble de ces composants dans le même service d'assemblage.



Illustration 142 : Assemblage File, FTP, XSLT, BPEL, réalisé sous Netbeans

Il faut veiller à ce que le paramétrage reste cohérent. Par exemple, le composant sun-file-binding est utilisé pour deux opérations distinctes :

q La détection de fichier VQTIERS.XML,

q La détection de fichier GRC.XML.

Par défaut, ce composant positionne des fichiers de gestion d'accès concurrent. Aussi, faut il veiller au nommage de ces fichiers de manière distincte.

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

Cette réalisation doit répondre aux exigences suivantes :

q Mettre l'accent sur l'interopérabilité des architectures SOA,

q Mise en place d'une politique de contrat de service,

q Prise en compte des spécificités SOAml.

Pour ce faire, la seconde réalisation doit être réalisée sur la base d'un autre outil de modélisation et une plate forme technique différente. Le modeleur Magicdraw sera remplacé par un autre ou complété d'un pluging intégrant le profil SOAml et Websphere sera préféré à Netbeans. L'idée est de vérifier les possibilités d'échange à la fois entre les deux modeleurs supportant une interface XMI et la portabilité du code généré sur une nouvelle plateforme technique.

Pour ce qui est du contrat de service, ce sera l'occasion d'introduire le langage OCL dans la modélisation et d'observer son impact sur le déploiement.

L'objectif de ce chapitre est de répondre à la question posée par le sujet de ce mémoire, ou autrement exprimé, de définir la valeur d'une mise en place d'une architecture SOA, pour le Groupe Terrena.



3.4.4 Résultats obtenus

3.4.4.1 Première réalisation

La première réalisation n'a pas posé de problème dans le sens où les contraintes étaient faibles :

q Le processus était élémentaire, sans introduction de contrat de service complexe,

q Les composants de l'offre SUN sont à la fois riches, stables et bien documentés,

q La modélisation a permis d'obtenir une ossature de code,

q On peut saluer une réelle prise en compte du monde XML par Oracle (même s'il ne faut pas se laisser tenter par un cloisonnement Oracle ...).

Cependant, cette expérimentation ne doit pas cacher une réalité plus complexe :

q Le processus expérimenté, même s'il répondait à un besoin métier, était principalement constitué de briques techniques,

q Le code a dû faire l'objet de compléments et d'adaptations avant d'être opérationnel, car comme le dit un proverbe chinois « les modèles font d'excellents serviteurs mais de bien mauvais maîtres ». L'état actuel du BPMN n'enchaîne pas les différents modèles UML permettant de générer le code attendu pour une architecture SOA appuyée d'un ESB,

q La modélisation a cruellement manqué du nouveau profil SOAml spécifié début 2009, mais apparu dans les modeleur MagicDraw et Objecteering que courant mars,

q L'ESB devient un point névralgique. En cas de panne de ce dernier, le système d'information tout entier est paralysé. Des recherches complémentaires sont réalisées afin de s'assurer de la disponibilité de notre architecture en cas de panne des communications avec le serveur d'hébergement de l'ESB.

Isoler la valeur d'une telle mise en place, n'est pas chose simple et bien que les outils ne constituent pas à eux seuls une architecture SOA, ils sont néanmoins nécessaires dans la phase d'industrialisation.

Avant tout chiffrage, il y a des avancées qu'il n'est pas facile d'évaluer, mais que l'on peut lister :

q la définition d'un référentiel et d'une sémantique d'entreprise,

q la construction de modèles avec les métiers, permettant à ces derniers de devenir de réels acteurs et propriétaires des processus les concernant.

Une fois ce premier niveau de maturité atteint, d'autres sources de valeur, toutes aussi délicates à valoriser, peuvent être dégagées, telles que l'optimisation des processus grâce à la mise en place d'indicateurs.

Mais la démarche est au moins aussi importante que l'architecture SOA. Les nouvelles spécifications SOAml en sont un exemple. Une fois la phase d'étude achevée, le développement doit impérativement être en lien direct avec la modélisation qui reste, une fois couplée à la couche métier (BPMN), l'interface visible et compréhensible par l'acteur Métier.

3.4.4.2 Seconde réalisation

Les spécifications SOAml ont été mises à dispositions le 13 janvier 2009 par l'OMG. Il a fallu attendre le 23 mars pour qu'un plugin MagicDraw baptisé CAMEO SOA+ béta 1 soit proposé pour intégrer ce nouveau profil SOAml dans une approche MDA.



Illustration 143 : Nouveau Profil SOAml intégré à MagicDraw 16.1

Se déclinent 6 diagrammes plus adaptés à l'approche des services et de l'ESB :

q Service Structure,

q Service Choreography,

q Service Architecture,

q Message Type,

q Composite Application Component,

q Activity, Capability and provisioning

L'objectif de cette seconde partie est de retravailler la phase PIM de MDA, afin d'analyser l'impact sur l'implémentation et la maintenance, tout en intégrant le concept de QoS, sur un autre ESB : Websphère d'IBM.

L'objectif de cette conclusion est de prendre un peu de recul sur l'architecture SOA tout en rappelant les ingrédients nécessaires à cette recette bien prometteuse.



Conclusion Générale

En dépit d'un avis de décès^156(*) du SOA paru le 9 janvier 2009 sur le blog du Burton Group, et ce en raison des nouvelles priorités d'investissement liées à la crise, le message porté par la thématique SOA reste quant à lui bien vivant :

q Le « mash-up » (la combinaison de services applicatifs en ligne, aussi appelé la « SOA de l'internet »),

q le « cloud computing » (le nuage de ressources informatiques permettant l'externalisation des services informatiques),

q le Software As A Service ou « Saas » (logiciels fournis en ligne sous forme de services^157(*), successeur de l'Application Service Provider ou « ASP »),

q le Platform As A Service ou « Paas » (plateforme incluant des services d'infrastructures tels que les outils de surveillance, de persistance des données, d'hébergement d'application).

Toutes ces technologies reprennent le principe d'orientation de services. Cependant, ces nouvelles tendances ne doivent pas s'ajouter au mille-feuilles technologique existant. C'est par l'effort des urbanistes et autres architectes, que le système d'information deviendra moins rigide et utile aux métiers. Pour que ce premier niveau de maturité soit atteint, seules les organisations mettant en oeuvre une réelle gouvernance, et disposant d'un budget (car soutenues par les directions générales), pourront faire bouger les lignes.

La SOA n'est pas une recette miraculeuse mais en premier lieu, la prise de conscience qu'un travail de fond doit être réalisé. Les principales réussites en la matière ont de commun cette longue mise à plat de l'existant, avant toute nouvelle mise en oeuvre technique. La SOA doit probablement être perçue comme un nouveau métier, qui s'inscrit en ligne directe avec la stratégie de l'entreprise, reposant sur une approche fondamentalement différente de celle existante aujourd'hui, tant au niveau technique que méthodologique. Elle nécessite une conduite au changement tant les conséquences sont multiples, et s'accompagne d'un plan de communication et de formation des acteurs du SI mais aussi des utilisateurs métiers.

Et après ?

L'offre SOA s'est aujourd'hui largement répandue au niveau des différentes solutions informatiques. Comme toute mini-révolution, SOA s'est installée dans les esprits et fera peu à peu son chemin. Et comme toujours, une nouvelle technologie la relèguera un jour au rang des anciens concepts. Comme cela a été expliqué dans la première partie (« Etat de l'Art » de l'intégration), une nouvelle strate technologique répond toujours à un besoin du moment. Aussi, imaginer aujourd'hui, ce que serait la nouveauté de demain, revient à révéler la fragilité de l'Architecture SOA et de tenter d'y répondre.

Dans ce mémoire, un parallèle a été fait entre les systèmes multi-Agents (SMA) et les composants SOA : autonomes, déterministes, dotés d'un couplage lâche. Si l'on observe l'évolution des SMA, on constate qu'ils se sont « dynamisés », afin d'entrer dans l'univers du jeu de rôle par exemple. Ainsi, dès la première utilisation, les scénarios internes au jeu sont modifiés, en fonction du comportement du joueur observé. L'agent enrichit donc ses connaissances au fil du temps. Il ne s'agit plus de calculer une solution à partir de paramètres stables, mais de proposer une solution acceptable en fonction de la nouvelle organisation et des changements perçus. Les métiers de la Simulation sont également bénéficiaires de ces systèmes multi-agents dynamiques.

Aujourd'hui, SOA n'est pas réellement dynamique. Le routage, les processus sont autant d'éléments inscrits dans le marbre. Pour que la SOA soit hissée au rang des architectures dynamiques et ce, afin d'accroitre son adaptabilité à son environnement, il faudrait qu'elle puisse assembler spontanément ses propres composants et ceux d'autres architectures, afin de répondre à une problématique non envisagée initialement. Le résultat de récentes recherches^158(*) entreprises par l'INRIA, avancent le terme de « SOA dynamique » ou D-SOA comme « élément important pour les architectures (...) du futur, surtout dans le contexte dynamique des réseaux sociaux et de l'Internet des Objets ». Pour l'instant les domaines étudiés sont ceux des services de petits supports tels que les Smartphones et les PDA, en supposant de les doter d'une JVM^159(*).

Les perspectives de l'ingénierie informatique constituent ainsi la clef de voute des architectures de demain. Un auteur, parmi d'autres, RACCOON^160(*), illustrait en 1997 cette perpétuelle évolution de la manière suivante :



Illustration 144 : Les cycles de l'évolution IT

(Source: Raccoon, Fifty Years of Progress in Software Engineering, [RAC-FYP])

Mais qu'en est-il aujourd'hui de cette projection confrontée à la réalité :

Instruction Procédurale Module Objet Composant Service Modèle ???

Mainframe Mini Station PC Web Station Ubi Station^161(*) M2M ???

http/Html Xml ???

M2M (Machine to Machine)

B2C B2B

Intérêt

Axe temporel

1944 1958 1973 1988 2000 2005 2010

Illustration 145 : Extrapolation des cycles de Raccoon

La D-SOA (SOA dynamique) s'appuie sur le principe d'une passerelle OSGi (Open Services Gateway initiative) qui rend indépendant le consommateur du service, quelque soit leur localisation. Dans le principe, le bus dédié au consommateur est connecté, comme d'autres bus dédiés, à un bus JMS constitué de connecteurs OSGi. Pour illustrer l'intérêt de ce bus à grande échelle, il est possible de prendre l'exemple d'un usager se trouvant hors de son foyer et souhaitant contrôler le réseau domotique de son habitation (température, caméra de surveillance, compteur électrique, moniteur cardiaque ...). Pour reprendre le nom donné au prochain salon MtoM de Paris-Porte de Versailles en 2010 : « Les objets deviennent intelligents et communiquent » entre eux.

Enfin, la modélisation, ingrédient majeur à la construction d'une architecture SOA, n'est pas suffisamment intégrée à ce jour. Les articulations des différentes phases : « Cartographie Processus Métiers », « Processus Modèles Modèles UML», « Modèles UML Code» ne sont pas matures et constituent une fragilité certaine pour l'édifice tout entier qui doit pouvoir être flexible et donc rester souple. Nul doute que les consortiums présents et à venir seront de grands contributeurs à l'avancée de cette intégration par les modèles, indispensable à toute forme d'architecture.

Les pages à suivre rassemblent l'index bibliographique, les acronymes et les différentes annexes cités en référence dans ce mémoire.



Bibliographie SOA (Services Oriented Architecture)

Ouvrage(s)

[ANQ-URBA] ; Club Urba-EA ; ANQUETIL, Philippe; BONNE, Jean-Christophe; CARPENTIER, Denis. Urbanisme des SI et gouvernance : Retours d'expériences et bonnes pratiques. Coll. InfoPro - Management des systèmes d'information Paris : Dunod, 2006. 274 p. ISBN 2-10-049678-6.

Le Club Urba (Urbanisme du SI -Enterprise Architecture) est une association qui rassemble 55 grandes entreprises et administrations constituant un lieu d'échanges entre urbanistes, architectes, responsables d'études et MOA.

[BEU-MCC]; BEUGNARD, Antoine; Making Components Contract Aware. Coll. Computer. pp. 38-45, juillet 1999.

Antoine Beugnard est enseignant et chercheur en informatique. Il est l'auteur de nombreux ouvrages touchant à l'assemblage des composants.

[BRI-IPM] ; BRIOL, Patrice ; L'ingénierie des processus métiers - De l'élaboration à l'exploitation. Belgique, éditeur lulu.com, 2008. 361 p. ISBN 978-1-4092-0040-6.

Patrice Briol est architecte d'applications chez E-Consult (membre du groupe Altran).

[FOU-GUID] ; FOURNIER-MOREL, Xavier; GROJEAN, Pascal; PLOUIN, Guillaume. SOA le Guide de l'architecte. Coll. InfoPro - Management des systèmes d'information. Paris : Dunod, 2006. 302p. ISBN 2-10-049972-6.

Xavier FOURNIER MOREL est consultant au sein du pôle conseil et veille technologique du groupe SQLI.

[MAU-VITR] ; MAUFRAS. L'architecture de Vitruve, Tome III. Traduction nouvelle. Paris, éditeur C. L. F. Panckoucke, 1847. Texte latin et français en regard.

Vitruve : Ingénieur et architecte romain (1er siècle av. J.C.), auteur de 10 volumes consacrés à l'architecture.

[POP-LEA] ; POPPENDIECK, Mary et Tom; Lean Software Development. Canada, éditeur Addison Wesley professional, 2003. 240 p. ISBN 978-0321150783.

Mary et Tom POPPENDIECK créent le Lean Software Developement en 2003, selon les principes fondateurs du Lean.

[LOG-PUR] ; LONGEPE, Christophe; Le Projet d'Urbanisation du SI démarche pratique avec cas concrêt. Coll. InfoPro - Management des systèmes d'information, Paris : Dunod, 2006 ; 3^ème édition. 396 p. ISBN 2-10-050093-7.

Christophe LONGEPE est Directeur de l'urbanisme et des référentiels Groupe Société Générale.

[LON-MXM] ; LONJON. Antoine ; THOMASSON Jean-Jacques. Modélisation XML. Coll. Architecte logiciel ; Edition Eyrolles, 2006 ; 498p. ISBN 2-212-11521-0.

Antoine LONJON est Directeur de l'offre citée dans ce mémoire chez Mega. Il participe à l'élaboration des standards au sein de l'OMG et autres consortiums de normalisation de l'industrie de logiciel (la norme Business Process Spécification Schema, ebXML, la notation Business Process Modeling Notation pour les processus métiers ainsi qu'à la dernière version 2.0 d'UML).

[RAC-FYP] ; RACCOON; Fifty Years of Progress in Software Engineering. Coll. ACM SIGSOFT Software Notes: volume 22, no 1, Janvier 1997, New-York. ISSN: 0163-5948.

[VDB-PROF] ; VAN DEN BERG, Martin; VAN OMMEREN, Erik; BIEBERSTEIN, Norbert. SOA for profit. Bruxelles : Sogeti et IBM, 2007. 256 p. ISBN 907-5-41-4188.

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

[AIM-VHC] ; AIME, Xavier. Visualisation d'alignements d'ontologies ; Mémoire Ingénieur Cnam en Informatique, Centre Régional Associé de Nantes, XXX 200N.

[GUI-PMA] ; GUITTON, Julien. Planification multi-agent pour la composition dynamique de Services Web ; Rapport de stage - Master 2 Recherche Intelligence Interaction Information, Université Joseph Fourier - Grenoble 1 - Informatique et Mathématique Appliquée, juin 2006.

[TOU-ACS] ; TOUZI, Jihed. Aide à la conception de Système d'Information Collaboratif, support de l'interopérabilité des entreprises ; Thèse soutenue au Centre de Génie Industriel - Ecole des Mines d'Albi - novembre 2007.

Article(s)

[LIT-CAA] ; LITTLE, Todd. Context-Adaptive Agility: Managing Complexity and Uncertainty. IEEE Software, vol 22, no.3, PP.28-35, Mai/juin 2005.

Todd LITTLE est Responsable de développements chez Landmark Graphics, leader dans la vente de solutions dans le domaine pétrolier et gazier, auteur de plusieurs articles concernant les mesures d'estimation de projet.

[LEG-LST] ; LÉGERON, Patrick. Le stress au travail : de la performance à la souffrance. Droit Social, no.12, P.2, Décembre 2004.

Patrick LÉGERON est Docteur Psychiatre, praticien attaché, service hospitalo-universitaire, Centre hospitalier Sainte-Anne, Paris. Il est Directeur de STIMULUS, cabinet de conseil sur le stress professionnel

[MON-RFA] ; MALINGRE, Virginie. 2006, année record pour les fusions-acquisitions. Le monde, 22 décembre 2006.

Ressource(s) Internet

[CHA-CONT] ; CHAPPELL, David. Using the ESB Service Container. Site disponible sur http://www.onjava.com/pub/a/onjava/excerpt/esb_ch6/index.html

David CHAPELL est Vice Président et responsable de la technologie de SOA chez Oracle Corporation.

[BON-CSOA] ; BONNET, Pierre. Cadre de Référence Architecture SOA - Meilleures Pratiques. Site disponible sur http://pie.bonnet.ifrance.com/ON-seminaire-SOA-Webservice-Part01.pdf

Pierre BONNET est expert en architecture des Systèmes d'Information orientée objets et services.

[RAF-BLAN] ; RAFAL, Olivier. Livre blanc - GUIDE SOA 2008. 2008.

Olivier RAFAL est Rédacteur en chef de LeMondeInformatique.fr.

[OCT-SYST] ; Consultant OCTO Technology. Livre blanc - Architectures de systèmes d'information. Novembre 2002

[OCT-EAI] ; Consultant OCTO Technology. Livre blanc - Intégration des Applications d'Entreprise. 2000

[OCT-SOA] ; Consultant OCTO Technology. Livre blanc - Architecture Orientée Services (SOA) - Une politique d'interopérabilité. 2005

OCTO Technology a été fondé en 1998. C'est un cabinet spécialisé en Architecture de Systèmes d'Information.

[FOR-EAE] ; Forrester Research. Evaluez l'agilité de votre entreprise. 2007. Site disponible sur http://www.sap.com/france/campagnes/Mega_Program_Driving_Efficiency/Evaluez_Reactivite_Votre_Entreprise_Forrester.pdf.

[FOR-APE] ; Forrester Research : Carey Schwaber, Randy Heffner. Agile Processes Enable SOA Success : The Story Behind The Correlation In Agile And SOA Adoption. 2006. Site disponible sur http://www.forrester.com/Research/Document/Excerpt/0,7211,38853,00.html

Forrester Research est un vieux cabinet d'études indépendant (25 ans) coté en bourse dont les chiffres et les prévisions sont très suivis.

Sigles, Acronymes et Lexique de termes

3-tiers, architecture à trois niveaux est l'application du modèle plus général qu'est le multi-tiers. L'architecture logique du système est divisée en trois niveaux ou couches : présentation, métier, données.

A2A (Application to Application) : caractérise l'échange d'information entre deux applications de la même entreprise.

API (Application Programming Interface) : interface pour les applications permettant de communiquer.

B2B (Business to Business) : caractérise le type de commerce électronique conduit entre entreprises.

B2C (Business to Consumer) : caractérise le type de commerce électronique conduit entre une entreprise et une personne privée.

BAM (Business Activity Monitoring) : comprend l'acquisition, l'agrégation, l'analyse et la présentation en temps réel de données associées à des processus d'entreprise.

BEA MessageQ :

BPDM (Business Process Definition Metamodel): proposition de l'OMG.

BPEL : langage de description des procédures d'entreprise. Ce langage a été défini dans sa version 2.0 par une spécification du consortium OASIS à la fin du mois de mars 2007.

BPM  (business process managment) : approche consistant à modéliser informatiquement les processus métiers de

l'entreprise, aussi bien dans leur aspect applicatif qu'humain.

BPMI : Business Process Management Initiative) : consortium de standardisation.

BPML (Business Process Modeling Language) : langage basé sur XML, permet de modéliser les processus métier.

BPMN (Business Process Management Notation): premier standard du Business Process Management.

BRMS (Business rules management system) : système de gestion des règles métier

C/C++ : langage de programmation existant depuis 1985 et largement utilisé depuis 1995, non propriétaire, et permettant la programmation sous de multiples paradigmes comme, par exemple, la programmation procédurale, la programmation orientée objet.

CICS (Customer Information Control System) : système qui permet d'effectuer des opérations transactionnelles (en général consultation ou mise à jour de bases de données ou de fichiers) avec une très grande économie de moyens.

CIM (Computation Independent Model) : parfois appelé Business Model, il s'agit de représenter l'entreprise.

Architecture client/serveur : mode de communication entre plusieurs ordinateurs d'un réseau qui distingue un ou plusieurs postes clients du serveur (actifs): chaque logiciel client peut envoyer des requêtes à un serveur (passif).

COM (Component Object Model) : composant utilisé en programmation pour permettre le dialogue entre programmes, très présent dans le monde Microsoft Windows.

Communication asynchrone (Asynchronous Communication) : type d'échange non bloquant dans lequel une application envoie un message à l'autre sans attendre la réponse, afin que les applications puissent opérer indépendamment.

Communication synchrone (Synchronuous Communication) : type d'échange bloquant dans lequel une application envoie un message à l'autre en attendant la réponse, de telle sorte que les applications opèrent en dépendance.

Compensation : mécanisme de retour arrière par exemple lorsqu' un traitement de virement échoue en cours de route. Si un mouvement de débit a déjà été créé sur le compte d'origine, alors la compensation sera de créditer de la même somme le compte.

Datawarahouse : entrepôt de données qui se caractérise par des données orientées « métiers » (...) non volatiles (...) présentées selon différents axes d'analyse ou « dimensions ».

DTD (Document Type Definition) : document permettant de décrire un modèle de document SGML ou XML

EAI (Intégration d'applications d'entreprise) : architecture intergicielle permettant à des applications hétérogènes de gérer leurs échanges.

EAM (Enterprise Architecture Modeling) : outil de modélisation de l'architecture d'entreprise.

Eclipse : IDE libre d'IBM, fonctionnant à partir de plugin spécifiques.

EDI (Electronic Data Interchange) : échange de données électroniques organisées selon des messages à plusieurs niveaux, avec en-têtes de trois caractères et des codages longueur - champ, standardisé dans les années 80.

Edifact (Échange de données informatisées pour l'administration, le commerce et le transport) : norme des Nations unies décrivant des modalités techniques pour l'échange de données informatisé (EDI) dans différents secteurs industriels.

Endpoints : point d'accès à un service.

ERP (Enterprise Resource Planning) ou Progiciel de gestion intégré (PGI)

ESB (Enterprise Service Bus) : est une architecture fonctionnant comme un bus entre des clients et des fournisseurs de services

EJB (Enterprise JavaBeans) : Extension des JavaBeans permettant de réaliser des composants réutilisables sur n'importe quelle plate-forme Java.

ETL (Extract, Transform and Load) : technologie informatique permettant d'effectuer des synchronisations (« alimentation », « extraction », « transformation », « constitution » ou « conversion », souvent combinés) massives d'information d'une base de données vers une autre

FIX (Financial Information eXchange) : standard de message développé dans le but de faciliter les échanges d'informations relatifs aux transactions boursières.

Hash-coding : Technique logicielle permettant d'attribuer un emplacement de mémoire grâce à un calcul faisant intervenir directement l'Information à ranger ou à retrouver.

HL7 (Health Level 7) : standard qui devient internal, définissant un format pour les échanges informatisés de données cliniques, financières et administratives entre systèmes d'information hospitaliers.

Http (HyperText Transfer Protocol): dans le protocole de transfert Hyper Texte, une méthode est une commande spécifiant un type de requête demandant au serveur d'effectuer une action. Cette action concerne une ressource identifiée par l'URL qui suit le nom de la méthode. SSL est une forme sécurisée de HTTP.

Hub : point central où convergent les informations du système.

IBM WebSphere MQ, anciennement MQ Series est une famille de logiciels, développé par IBM depuis 1992. Service de messagerie inter-applicative (ou MOM : Message Oriented Middleware), permettant la communication entre différentes applications, via l'utilisation de files d'attente.

IDE (Environnement Intégré de Développement) : Outils se présentant comme un ensemble de consoles intégrées qui permet la gestion complète du cycle de vie des composants techniques et fonctionnels entrant dans la composition d'un système d'information conforme à une architecture SOA.

ITIL (Information Technology Infrastructure Library) : ensemble de 5 ouvrages recensant les bonnes pratiques en matière informatique (la dernière version : Version 3, est sortie en mai 2007). On trouve le berceau d'Itil en Angleterre dès la fin des années 1980. Le gouvernement Thatcher souhaite mettre en concurrence systématique les prestations informatiques internes des services publics avec l'offre du marché (Market testing).

Java : langage de programmation orienté objet avec la particularité principale que les logiciels écrits en java sont très facilement portables sur plusieurs systèmes d'exploitation tels que Unix, Microsoft Windows, Mac OS ou Linux avec peu ou pas de modifications.

JCA (Java connector architecture) : solution de J2EE pour résoudre le problème d'intégration entre le monde J2EE et le système d'information d'entreprise

JBI (Java Business Intégration) : spécification normalisant ces intégrations via un jeu d'API permettant à tout fournisseur de pouvoir se connecter à un conteneur JBI pour échanger des messages avec le reste du SI.

JMS (Java Message Service) : Interface Java standard d'accès à un système de messagerie (ex MOM) pour l'échange fiable de messages entre applications ou machines. Noter que JMS ne standardise pas le système de messagerie utilisé.

JVM (Java Virtual Machine, en français Machine virtuelle Java) : machine virtuelle permettant d'interpréter et d'exécuter le bytecode Java.

KAI (Key Agility Indicator) : notion d'évaluation de l'agilité avancée par Tami Cannizzaro, directeur SOA chez IBM.

Legacy System : vieux Mainframe plébiscités par les utilisateurs qui refusent parfois de changer d'application auxquels ils sont attachés

Liberty Alliance : aussi connu sous le nom de Project Liberty, projet réunissant depuis 2001 des acteurs industriels, informatiques, bancaires et gouvernementaux sous la forme d'un consortium afin de définir des spécifications de protocoles de fédération d'identité et de communication entre services web.

M2M (machine to machine) : technologie permettant des communications entre machines sans intervention humaine.

Mappage (mapping) : définition d'une correspondance entre deux objets de même nature mais pas de même forme.

MDA (Model driven architecture,) : Démarche de réalisation de logiciel, proposée et soutenue par l'OMG. C'est une variante particulière de l'ingénierie dirigée par les modèles. Le principe de base du MDA est l'élaboration de modèles indépendants de plate-formes (Platform Independent Model, PIM) et la transformation de ceux-ci en modèles dépendants de plates-formes(Platform Specific Model, PSM) pour l'implémentation concrète du système. Les techniques employées sont donc principalement des techniques de modélisation et des techniques de transformation de modèles.

MOM (Message Oriented Middleware) : système de messagerie pour la transmission de messages entre applications.

Monde clos : Hypothèse selon laquelle tout ce qui n'est pas dit est faux.

Netbeans : IDE libre en java édité par SUN et open source depuis 2000.

OASIS : consortium mondial qui travaille pour la normalisation et la standardisation de formats de fichiers ouverts basés notamment sur XML. Créé en 1993, il compte 3500 membres faisant partie de 600 organisations dans 100 pays. OASIS est structuré en groupes de travail appelés les Technical Committees.

OMG : organisme à but non lucratif, créé en 1989 à l'initiative de grandes sociétés (HP, Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fédère plus de 850 acteurs du monde informatique. Son rôle est de promouvoir des standards qui garantissent l'interopérabilité entre applications orientées objet, développées sur des réseaux hétérogènes.

Ontologie : cherche à représenter le sens des concepts d'un domaine et les relations qui les lient.

ORB : s'apparente à un bus permettant les échanges de messages entre objets.

Orchestration : système qui permet de superviser les chaînes applicatives dont les maillons sont des services.
L'orchestration assure la succession des tâches, le contrôle de la bonne exécution, les reprises en cas d'incident.

OW2 : ObjectWeb est un consortium actif d'industriels internationaux (INRIA, Bull, France Télécom, Thales Group ou Red Hat) engagé en matière de Commerce électronique, d'EAI, de Services web. Il s'engage sur le respect de standard de l'OMG (Object Management Group), le JCP (Java Community Process ), OSGi (Open Services Gateway initiative).

OWL : est un dialecte XML basé sur une syntaxe RDF. Il fournit les moyens pour définir des ontologies Web structurées.

OWL-S : OWL pour les services.

Pare-feu : élément du réseau, qui a pour fonction de faire respecter la politique de sécurité en définissant quels sont les types de communication autorisés ou interdits.

Parseur (Parser) : module analysant et décodant les balises d'un document XML afin de permettre à l'application utilisant ce parseur de traiter les données.

PDM (Plateform Description Model) : correspond au modèle de transformation du PIM vers le PSM.

Petals : bus d'entreprise orienté services (ESB) hautement distribué, construit sur les spécifications JBI. Le projet est dirigé par EBM Websourcing, et développé selon les orientations du consortium OW2.

PRA (Plan de Reprise d'Activité) : plan permettant d'assurer, en cas de crise majeure ou importante d'un centre informatique, la reconstruction de son infrastructure et la remise en route des applications.

QOS : La qualité de service (QoS, Quality of Service) est la capacité à véhiculer un type de trafic donné, en termes de disponibilité, débit, délais de transmission etc ...

RDF : langage de base du Web sémantique.

RDF-S : RDFS fournit des éléments de base pour la définition d'ontologies ou vocabulaires destinés à structurer des ressources RDF.

Référentiel de Méta-données : sert à décrire l'ensemble des règles, définitions, transformations et processus associés à une donnée.

Réification : action de transposer une abstraction en un objet concret.

Rose : Logiciel de modélisation UML édité par Rational Software. Il permet de générer automatiquement du code Java, C++ ou Visual Basic à partir du modèle objet.

RPC (Remote Procédure Call) : protocole permettant de faire des appels de procédures sur un ordinateur distant à l'aide d'un serveur d'application.

Scalabilité : capacité d'un composant à être utilisé sur des plates-formes beaucoup plus petites et plus grosses.

Service Web (Web Service) : groupe de fonctions accessibles par un client Web en SOAP, codées en WSDL.

Servlet : application Java qui permet de générer dynamiquement des données au sein d'un serveur HTTP.

SMA (systèmes multi-agent) : ensemble d'agents situés dans un certain environnement et interagissant selon une certaine organisation. Un agent est une entité caractérisée par le fait qu'elle est, au moins partiellement, autonome. Ce peut-être un processus, un robot, un être humain, etc...

SOAML (Service-oriented architecture Modeling Language) : Langage de modélisation SOA.

Soap (Simple Object Access Protocol) : protocole de RPC orienté objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se faire par un autre protocole, comme SMTP.

Taxonomie ou taxinomie : science qui a pour objet de décrire les organismes vivants et de les regrouper en entités appelées taxons afin de pouvoir les identifier puis les nommer, et enfin les classer.

Tuxedo (Transactions for Unix, Extended for Distributed Operations) : logiciel middleware destiné à gérer les transactions dans un environnement distribué pour systèmes Unix, conçu en 1983.

UDDI (Universal Discovery, Description and Integration) : spécification d'accès en langage XML à un catalogue de services offerts par des fournisseurs de services, permettant à un consommateur de services de localiser et d'obtenir les caractéristiques de services dont il a besoin afin de pouvoir invoquer les fournisseurs de ces services.

UML (Unified Modeling Language ou langage de modélisation unifié) : langage graphique de modélisation des données et des traitements. Pour approfondir : http://www.uml.org.

UPMS (UML Profile and Metamodel for Service) : spécification de l'OMG appliquée aux Services via les profils UML.

URI (Uniform Resource Identifier) : chaîne de caractères identifiant une ressource sur un réseau

Workflow : décrit le circuit de validation, les tâches à accomplir entre ldifférents acteurs d'un processus, les délais, les modes de validation, et fournit à chacun des acteurs les informations nécessaires pour la réalisation de sa tâche

WS-Federation : spécification développées par BEA Systems, BMC Software, CA, Inc., IBM, Layer 7 Technologies, Microsoft, Novell, définissant les mécanismes de sécurité.

WS-I (Web Services Interoperability) : consortium d'industriels de l'industrie du logiciel : BEA, IBM, Microsoft, Oracle, HP, SAP, INTEL et SUN) oeuvrant à la promotion de l'interopérabilité entre plate-formes par la rédaction des spécifications des Services Web annotés : WS-*. Le WS-I a été initié en 2000.

WSDL (Web Services Description Language) : normalisation regroupant la description des éléments permettant de mettre en place l'accès à un service web. Pour cela il utilise le langage XML, dans sa version 2.0 approuvé par le W3C.

W3C (World Wide Web Consortium) organisme de normalisation a but non-lucratif, fondé 1994. Consortium actif dans la promotion des technologies Web telles que HTML, XHTML, XML, RDF, CSS, PNG, SVG et SOAP, le W3C n'émet aucune norme, mais des recommandations considérés comme des standards industriels.

XMI (XML Metadata Interchange) : définit un format d'échange standard entre ateliers logiciels.

XML (Extensible Markup Language) : méta-language développé par le W3C permettant de définir des langages de marquage de documents ou de messages, au centre d'un ensemble de standards dédiés à la communication dans les systèmes d'information.

XPDL (XML Process Definition Language) : standard de la Workflow Management Coalition qui permet de définir un processus métier avec XML, pour ensuite l'utiliser dans un moteur de workflow.

XSD (XML Schema Description) : recommandation par le W3C en mai 2001 est un langage de description de format de document XML permettant de définir la structure d'un document XML.

Zero Latency : L'information doit ou est immédiatement disponible à un autre point du système.

Table des Illustrations

Illustration 1 : Cartouche Mémoire 8

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

Illustration 3 : la Rome Antique où l'ominiprésence de la religion 11

Illustration 4 : Interfaçage Point à Point 14

Illustration 5 : ETL : le plat de spaghettis semble plus organisé 15

Illustration 6 : Constitution d'un ETL 16

Illustration 7 : EAI : le plat de spaghettis semble plus ordonnancé et mieux distribué 17

Illustration 8 : Constitution d'un E.A.I. 20

Illustration 9 : Cas d'utilisation / Services 26

Illustration 10 : Service SU - Get FTP 27

Illustration 11 : Service SA pointant sur un SU FTP 27

Illustration 12 : Constitution d'un ESB 28

Illustration 13 : Articulation Référentiel / UDDI 29

Illustration 14 : Diagramme de séquence d'exécution d'un service 30

Illustration 15 : Diagramme de séquences d'un échange In Out se terminant normalement 31

Illustration 16 : Diagramme de séquences d'un échange In Out se terminant en erreur 31

Illustration 17 : ESB + BPM + BAM + IDE : les Clefs de l'agilité ? 32

Illustration 18 : Différentiation Service / Composant 35

Illustration 19 : Service 36

Illustration 20 : Cycle de vie des services ITIL 36

Illustration 21 : Extrapolation de la représentation des cas d'utilisation pour illustrer les Opérations 37

Illustration 22 : Phases d'orchestration vues au travers d'un diagramme d'activités réalisé sous Magicdraw 38

Illustration 23 : Diagramme de Composants réalisé sous Magicdraw 38

Illustration 24 : Couplage fort 39

Illustration 25 : Couplage faible 39

Illustration 26 : Pré et post conditions d'un service 40

Illustration 27 : Erreur véhiculée dans un message SOAP 41

Illustration 28 : Pré et post conditions d'un service 41

Illustration 29 : Traduction XML des contraintes via MagicDraw 42

Illustration 30 : Données d'échange et Format pivot XML (Master Data Managment) 43

Illustration 31 : Répartition entre domaine privé et domaine public 45

Illustration 32 : Gains pour le département Informatique 52

Illustration 33 : Etapes de la démarche MDA 58

Illustration 34 : Articulation MDA 59

Illustration 35 : Réalisation Model Driven Architecture (MDA) 61

Illustration 36 : BPEL : Demande de Prêt réalisé avec Netbeans 6.5 63

Illustration 37 : Traduction XML du BPEL (extrait des Acteurs) 63

Illustration 38 : D'UML vers BPEL et WSDL 65

Illustration 39 : Mise en place d'un processus 65

Illustration 40 : Sous Estimation de la charge par Todd Little 69

Illustration 41 : Conduite de projet classique, diagramme de Timing UML 2.0 69

Illustration 42 : Projet Lean, diagramme de Timing UML 2.0 70

Illustration 43 : Interactions au sein d'un projet 71

Illustration 44 : Courbe du stress 71

Illustration 45 : Le Cycle itératif 72

Illustration 46 : Bilan de fin d'itération 74

Illustration 47 : Cellule transverse chargée de gérer les services 75

Illustration 48 : Proposition de fiche de service 76

Illustration 49 : Cartographie macroscopique réalisé sous Netbeans 77

Illustration 50 : Méta-modèle du Processus 79

Illustration 51 : Constitution d'une Architecture SOA (clin d'oeil à Vitruve) 85

Illustration 52 : Standardisation des Web Service 86

Illustration 53 : La Galaxie XML 87

Illustration 54 : Grid XML des Animaux de la Ferme, réalisé avec XmlSpy 89

Illustration 55 : Extrait XML du 1ère Atelier 89

Illustration 56 : Illustration et extrait XSD, réalisés avec XmlSpy 90

Illustration 57 : Triplet RDF 91

Illustration 58 : URI 92

Illustration 59 : Extrait RDF, réalisé avec XmlSpy 92

Illustration 60 : RDFS 93

Illustration 61 : Réification 93

Illustration 62 : Langage OWL Lite 94

Illustration 63 : Langage OWL DL et Full 95

Illustration 64 : Diagramme de classe correspondant à l'ontologie décrite en exemple 96

Illustration 65 : Correspondance sémantique de deux ontologies 97

Illustration 66 : Ontologie de présentation déduite des deux autres ontologies 97

Illustration 67 : Ontologie des services 98

Illustration 68 : Ontologie du ServiceProfile 99

Illustration 69 : Ontologie du ServiceModel 100

Illustration 70 : Correspondance entre OWL-S et WSDL 101

Illustration 71 : Expression d'une définition de paramètres OWL-S 102

Illustration 72 : Expression d'un pré condition OWL-S 102

Illustration 73 : Comparaison BEA des coûts selon une approche traditionnelle et SOA 106

Illustration 74 : Productions de la Coopérative Terrena en 2006 109

Illustration 75 : Organisation par pôles des Productions de la Coopérative 109

Illustration 76 : Echanges inter-outils 110

Illustration 77 : Cartographie actuelle façon Package UML 113

Illustration 78 : Cartographie actuelle, façon MEGA 113

Illustration 79 : XSD du processus d'alimentation des tiers réalisé avec XmlSpy 115

Illustration 80 : Extrait de l'inventaire XML des activités d'alimentation de tiers 116

Illustration 81 : Diagramme Causes-Effets d'Ishikawa 120

Illustration 82 : Extrait SOAml 121

Illustration 83 : Architecture logicielle de l'agent 122

Illustration 84 : Système de transition d'états appliqué à notre échange de fichier Tiers 123

Illustration 85 : Diagramme Etat-Transition de l'objet Message 124

Illustration 86 : Exemple de représentation d'un état 126

Illustration 87 : Diagramme de classes de l'Agent, réalisé sous magicdraw 127

Illustration 88 : Diagramme de communication, réalisé sous Magicdraw 129

Illustration 89 : Diagramme de classes, réalisé sous Magicdraw 130

Illustration 90 : Cas d'utilisation UML de la communication actuelle 131

Illustration 91 : Processus métier actuel, BPMN réalisé avec Magicdraw 132

Illustration 92 : Les Consommateurs et le Fournisseur 133

Illustration 93 : Diagramme d'activité actuel 135

Illustration 94 : Diagramme de séquence de l'activité d' « Attente de fin de transfert » 139

Illustration 95 : Diagramme de séquence de l'activité « Contrôle du contenant » 141

Illustration 96 : Entête d'un Message SOAP 142

Illustration 97 : Couche Transport 143

Illustration 98 : Diagramme de séquence de la distribution 144

Illustration 99 : Composants de la démarche MDA aboutissant aux étapes de réalisation 149

Illustration 100 : Composants SOA : Objets pivots et métiers, interfaces et services 151

Illustration 101 : Cartographie cible Selon les règles de Longépé 152

Illustration 102 : Les trois types d'objets selon Jacobson 153

Illustration 103 : Cas d'utilisation obtenu par lecture de la cartographie cible 154

Illustration 104 : Diagramme BPMN réalisé sous Magicdraw 155

Illustration 105 : Diagramme de classe obtenu à partir du BPMN 156

Illustration 106 : Diagramme d'Etats Transitions obtenu à partir du BPMN 157

Illustration 107 : Diagramme de Séquences obtenu à partir du BPMN 158

Illustration 108 : Diagramme d'Activités obtenu à partir du BPMN 159

Illustration 109 : SOA, une architecture interopérable 160

Illustration 110 : Interaction Processus-Composants-Ressources 161

Illustration 111 : Début d'ontologie réalisée avec Protégé 162

Illustration 112 : Extrait xml de la personne morale 163

Illustration 113 : Typologies d'adresse référencées par l'INSEE présentées via XmlSpy 163

Illustration 114 : Inclusion de Module d'information 164

Illustration 115 : Représentation XmlSpy d'un Xml Schema de la Personne Physique selon l'Insee 165

Illustration 116 : Tiers, une Ontologie à trois niveaux 171

Illustration 117 : Diagramme de Classe des Tiers réalisé sous MagicDraw 172

Illustration 118 : BPEL réalisé sous Magicdraw à partir d'un diagramme BPMN valide 174

Illustration 119 : Diagramme XML réalisée à partir d'un diagramme de classes au profil UML standard 177

Illustration 120 : Adaptations manuelles impactées au modèle XML 178

Illustration 121 : Exposition d'un service pour le consommateur 179

Illustration 122 : Interface entre le composant de détection de fichier et le composant de transformation 179

Illustration 123 : Exemple de modelisation d'un service de données ou CRUD 180

Illustration 124 : Diagramme WSDL du CRUD d'extraction réalisé sous MagicDraw 182

Illustration 125 : Code WSDL du CRUD d'extraction 182

Illustration 126 : Modélisation d'un composant selon les spécifications UML 2.0, réalisé sous MagicDraw 184

Illustration 127 : Notation UML 2 pour l'assemblage des composants 184

Illustration 128 : Diagramme WSDL du service de transformation réalisé sous MagicDraw 185

Illustration 129 : Code WSDL du service de transformation 185

Illustration 130 : Cycle de vie d'un document XML Tiers 186

Illustration 131 : Document XML VQTIERS 190

Illustration 132 : Assemblage de la transformation pour la JBI (Jbi.xml) 191

Illustration 133 : Représentation graphique de la connexion des deux services unitaires, réalisé sous Netbeans 192

Illustration 134 : Représentation graphique du WSDL, réalisé sous XmlSpy 193

Illustration 135 : Paramètre du service 193

Illustration 136 : Mapping de transformation XSLT entre le message Input et Output, réalisé sous Netbeans 194

Illustration 137 : Traduction XML dans le fichier to_grc.xsl 194

Illustration 138 : Représentation graphique du transfert du fichier XML par FTP, réalisé sous Netbeans 195

Illustration 139 : Assemblage du transfert FTP pour la JBI (Jbi.xml) 196

Illustration 140 : Représentation graphique de l'orchestration, réalisée sous Netbeans 197

Illustration 141 : Actions du processus BPEL (extrait du PUT_GRC.bpel) 198

Illustration 142 : Assemblage File, FTP, XSLT, BPEL, réalisé sous Netbeans 199

Illustration 143 : Nouveau Profil SOAml intégré à MagicDraw 16.1 203

Illustration 144 : Les cycles de l'évolution IT 207

Illustration 145 : Extrapolation des cycles de Raccoon 208

Illustration 146 : Classe sous Rose 235

Illustration 147 : la "Demande de Prêt" 235

Illustration 148 : Export XMI 236

Illustration 149 : Extrait de la traduction BPEL 237

Illustration 150 : Déploiement du Processus 238

Illustration 151 : Déploiement des services 238

Illustration 152 : Spécification SOAml des Services d'après l'OMG 241

Illustration 153 : Spécification SOAml des Contrats de Services d'après l'OMG 242

Illustration 154 : Collaboration UML autour d'une vente 242

Illustration 155 : Architecture des Services de transfert d'information appliquée à SOAML 243

Table des Tableaux

Tableau 1 : Services Vs Composants 46

Tableau 2 : Richesse des standards en matière de processus Métiers 64

Tableau 3 : Principaux Outils BPM 80

Tableau 4 : Principaux Outils BAM 80

Tableau 5 : Versions UDDI 82

Tableau 6 : Principaux UDDI 82

Tableau 7 : Mots clefs permettant la construction d'un process composite 101

Tableau 8 : triplet RDF 125

Tableau 9 : Bonnes pratiques SOA 139

Tableau 10 : Fiche Service 181

Tableau 11 : Mapping UML / BPEL 236

Table des Dessins

Dessin 1 : Portrait, époque Renaissance, de Marcus Vitruvius Pollio (-90 à -20) 1

Annexes

Enumérations

CJ : Catégories juridiques (extrait)

1 PERSONNE PHYSIQUE

2 GROUPEMENT DE DROIT PRIVÉ NON DOTÉ DE LA PERSONNALITÉ MORALE

21 Indivision

2110 Indivision entre personnes physiques

2120 Indivision avec personne morale

22 Société créée de fait

2210 Société créée de fait entre personnes physiques

2220 Société créée de fait avec personne morale

23 Société en participation

2310 Société en participation entre personnes physiques

2320 Société en participation avec personne morale

2385 Société en participation de professions libérales

2700 Paroisses hors zone concordataire

2900 Autre groupement de droit privé non doté de la personnalité morale

3 PERSONNE MORALE DE DROIT ÉTRANGER

31 Personne morale de droit étranger immatriculée au RCS

3110 Représentation ou agence commerciale d'état ou organisme public étranger immatriculée au RCS

3120 Société étrangère immatriculée au RCS

32 Personne morale de droit étranger non immatriculée au RCS

3205 Organisation internationale

3210 Etat, collectivité ou établissement public étranger

3220 Société étrangère non immatriculée au RCS

3290 Autre personne morale de droit étranger

4 PERSONNE MORALE DE DROIT PUBLIC SOUMISE AU DROIT COMMERCIAL

41 Etablissement public ou régie à caractère industriel ou commercial

4110 Etablissement public national à caractère industriel ou commercial doté d'un comptable public

4120 Etablissement public national à caractère industriel ou commercial non doté d'un comptable public

4130 Exploitant public

4140 Etablissement public local à caractère industriel ou commercial

4150 Régie d'une collectivité locale à caractère industriel ou commercial

4160 Institution Banque de France

5 SOCIÉTÉ COMMERCIALE

51 Société coopérative commerciale particulière

5191 Société de caution mutuelle

5192 Société coopérative de banque populaire

5193 Caisse de crédit maritime mutuel

5194 Caisse (fédérale) de crédit mutuel

5195 Association coopérative inscrite (droit local Alsace et Moselle)

52 Société en nom collectif

5202 Société en nom collectif

5385 Société d'exercice libéral en commandite par actions

54 Société à responsabilité limité (SARL)

5410 SARL nationale

5415 SARL d'économie mixte

5422 SARL immobilière pour le commerce et l'industrie (SICOMI)

5460 Autre SARL coopérative

5485 Société d'exercice libéral à responsabilité limitée

5498 SARL unipersonnelle

5499 Société à responsabilité limitée (s.a.i.)

55 Société anonyme (SA) à conseil d'administration

5505 SA à participation ouvrière à conseil

5510 SA nationale à conseil

5515 SA d'économie mixte à conseil

5520 Société d'investissement à capital variable (SICAV) à conseil

5522 Société anonyme immobilière pour le commerce et l'industrie (SICOMI) à conseil

5525 Société anonyme immobilière d'investissement à conseil

5530 Société anonyme d'aménagement foncier et d'équipement rural (SAFER) à conseil

5531 Société anonyme mixte d'intérêt agricole (SMIA) à conseil

5532 Société anonyme d'intérêt collectif agricole à conseil

5547 SA coopérative de production de HLM à conseil

5548 SA de crédit immobilier à conseil

5551 SA coopérative de consommation à conseil

5555 SA coopérative de transport à conseil

5558 SA coopérative ouvrière de production et de crédit à conseil

5559 SA union de sociétés coopératives à conseil

5560 Autre SA coopérative à conseil

5585 Société d'exercice libéral à forme anonyme à conseil d'administration

5599 SA à conseil d'administration (s.a.i.)

56 Société anonyme (SA) à directoire

5605 SA à participation ouvrière à directoire

5610 SA nationale à directoire

5615 SA d'économie mixte à directoire

5620 Société d'investissement à capital variable (SICAV) à directoire

5622 Société immobilière pour le commerce et l'industrie (SICOMI) anonyme à directoire

5625 Société immobilière d'investissement à directoire

5630 SAFER anonyme à directoire

5631 Société mixte d'intérêt agricole (SMIA)

5632 Société d'intérêt collectif agricole (SICA)

5642 Société d'attribution anonyme à directoire

5643 Société coopérative de construction anonyme à directoire

5646 SA de HLM à directoire

5647 SA coopérative de production HLM à directoire

5648 SA de crédit immobilier à directoire

5651 SA coopérative de consommation à directoire

5652 SA coopérative de commerçants-détaillants à directoire

5653 SA coopérative artisanale à directoire

5654 SA coopérative (d'intérêt) maritime à directoire

5655 SA coopérative de transport à directoire

5658 SA coopérative ouvrière de production et de crédit à directoire

5659 SA union de sociétés coopératives à directoire

5660 Autre SA coopérative à directoire

5685 Société d'exercice libéral à forme anonyme à directoire

5699 SA à directoire (s.a.i.)

5710 SAS, société par actions simplifiée

5720 SASU, société par actions simplifiée unipersonnelle

6 AUTRES PERSONNES MORALES IMMATRICULÉES AU REGISTRE DU COMMERCE ET DES SOCIÉTÉS

6100 Caisse d'Épargne et de Prévoyance

62 Groupement d'intérêt économique (GIE)

6210 Groupement européen d'intérêt économique (GEIE)

6220 Groupement d'intérêt économique (GIE)

63 Société coopérative agricole

6316 Coopérative d'utilisation de matériel agricole en commun (CUMA)

6317 Société coopérative agricole

6318 Union de sociétés coopératives agricoles

64 Société non commerciale d'assurance

6411 Société d'assurance à forme mutuelle

6412 Société mutuelle d'assurance

6413 Union de sociétés mutuelles d'assurance

6414 Autre société non commerciale d'assurance

65 Société civile

6521 Société civile de placement collectif immobilier (SCPI)

6532 Société civile d'intérêt collectif agricole (SICA)

6533 Groupement agricole d'exploitation en commun (GAEC)

6534 Groupement foncier agricole

6535 Groupement agricole foncier

6536 Groupement forestier

6537 Groupement pastoral

6539 Société civile foncière

6540 Société civile immobilière

6541 Société civile immobilière de construction-vente

6542 Société civile d'attribution

6543 Société civile coopérative de construction

6554 Société civile coopérative (d'intérêt) maritime

6558 Société civile coopérative entre médecins

6560 Autre société civile coopérative

6561 Société Civile Professionnelle (SCP) d'avocats

6562 SCP d'avocats aux conseils

6563 SCP d'avoués d'appel

6564 SCP d'huissiers

6565 SCP de notaires

6566 SCP de commissaires-priseurs

6567 SCP de greffiers de tribunal de commerce

6568 SCP de conseils juridiques

6569 SCP de commissaires aux comptes

6571 SCP de médecins

6572 SCP de dentistes

6573 SCP d'infirmiers

6574 SCP de masseurs-kinésithérapeutes

6575 SCP de directeurs de laboratoires d'analyse médicale

6576 SCP de vétérinaires

6577 SCP de géomètres experts

6578 SCP d'architectes

6585 Autre société civile professionnelle

6589 Société civile de moyens

6595 Caisse (locale) de crédit mutuel

6596 Caisse de crédit agricole mutuel

6597 Société civile d'exploitation agricole

6598 Exploitation agricole à responsabilité limitée

6599 Autre société civile

6901 Autre personne de droit privé inscrite au registre du commerce et des sociétés

7 PERSONNES MORALES ET ORGANISMES SOUMIS AU DROIT ADMINISTRATIF

7348 Communauté d'agglomérations

8 ORGANISME PRIVE SPECIALISE

81 Organisme gérant un régime de protection sociale à adhésion obligatoire

8110 Régime général de la Sécurité Sociale

8140 Mutualité sociale agricole

8150 Régime maladie des non-salariés non agricoles

8160 Régime vieillesse ne dépendant pas du régime général de la Sécurité Sociale

8170 Régime d'assurance chômage

8190 Autre régime de prévoyance sociale

82 Organisme mutualiste

8210 Mutuelle

8250 Assurance mutuelle agricole

8290 Autre organisme mutualiste

83 Comité d'entreprise

8410 Syndicat de salariés

8420 Syndicat patronal

8450 Ordre professionnel ou assimilé

8470 Centre technique industriel ou comité professionnel de développement économique

8490 Autre organisme professionnel

85 Organisme de retraite à adhésion non obligatoire

8510 Institution de prévoyance

8520 Institution de retraite supplémentaire

9 GROUPEMENT DE DROIT PRIVÉ

91 Syndicat de propriétaires

9110 Syndicat de copropriété

9150 Association syndicale libre

92 Association (loi de 1901) et assimilés

9240 Congrégation

9260 Association de droit local (Bas-Rhin, Haut-Rhin et Moselle)

9300 Fondation

9900 Autre personne morale de droit privé

TL :Type de lien fonctionnel

Lien entre deux organisations :

Contrat de gérance de l'organisation

Mise en location d'une organisation

Partenariat

Lien économique (client / fournisseur)

Obligations (contrats et réglementations)

Gestion/conduite (entre une entreprise et une exploitation)

Lien entre une organisation et une personne :

Administrateur

Associé

Conjoint co-exploitant

Contact

Directeur

Dirigeant

Expert

Gérant

Maire

Mandataire

Mandataire Exploitation en commun

Président

Représentant ou assimilé

Salarié (CDD, CDI, CNE, vacataire)

Conjoint collaborateur

Aide familiale

Stagiaire

Actionnaire

Représentant légal

Lien entre deux personnes :

contrat (travail, bail, mariage, PACS, ...)

associé,

Supérieur hiérarchique.

TA : Types Adresses

Postale,

Relais Appro,

Relais Céréale

.../...

CP : Codes Postaux

http://www.laposte.fr/ (Site Service National de l'Adresse)

LL : Liste des Localités

http://www.laposte.fr (Site Service National de l'Adresse)

LL : Liste des Pays

http://www.iso.org/iso/fr/CatalogueListPage.CatalogueList

TC : Type de moyen de Communication

téléphone fixe,

téléphone mobile,

adresse électronique,

URL,

télécopie,

telex,

Ftp...

NL : Nature du lien entre deux exploitations

Reprise = R (l'organisation actuelle succède à l'organisation précédente)

Fusion = F (l'organisation actuelle a absorbé l'organisation précédente : plusieurs liens de fusion pour l'organisation actuelle)

Scission = S (l'organisation actuelle est une émanation de l'organisation précédente : plusieurs liens de scission pour l'organisation précédente)

CA : Codes Activités Agricoles

Extrait de la nomenclature NAF (Nomenclature des Activités Françaises)

01.1A Culture de céréales ; cultures industrielles

01.1C Culture de légumes ; maraîchage

01.1D Horticulture ; pépinières

01.1F Culture fruitière

01.1G Viticulture

01.2A Elevage de bovins

01.2C Elevage d'ovins, caprins et équidés

01.2E Elevage de porcins

01.2G Elevage de volailles

01.2J Elevage d'autres animaux

01.3Z Culture et élevage associés

01.4A Services aux cultures productives

...

01.4D Services annexes à l'élevage

...

15.1F Charcuterie

...

15.4E Fabrication de margarine

15.5A Fabrication de lait liquide et de produits frais

15.5B Fabrication de beurre

15.5C Fabrication de fromages

15.5D Fabrication d'autres produits laitiers

...

15.6A Meunerie

15.6B Autres activités de travail des grains

15.6D Fabrication de produits amylacés

15.7A Fabrication d'aliments pour animaux de ferme

15.7C Fabrication d'aliments pour animaux de compagnie

15.8A Fabrication industrielle de pain et de pâtisserie fraîche

15.8B Cuisson de produits de boulangerie

15.8C Boulangerie et boulangerie-pâtisserie

15.8D Pâtisserie

...

Exemples de grandeurs mesurables et unités associées

Grandeur mesurée	Unité d'expression	Symbole	Nature ou rôle	Multiples utilisés
Longueur	mètre	m		mm, cm, km
Masse	kilogramme	Kg		g, q, t
Temps	Seconde	S		ms, mn, h
Superficie	mètre carré	M2		km², a, ha
Température	Kelvin	K		°C, °F
Volume	mètre cube	M3		mm3, cm3, l, hl
Taux	Pourcentage	%		°/°°

Package Oracle : Extraction

PROCEDURE Demande_Extraction

(

P$Table in Varchar2, -- Table a extraire

P$Fichier in Varchar2, -- Fichier de sortie

P$Repertoire in Varchar2, -- Répertoire de sortie

P$Separateur in Varchar2 Default ',', -- Séparateut Csv

P$Entetes in Varchar2 Default 'O', -- Entete des colonnes

P$Date in Varchar2 Default 'DD/MM/YYYY', -- Format date

P$Where in Varchar2 Default Null, -- Clause Where

P$Order in Varchar2 Default Null -- Clause Order by

) IS

F$Fichier UTL_FILE.FILE_TYPE ;

L$Ligne Varchar2(32767) ;

L$I Integer ;

L$Date Varchar2(40) := '''' || P$Date || '''' ;

XmlFic Utl_File.File_Type;

XmlData CLOB;

Fin BOOLEAN := TRUE;

qryCtx DBMS_XMLGEN.ctxHandle;

TYPE REFCUR1 IS REF CURSOR ;

cur REFCUR1;

-- Colonnes de la table --

CURSOR C_COLTAB ( P$Tab IN VARCHAR2 ) IS

SELECT

COLUMN_NAME,

DATA_TYPE

FROM

USER_TAB_COLUMNS

WHERE

TABLE_NAME = P$Tab

AND

DATA_TYPE IN ('CHAR','VARCHAR2','NUMBER','DATE','FLOAT')

;

L$Separateur Varchar2(2) := P$Separateur ;

L$Requete Varchar2(10000) ;

L$Desc Varchar2(10000) ;

L$SQLW VARCHAR2(10000):= 'SELECT ';

L$Col VARCHAR2(256);

-----------------------------------------

-- Ouverture d'un fichier d'extraction --

-----------------------------------------

FUNCTION Ouvrir_fichier

(

P$Dir in Varchar2,

P$Nom_Fichier in Varchar2

) RETURN UTL_FILE.FILE_TYPE

IS

Fichier UTL_FILE.FILE_TYPE ;

L$Msg Varchar2(256);

Begin

Fichier := UTL_FILE.FOPEN( P$Dir, P$Nom_Fichier, 'W', 32764 ) ;

If not UTL_FILE.IS_OPEN( Fichier ) Then

L$Msg := 'Erreur ouverture du fichier (' || P$Dir || ') ' || P$Nom_Fichier ;

RAISE_APPLICATION_ERROR( -20100, L$Msg ) ;

End if ;

Return( Fichier ) ;

Exception

When UTL_FILE.INVALID_PATH Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'File location is invalid.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.INVALID_MODE Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'The open_mode parameter in FOPEN is invalid.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.INVALID_FILEHANDLE Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'File handle is invalid.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.INVALID_OPERATION Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'File could not be opened or operated on as requested.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.READ_ERROR Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'Operating system error occurred during the read operation.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.WRITE_ERROR Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'Operating system error occurred during the write operation.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.INTERNAL_ERROR then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'Unspecified PL/SQL error';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.CHARSETMISMATCH Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'A file is opened using FOPEN_NCHAR,'

|| ' but later I/O operations use nonchar functions such as PUTF or GET_LINE.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.FILE_OPEN Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'The requested operation failed because the file is open.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.INVALID_MAXLINESIZE Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'The MAX_LINESIZE value for FOPEN() is invalid;'

|| ' it should be within the range 1 to 32767.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.INVALID_FILENAME Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'The filename parameter is invalid.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.ACCESS_DENIED Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'Permission to access to the file location is denied.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.INVALID_OFFSET Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'The ABSOLUTE_OFFSET parameter for FSEEK() is invalid;'

||' it should be greater than 0 and less than the total number of bytes in the file.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.DELETE_FAILED Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'The requested file delete operation failed.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When UTL_FILE.RENAME_FAILED Then

L$Msg := P$Dir || P$Nom_Fichier || ' : ' || 'The requested file rename operation failed.';

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

When others Then

L$Msg := 'Erreur : ' || To_char( SQLCODE ) || ' sur ouverture du fichier ('

|| P$Dir || ') ' || P$Nom_Fichier ;

RAISE_APPLICATION_ERROR( -20070, L$Msg ) ;

End Ouvrir_fichier ;

Begin

-- Ouverture du fichier --

F$Fichier := Ouvrir_fichier( P$Repertoire, P$Fichier||'.txt' ) ;

-- Affichage des entetes de colonne ? --

If Upper(P$Entetes) = 'O' Then

L$I := 1 ;

For COLS IN C_COLTAB( P$Table ) Loop

If L$I = 1 Then

L$Ligne := L$Ligne || COLS.COLUMN_NAME ;

Else

L$Ligne := L$Ligne || L$Separateur || COLS.COLUMN_NAME ;

End if ;

L$I := L$I + 1 ;

End loop ;

-- Ecriture ligne entetes --

UTL_FILE.PUT_LINE( F$Fichier, L$Ligne ) ;

ElsIf Upper(P$Entetes) = 'I' Then

L$Separateur := ',' ;

L$Desc := 'INSERT INTO ' || P$Table || ' (' ;

L$I := 1 ;

For COLS IN C_COLTAB( P$Table ) Loop

If L$I = 1 Then

L$Desc := L$Desc || COLS.COLUMN_NAME ;

Else

L$Desc := L$Desc || L$Separateur || COLS.COLUMN_NAME ;

End if ;

L$I := L$I + 1 ;

End loop ;

L$Desc := L$Desc || ' ) VALUES (' ;

End if ;

-- Réenvoyer un résultat lisible d'un browser dans le cas où l'invocation est faite par HTTP

htp.htmlopen;htp.bodyopen;htp.line;

htp.tableopen('border');

htp.tablecaption(P$Table,'center');

htp.tablerowopen;

--

htp.tableheader(L$Ligne);

----

-- Génération de la requete --

L$I := 1 ;

FOR COLS IN C_COLTAB( P$Table ) LOOP

IF L$I > 1 THEN

L$SQLW := L$SQLW || '||' ;

END IF ;

If COLS.DATA_TYPE IN ('NUMBER','FLOAT') Then

L$Col := 'Decode(' || COLS.COLUMN_NAME || ',NULL, ''NULL'',To_char("'

|| COLS.COLUMN_NAME || '"))' ;

ElsIf COLS.DATA_TYPE = 'DATE' Then

If Upper(P$Entetes) = 'I' Then

L$Col := 'Decode(' || COLS.COLUMN_NAME || ',NULL,''NULL'',''to_date(''''''||'

|| 'To_char("' || COLS.COLUMN_NAME || '",'|| L$Date ||')' || '||'''''','''|| L$Date||''')'')' ;

Else

L$Col := 'To_char("'|| COLS.COLUMN_NAME || '",'|| L$Date ||')' ;

End if ;

Else

If Upper(P$Entetes) = 'I' Then

L$Col := 'Decode(' || COLS.COLUMN_NAME || ',NULL, ''NULL'',' || ''''''''''

|| '|| REPLACE("'|| COLS.COLUMN_NAME || '",CHR(39),CHR(39)||CHR(39))' || '||' || ''''''''')' ;

Else

L$Col := '"'|| COLS.COLUMN_NAME || '"' ;

End if ;

End if ;

IF L$I = 1 THEN

L$SQLW := L$SQLW || L$Col ;

ELSE

L$SQLW := L$SQLW || '''' || L$Separateur || '''' || '||' || L$Col ;

END IF ;

L$I := L$I + 1 ;

END LOOP ;

L$Requete := L$SQLW || ' FROM ' || P$Table ;

If P$Where is not null Then

-- ajout de la clause WHERE --

L$Requete := L$Requete || ' WHERE ' || P$Where ;

End if ;

If P$Order is not null Then

-- ajout de la clause ORDER BY --

L$Requete := L$Requete || ' ORDER BY ' || P$Order ;

End if ;

--F_TRACE( L$Requete, 'T' ) ;

htp.tableRowClose;

htp.tablerowopen;

-- Extraction des lignes --

Open cur For L$Requete ;

Loop

Fetch cur Into L$Ligne ;

Exit when cur%NOTFOUND ;

--

htp.tablerowopen;

htp.tabledata(L$Ligne);

htp.tablerowclose;

--

-- Ecriture du fichier de sortie --

If Upper(P$Entetes) = 'I' Then

UTL_FILE.PUT_LINE( F$Fichier, L$Desc || L$Ligne || ' );' ) ;

Else

UTL_FILE.PUT_LINE( F$Fichier, L$Ligne ) ;

End if ;

End loop ;

--

htp.tablerowclose;

htp.tableclose;

htp.bodyclose;

htp.htmlclose;

--

Close cur ;

-- Fermeture fichier --

UTL_FILE.FCLOSE( F$Fichier ) ;

if P$Where is null

then

qryCtx := dbms_xmlgen.newContext ('select * FROM '|| P$Table || '');

else

qryCtx := dbms_xmlgen.newContext ('select * FROM '|| P$Table || ' where ' || P$Where || '');

end if;

DBMS_XMLGEN.setRowsettag(qryCtx, '');

DBMS_XMLGEN.setRowTag(qryCtx, P$Table);

DBMS_XMLGEN.setMaxRows(qryCtx, 1);

-- Créer des données au format XML à partir d'une requête :

XmlData :=DBMS_XMLGEN.getXML(qryCtx);

-- Copie les données au format XML dans un fichier :

XmlFic := sys.Utl_File.FOpen (P$Repertoire, P$Table||'.xml', 'W');

WHILE FIN LOOP

-- Assigner le XML Schema

xmldata := REPLACE(Xmldata,'<'||P$Table||'>',

'<'||P$Table||'_PIVOT:'||P$Table||' xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:'||P$Table||'_PIVOT="http://xml.netbeans.org/schema/'||P$Table||'"

xsi:schemaLocation="http://xml.netbeans.org/schema/'||P$Table||' '||P$Table||'.xsd">');

xmldata := REPLACE(Xmldata,'</'||P$Table||'>','</'||P$Table||'_PIVOT:'||P$Table||'>');

Utl_File.Put (XmlFic, SUBSTR (XmlData,1,32767));

Utl_File.FFlush(XmlFic);

IF LENGTH (XmlData) > 32767 THEN

XmlData := SUBSTR (XmlData, 32768);

ELSE

FIN := FALSE;

DBMS_OUTPUT.PUT_LINE ('FIN');

END IF;

END LOOP;

Utl_File.FClose (XmlFic);

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

Pseudo Code L3G :

Début de saisie d'un devis pour un tiers (client, produit, quantite, date_livraison)

select * from Client where nomduClient='client'

Si Client n'existe pas

Alors

Saisir information du client

insert into Client... values...

Fin

select * from Produit where nomduProduit = `produit'

Si Produit.quantitestock - quantite_reservee < quantite

Alors

select Produit.delais from Produit where nomduProduit = `produit'

si Date_jour + Produit.delais > date_livraison

Alors

Message «Devis refusé car stock indisponible dans délais imparti»

Exit

Fin

Fin

Update produit set quantite_reservee = quantite_reservee + quantite

Insert into devis ... values ...

Fin de Saisie de devis

Constats :

Constat :

q Mélange des genres : Client, Produit, Devis,

q Appel aux bases de données de façon séquentielle,

q Logique monolithique,

q Pas de couplage faible car tout est lié,

q Rien n'est réutilisable ni exposable,

q Aucune logique de processus,

q Les règles d'enchaînement sont noyées dans le code.

Pseudo Code d'appel de services :

Début de saisie d'un devis pour un tiers (client, produit, quantite, date_livraison)

Client = ObtenirleClient(client)

Si AnalyserStockProduit(produit, quantite) = rupture_stock

Alors

Si AnalyserDelaisProduit(produit,date_livraison) = date_impossible

Alors

Message «Devis refusé car stock indisponible dans délais imparti»

Exit

Fin

Fin

MettreajourStockreserve(produit, quantite)

CreerleDevis(Client, produit, quantite,date_livraison)

Fin de Saisie de devis

Constats :

q Appels de 5services faiblement couplés

q Code clair

q Services réutilisables par d'autres programmes. Il est facile d'imaginer l'appel des deux services :

MettreajourStockreserve(produit, quantite) lors de la livraison du produit, ObtenirleClient(client) dans le cas d'une saisie de commande sans devis préalable.

Annuaire de Services :

Début ObtenirleClient(client)

select * from Client where nomduClient=client

Si n'existe pas

Alors

Saisir information du client

insert into Client... values...

Fin

Retourner Client

Fin ObtenirleClient

Début CreerleDevis(Client, produit, quantite, date_livraison)

insert into Devis... values...

Fin CreerleDevis

Début AnalyserStockProduit(produit,quantite)

select quantitestock + quantite_reservee from Produit

where nomduProduit = produit

Si quantitestock + quantite_reservee < quantite Alors

Retourne rupture_stock

Sinon

Retourne ok

Fin

Fin AnalyseStockProduit

Début AnalyserDelaisProduit(produit,date_livraison)

select delais Produit where nomduProduit = produit

Si date_jour + delais < date_livraison Alors

Retourne date_impossible

Sinon

Retourne ok

Fin

Fin AnalyseDelaisProduit

Début MettreajourStockreserve(produit, quantite)

Update produit set quantite_reservee = quantite_reservee + quantite

Fin CreerleDevis

Illustration de l'interopérabilité (traduction d'une source IBM162(*))



1) Le diagramme de classe (outil Rose) ci dessous représente le processus d'approbation de prêt (demande de crédit, évaluation du risque, approbation, erreur) :

Illustration 146 : Classe sous Rose

2) Proposition IBM de diagramme d'activité :

Illustration 147 : la "Demande de Prêt"

Les activités sont nommées (exemple : invokeAssessor) via des rectangles aux coins arrondis. Les actions devant être exécutées selon des conditions d'entrée à l'activité se trouvent dans le cartouche de l'activité. Par exemple, riskAssessment (une variable) est mis à jour selon le résultat du service de contrôle. Les Acteurs sont représentés dans des cadres encapsulant les activités pour lesquelles un message de réception ou d'émission leur est attribué. Une activité sans cadre (sans Acteur) signifie quelle est gérée par le processus lui-même sans besoin de service particulier. Les flèches quant à elles, indiquent le sens du processus. Ici, l'activité « Reply » renvoie une réponse au client, achevant l'exécution du processus.

3) Un export XMI^163(*) du diagramme d'activités est effectué :

Illustration 148 : Export XMI

4) Sous Eclipse, un projet Java est créé pour importer le fichier XMI. Puis la génération BPEL est déclenchée (fonction standard). Enfin, après avoir appuyé sur « Finish », un certain nombre de fichiers apparaissent dans le projet, dont les fichiers BPEL et WSDL (Service Web).

Profile Construct	Concepts BPEL4WS
<<process>> class	BPEL process definition
Activity graph on a <<process>> class	BPEL activity hierarchy
<<process>> class attributes	BPEL variables
Hierarchical structure and control flow	BPEL sequence and flow activities
<<receive>>, <<reply>>, <<invoke>> activities	BPEL activities

Tableau 11 : Mapping UML / BPEL

<process name="loanApprovalProcess" ...>

<variables>

<variable name="request"

messageType="loandef:creditInformationMessage"/>

<variable name="riskAssessment"

messageType="asns:riskAssessmentMessage"/>

...

</variables>

...

<flow>

<receive name="receive1" partner="customer"

portType="apns:loanApprovalPT"

operation="approve" variable="request"

createInstance="yes">

<source linkName="receive-to-assess"

transitionCondition=

"bpws:getVariableData('request', 'amount')<10000"/>

<source linkName="receive-to-approval"

transitionCondition=

"bpws:getVariableData('request', 'amount')>=10000"/>

</receive>

<invoke name="invokeAssessor" partner="assessor"

portType="asns:riskAssessmentPT"

operation="check"

inputVariable="request"

outputVariable="riskAssessment">

<target linkName="receive-to-assess"/>

<source linkName="assess-to-setMessage"

transitionCondition=

"bpws:getVariableData('riskAssessment', 'risk')='low'"/>

<source linkName="assess-to-approval"

transitionCondition=

"bpws:getVariableData('riskAssessment', 'risk')!='low'"/>

</invoke>

<assign name="assign">

<target linkName="assess-to-setMessage"/>

<source linkName="setMessage-to-reply"/>

<copy>

<from expression="'yes'"/>

<to variable="approvalInfo" part="accept"/>

</copy>

</assign>

...

<reply name="reply" partner="customer" portType="apns:loanApprovalPT"

operation="approve" variable="approvalInfo">

<target linkName="setMessage-to-reply"/>

<target linkName="approval-to-reply"/>

</reply>

</flow>

</process>

Illustration 149 : Extrait de la traduction BPEL

5) Enfin, pour tester le résultat, il faut déployer les fichiers générés via un serveur TOMCAT par exemple ou sous WebSphere Application Server.

Illustration 150 : Déploiement du Processus

Après avoir cliqué sur "Continue Deployment", insérer les fichiers requis pour les différents rôles. Dans cet exemple, il y en a deux : LoanAssessor and LoanApprover.

Illustration 151 : Déploiement des services

Une fois le Processus déployé, le lancer en invoquant le script LoanApprovalSample :

LoanApprovalSample [soap-address] first-name last-name amount.

Par exemple : LoanApprovalSample http://localhost:80/bpws4j/soaprpcrouter Joe Black 10

Structures : Tiers, RIB et Adresses

Tiers

Nom	Libellé	Format		Clé	Commentaire
SOCIETE	Code Société REPORTING	Alpha CHAR	#(3)	Non	Pos: 001 Long : 003
TIERSTYP	TYPE DE TIERS	Alpha CHAR	#(4)	Non	Pos: 004 Long : 004
CPTENUM	Numéro de Compte	Alpha CHAR	#(5)	Non	Pos: 008 Long : 005
SSCPTECOD	Code Sous-compte	Alpha CHAR	#(2)	Non	Pos : 013 Long : 002
TIERSNOM	Nom du Tiers	Alpha CHAR	#(30)	Non	Pos : 015 Long : 030
SPCTELIB	Libellé du sous-compte	Alphanumérique	#(30)	Non	Pos: 045 Long : 030
ADRDEFNUM	Numéro d'adresse par Défaut = '001'	Numérique	#(3)	Non	Pos : 075 Long :003
SITE	Code Site (Relais Appro)	Alpha CHAR	#(4)	Non	Pos : 078 Long : 004
PAYSCOD	Code Pays	Alpha CHAR	#(3)	Non	Pos : 082 Long: 003
IVTCOD	Code Interdit vente à Terme O/N	Alpha CHAR	#(1)	Non	Pos : 085 Long :001
REGMODDEF	Mode de Règlement par Défaut	Alpha CHAR	#(2)	Non	Pos : 086 Long : 002
CLIREGDELAI	Délai de règlement du Client	Numérique	#(3)	Non	Pos: 088 Long : 003
CLIDECALDEP	Type de Décalage Départ	Alpha CHAR	#(1)	Non	Pos : 091 Long : 001
CLIDECALARR	Type de Décalage Arrivée	Alpha CHAR	#(2)	Non	Pos : 092 Long : 002
RIBETAB	Code Etablissement	Alpha CHAR	#(5)	Non	Pos : 094 Long : 005
RIBGUICHET	Code Guichet	Alpha CHAR	#(5)	Non	Pos : 099 Long :005
RIBCOMPTE	Numéro de Compte	Alpha CHAR	#(11)	Non	Pos : 104 Long : 011
RIBCLE	Clé de contrôle du RIB	Numérique	#(2)	Non	Pos : 115 Long : 002
PARTTVAINTC	Code TVA Intracommunautaire	Alpha CHAR	#(13)	Non	Pos :117 Long : 020
IBAN	International Bank Account Number	Alphanumérique	#(34)	Non	Pos : 137 Long : 034
TIERSSITU	Situation du Tiers	Alpha CHAR	#(1)	Non	Pos : 171 Long : 001
TIERSSITUDAT	Date d'application de la situation	Date	#(0)	Non	Pos : 172 Long : 008
RIBBIC	Code BIC	Alphanumérique	#(11)	Non	Pos : 180 Long: 011
FACTORINGCOD	Code Factoring (Fournisseur)	Alpha CHAR	#(8)	Non	Pos : 191 Long : 008
NIG	Numéro d'Identifiant Groupe	Alpha CHAR	#(6)	Non	Pos : 199 Long : 006
PARTPERSTYP	Type de personne (morale/physique)	Alpha CHAR	#(1)	Non	Pos : 205 Long : 001
PARTSIREN	Numéro de SIREN	Alpha CHAR	#(9)	Non	Pos : 206 Long : 009
PARTSIRET	Numéro de SIRET	Alpha CHAR	#(5)	Non	Pos : 215 Long : 005
ADHTVAASSUJ	Assujettissement à la TVA	Alpha CHAR	#(1)	Non	Pos : 220 Long : 001
FICONSCOD	Code Consigne Financière	Alpha CHAR	#(2)	Non	Pos : 221 Long : 002
CLITERSS	Client Terrena Site Spécialisé	Alpha CHAR	#(1)	Non	Pos : 223 Long : 001
PARTNAISDAT	Date de Naissance	Date	#(0)	Non	Pos : 224 Long : 010
PARTPACAGEN	Numéro de Pacage	Alpha CHAR	#(9)	Non	Pos : 234 Long : 009
PARTONICN	Numéro d'ONIC	Alpha CHAR	#(12)	Non	Pos : 243 Long : 012
ADHTVAVALD	Date assujétissement TVA	Date	#(0)	Non	Pos : 255 Long : 008
CAPSTATCOD	A jour du capital Statutaire	CHAR	#(1)	Non	Pos : 263 Long : 001
CAPSTATVALD	Date de mise à jour	Date	#(0)	Non	Pos : 264 Long : 008
INTITUC	Initulé	Alpha CHAR	#(2)	Non	Pos : 272 Long : 002
FORMJURCOD	Forme juridique	Alpha CHAR	#(4)	Non	Pos : 274 Long : 004
MV_IDAPPLI	Code Application	Alpha CHAR	#(6)	Non	Pos : 278 Long : 006
MV_NOENREG	Numéro enregistrement	Numérique	#(6)	Non	Pos : 284 Long : 006
RELCERCOD	Code relais céréales	Alpha CHAR	#(14)	Non	Pos : 290 Long : 014

Clé unique = SOCIETE + TIERSTYP + CPTENUM + SSCPTECOD

Adresse

Nom	Libellé	Format		Clé	Commentaire
SOCIETE	Code Société REPORTING	Alpha CHAR	#(3)	Non	Pos : 001 Long : 003
TIERSTYP	TYPE DE TIERS	Alpha CHAR	#(4)	Non	Pos : 004 Long : 004
TIERSNUM	Code Tiers	Alphanumérique	#####	Non	Pos : 008 Long : 005
SSCPTECOD	Code Sous-compte	Alpha CHAR	#(2)	Non	Pos : 013 Long : 002
ADRNUM	Numéro d'adresse	Alpha CHAR	#(3)	Non	Pos : 015 Long : 003
ADRRAISONSOC	Raison Sociale	Alphanumérique	#(50)	Non	Pos : 018 Long : 050
ADRRUE	Rue	Alphanumérique	#(50)	Non	Pos : 068 Long : 050
ADRLIEU	Lieu	Alphanumérique	#(50)	Non	Pos : 118 Long : 050
ADRCPOST	Code Postal	Alphanumérique	#(10)	Non	Pos : 168 Long : 010
ADRVILLE	Ville	Alphanumérique	#(30)	Non	Pos : 178 Long : 030
ADREMAIL	Adresse Email Fournisseur	Alphanumérique	#(30)	Non	Pos : 208 Long : 030
ADRTEL	Numéro de Téléphone	Alphanumérique	#(20)	Non	Pos : 238 Long : 020
ADRFAX	Numéro de Télécopieur	Alphanumérique	#(20)	Non	Pos : 258 Long : 020
ADRPORT	Numéro de Mobile	Alphanumérique	#(20)	Non	Pos : 278 Long : 020
ADRCONTACT	Nom du Contact	Alphanumérique	#(30)	Non	Pos : 298 Long : 030
ADRCDE	Adresse de Commande	Alpha CHAR	#(1)	Non	Pos : 328 Long : 001
ADRLIV	Adresse de Livraison	Alpha CHAR	#(1)	Non	Pos : 329 Long :001
ADRFAC	Adresse de Facturation	Alpha CHAR	#(1)	Non	Pos: 330 Long : 001
ADRPAI	Adresse de Paiement	Alpha CHAR	#(1)	Non	Pos : 331 Long : 001
ADRDPT	Département	Alpha CHAR	#(2)	Non	Pos : 332 Long : 002
ADRCOM	Code Commune	Alpha CHAR	#(3)	Non	Pos : 334 Long : 003
NIG	Numéro d'Identifiant Groupe	Alpha CHAR	#(6)	Non	Pos : 337 Long : 006

RIB

Nom	Libellé	Format		Clé	Commentaire
SOCIETE	Code Société REPORTING	Alpha CHAR	#(3)	Non	Pos : 001 Long : 003
TIERSTYP	TYPE DE TIERS	Alpha CHAR	#(4)	Non	Pos : 004 Long : 004
TIERSNUM	Code Tiers	Alphanumérique	#####	Non	Pos : 008 Long : 005
SSCPTECOD	Code Sous-compte	Alpha CHAR	#(2)	Non	Pos : 013 Long : 002
RIBNUM	Numéro de RIB	Numérique	#(2)	Non	Pos : 015 Long : 002
SITUCOD	Code Situation	Alpha CHAR	#(1)	Non	Pos : 017 Long : 001
IBAN	International Bank Account Number	Alphanumérique	#(34)	Non	Pos : 018 Long : 034
MNEMOARCO	Code Mnémonique Arcole	Alpha CHAR	#(4)	Non	Pos : 052 Long : 004

SOAml



Illustration 152 : Spécification SOAml des Services d'après l'OMG^164(*)

On y retrouve des stéréotypes familiers : l'agent, le participant qui offre un service (le fournisseur) et/ou qui requiert un service (le client), le connecteur qui relie une classe et une interface, le port ...Ce nouveau profil n'est pas intégré aux modeleurs du marché. Aussi, faut-il s'assurer que le modeleur retenu pour la modélisation UML permet la création d'un profil spécifique ainsi que des stéréotypes SOAml. La transition du concept de composant à celui de service met ainsi en jeu des obligations réciproques entre le fournisseur et le consommateur. Ces obligations sont gérées au travers d'un service d'interface. Le contrat de service est le lien qui unit deux interfaces (l'élément de connexion). Les participants dans le cadre de notre modélisation concernent les automatismes qui demandent et répondent à des services.



Illustration 153 : Spécification SOAml des Contrats de Services d'après l'OMG^165(*)

Un contrat de service définit les termes de conditions d'interface entre participants (entre le fournisseur et le consommateur) qui collaborent entre eux. Celle collaboration est représentée par un objet spécifique UML :



Illustration 154 : Collaboration UML autour d'une vente



Illustration 155 : Architecture des Services de transfert d'information appliquée à SOAML

Les agents nécessaires à notre étude et internes à l'ESB et peuvent offrir les services suivants :

q routage basé sur le contenu du message,

q connexion permettant les accès (Clients et Fournisseurs),

q messagerie,

q validation de document XML,

q transformation Texte -> XML, XML -> XML, XML -> Texte

q Sérialisation et dé-sérialisation,

q polling de répertoire pour détecter l'arrivée de nouveaux fichiers/documents etc ...

Les Interfaces

Une interface (ou ensemble d'opérations), représente le ou les services d'un composant. Elle peut être « synchrone » ou « asynchrone » (car fonction de certains évènements) ou encore dite « de contrôle » lorsqu'elle regroupe les opérations nécessaire à la validation d'un contenu par exemple (formulaire HTML, document XML etc ...), d'une authentification ... Une même interface peut se situer sur plusieurs ports.

Les ports

L'assemblage de plusieurs composants nécessite la mise en oeuvre d'un ensemble de « ports requis » et de « ports fournis ». Ils constituent des portes d'accès au composant en terme de réponse à une invocation (port requis) ou en terme d'invocation (port fourni). Ces ports représentent le point d'ancrage d'un ensemble d'interfaces cohérentes vis à vis des fonctionnalités qu'elles apportent.

Les contrats

Le « contrat exigé » fixe les critères (aussi appelés « dimensions ») de compatibilité d'assemblage entre deux composants. Le « contrat offert » quant à lui offre des valeurs mis en regard avec le contrat exigé. Le langage d'expression des contrats est le langage des contraintes UML : OCL, déjà présenté dans la première partie. Un contrat peut être :

q syntaxique : dans la mesure où il définit l'ensemble des opérations.

q sémantique : car il précise le fonctionnement des opérations.

q pragmatique : lorsqu'il est a l'écoute de l'environnement et entre autre des contraintes de temps, d'espace (répartition des données).

Les connecteurs

Les connecteurs sont des objets permettant une interaction entre plusieurs composants. Autant ils restent abstraits dans la partie PIM de la démarche MDA, autant ils deviennent concrets dans la partie PSM. Ils peuvent être de différentes natures : de diffusion quand il s'agit de données à transmettre, de synchronisation, de coordination etc ...

Résumé

L'informatique, science en mouvement, est en constant renouvellement. D'abord laboratoire de quelques spécialistes, elle ouvre progressivement ses portes au plus grand nombre, passant ainsi dans le domaine publique. Les mentalités des usagers s'adaptent à son langage et le système d'information s'ajuste à l'usage des utilisateurs. Chaque nouveau cycle donne ainsi naissance à une mini-révolution de plus, ravivant l'espoir de redonner plus de pouvoir aux utilisateurs.

Très vite, la difficulté d'intégrer un système d'information complexe s'est traduite en syndrome « spaghetti ». Des boites noires sont alors venues s'ajouter au centre de l'assiette pour simplifier cette vision de flux. Mais, si ces boites répondent à certains besoins par un niveau d'abstraction supplémentaire, elles ne constituent néanmoins que des couches apportant leur propre lot de code.

La démarche SOA tente cette fois d'aligner la stratégie IT sur celle des métiers par une participation active des utilisateurs aux définitions de processus. Pour que le « plat de spaghetti » ne devienne pas un « rizotto de services métiers », SOA ne se focalise plus sur une technologie mais prend corps autour d'une démarche architecturale. Cette force constitue néanmoins sa faiblesse car tout ne repose plus sur le seul bon vouloir des informaticiens mais sur l'entreprise toute entière.

Mots clés : SOA, Architecture, Services, Processus Métiers, Interopérabilité, « Réutilisabilité ».

Summary

Computing, science in movement, is in constant renewal. At first laboratory of some specialists, it gradually opened its doors to most large number, so passing in the common domain. The mentalities of the users adapt themselves to its language and the information system adjusts in aid of the users. Every new cycle so gives birth to a mini-revolution furthermore, reviving the hope to restore the power to the users.

Very fast, the difficulty integrating a complex information system is symbolized by the « pasta theory » on software. Black boxes are then deposited in the center of the plate to simplify this vision of stream. But, if these boxes answer certain needs by a level of supplementary abstraction, they establish nevertheless layers bringing their own piece of code.

The step SOA tries this time to align the IT strategy on Business strategy by an active participation of the users in the definitions of process. So that the «pasta theory on software» does not become a «rizotto of business services», SOA does not focus any more on a technology but takes shape around an architectural step. This strength constitutes nevertheless its weakness because everything does not base any more on the only good will of the computer specialists but on the whole company.

Keywords: SOA, Architecture, Services, Business Process, Interoperability, Reutilisability.

* ¹ 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.

* ² Legacy System : vieux Mainframe plébiscités par les utilisateurs, difficile à remplacer.

* ³ Datawarahouse : entrepôt de données qui se caractérise par des données orientées « métiers » non volatiles présentées selon différents axes d'analyse ou « dimensions ».

* ⁴ ETL (Extract, Transform and Load) : technologie informatique permettant d'effectuer des synchronisations («alimentation », « extraction », « transformation », « constitution » ou « conversion », souvent combinés) massives d'information d'une base de données vers une autre.

* ⁵ Exemple des package d'interface Sunopsis (depuis la version 2 en 1999).

* ⁶ EAI (Intégration d'applications d'entreprise) : architecture « intergicielle » permettant à des applications hétérogènes de gérer leurs échanges.

* ⁷ Workflow : décrit le circuit de validation, les tâches à accomplir entre différents acteurs d'un processus, les délais, les modes de validation, et fournit à chacun des acteurs les informations nécessaires pour la réalisation de sa tâche.

* ⁸ MOM (Message Oriented Middleware) : système de transmission de messages entre applications.

* ⁹ Communication asynchrone (Asynchronous Communication) : type d'échange non bloquant dans lequel une application envoie un message à l'autre sans attendre la réponse, afin que les applications puissent opérer indépendamment.

* ¹⁰ ORB : s'apparente à une tuyauterie permettant les échanges de messages entre objets.

* ¹¹ Communication synchrone : type d'échange bloquant dans lequel une application envoie un message à l'autre en attendant la réponse, de telle sorte que les applications opèrent en dépendance.

* ¹² Hub : point central où convergent les informations du système.

* ¹³ Parseur (Parser) : analyseur syntaxique analysant et décodant les balises d'un document (XML ou autre) afin de permettre à l'application de traiter les données.

* ¹⁴ Référentiel de Méta-données : sert à décrire l'ensemble des règles, définitions, transformations et processus associés à une donnée.

* ¹⁵ ERP (Enterprise Resource Planning) ou Progiciel de gestion intégré (PGI).

* ¹⁶ Edifact (Échange de données informatisées pour l'administration, le commerce et le transport) : norme des Nations unies décrivant des modalités techniques pour l'échange de données informatisé (EDI) dans différents secteurs industriels.

* ¹⁷ EDI (Electronic Data Interchange) : échange de données électroniques organisées selon des messages à plusieurs niveaux, avec en-têtes de trois caractères et des codages longueur - champ, standardisé dans les années 80.

* ¹⁸ FIX (Financial Information eXchange) : standard de message développé dans le but de faciliter les échanges d'informations relatifs aux transactions boursières.

* ¹⁹ HL7 (Health Level 7) : standard qui devient international, définissant un format pour les échanges informatisés de données cliniques, financières et administratives entre systèmes d'information hospitaliers.

* ²⁰ XML (Extensible Markup Language) : métalangage développé par le W3C permettant de définir des langages de marquage de documents ou de messages, au centre d'un ensemble de standards dédiés à la communication dans les systèmes d'information.

* ²¹ Cf. Serge ABITEBOUL : «Interopérabilité des outils de traitement » ; cours Master 2004 XML : « XML et données demies structurées » ; http://www-rocq.inria.fr/~abitebou/DEA-III/2004/xml-intro-04.ppt.

* ²² Tuxedo (Transactions for Unix, Extended for Distributed Operations) : logiciel middleware destiné à gérer les transactions dans un environnement distribué pour systèmes Unix, conçu en 1983.

* ²³ IBM WebSphere MQ, anciennement MQ Series est une famille de logiciels, développée par IBM depuis 1992. Service de messagerie inter-applicative (ou MOM : Message Oriented Middleware), permettant la communication entre différentes applications, via l'utilisation de files d'attente.

* ²⁴ BEA MessageQ : système de message Queuing de BEA.

* ²⁵ Orchestration : système qui permet de superviser les chaînes applicatives, dont les maillons sont des services.
L'orchestration assure la succession des tâches, le contrôle de la bonne exécution, les reprises en cas d'incident.

* ²⁶ BPM  (business process management) : approche consistant à modéliser informatiquement les processus métiers de l'entreprise.

* ²⁷ Architecture client/serveur : mode de communication entre plusieurs ordinateurs d'un réseau qui distingue un ou plusieurs postes clients du serveur (actifs): chaque logiciel client peut envoyer des requêtes à un serveur (passif).

* ²⁸ 3-tiers, architecture à trois niveaux : application du modèle plus général qu'est le multi-tiers. L'architecture logique du système est divisée en trois niveaux ou couches : présentation, métier, données.

* ²⁹ API (Application Programming Interface) : interface pour les applications permettant de communiquer.

* ³⁰ C/C++ : langage de programmation existant depuis 1985 et largement utilisé depuis 1995, permettant la programmation sous de multiples paradigmes comme, par exemple, la programmation procédurale, la programmation orientée objet.

* ³¹ Java : langage de programmation orienté objet avec la particularité principale que les logiciels écrits en java sont très facilement portables sur plusieurs systèmes d'exploitation tels que Unix, Microsoft Windows, Mac OS ou Linux avec peu ou pas de modifications.

* ³² COM (Component Object Model)  : composant utilisé en programmation pour permettre le dialogue entre programmes, très présent dans le monde Microsoft Windows.

* ³³ JMS (Java Message Service) : interface Java standard d'accès à un système de messagerie (ex MOM) pour l'échange fiable de messages entre applications ou machines.

* ³⁴ EJB (Enterprise JavaBeans) : extension des JavaBeans permettant de réaliser des composants réutilisables sur n'importe quelle plate-forme Java.

* ³⁵ BAM (Business Activity Monitoring) : comprend l'acquisition, l'agrégation, l'analyse et la présentation en temps réel de données associées à des processus d'entreprise

* ³⁶ JCA (Java connector architecture) : solution de J2EE pour résoudre le problème d'intégration entre le monde J2EE et le système d'information d'entreprise

* ³⁷ Service Web (Web Service) : groupe de fonctions accessibles par un client Web en SOAP, codées en WSDL.

* ³⁸ B2B (Business to Business) : caractérise le type de commerce électronique conduit entre entreprises.

* ³⁹ B2C (Business to Consumer) : caractérise le type de commerce électronique conduit entre une entreprise et une personne privée.

* ⁴⁰ A2A (Application to Application) : caractérise l'échange d'information entre deux applications de la même entreprise.

* ⁴¹ ESB (Enterprise Service Bus) : architecture fonctionnant comme un bus entre des clients et des fournisseurs de services

* ⁴² Http (HyperText Transfer Protocol): dans le protocole de transfert Hyper Texte, une méthode est une commande spécifiant un type de requête demandant au serveur d'effectuer une action. Cette action concerne une ressource identifiée par l'URL qui suit le nom de la méthode. (SSL est une forme sécurisée de HTTP).

* ⁴³ Soap (Simple Object Access Protocol) : protocole de RPC orienté objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se faire par un autre protocole, comme SMTP.

* ⁴⁴ OW2 : ObjectWeb est un consortium actif d'industriels internationaux (INRIA, Bull, France Télécom, Thales Group ou Red Hat) engagé en matière de Commerce électronique, d'EAI, de Services web. Il s'engage sur le respect de standard de l'OMG (Object Management Group) , le JCP(Java Community Process ), OSGi (Open Services Gateway initiative).

* ⁴⁵ JSR-208 : http://www.jcp.org/en/jsr/detail?id=208.

* ⁴⁶ JBI (Java Business Intégration) : spécification normalisant ces intégrations via un jeu d'API permettant à tout fournisseur de pouvoir se connecter à un conteneur JBI pour échanger des messages avec le reste du SI.

* ⁴⁷ Endpoints : point d'accès à un service.

* ⁴⁸ UML (Unified Modeling Language ou langage de modélisation unifié) : langage graphique de modélisation des données et des traitements. Pour approfondir : http://www.uml.org.

* ⁴⁹ Petals : bus d'entreprise orienté services (ESB) hautement distribué, construit sur les spécifications JBI. Le projet est dirigé par EBM Websourcing, et développé selon les orientations du consortium OW2.

* ⁵⁰ Pour approfondir : « Using the ESB Service Container » [CHA-CONT]. 

* ⁵¹ UDDI (Universal Discovery, Description and Integration) : spécification d'accès, en XML, à un catalogue de services offerts par des fournisseurs, permettant à un consommateur de services de localiser et d'obtenir les caractéristiques de services, dont il a besoin, afin de pouvoir les invoquer.

* ⁵² OASIS : consortium mondial qui travaille pour la normalisation et la standardisation de formats de fichiers ouverts basés notamment sur XML. Créé en 1993, il compte 3500 membres faisant partie de 600 organisations dans 100 pays. OASIS est structuré en groupes de travail appelés les Technical Committees.

* ⁵³ WS-* : spécifications principalement du W3C, associées aux services Web.

* ⁵⁴ IDE (Environnement Intégré de Développement) : Outils se présentant comme un ensemble de consoles intégrées qui permet la gestion complète du cycle de vie des composants techniques et fonctionnels entrant dans la composition d'un système d'information conforme à une architecture SOA.

* ⁵⁵ Eclipse : IDE libre d'IBM, fonctionnant à partir de plugin spécifiques.

* ⁵⁶ Netbeans : IDE libre en java édité par SUN et open source depuis 2000.

* ⁵⁷ Scalabilité : capacité d'un composant à être utilisé sur des plates-formes beaucoup plus petites et plus grosses.

* ⁵⁸ Pour approfondir : « Architectures de systèmes d'information » [OCT-SYST] et « Intégration des Applications d'Entreprise » [OCT-EAI].

* ⁵⁹ Zero Latency : L'information doit ou est immédiatement disponible à un autre point du système.

* ⁶⁰ ITIL (Information Technology Infrastructure Library) : ensemble de 5 ouvrages recensant les bonnes pratiques en matière informatique (la dernière version : Version 3, est sortie en mai 2007). On trouve le berceau d'Itil en Angleterre dès la fin des années 1980. Le gouvernement Thatcher souhaite mettre en concurrence systématique les prestations informatiques internes des services publics avec l'offre du marché (Market testing).

* ⁶¹ Traduction de l'anglais : «Means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks  »

* ⁶² Cf. Origines de Itil à la note de base de page n° 62.

* ⁶³ La qualité de service (QoS, Quality of Service) est la capacité à véhiculer un type de trafic donné, en termes de disponibilité, débit, délais de transmission etc ...

* ⁶⁴ Cf. Guide des services UPS : http://www.ups.com/media/en/service_guide_fr_08.pdf

* ⁶⁵ Cf. Spécifications OCL : http://www.omg.org/docs/ptc/03-10-14.pdf

* ⁶⁶ Pour approfondir : Architecture Orientée Services (SOA) - Une politique d'interopérabilité. [OCT-SOA].

* ⁶⁷ Cf. Serge ABITEBOUL : «Interopérabilité des outils de traitement » ; cours Master 2004 XML : « XML et données demies structurées » ; http://www-rocq.inria.fr/~abitebou/DEA-III/2004/xml-intro-04.ppt.

* ⁶⁸ La recette informatique est l'étape du projet qui consiste à tester le développement avant son déploiement.

* ⁶⁹ Fondé en 1986 à Boston, AMR Research est spécialisé dans les Etudes et analyses dans le domaine des nouvelles technologies.

* ⁷⁰ POS : Plan d'occupation des sols : Zones, Quartiers, Ilots ou blocs.

* ⁷¹ PLU : Permis de construire, de démolir ...

* ⁷² EAM (Enterprise Architecture Modeling) : outil de modélisation de l'architecture d'entreprise.

* ⁷³ Pour approfondir : « Urbanisme des SI et gouvernance » [ANQ-URBA] et « Cadre de référence Architecture SOA - Meilleures pratiques » [BON-CSOA].

* ⁷⁴ J-B Ceccaldi, Directeur Général de Vistali, Cabinet de conseil accompagnant AIR France - KLM dans son approche SOA.

* ⁷⁵ Cf. Source : « process war being waged by a "Top-Down" and a "Bottom-up" brigades » disponible sur le site www.butlergroup.com/research/research.asp.

* ⁷⁶ Cf. Source : http://uk.sun.com/sunnews/events/2006/sep/mcr/presentations/David_Llamas.pdf

* ⁷⁷ MDA (Model Driven Architecture) : démarche proposée et soutenue par l'OMG, variante de l'ingénierie dirigée par les modèles. Le principe est l'élaboration de modèles indépendants de plate-formes (Platform Independent Model, PIM) et la transformation de ceux-ci en modèles dépendants de plates-formes (Platform Specific Model, PSM).

* ⁷⁸ Rose : Logiciel de modélisation UML édité par Rational Software. Il permet de générer automatiquement du code Java, C++ ou Visual Basic à partir du modèle objet.

* ⁷⁹ CIM (Computation Independent Model) : parfois appelé Business Model, il s'agit de représenter l'entreprise.

* ⁸⁰ PDM (Plateform Description Model) : correspond au modèle de transformation du PIM vers le PSM.

* ⁸¹ BPMN (Business Process Management Notation): premier standard du Business Process Management.

* ⁸² Projet JonES : le but est de développer un bus logiciel de type ESB open source pour l'entreprise. Participent à ce projet : l'INRIA, EBM WebSourcing; ENSTIMAC (Ecole des Mines d'Albi-Carmaux); France Telecom R&D, AMS lab; OpenWide; ScalAgent Distributed Technologies.

* ⁸³ Thèse J. Touzi : « Aide à la conception de Système d'Information Collaboratif, support de l'interopérabilité des entreprises ».

* ⁸⁴ Thèse V. Rajsiri : « Connaissance sur la collaboration des partenaires ».

* ⁸⁵ Thèse S. Truptil : « Processus flexibles et étude d'un cas d'application dans le domaine des crises ».

* ⁸⁶ Mappage (mapping) : définition d'une correspondance entre deux objets de même nature mais pas de même forme.

* ⁸⁷ SOAML (Service-oriented architecture Modeling Language) : Langage de modélisation SOA.

* ⁸⁸ UPMS (UML Profile and Metamodel for Service) : spécification de l'OMG appliquée aux Services via les profils UML.

* ⁸⁹ WSDL (Web Services Description Language) : normalisation regroupant la description des éléments permettant de mettre en place l'accès à un service web. Pour cela il utilise le langage XML, dans sa version 2.0 approuvé par le W3C.

* ⁹⁰ XMI (XML Metadata Interchange) : définit un format d'échange standard entre ateliers logiciels.

* ⁹¹ OMG : organisme à but non lucratif, créé en 1989 à l'initiative de grandes sociétés (HP, Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'OMG fédère plus de 850 acteurs du monde informatique. Son rôle est de promouvoir des standards qui garantissent l'interopérabilité entre applications orientées objet, développées sur des réseaux hétérogènes.

* ⁹² BPDM (Business Process Definition Metamodel): proposition de l'OMG.

* ⁹³ BPMI: Business Process Management Initiative): consortium de standardisation.

* ⁹⁴ XPDL (XML Process Definition Language) : standard de la Workflow Management Coalition qui permet de définir un processus métier avec XML, pour ensuite l'utiliser dans un moteur de workflow.

* ⁹⁵ BPML (Business Process Modeling Language) : langage basé sur XML, permet de modéliser les processus métier.

* ⁹⁶ BPEL : langage de description des procédures d'entreprise. Ce langage a été défini dans sa version 2.0 par une spécification du consortium OASIS à la fin du mois de mars 2007.

* ⁹⁷ Cf. Serge ABITEBOUL : «Interopérabilité des outils de traitement » ; cours Master 2004 XML : « XML et données demies structurées » ; http://www-rocq.inria.fr/~abitebou/DEA-III/2004/xml-intro-04.ppt.

* ⁹⁸ Mappage (mapping) : définition d'une correspondance entre deux objets de même nature mais pas de même forme.

* ⁹⁹ Traduction de l'anglais : «Two trends in information technology will become increasingly important to CIOs in 2007: a migration to service-oriented architectures and the introduction of lean-manufacturing principles to data center operations ».

* ¹⁰⁰ McKinsey & Company : cabinet de conseil auprès des directions générales, leader mondial dans son secteur. Le cabinet aide un vaste éventail d'entreprises (93% des 100 premières entreprises mondiales) ou de gouvernements (50 à son actif). Afin d'améliorer leur performance et leur compétitivité, via des missions de stratégie, d'organisation ou d'efficacité opérationnelle.

* ¹⁰¹ Cf. extrait: « Agile software development processes and service-oriented architecture (SOA) accomplish two different yet related goals: Agile processes increase the effectiveness of a team's software delivery, while SOA increases the flexibility and reusability of the software itself. Forrester's data shows a close correlation between adoption rates for Agile and SOA: Organizations with an enterprise-level commitment to SOA are twice as likely to use Agile processes » [FOR-APE].

* ¹⁰² Le Standish Group est un cabinet de conseil de Boston fondé en 1985, spécialisé sur les aspects de coûts et les ROI informatiques. Son panel d'étude est constitué de 365 entreprises américaines et européennes (PME et gros groupes industriels, bancaires, de la santé, des assurances, des services, de négoce, de vente au détail et en gros) pour un total de 8380 applications.

* ¹⁰³ Au Keynote Speech XP 2002 (XP est une des méthodes agiles).

* ¹⁰⁴ Cf. source : http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

* ¹⁰⁵ Cf source : http://net.educause.edu/ir/library/pdf/NCP08083B.pdf

* ¹⁰⁶ Todd Little, Responsable de développements chez Landmark Graphics, leader dans la vente de solutions dans le domaine pétrolier et gazier, auteur de plusieurs articles concernant les mesures d'estimation de projet. Cette étude a été produite à partir d'un portefeuille de 570 projets.

* ¹⁰⁷ Docteur Patrick LÉGERON : Docteur en médecine, psychiatre et "post-doctoral scholar" de l'Université de Californie à Los Angeles.

* ¹⁰⁸ KAI (Key Agility Indicator) : notion d'évaluation de l'agilité avancée par Tami Cannizzaro, directeur SOA chez IBM.

* ¹⁰⁹ Jacobson : contributeur important à la fois du langage UML et du RUP (Rational Unified Process) en 1986.

* ¹¹⁰ Le concept de catégorie : agrégat de classes du diagramme de classes respectant des propriétés strictes de stabilité, de continuité et de consistance métier. Pivot de la SOA il existe depuis longtemps dans UML au travers du concept d'objet métier.

* ¹¹¹ Grady Booch : créateur d'une approche d'analyse et de conception orientée objet portant son nom : la méthode booch ; en collaboration avec James Rumbaugh, créateur de la notation OMT, et avec Ivar Jacobson, créateur de la méthode OOSE ; il est à l'origine du langage de modélisation UML.

* ¹¹² Activity : «smallest identified item ok work in a project, process», traduction de l' ISO 10006:2003 (E) (déf. 3.1).

* ¹¹³ CICS (Customer Information Control System) : système qui permet d'effectuer des opérations transactionnelles (en général, consultation ou mise à jour de bases de données ou de fichiers).

* ¹¹⁴ RPC (Remote Procédure Call) : protocole permettant de faire des appels de procédures sur un ordinateur distant à l'aide d'un serveur d'application.

* ¹¹⁵ Taxonomie ou taxinomie : science qui a pour objet de décrire les organismes vivants et de les regrouper en entités appelées taxons afin de pouvoir les identifier puis les nommer, et enfin les classer.

* ¹¹⁶ Pare-feu : élément du réseau, qui a pour fonction de faire respecter la politique de sécurité en définissant quels sont les types de communication autorisés ou interdits.

* ¹¹⁷ Le Gartner Group est un cabinet d'experts américains spécialisé dans le domaine de la technologie. Fondé en 1979 est regroupe plus de 10 000 clients.

* ¹¹⁸ WS-Federation : spécification développée par BEA Systems, BMC Software, CA, Inc., IBM, Layer 7 Technologies, Microsoft, Novell, définissant les mécanismes de sécurité.

* ¹¹⁹ Liberty Alliance : aussi connu sous le nom de Project Liberty, projet réunissant depuis 2001 des acteurs industriels, informatiques, bancaires et gouvernementaux sous la forme d'un consortium afin de définir des spécifications de protocoles de fédération d'identité et de communication entre services web.

* ¹²⁰ WS-I (Web Services Interoperability) : consortium d'industriels de l'industrie du logiciel : BEA, IBM, Microsoft, Oracle, HP, SAP, INTEL et SUN) oeuvrant à la promotion de l'interopérabilité entre plates-formes par la rédaction des spécifications des Services Web annotés : WS-*. Le WS-I a été initié en 2000.

* ¹²¹ W3C (World Wide Web Consortium) : organisme de normalisation a but non-lucratif, fondé 1994. Consortium actif dans la promotion des technologies Web telles que HTML, XHTML, XML, RDF, CSS, PNG, SVG et SOAP, le W3C n'émet aucune norme, mais des recommandations considérés comme des standards industriels.

* ¹²² Ontologie : cherche à représenter le sens des concepts d'un domaine et les relations qui les lient. Cf. Mémoire X. Aimé [AIM-VHC].

* ¹²³ XSD (XML Schema Description) : recommandation par le W3C en mai 2001 est un langage de description de format de document XML permettant de définir la structure d'un document XML.

* ¹²⁴ URI (Uniform Resource Identifier) : chaîne de caractères identifiant une ressource sur un réseau.

* ¹²⁵ Réification : action de transposer une abstraction en objet concret.

* ¹²⁶ A l'origine OWL-S s'appelait DAML-S par le DARPA.

* ¹²⁷ Cf. source : http://www.01net.com/clubs/resultat_etude_soa.pdf.

* ¹²⁸ Le Groupe Tests crée en 1966 à Paris, regroupe 01 Informatique, 01 DSI, Décision Informatique, Décision Distribution, 01 Réseaux, L'Ordinateur individuel, Electronique Internationnal etc...

* ¹²⁹ Cf. Lien : http://www.osoa.org/display/Main/Home.

* ¹³⁰ Ontologie : ensemble structuré des termes et des concepts d'informations (par l'utilisation de métadonnées d'un espace de noms, ou d'éléments d'un domaine de connaissances).

* ¹³¹ Traduction de l'anglais : « Only 37% of enterprises have achieved a positive ROI from SOA deployments».

* ¹³² Nucleus Research : Cabinet d'analyse et de conseil en informatique.

* ¹³³ Mariano Boni : Directeur technique de Dreamsoft.

* ¹³⁴ Solucom group publie les résultats de la première grande enquête sur la SOA réalisée auprès de décideurs du Top 500 des entreprises françaises : http://www.solucom.fr/IMG/pdf/Etude_SOA_2008_solucom_group-2.pdf

* ¹³⁵ Traduction de l'anglais : « By 2008, more than 75 percent of then-current application packages either will be natively SOA or will expose SOA interfaces through a wrapping layer of interfaces (0.8 probability)». 

* ¹³⁶ Total Economic Impact : Nom déposé par Software ag.

* ¹³⁷ DTD : définition de type de document, document SGML.

* ¹³⁸ XSD (XML Schema Description) : recommandation par le W3C en mai 2001 est un langage de description de format de document XML permettant de définir la structure d'un document XML

* ¹³⁹ PRA (Plan de Reprise d'Activité) : plan permettant d'assurer, en cas de crise majeure ou importante d'un centre informatique, la reconstruction de son infrastructure et la remise en route des applications.

* ¹⁴⁰ Kaoru Ishikawa (Ishikawa Kaoru, Tôkyô, 1915 - 16 avril 1989), ingénieur chimiste japonais précurseur et un des théoriciens pour la gestion de la qualité. On lui doit notamment le diagramme de causes et effets qui est un des outils fondamental pour assister les cercles de qualité.

* ¹⁴¹ SMA (systèmes multi-agent) : ensemble d'agents situés dans un certain environnement et interagissant selon une certaine organisation. Un agent est une entité caractérisée par le fait qu'elle est, au moins partiellement, autonome. Ce peut-être un processus, un robot, un être humain, etc...

* ¹⁴² Cf. Rapport de Stage Master 2 de J. GUITTON. « Planification multi-agent pour la composition dynamique de Services Web » [GUI-PMA].

* ¹⁴³ Le Monde clos : Hypothèse selon laquelle tout ce qui n'est pas dit est faux.

* ¹⁴⁴ Notion de compensation : mécanisme de retour arrière par exemple lorsqu' un traitement de virement échoue en cours de route. Si un mouvement de débit a déjà été créé sur le compte d'origine, alors la compensation sera de créditer de la même somme le compte.

* ¹⁴⁵ Hash-coding : Technique logicielle permettant d'attribuer un emplacement de mémoire grâce à un calcul faisant intervenir directement l'Information à ranger ou à retrouver.

* ¹⁴⁶ «SoaML, pour décrire les SOA avec UML », Le Monde Informatique, Edition du 11/12/2008.

* ¹⁴⁷ Cf. Source de la thèse de J. Touzi : http://ethesis.inp-toulouse.fr/archive/00000606/01/touzi.pdf [TOU-ACS].

* ¹⁴⁸ Christophe Longépé : Directeur de l'Urbanisme et des Référentiels des Systèmes d'Information Groupe et Administrateur du Club Urba-EA, Groupe Société Générale.

* ¹⁴⁹ Ivar Jacobson (né le 2 septembre 1939 à Ystad en Suède) est un informaticien suédois. Il est principalement connu pour être l'un des concepteurs du langage de modélisation UML.

* ¹⁵⁰ Cf. Spécifications : http://www.bpmn.org/Documents/BPMN%20V1-0%20May%203%202004.pdf.

* ¹⁵¹ BRMS (Business rules management system) : système de gestion des règles métier.

* ¹⁵² Protégé : Outil de modélisation d'ontologies.

* ¹⁵³ GIEA = Gestion des Informations de l'Exploitation Agricole » plus d'informations disponibles sur le site www.projetgiea.fr.

* ¹⁵⁴ Pour approfondir : A. LONJON « Modélisation XML » [LON-MXM].

* ¹⁵⁵ Cf. Source: « Making Components Contract Aware » [BEU-MCC].

* ¹⁵⁶ Cf. Source : http://forumsoa.lemondeinformatique.fr/index.php?centre=article-actu&id=27791.

* ¹⁵⁷ Exemple de Saas : Google Apps, outils collaboratifs. Les interfaces RIA (Rich Internet Application) permettent l'exposition des services.

* ¹⁵⁸ Cf. Source : hal.archives-ouvertes.fr/docs/00/34/23/10/PDF/soa-3.pdf.

* ¹⁵⁹ JVM (Java Virtual Machine, en français Machine virtuelle Java, est une machine virtuelle permettant d'interpréter et d'exécuter le bytecode Java.

* ¹⁶⁰ Il ya 50 ans, Raccoon a proposé une projection de l'évolution des paradigmes d'ingénierie logiciel. Il a introduit la notion de vagues de l'évolution logiciel, divisibles en 4 phases : innovation, croissance, maturité et convention.

* ¹⁶¹ « Ere ubiquitaire» selon Mark Weiser : terminaux à la fois client et serveurs (en architecture pear to pear) tels que les assistants personnels, les téléphones mobiles, les terminaux interactifs (tv, bornes), les consoles de jeux, les appareils photo numérique etc ...

* ¹⁶² http://www.ibm.com/developerworks/webservices/library/ws-uml2bpel

* ¹⁶³ XMI (XML Metadata Interchange) : définit un format d'échange standard entre ateliers logiciels.

* ¹⁶⁴ Cf. source : http://www.omg.org/docs/ad/08-11-01.pdf, page 43

* ¹⁶⁵ Cf. source : http://www.omg.org/docs/ad/08-11-01.pdf, page 43