Thème : ELABORATION D UN META-MODELE D INTEGRATION WEB

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE Ministère De L Enseignement Supérieure Et De La Recherche Scientifique ECOLE NATIONALE SUPERIEURE D'INFORMATIQUE ECOLE DOCTORALE DES SCIENCES ET TECHNOLOGIES D INFORMATIONS ET DE COMMUNICATIONS (STIC) MEMOIRE Présenté pour l'obtention du diplôme de Magister OPTION : Systèmes d Informations et de Connaissances (SIC) Thème : ELABORATION D UN META-MODELE D INTEGRATION WEB Elaboré par : DJEDDAI Lekhmissi (Ingénieur d'etat en Génie Informatique) Dirigé par : Mr. AHMED NACER Mohamed Soutenu publiquement le: 12/03/2012 Membres du jury: Président: Examinateurs: Mr. KOUDIL Mouloud (Professeur, ESI) Mr. BOUKHALFA Kamel (MC.A, USTHB) Mr. GHOMARI Abdessamed Rédha (MC.A, ESI) Directeur de mémoire: Mr. AHMED NACER Mohamed (Professeur, USTHB) 2012

DEDICACE Je dédie ce modeste travail à : Mes très chers parents qui ont veillé sur mon éducation et sur mes études, Tous les membres de ma famille pour leurs encouragements, Ma future épouse, Mes encadreurs, Mes enseignants, Mes chers amis, Ma promotion d ingéniera (2005), Ma promotion EDSTIC (ESI 2008), Mes collègues de travail, 2012

REMERCIEMENTS Je tiens à adresser mes sincères remerciements à mes encadreurs : le professeur Mr Ahmed NACER et Mme Hakima MELLAH, pour leurs orientations précises, leurs conseilles précieuses et leurs critiques constructives, toute au long du parcours de l élaboration de ce mémoire, En deuxième lieu, Je tiens à remercier l ensemble des professeurs de l ESI pour avoir assurer notre formation, Nous remercions aussi toute la hiérarchie de mes responsables et les membres de l administration de l ESI qui m ont assuré l environnement adéquat afin de réaliser ce travail, Mes sentiments de profonde gratitude vont à mes enseignants qui, tout au long des années d études, m ont transmit leur savoir sans réserve. Enfin, Je tiens à remercier tous mes amis et collègues pour leur soutien moral durant la préparation de ce mémoire. 2012

Résumé: MDA (Model Driven Architecture) est considéré comme une approche recommandée pour remédier au problème de l interopérabilité, parce qu elle permet d aborder la conception d applications indépendamment des plates-formes de développement et avant de penser à leurs implémentations. C est pour cette raison que nous avons opté pour l application de l approche MDA pour élaborer un métamodèle d intégration web. Ainsi, nous avons construit ce méta-modèle à partir des modèles d intégration de différentes technologies web (service web, SOA et mashups), après leur adaptation et leur assemblage dans un modèle global. A partir de ce dernier méta-modèle, nous avons procédé à l instanciation d un PIM spécifique pour un cas d utilisation. Pour cela, nous avons fait un autre passage qui sert à générer un profil UML à partir du méta-modèle, dont, l objectif est de produire une boite à outil qui nous a permis d instancier le modèle PIM spécifique. Mots clés: Integration web, Services web, SOA: Service Oriented Architecture, Mashups, MDA: Model Driven Architecture, MOF: Meta-Object Facilities, Métamodèle, Transformation. Summary: MDA (Model Driven Architecture) is considered as recommended approach to remedy interoperability problem, because it permits to board the application conception independently of development platforms and before thinking of their implémentation. For that reason, we have opted for the application of an MDA approach to design a web Integration meta-model. We have conceived this metamodel by adapting and assembling different web technologies integration models (web sevices, SOA and mashups). From this meta-model, we have instantiated a specific PIM for an use's case. To do, we have proceded an other passage, which serves for generating an UML profil from this meta-model, which is used to produce a tool box to instanstiate the specific PIM. Key Words: Web Integration, Web Services, SOA: Service Oriented Architecture, Mashups, MDA: Model Driven Architecture, MOF: Meta-Object Facilities, Metamodel, Model Transformation. 2012

SOMMAIRE SOMMAIRE... 1 LISTE DES FIGURES... 3 LISTE DES TABLEAUX... 4 INTRODUCTION GENERALE... 5 ENJEUX D INTEGRATION DU CONTENU... 5 ORIENTATION VERS L INTEGRATION WEB... 5 POSITION DE PROBLEME... 6 ORGANISATION DU MEMOIRE... 8 I INTEGRATION WEB, ETAT DE L ART... 10 I.1 INTRODUCTION... 10 I.2 APERÇU SUR L INTEGRATION... 10 I.2.1 Notion D intégration... 10 I.2.2 Enjeux D intégration... 11 I.2.3 Orientation Vers L intégration Web... 12 I.3 GENERALITES SUR L INTEGRATION WEB... 12 I.3.1 Notion De L intégration Web... 12 I.3.2 Avantages De L intégration Web... 12 I.3.3 Points D accès De L intégration Web... 13 I.4 L INTEGRATION AVEC LES SERVICES WEB... 14 I.4.1 Introduction Au Paradigme Orienté Service... 14 I.4.2 Généralités Sur Les Services Web... 15 I.4.3 Architecture Des Services Web... 17 I.4.4 Classifications Des Services Web... 20 I.4.5 Technologies Et Standards De Services Web... 25 I.5 INTEGRATION WEB AVEC SOA... 31 I.5.1 Historique Sur SOA... 31 I.5.2 Principes De SOA... 32 I.5.3 Caractéristiques De SOA... 35 I.5.4 SOA Et Les Architectures Précédentes... 40 I.5.5 Conclusion... 49 I.6 INTEGRATION WEB AVEC LES MASHUPS... 50 I.6.1 Introduction aux mashups... 50 I.6.2 Généralités Sur Les Mashups... 50 I.6.3 Classification Des Mashups... 55 I.6.4 Architecture Des Mashups... 58 I.6.5 Développement Des Mashups... 64 I.6.6 Les Mashups Vs Les Portails web... 73 I.6.7 Défis De Construction Des Mashups... 75 I.7 ENJEUX D INTEGRATION WEB... 77 I.7.1 Temps... 77 I.7.2 Maintenance... 78 I.7.3 Coût... 78 I.8 CONCLUSION... 78 1

II APPROCHE MDA POUR L INTEGRATION WEB... 79 II.1 INTRODUCTION... 79 II.2 APERÇUS SUR L ARCHITECTURE ORIENTEE MODELE (MDA)... 79 II.2.1 Introduction A MDA... 79 II.2.2 Notions Générales Sur MDA... 80 II.2.3 Types Des Modèles Utilisés Dans MDA... 86 II.2.4 Transformations De Modèles Dans MDA... 87 II.2.5 Etapes D application De MDA... 89 II.2.6 Avantages Et Inconvénients De MDA... 90 II.3 DESCRIPTION DE NOTRE DEMARCHE... 91 II.3.1 Les grandes étapes de notre approche MDA... 91 II.3.2 Schéma détaillée des différentes transformations de modèles... 93 II.4 APERÇU SUR L OUTIL MDA UTILISÉ : «ENTREPRISE ARCHITECT»... 94 II.5 DESCRIPTION DES MODELES PIMs D INTEGRATION WEB... 94 II.5.1 Modèle D intégration Des Services Web... 95 II.5.2 Modèle D intégration Des SOAs... 95 II.5.3 Modèle D intégration Des Mashups... 96 II.6 INTEGRATION DES MODELES PIMs D INTEGRATION WEB... 97 II.6.1 Procédure D intégration Des Modèles PIMs... 97 II.6.2 Description Du Meta-Modèle D intégration Web Elaboré... 98 II.6.3 Vérification Du Méta-Modèle Elaboré... 99 II.7 GENERATION D UN PIM SPECIFIQUE POUR UN CAS D UTILISATION... 100 II.7.1 Choix D un Cas D utilisation... 100 II.7.2 Génération D un Profil UML A Partir Du Méta-Modèle... 101 II.7.3 Génération D un PIM Spécifique A Partir Du Profil UML... 103 II.8 VERSION DETAILLEE DU META MODELE ELABORE... 105 II.8.1 Versions détaillées Des Modèles D'intégration Des Services Web... 105 II.8.2 Version Détaillée Du Modèle D'intégration SOA... 112 II.8.3 Version Détaillée Du Modèle D'intégration Des Mashups... 113 II.8.4 Description de quelques relations entre les concepts... 114 II.8.5 Version Détaillée Du Méta-Modèle Global D'intégration Web... 114 II.9 CONCLUSION... 116 CONCLUSION GENERALE... 117 ANNEXES... 120 A. APERÇU SUR LE PARADIGME ORIENTE SERVICE... 120 B. HISTORIQUE SUR LES ARCHITECTURES D APPLICATIONS... 123 C. HISTORIQUE : XML, SERVICES WEB, SOA... 128 D. LISTE D ABREVIATIONS... 131 BIBLIOGRAPHIE... 132 2

LISTE DES FIGURES Figure I.1: Points d accès de l Intégration Web.... 14 Figure I.2: les modèles de l architecture des services web.... 17 Figure I.3: le modèle orienté message de l architecture des services web.... 18 Figure I.4: le modèle orienté service de l architecture des services web.... 19 Figure I.5: le modèle orienté ressource de l architecture des services web.... 19 Figure I.6: le modèle orienté sécurité de l architecture des services web... 20 Figure I.7: spécification WSDL d un service web.... 28 Figure I.8: exemple d un lien WSDL pour un service web.... 29 Figure I.9: les enregistrements dans le modèle découvrir trouver utiliser.... 30 Figure I.10: composants de base d une SOA... 32 Figure I.11: Possibilité de choisir entre différentes sources de mêmes données.... 55 Figure I.12: Agrégation de données concernant les activités d une personne en ligne.... 55 Figure I.13: une architecture générale d un mashup.... 58 Figure I.14: architecture de mashups coté serveur.... 59 Figure I.15: architecture de mashups coté client.... 60 Figure I.16: architecture d un environnement de mashups d entreprise.... 61 Figure I.17: cycle de développement des mashups... 66 Figure I.18: interface de l outil Dapper.... 69 Figure I.19: interface de Microsoft Popfly.... 70 Figure I.20: taux d utilisation des mashups.... 72 Figure I.21: taux d utilisation des APIs pour les mashups... 72 Figure I.22: modèle d agrégation d un Portail web.... 74 Figure I.23: modèle d agrégation du Mashups.... 74 Figure II.1: principaux concepts du MDA.... 81 Figure II.2: architecture MOF à quatre couches.... 82 Figure II.3: transformation d un PIM en plusieurs PSMs dans MDA... 87 Figure II.4: principe de transformation de modèles dans MDA.... 88 Figure II.5: étapes d application de MDA.... 89 Figure II.6: Approche d application de MDA pour l intégration web.... 92 Figure II.7: Schéma détaillé des différentes transformations de modèles.... 93 Figure II.8: interface de l outil Enterprise Architect.... 94 Figure II.9: modèle d intégration des services web... 95 Figure II.10: modèle d intégration de SOA... 96 Figure II.11: modèle d intégration des mashups.... 97 Figure II.12: méta modèle global d intégration web.... 99 Figure II.13: cas d utilisation Buyer, Seller, CreditAgency et Shipper.... 101 Figure II.14: profil UML d intégration web, sous forme de fichier XML.... 102 Figure II.15: modèle PIM spécifique au cas d utilisation... 104 Figure II.16: modèle orienté message de l architecture de services web.... 106 Figure II.17: modèle orienté service de l architecture de services web.... 108 Figure II.18: modèle orienté ressource de l architecture de services web.... 110 Figure II.19: modèle orienté sécurité pour une architecture de services web.... 111 Figure II.20: modèle d intégration d une SOA.... 113 Figure II.21: modèle d intégration des mashups.... 113 Figure II.22: version détaillée d un modèle d intégration web.... 115 3

LISTE DES TABLEAUX Tableau I.1: les principes orientés service et leurs supports dans les services web.... 16 Tableau I.2: récapitulation de certains modèles de services Web.... 24 Tableau I.3: classification des outils de mashups... 68 Tableau I.4: produits de pointe de création et de gestion des mashups.... 71 Tableau I.5: développement des mashups vs développement traditionnel... 73 Tableau II.1: définitions des concepts du modèle orienté message.... 107 Tableau II.2: définitions des concepts du modèle orienté service... 109 Tableau II.3: définitions des concepts du modèle orienté ressource... 111 Tableau II.4: définitions des concepts du modèle orienté sécurité... 112 Tableau II.5: définitions de certaines relations utilisées dans les différents modèles... 114 Tableau III.1: liens entre les principes orientés objet et les principes orientés service... 122 4

INTRODUCTION GENERALE ENJEUX D INTEGRATION DU CONTENU Comme les organisations rencontrent aujourd'hui des défis de plus en plus croissants afin de rester compétitives, l'accessibilité et l'exactitude d'informations sont devenus des facteurs de succès critiques. Un meilleur accès à l'information peut améliorer l'efficacité opérationnelle, le service à la clientèle, la rentabilité de commercialisation, et la gestion des capitaux et des ressources, cela mène directement à un impact positif sur les résultats attendus. Pour remédier à leurs insuffisances de gestion de l'information, les départements de technologies d information des organisations ont opté pour des solutions d'intégration. [01] Les entreprises sont confrontées avec des problèmes d'intégration de plus en plus critiques. Ainsi, les départements de technologies d information doivent traiter avec diverses applications qui ne sont pas conçues initialement pour interagir les uns avec les autres. En plus, les entreprises ont besoin souvent de certaines connections aux applications externes, en particulier dans les cas où elles interagissent avec des clients, des fournisseurs, des distributeurs, ou bien avec des agences gouvernementales. [02] Conceptuellement, trois types de connexions peuvent être établis : connexions à la couche de présentation, à la couche de fonctionnalités, ou à la couche de données. Des méthodes traditionnelles d'intégration sont souvent appliquées mais elles ont des inconvénients significatifs, incluant : le coût, le temps et l inefficacité. [03] ORIENTATION VERS L INTEGRATION WEB Pour faire face aux enjeux de l'intégration, les départements de technologies d information des organisations s'orientent vers l'intégration Web. Ceci est du à une caractéristique clef de l'intégration Web : Beaucoup d'applications ont déjà des interfaces Web basées sur HTML qui peuvent donner l'accès à leurs fonctionnalités, données, et même à la logique incluse dans la couche de présentation. Bien que cette interface soit prévue pour les utilisateurs humains, l'intégration Web peut la transformer en une interface programmable bien définie qui expose la fonctionnalité et les données de l'application. Avec cette méthode, l'intégration peut être faite rapidement, itérativement, et économiquement. En outre, l'intégration Web n'exige pas de compétences avancées. [03] 5

Vus ces avantages, le domaine d intégration web a connu de grandes évolutions concrétisées par l émergence de diverses technologies d intégration web, à savoir : les services Web, SOA (Architecture Orientée Services) et le Web 2.0. Les récentes évolutions de la technologie de service Web auront des effets de grande envergure sur l'internet et les réseaux d'entreprises. Les services Web basés sur Extensible Markup Language (XML), Simple Objec Access Protocol (SOAP), et les standards ouverts connexes, et déployés dans des Architectures Orientées Services (SOAs), permettent aux applications d'interagir via des connexions dynamiques et ad hoc. La technologie de services web peut être implémentée dans une large variété d'architectures, peut coexister avec d'autres technologies et approches de conception de logiciel, et peut être adoptée d'une façon évolutionnaire sans exiger des transformations importantes aux applications et aux bases de données existantes. [04] Malgré l'hétérogénéité des plates-formes fondamentales, les services web augmentent l'interopérabilité et peuvent, ainsi, supporter des applications économiques composées par des chaînes de services Web. Une telle technologie facilite également une deuxième génération de communautés web et de services hébergés, tels que les sites web de réseau sociaux et les wikis, qui supportent la collaboration et le partage entre les utilisateurs. Le terme "Web 2.0" a été inventé pour embrasser toutes ces nouvelles applications de collaboration et pour indiquer également une nouvelle approche «sociale» pour la création et la distribution du contenu web, caractérisé par une communication ouverte, décentralisation d'autorité, et liberté de partage et de réutilisation. Ainsi, la technologie de service web fait du web «l'endroit» où la majorité d'interactions humaines et sociales ont lieu. [04] POSITION DE PROBLEME Malgré toutes ces évolutions, le domaine d intégration web connaît toujours plusieurs enjeux entre autres on insiste sur le problème de l interopérabilité. Ainsi, depuis quelques années, l interopérabilité des applications est devenue le leitmotiv refrain des développeurs et concepteurs de systèmes. L interopérabilité signifie «la capacité à communiquer, coopérer et échanger des modèles ou des données entre deux ou plusieurs applications, malgré les différences dans les langages d implémentation, les environnement d exécution ou les modèles d abstraction» (Kalfoglou et Schorlemmer, 2004). [05] 6

La plupart des approches existantes pour l interopérabilité dans l environnement d entreprise ont pour objectif principal l ajustement et l adaptation de types et structures des paramètres d appel, lorsqu une procédure doit invoquer une autre. Ces approches se basent sur le paradigme d appel de procédures ; ce type d interopérabilité est appelé l interopérabilité orientée procédure. Dans ce cadre, il est admis que la procédure requise par le client et celle offerte par le serveur soient fonctionnellement identiques, autrement dit les fonctions réalisées par la procédure du client et celles réalisées par la procédure du serveur sont les mêmes ou tout au moins compatibles. Bien que l interopérabilité orientée procédure soit une bonne base pour l interopérabilité entre composants ou applications hétérogènes en se basant sur l unification des interfaces, les solutions offertes résolvent uniquement le coté syntaxique de l interopérabilité. Le protocole d interconnexion des interfaces ne traite ni la sémantique des fonctions réalisée par les procédures ni la sémantique des données en entrée ou en sortie. Les travaux relatifs aux services web apportent un peu plus de sémantique par la définition des services disponibles de manière distribuée mais restent, tout de même, très technologiques. Pour traiter l interopérabilité sémantique des données, plusieurs travaux de recherche ont vu le jour, on peut les classifier en trois grandes approches : l interopérabilité par mapping, l interopérabilité via des middlwares et l interopérabilité par échange de requêtes. Mais ces approches présentent des inconvénients en relation avec, respectivement, la définition explicite de la sémantique, la définition des ontologies et l implication de la responsabilité de l utilisateur dans le processus de résolution des conflits sémantiques. [05] En novembre 2000 à Orlando, l'omg (Object Management Group) a rendu publique sa nouvelle orientation dans un document intitulé MDA (Model Driven Architecture). Il s'agit du constat, plus de 10 ans après la création de l'omg, que la recherche de l'interopérabilité dans les systèmes d'information ne peut être atteinte uniquement grâce à la standardisation des infrastructures de middleware, mais par une approche beaucoup plus globale où la notion de modèle devient essentielle et centrale. [06] Plusieurs travaux sur l application de l approche MDA pour intégration web ont été abordés dans les dernières années. Ces travaux, guidés principalement par l OMG et W3C, consiste en l élaboration de méta-modèles, de modèles de domaines et de profils UML, [34], [35], [36], [37], [38]. Cependant, ces travaux ont été entamés, d une manière indépendante, sur les technologies d intégration web (les services web, SOA, les mashups, etc.). Autrement dit, l interopérabilité est traitée, selon l approche MDA, entre les 7

applications qui respectent la même architecture. Cependant, l interopérabilité, entre des applications ayants de diverses architectures, est traitée, d une manière classique (niveau technologie), par le biais de services web. Dans le but de dépasser les frontières technologiques, nous présentons dans notre travail une approche MDA qui se caractérise par une vision globale, en considérant que les différentes technologies d intégration web ne représentent que des composants complémentaires qui doivent être prises en compte à n importe quelle étape de cycle de développement. Généralement, MDA vise à séparer la logique d'affaires, d'application ou de domaine (Platform Independant Model : PIM) de la technologie fondamentale d'implémentation (Platform Specific Model : PSM et l'implémentation). La séparation de PIM, de PSM et d'implémentation est conforme à la règle la plus importante dans le développement de systèmes d'information, qui est la séparation des soucis. En plus, l'utilisation des modèles PIM nous permet de soustraire de la technologie d'implémentation, de telle sorte que le développement de système d'information atteint un niveau plus haut d'abstraction. Cette augmentation dans l'abstraction est comparable à l'évolution des langages de programmation, à partir du langage machine à l'assembleur, à la procédure, au langage orienté module et aujourd'hui au langage orienté objet. [07] ORGANISATION DU MEMOIRE Pour mener à bien ce travail, nous avons organisé notre mémoire en deux parties. La première partie sera consacrée à état d art sur le domaine d intégration web, hors que la deuxième partie soit réservée à l application de la démarche MDA sur le domaine d intégration web, dont, le but final est d élaborer un méta-modèle d intégration web. Dans la première partie, nous commencerons tout d abord par un aperçu général sur le domaine d intégration, en focalisant sur les enjeux qui ont dicté l orientation vers l intégration web comme étant une solution recommandée pour favoriser les échanges entre des applications hétérogènes dans une entreprise ou entre plusieurs partenaires. Ensuite nous donnerons des notions générales sur l intégration web, en précisant les points d accès qui permettent l échange et la communication entre les applications web, à savoir les données, les fonctionnalités et les présentations. Après, nous explorerons les technologies de pointe qui ont connu un grand succès dans le domaine d intégration web à savoir : les services web, SOA et les mashups. Ainsi, nous expliquerons, les enjeux qui 8

gênent les projets d intégration web en termes de : temps, coût, maintenance et d interopérabilité. Vu l importance de l initiative MDA de l OMG pour faire face aux enjeux connus par la communauté de développement d une manière générale et en particulier la communauté web, nous entamerons la deuxième partie par un aperçu sur les principaux concepts de cette architecture (MDA), qui consiste à transformer des modèles PIM en des modèles PSM pour générer enfin le code source d une application. Ainsi, nous commencerons par des notions générales, en insistant sur la relation entre MDA et d autres initiatives d OMG (UML et MOF). Par la suite, nous énumérerons les concepts de base utilisés dans MDA. En plus, nous explorerons les standards, les types de modèles, les transformations de modèles et les grandes étapes à parcourir dans une démarche MDA. Après avoir étudié le domaine d intégration web et donné un aperçu sur l approche de développement MDA, nous continuerons toujours avec la deuxième partie, en présentant, ainsi, une démarche d application de l approche MDA afin d élaborer un méta modèle d intégration web. En premier lieu, nous commencerons par l énumération des raisons de l adoption de notre approche. Ensuite, nous parcourrons les étapes de l application de cette approche, en commençant par la collecte de différents modèles d intégration de services web, de SOA est des mashups, Ces deniers modèles seront considérés comme étant une matière première qui aura subi une suite de transformations pour mener à la production d un modèle PIM qui représente notre dudit méta modèle. Ce dernier fera l objet d autres transformations pour générer un modèle PIM spécifique à un cas d utilisation bien choisi. Ce modèle PIM spécifique pourra être transformé à son tour en un modèle PSM qui sera utilisé pour générer, d une manière semi automatique le code source d une application d intégration web pour ce cas d utilisation. Enfin, nous conclurons notre travail, en citant les difficultés rencontrées, les avantages et les inconvénients de notre approche. Enfin, nous clôturons notre mémoire par une conclusion générale, dans laquelle nous extrairons les points précieux de notre mémoire et nous nous envisagerons quelques perspectives. 9

I INTEGRATION WEB, ETAT DE L ART I.1 INTRODUCTION L objectif de cette partie est de relever les concepts de base du domaine d intégration web, en explorant les technologies qui ont connu un grand succès. Ainsi, nous rappelons, en premier lieu, la notion de l intégration d une manière générale et les enjeux qui ont imposé l orientation des départements de TI vers l intégration web pour faire face au problème d hétérogénéité entre les différentes génération des applications, que se soient internes ou externes à l entreprise. Ensuite, nous explorons les technologies d intégration web les plus utilisées à savoir : les services web, SOA et les mashups. Enfin, nous relèverons les enjeux de l intégration web. I.2 APERÇU SUR L INTEGRATION I.2.1 Notion D intégration L'intégration d applications d'entreprise (EAI: Entreprise Application Integration) est un genre de Velcro technologique, permettant aux systèmes informatiques de s'adapter à un tel changement. EAI permet aux divers systèmes de se connecter entre eux rapidement pour partager des données, des communications, et des processus, allégeant les silos de l'information qu infestent beaucoup d'entreprises. Les avantages d'assimiler de nouveaux systèmes sans efforts de programmation prolongés sont évidents après une activité de fusion et d'acquisition. Les solutions d'eai fournissent une manière de connecter des systèmes de collaborateurs, de partenaires, et d'autres, autant qu il est nécessaire, et permettent de découpler ces systèmes quand la relation s'est terminée. EAI est, essentiellement, la colle soluble pour la corporation modulaire. [09] Afin de segmenter leur marché, les éditeurs d EAI ont effectué une différenciation des problématiques adressées, selon la prise en considération: [10] - des échanges internes de l entreprise (AtoA: Application to Application), - des échanges inter-entreprises (BtoB : Business to Business), - des échanges entre l entreprise et les consommateurs finaux (BtoC : Business to Consumers). 10

I.2.2 Enjeux D intégration Les entreprises sont confrontées de plus en plus aux problèmes d'intégration critiques. En dépit des efforts fournis, les départements de technologies d'information doivent s'occuper de nombreuses applications qui ne sont pas conçues pour interagir les unes avec les autres. En outre, les entreprises ont besoin souvent de se connecter aux applications en dehors de l'entreprise, en particulier dans les cas où elles interagissent avec des clients, des fournisseurs, des distributeurs, ou des organismes gouvernementaux. Des méthodes traditionnelles d'intégration, aussi bien que les services web, sont souvent appliquées mais elles ont des inconvénients significatifs, incluant : [03] I.2.2.1 Le Coût L'approche d'intégration d'application la plus connue se fonde sur la possibilité d'avoir le contrôle des applications et d y apporter des modifications. Par exemple, les staffs d'it ajoutent souvent une interface de service web qui expose la fonctionnalité et les données désirées. Mais cette approche a comme conséquence des projets de développement coûteux et longs qui réclament des programmeurs qualifiés. Elle est également remplie de haut risque et d'un impact architectural élevé. [03] I.2.2.2 Le Temps Les organisations de technologies d'information sont chargées d'accomplir des projets d'intégration à un rythme toujours croissant. Malheureusement, la définition des API et des chemins de communications est un processus long. Les efforts courants de normalisation des interfaces de programmation pourront aider probablement, une fois que des services web ont été créés. Cependant, les services web doivent encore être implémentés. L'exposition des données et de la logique d'application dans une interface programmable sera une tâche considérable. (En outre, cette approche exige le plein contrôle au-dessus du code source d'application.) [03] I.2.2.3 L Inefficacité Pour des applications en dehors du domaine d'entreprise, les méthodes traditionnelles de modification, habituellement, ne peuvent pas être utilisées. En conséquence, beaucoup de projets critiques d'intégration de métiers ne peuvent même pas décoller. Les conséquences d'affaires incluent une productivité réduite, des coûts d'exploitation plus élevés, des occasions perdues, et une agilité affaiblie. [03] 11

I.2.3 Orientation Vers L intégration Web Pour faire face aux enjeux d'intégration, les départements d IT des organisations s'orientent vers l'intégration web. Ceci est du à une caractéristique clef de l'intégration web : Beaucoup d'applications ont déjà une interface web basée sur HTML qui peut donner l'accès à leur fonctionnalité, données, et même la logique incluse dans la couche de présentation. Bien que cette interface soit prévue pour les utilisateurs humains, l'intégration web peut la transformer en une interface programmable bien définie qui expose la fonctionnalité et les données de l'application. Avec cette méthode, l'intégration peut être faite rapidement, itérativement, et économiquement. En outre, l'intégration Web n'exige pas de compétences avancées. [03] I.3 GENERALITES SUR L INTEGRATION WEB I.3.1 Notion De L intégration Web A partir de la définition de l intégration d une manière générale, on peut définir l intégration web comme étant un domaine qui s occupe de problèmes concernant l intégration des applications particulières ayant des architectures orientées web. La particularité de ces applications est due au fait qu elles soient implémentées dans un environnement ouvert (Internet). Cette ouverture des applications web permet de répondre à certains enjeux d intégration, surtout l interopérabilité et la distribution. Cependant, elle constitue une source d autres problèmes, à savoir la sécurité et la qualité de service (QoS), qui peuvent infecter l intégration de ces applications elles-mêmes. En tous les cas, l intégration web a pris une grande ampleur et a constitué l une des principales alternatives d intégration d applications d entreprises. I.3.2 Avantages De L intégration Web Comparée aux approches traditionnelles d'intégration, l'intégration Web a un certain nombre d'avantages significatifs : [03] I.3.2.1 Moins coûteuse L'intégration Web n'exige pas les efforts coûteux de l'intégration traditionnelle, tels que les programmeurs à haut niveau qui coûtent cher, ou la nécessité d'apporter des modifications dans des applications existantes, la sécurité, l installation des pare-feux, etc. 12

I.3.2.2 Processus Non-intrusif L'intégration Web n'exige aucune modification de l'application à intégrer. Cette approche élimine le besoin aux changements architecturaux et réduit le potentiel en cas de panne. Elle permet également l'intégration des applications qui sont accessibles seulement par le Web. [03] I.3.2.3 Faible risque Avec l'intégration Web, le premier projet est souvent mis en service dans une durée de quelques jours, et d'autres intégrations peuvent être faites itérativement, car certaines expériences et le rendement des premières intégrations sont analysés. Sur ce plan-là, les entreprises peuvent essayer de nouvelles opportunités d affaires à un risque plus inférieur par rapport aux méthodes traditionnelles. [03] I.3.2.4 Délai d intégration réduit Même les projets d'intégration compliqués peuvent être accomplis en quelques semaines plutôt que des mois ou des années. Les entreprises peuvent gagner l'avantage compétitif en accroissant leurs applications existantes plus rapidement que leurs concurrents. [03] I.3.2.5 Phase de conception plus précise L'interface Web est également bien comprise par la personne d'affaires et le programmeur. Cela permet des communications plus précises au sujet de la conception d'application. [03] I.3.2.6 Moins d exigences de compétence Un projet traditionnel d'intégration exige des développeurs qualifiés qui sont moins disponibles. Ils ont besoin d une connaissance étendue des applications à intégrer et d une bonne compréhension de l'intégration d'application en général. En utilisant l'intégration Web et avec juste une expérience de programmation de base et la connaissance de HTML, les développeurs peuvent effectuer le travail pour se connecter aux applications accessibles par le web. [03] I.3.3 Points D accès De L intégration Web Beaucoup d'applications ont déjà une interface Web basée sur HTML qui peut donner l'accès à leur fonctionnalité, données, et même la logique incluse dans la couche 13

de présentation. Bien que cette interface soit prévue pour les utilisateurs humains, l'intégration Web peut la transformer en une interface programmable bien définie qui expose la pleine fonctionnalité et données de l'application. Ceci est illustré dans la figure suivante : [03] Figure I.1: Points d accès de l Intégration Web. Comme ce que montre cette figure, le serveur d'intégration Web accède à la couche de présentation d'une application par l interface Web. Le serveur d'intégration Web peut alors rendre un ou plusieurs des points d'accès suivants disponibles : une interface Web modifiable, un api, un service Web, ou données structurées. Cette approche peut être utilisée pour transformer facilement en un service web n'importe quelle application ayant une interface Web. I.4 L INTEGRATION AVEC LES SERVICES WEB I.4.1 Introduction Au Paradigme Orienté Service Il y a plusieurs points de vue, provenant d organismes de TI publiques, de fournisseurs et de consultants, au sujet de ce qui constitue «le paradigme orienté service». Ce dernier a ses racines dans une théorie de programmation connue sous le nom de «séparation des soucis». Cette théorie est basée sur la notion de décomposer un grand problème en une série de petits problèmes. Ceci permet de décomposer la logique nécessaire pour résoudre un problème en une collection de petites parties (services). Chaque partie de logique aborde un souci spécifique. Cette théorie a été implémentée de différentes manières avec diverses plates-formes de développement. La programmation 14

orientée objet et les approches de programmation à base de composants, par exemple, réalisent une séparation des soucis par l'utilisation des objets, des classes, et des composants. [11] Comme précédemment mentionné, il n'y a aucun ensemble officiel de principes du paradigme orienté service. Cependant, il y a un ensemble des principes généraux les plus associés au paradigme orienté service à savoir : la réutilisabilité, le contrat, le couplage faible, l abstraction, la composition, l autonomie, l apatridie et la découverte de service. Ces principes sont expliqués dans l annexe : A. Aperçu sur le paradigme orienté service. I.4.2 Généralités Sur Les Services Web I.4.2.1 Définition d'un service web Un service Web est un système logiciel conçu pour supporter l'interaction interopérable machine-à-machine à travers un réseau. Il a une interface décrite dans un format exploitable par machine (spécifiquement WSDL). D'autres systèmes interagissent avec un service web selon la manière prescrite par sa description en utilisant des messages SOAP, typiquement transmis en utilisant le protocole HTTP avec une sérialisation XML et d'autres standards WEB. [12] I.4.2.2 Service web et le paradigme oriente service Après avoir eu un aperçus sur les différents principes du paradigme orienté service, il devient évident que les services web fournissent un support inhérent pour certains d entre eux. Il est important de reconnaître spécifiquement que certains principes sont construits dans la structure des services web, parce que ceci nous permet de mettre un accent sur ceux qui exigent un effort de réalisation conscient. Le «tableau I.1» récapitule les principes du paradigme orienté service et explique dans quelle mesure qu ils soient supportés par les services web. [11] Principes orienté service Réutilisabilité de service contrat de service Possibilité d être supporté par les services web Les services web ne sont pas automatiquement réutilisables. Cette qualité est liée à la nature de la logique encapsulée et exposée par le service web. Chaque service web exige l'utilisation d une description qui constitue une partie fondamentale pour la communication avec les autres services web. 15

Principes orienté service Possibilité d être supporté par les services web Les services web sont naturellement légèrement Couplage faible de service couplés par l'utilisation des descriptions de service. Les services web émulent automatiquement le modèle de boîte noire dans l environnement de Abstraction de service communications de services web, cachant tous les détails de leur logique fondamentale. Les services web sont naturellement composables. Le point auquel un service peut être composé est Composition de service généralement déterminé par la conception de service et la réutilisabilité de la logique représentée. Pour assurer un environnement de traitement autonome, cela exige un effort de conception. Autonomie de service Donc, l'autonomie n est pas automatiquement fournie par un service web. L'apatridie est une condition préférée pour les services web, fortement supportée par beaucoup de Apatridie de service spécifications WS-* et le modèle de messages SOAP. La découverte doit être mise en application par l'architecture et peut être considérée une Découverte de service prolongation à l'infrastructure IT. Donc, elle n'est pas supportée nativement par les services web. Tableau I.1: les principes orientés service et leurs supports dans les services web. Il est important de souligner les principes qui nécessitent une attention particulière pour la réalisation des solutions orientées services. Ces principes ne sont pas supportés automatiquement par les services web: la réutilisabilité de service, l autonomie de service, l apatridie de service et la découverte de service. I.4.2.3 Service web et agent Un service web est une notion abstraite qui doit être mise en application par un agent concret. L'agent est la partie concrète de logiciel ou de matériel qui envoie et reçoit les messages, alors que le service est la ressource caractérisée par l'ensemble abstrait de fonctionnalités qu'il fournit. Pour illustrer cette distinction, il est possible d' implémenter un service web en utilisant un agent (écrit en un langage de programmation), ou en utilisant plusieurs agents (pouvant être écrits avec différents langages de programmation) avec la même fonctionnalité. Bien que l'agent puisse être changé, le service web reste toujours le même. [12] 16

I.4.3 Architecture Des Services Web I.4.3.1 Le but de l architecture des services web Les services web fournissent un moyen standard d'interopérabilité entre différentes applications logicielles, exécutées sur une variété de plates-formes et/ou d environnements. L'architecture de services web fournit un modèle conceptuel et un contexte pour comprendre les services web et les relations entre les composants de ce modèle. L'architecture n'essaye pas de spécifier comment les services web sont implémentés, et n'impose aucune restriction sur la façon dont les services web pourraient être combinés. Cette architecture décrit les caractéristiques minimales qui sont communes à tous les services web, et un certain nombre de caractéristiques qui sont nécessaires pour beaucoup de services web. L'architecture de services web est une architecture d'interopérabilité : elle identifie les éléments globaux qui sont nécessaires afin d'assurer l'interopérabilité entre les services web. [12] I.4.3.2 Les modèles de l architecture des services web Cette architecture, illustrée sur la figure I.2, a quatre modèles. Chaque modèle dans cette figure est étiqueté avec ce qui peut être vu comme concept clé de ce modèle. [12] Figure I.2: les modèles de l architecture des services web. 17

Le modèle orienté message : il focalise sur les messages, la structure des messages, le transport d un message et ainsi de suite, sans aucune référence particulière quant aux raisons des messages, ni à leur signification (voir la figure I.3). [12] Figure I.3: le modèle orienté message de l architecture des services web. L'essence du modèle des messages tourne autour de quelques concepts principaux à savoir : l'agent qui envoie et reçoit les messages, la structure du message en termes d'en-têtes de message et corps et les mécanismes employés pour fournir des messages. De plus, des détails supplémentaires sont à considérer : le rôle du concept de sécurité et comment il régisse le modèle des messages. Le diagramme abrégé montre les concepts principaux ; le diagramme détaillé est enrichie pour inclure plus de concepts et de relations. Le modèle orienté service : focalise sur des aspects de service, action et autre. Tandis que clairement, dans aucun système distribué, des services ne peuvent pas être réalisés d'une manière adéquate sans quelques moyens de transmission de messages, l'inverse n'est pas le cas : les messages n'ont pas besoin de se rapporter aux services. [12] Le modèle orienté services est le plus compliqué de tous les modèles dans l'architecture des services web [12]. Cependant, il tourne aussi autour de quelques idées principales. Un service est réalisé par un agent et employé par un autre agent. Les services sont négociés au moyen des messages échangés entre les agents demandeurs et les agents fournisseurs. Ce modèle est illustré dans la figure ci-après. [12] 18

Figure I.4: le modèle orienté service de l architecture des services web. Un aspect très important des services c'est leur relation avec le monde réel : les services sont, la plupart du temps, déployés pour offrir des fonctionnalités dans le monde réel. Nous modelons ceci par l'élaboration du concept de propriétaire d'un service qui, soit une personne ou une organisation, a une responsabilité de monde réel du service. Le modèle orienté ressource: il se focalise sur les ressources qui existent et qui ont des propriétaires qui peuvent être des personnes ou des organisations (voire la figure I.5). [12] Figure I.5: le modèle orienté ressource de l architecture des services web. Le modèle de ressource est adopté à partir du concept de ressource de l'architecture Web. Nous nous basons sur ceci pour incorporer les relations entre les ressources et les propriétaires. 19

Le modèle de sécurité: se concentre sur des contraintes de comportement des agents et des services (voir la figure I.6). Nous généralisons ceci aux ressources, puisque la sécurité peut s'appliquer également aux documents (tels que des descriptions des services) aussi bien que les ressources informatiques actives. [12] Figure I.6: le modèle orienté sécurité de l architecture des services web. La sécurité est au sujet des ressources. Elle est appliquée aux agents qui peuvent essayer d'accéder à ces ressources, et sont mises en place, ou établies, par les personnes qui ont la responsabilité sur la ressource. Ces modèles seront détaillés ultérieurement dans la deuxième partie. I.4.4 Classifications Des Services Web Chaque service web peut être associé à : [11] - une classification temporaire basée sur les rôles qu'il assume pendant le traitement d'un message, - une classification permanente basée sur la logique d'application qu'il fournit dans un environnement d une solution. I.4.4.1 Classification temporaire des services web Un service web est capable d'assumer différents rôles, selon le contexte dans lequel il est employé. Par exemple, un service peut agir en tant qu'initiateur, réémetteur, ou destinataire d'un message. Un service donc n'est pas marqué exclusivement comme client ou serveur, mais comme unité logicielle capable de changer son rôle, selon sa responsabilité de traitement dans un scénario donné. [11] 20

Il n'est pas rare qu'un service web change plus d'une fois son rôle dans une tâche métier donnée. Il n'est particulièrement pas rare qu'un service web assume différents rôles dans différentes tâches métier. Nous discutons ci-dessous les descriptions des rôles fondamentaux de services web. a- Fournisseur de services Le rôle de fournisseur de services est assumé par un service Web dans les conditions suivantes : [11] - Le service Web est appelé par une source extérieure, telle qu'un demandeur de service, - Le service Web fournit une description du service publiée, en offrant des informations au sujet de ses caractéristiques et son comportement. Le rôle de fournisseur de service est synonyme au rôle de serveur dans l'architecture classique client-serveur. Selon le type d'échange de message utilisé pour invoquer un fournisseur de service, le fournisseur de service peut répondre au message de demande avec un message de réponse. [11] Le terme «fournisseur de service» est employé également pour identifier l'organisation (ou l'individu) responsable de fournir réellement le service Web. Pour aider à distinguer entre le rôle de service et le fournisseur réel du service, les termes suivants sont parfois utilisés : [11] - entité fournisseur de service (l'organisation ou l'individu fournissant le service Web) - agent fournisseur de service (le service Web lui-même, agissant en tant qu'agent au nom de son propriétaire) Cependant, il est plus fréquent de se référer simplement au service appelé comme étant le fournisseur de service. b-demandeur de service N'importe quelle unité de traitement capable de publier un message de demande qui peut être compris par le fournisseur de service est classifiée en tant que demandeur de service. Un service Web est toujours un fournisseur de service mais peut agir également en tant que demandeur de service. [11] 21

Un service Web prend le rôle de demandeur de service dans les circonstances suivantes : [11] - Le service Web appelle un fournisseur de services en lui envoyant un message, - Le service Web recherche et évalue le fournisseur de service le plus approprié en étudiant les descriptions disponibles de service. Le demandeur de service est la contrepartie naturelle du fournisseur de service, comparable au client dans un environnement client serveur. Il est important de noter qu'un fournisseur de service n'agit pas en tant que demandeur de service quand il envoie un message en réponse à un message de demande. Un demandeur de service est mieux vu comme un logiciel qui initie une conversation avec un fournisseur de service. [11] Ce terme présente aussi une certaine ambiguïté. Un demandeur de service peut représenter tous les deux : le service Web lui-même aussi bien que le propriétaire de service Web. Par conséquent, les termes suivants sont disponibles (mais pas vraiment utilisés) : [11] - entité demandeur de service (l'organisation ou l'individu demandant le service Web), - agent demandeur de service (le service Web lui-même, agissant en tant qu'agent au nom de son propriétaire). Un autre terme fréquemment utilisé au lieu du demandeur de service est «le consommateur de service». c-service Intermédiaire Un environnement de communications établi par des services Web contraste la nature prévisible de canaux de transmissions point-à-point traditionnel. Bien que moins flexible et moins extensible, une communication point à point est beaucoup plus facile à concevoir. La communication des services Web est basée sur l'utilisation des chemins de transmission de messages, qui peuvent mieux être décrits comme chemins point-to-*. Cela, parce qu'une fois qu'un fournisseur de service soumet un message, il peut être traité par multiple agents intermédiaires de routage et de traitement avant qu'il arrive à sa destination finale. [11] Les services Web et les agents de services qui font le routage et le traitement d'un message, après qu'il soit initialement envoyé et avant qu'il arrive à sa destination finale, sont désignés sous le nom d intermédiaires ou de services intermédiaires. Puisqu'un 22

service intermédiaire reçoit et soumet des messages, il a toujours des transitions entre des rôles de fournisseur de service et de demandeur de service. [11] Il y a deux types d'intermédiaires. Le premier, connu comme intermédiaire passif, est en général responsable de routage des messages vers l'endroit suivant. Il peut employer l'information dans l'en-tête de message SOAP pour déterminer le chemin de routage, ou il peut utiliser la logique de routage native pour réaliser un certain niveau d'équilibrage de charge. D'autre manière, ce que fait ce type d'intermédiaire passif est qu'il ne modifie pas le message. [11] Comme les services intermédiaires passifs, les intermédiaires actifs conduisent également des messages à une destination d'expédition. Cependant, avant de transmettre un message, ces services activement traitent et changent le contenu du message. Typiquement, les intermédiaires actifs rechercheront les blocs d'en-tête SOAP particuliers et effectueront une certaine action en réponse à l'information qu'ils trouvent là. Ils changent presque toujours des données dans des blocs d'en-tête et peuvent insérer ou même supprimer des blocs d'en-tête entièrement. [11] d-expéditeur initial et récepteur final Les expéditeurs initiaux sont simplement des demandeurs de service qui initient la transmission d'un message. Par conséquent, l'expéditeur initial est toujours le premier service Web dans un chemin de message. La contrepartie de ce rôle est le récepteur final. Cette désignation identifie les prestataires de service qui existent comme dernier service Web dans un chemin de message. [11] e-membre de compositions de service Le terme «composition» ne s'applique pas à un service Web simple, mais à une relation de composition entre une collection de services. N'importe quel service peut faire appel à un ou plusieurs services additionnels pour accomplir une tâche donnée. De plus, les services appelés peuvent utiliser d'autres services pour accomplir une sous-tâche donnée. Par conséquent, chaque service qui participe à une composition assume un rôle individuel de membre de composition de service. Typiquement, les services Web doivent être conçus pour être des membres efficaces de composition. Les principes du paradigme orienté service mettent un accent sur la composition, en permettant à quelques services Web d'être conçus de façon qu'ils puissent participer dans de futures compositions de services sans connaissance préalable de la façon dont ils seront utilisés. [11] 23

I.4.4.2 Classification permanente des services web Les rôles que nous avons explorés jusqu'ici sont agnostiques à la nature de la fonctionnalité fournie par le service Web. Ils y a des états génériques qu'un service peut y entrer dans un contexte générique. Cependant, la façon dont les services sont utilisés dans le monde réel a mené à une classification basée sur la nature de la logique d'application qu'ils fournissent, aussi bien que leurs rôles liés au marché dans la solution globale. Ces classifications sont connues comme modèles de service. Le tableau suivant récapitule certains modèles de services Web. [11] Modèle de service Service d'application Service d'affaires Service de contrôle Service de coordination Service d utilité Description Une catégorie générique utilisée pour représenter les services qui contiennent une logique dérivée d'une plateforme de solution ou de technologie. Une catégorie générique utilisée pour représenter les services qui contiennent la logique d'affaires. Un service qui compose d'autres. Les variations de ce modèle existent, selon la position du contrôleur dans la hiérarchie de composition. Le service de contrôle parent peut être classifié comme contrôleur principal et un service qui compose un sousensemble de plus grande composition peut être désigné comme un contrôleur secondaire. Trois modèles de service sont dérivés du concept de la coordination : le coordonnateur, le coordonnateur atomique de transaction, et le coordonnateur d'activité d'affaires. Chacun des trois modèles est spécifique au spécification WS-Coordination et aux protocoles relatifs. Un service qui offre une logique réutilisable. Cette catégorie est principalement prévue pour la classification des services d'application. Cependant, elle peut être également employée pour se rapporter aux services d'affaires réutilisables. Tableau I.2: récapitulation de certains modèles de services Web. Dans la section suivante, nous présenterons les principales technologies et standards des services web. 24

I.4.5 Technologies Et Standards De Services Web Les bases technologiques des services Web comptent en grande partie sur des technologies implémentant des standards pour le World Wide Web. Les bases technologiques du World Wide Web sont fondamentalement ceux qui tiennent compte de l'identification des ressources (Universal Resource Identifier, URI), de la représentation de leur état, et des protocoles standards qui soutiennent l'interaction entre les agents et les ressources dans l'espace Web, tel que le protocole de transfert hypertexte (HTTP). Les standards et les technologies basés sur XML incluent : Extensible Markup Language luimême, schéma XML, SOAP, langage de description de services Web (WSDL), et Universal Description Discovery and Integration (UDDI). [13] L'URI c est une chaine de caractères compacte utilisé pour identifier ou désigner une ressource, c'est la spécification la plus fondamentale de l'architecture Web. Les spécifications d'uri transforment le Web en un espace uniforme, faisant les propriétés des systèmes d'adressage et de nomination indépendants des langages qu'ils les utilisent. Le protocole de transfert hypertexte (HTTP) c'est un protocole de communication général pour le transfert de l'information sur le World Wide Web. La propriété la plus appropriée de HTTP est son extensibilité. Un mécanisme d'extension identifie explicitement et clairement les possibilités des implémentations. L'extensibilité est une condition principale pour assurer l'interopérabilité, puisque cette dernière exige la compatibilité avec les versions précédentes du protocole. [13] I.4.5.1 XML (Extensible Markup Language) XML, un standard approuvé par W3C pour le balisage de document, est le «lingua franca» pour le Web. XML peut revenir à SGML, Standard Generalized Markup Langage. XML est un langage de méta-balisage conçu pour la création des langages. Simplement, XML ne contraint pas ses utilisateurs à un ensemble fixe d'étiquettes et d'éléments ; plutôt il est intrinsèquement extensible, permettant aux développeurs de définir de nouvelles langages capables de donner la sémantique nécessaire pour des applications spécifiques (appelées également les applications XML). Au même temps, les spécifications XML définissent une grammaire stricte pour des documents XML, qui permet d'implémenter des parseurs XML pouvant lire des documents XML. Par le mécanisme de namespace, il est possible d'étendre XML par le mixage de multiples vocabulaires dans un même document et la gestion des significations de noms d'une manière non ambiguë, sans encourir des 25

problèmes de collision et de détection de noms. Les spécifications de namespaces XML définissent les constructions qui permettent à un document XML simple de contenir des éléments et des attribues XML définis et utilisés par différents modules logiciels. [13] Les règles concernant la structure d'un document XML, c.-à-d, les éléments et les attributs qui peuvent faire partie d'un document XML et où ils peuvent apparaître, peuvent être documentés dans un schéma. Des instances de document XML peuvent être validées par rapport au schéma. Un schéma peut être assimilé avec une définition de type dans un langage de programmation, et le document XML adhérant au schéma avec une instance d'un type. Plusieurs langages de schéma avec différents niveaux d'expressivité ont été proposés: DÉTENDRE, TREX et SOX. Le langage qui supporte le plus largement le schéma pour XML est le «Document Type Definition (DTD)» qui est également le seul défini par des spécifications XML. A cause de la limitation de syntaxe du DTD, W3C a défini «W3C XML Schéma Langage», et a été publié comme recommandation de W3C en mai 2001. Il est à noter que, à cause de la nature déclarative des langages de schéma, il y a toujours quelques contraintes qui ne peuvent pas être exprimées. Ceci exige d'ajouter du code au programme qui lit et interprète le document XML. [13] I.4.5.2 Simple Object Access Protocol (SOAP) Les interactions de services Web, telles que les demandes envoyées par des demandeurs aux services Web et les réponses envoyées par le service Web, sont basées sur le Simple Object Access Protocol (SOAP). SOAP définit un environnement basé sur XML standard pour l'échange d'information structurée et typée entre les services. [13] Les spécifications (soumises à W3C en 2000) ont été conçues à unifier la communication Remote Procedure Call (RPC), fondamentalement en sérialisant dans XML les données transmises entre les composants, transportant, et dé-sérialisant finalement ces données au composant de destinataire. [13] SOAP est fondamentalement un paradigme apatride et à sens unique d'échange de message qui permet à des applications de créer des modèles plus complexes d'interaction (par exemple, demande-réponse, demande-multi-réponses, etc.) en combinant des échanges à un sens unique avec des configurations fournies par un protocole fondamental et/ou une information spécifique à l'application. [13] À son origine, un message SOAP a une structure très simple : un élément XML avec deux éléments fils, un contenant l'en-tête et l'autre le corps. L'en-tête est un élément 26

facultatif qui permet à l'expéditeur de transmettre des informations de contrôle. Les entêtes peuvent être inspectés, insérés, supprimés, ou expédiés par des nœuds SOAP rencontrés le long d'un chemin de message SOAP. [13] SOAP fournit également une description complète des règles qu'un nœud SOAP, recevant un message SOAP, doit suivre. Ce genre de règles s appelle le modèle de traitement du SOAP. Le modèle de traitement du SOAP définit comment un nœud SOAP doit traiter un message SOAP simple. D'ailleurs, le modèle de traitement du SOAP assume que: un message SOAP commence dans un nœud SOAP expéditeur initial et est envoyé à un récepteur SOAP final via zéro ou plus d'intermédiaires SOAP; un nœud SOAP ne maintient aucune information d'état ; un nœud SOAP ne maintient aucune corrélation entre les messages SOAP. Le comportement d'un nœud SOAP est déterminé selon l'attribut env:mustunderstand des éléments d'en-tête SOAP. Si l'attribut, env:mustunderstand, a une valeur «vraie», le nœud SOAP doit traiter le bloc d'en-tête SOAP selon les spécifications de ce bloc, ou bien produire 'une erreur SOAP. La compréhension d'un en-tête SOAP signifie que le nœud doit être préparé pour faire tous ce qui est décrit dans les spécifications de ce bloc. [13] Lors de l'utilisation du SOAP, un processeur SOAP (ou un moteur SOAP) est nécessaire du côté de demandeur et du côté de service Web pour construire et décoder des messages SOAP. SOAP prévoit pour Remote Procedure Call (RPC) un modèle d'interactions, semblables aux appels de fonction à distance, et une communication styledocument, avec un contenu de message basé exclusivement sur XML Schema Definition. Les résultats d'invocation peuvent être optionnellement renvoyés dans le message de réponse, ou une erreur peut être retournée, qui est similaire aux exceptions dans les langages de programmation traditionnels. [13] I.4.5.3 Web Services Description Language (WSDL) La version 2.0 du Langage de Description de Services Web (WSDL) permet de décrire l'interface de service Web, commençant par les messages échangés entre le demandeur et les agents de fournisseur du service. Les messages sont décrits d'une manière abstraite et sont attachés ensuite à un protocole de réseau et un format de message concret. Les définitions de service Web peuvent être transformées à n'importe quel langage d'implémentation, plate-forme, modèle d'objet, ou système de messagerie. Suivant les indications de la figure I.7, WSDL sépare la description de la fonctionnalité 27

abstraite offerte par un service, appelé l'interface abstraite, de ses détails d'implémentation à savoir, comment le client et le service Web échangent les messages ; comment le service est implémenté (Java,.NET) ; et où le service sera disponible. [13] Figure I.7: spécification WSDL d un service web. Fondamentalement, une interface regroupe un ensemble d'opérations abstraites. À son tour, chaque opération est définie comme une séquence de messages d'entrée et de sortie. Un modèle d'échange de message peut être associé à un ou plusieurs messages. Au niveau abstrait, WSDL définit un service comme une collection de points finaux ou de ports de réseau. La définition abstraite des points finaux et des messages est séparés de leurs déploiements concrets ou des liens de formats de données. Une telle séparation permet de réutiliser les définitions abstraites des messages et des types de port qui représentent des collections d'opérations. Les spécifications concrètes du protocole et du format de données pour un type de port particulier constituer un lien. Un port est défini en associant une adresse réseau à un lien. Ainsi, une collection de ports définit un service. La partie concrète de WSDL fournit les détails d'implémentation suivants (voir la figure I.7) [13]: - Un lien (voire la figure suivante) pour spécifier des détails de format et de transport pour une ou plusieurs interfaces. 28

- Un point final pour associer une adresse réseau à un lien. - Un service pour regrouper des points finaux qui implémentent une interface commune. L'élément de service assigne un nom au service, l'associe à l'interface abstraite et décrit l adresse d accès au service (voir la figure 1.8). <binding name="reservationsoapbinding" interface="tns:reservationinterface" type="http://www.w3.org/ns/wsdl/soap" wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/http/"> <operation ref="tns:opcheckavailability" wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/> </binding> <service name="reservationservice" interface="tns:reservationinterface"> <endpoint name="reservationendpoint" binding="tns:reservationsoapbinding" address ="http://greath.example.com/2004/reservation"/> </service> Figure I.8: exemple d un lien WSDL pour un service web. I.4.5.4 Universal Description, Discovery and Integration (UDDI) Le processus de découverte englobe deux niveaux de description, supportant deux processus distincts: [13] - Le premier est la description des affaires elles-mêmes. Cette description est utile au client d'affaires afin de limiter la portée de leur recherche aux secteurs spécifiques. - Le deuxième comprend la description technique (c.-à-d., la description WSDL) des services Web fournis par les affaires précédemment identifiées. UDDI a été principalement conçu pour fournir des descriptions standardisées des affaires et des services Web qu'elles fournissent pour les enregistrer dans des catalogues (enregistrements). Un tel catalogue peut être interrogé par le client pour trouver facilement les services qu'il a besoin. [13] UDDI définit un ensemble de services standards supportant la description et la découverte (1) des affaires, des organisations, et d'autres fournisseurs de services web fournisseurs ; (2) les services Web qu'ils rendent disponible ; et (3) les interfaces techniques qui sont utilisées pour accéder à ces services. UDDI est basé sur un certain ensemble de standards industriels, y compris HTTP, XML, schéma XML, et SOAP. [13] 29

UDDI, principalement, est un enregistrement contenant des données et des métadonnées concernant des services de Web, y compris l'endroit des services et des informations sur la façon d'invoquer les services Web enregistrés. [13] Un enregistrement UDDI permet de classifier et cataloguer une telle information de telle sorte que les services Web puissent être découverts (et consommés). Donc, il supporte le modèle découvrir-trouver-utiliser (voir la figure I.9) [13]. Figure I.9: les enregistrements dans le modèle découvrir-trouver-utiliser. Dans ce modèle, les différents acteurs se comportent avec l enregistrement selon les étapes suivantes: - Les fournisseurs remplissent l'enregistrement avec les descriptions des services qu'elles supportent; - Les organismes standards et les fournisseurs de logiciel remplissent l'enregistrement avec les descriptions de différents types de services ; - Les clients, les applications d affaires, et les moteurs de recherche peuvent questionner l'enregistrement pour découvrir des services d'autres compagnies. - L'information obtenue par un enregistrement peut être employée pour faciliter l'interaction avec un service et/ou pour composer dynamiquement un service complexe à partir d'un certain nombre de services plus simples. Dans la section suivante, nous aborderons une autre technologie aussi importante dans le domaine d intégration web, qui est : la technologie SOA (Service Oriented Architecture), qui a ses origines du paradigme orientée service (Service Orientation). 30

I.5 INTEGRATION WEB AVEC SOA I.5.1 Historique Sur SOA Nous commençons cette section en couvrant, brièvement, l'historique des principaux développements qui ont émergé pour former la plate-forme courante de SOA (pour plus de détail voir l annexe : Historique XML, Service Web, SOA). Nous prenons alors un regard à la façon dont l'émergence de SOA comme plate-forme architecturale a changé les rôles de XML et de technologies de services Web. Comme HTML, Extensible Markup Language (XML) était une création de W3C dérivée du Standard Generalized Markup Language (SGML) qui a existé depuis les dernières années 60s. Ce méta langage a permis à des organisations d'ajouter de l'intelligence aux données brutes. L'architecture de représentation de données XML représente la couche de base de SOA, dans laquelle, XML établit le format et la structure des messages transmis entre les services. [11] En 2000, le W3C a reçu une soumission pour les spécifications du Simple Object Access Protocol (SOAP). Ces spécifications ont été à l'origine conçues pour unifier et remplacer dans certains cas la communication RPC. L'idée était de paramétrer les données transmises entre les composants afin de les sérialiser dans XML, les transporter, et puis les dé-sérialiser de nouveau dans leur format originaire. Bientôt, les sociétés et les vendeurs de logiciels ont commencé à voir un grand potentiel pour avancer l'état de technologie de commerce électronique, en développant leurs propres environnements de communications libres sur Internet. Ceci a finalement mené à l'idée de créer une technologie distribuée, basée sur le WEB, qui pourrait accroître le concept d'environnement standard de communications, pour faire face à l'énorme disparité qui existe entre et dans les organisations. Ce concept s'est appelé les services web. [11] Il n'était pas longtemps que les organisations ont commencé à se rendre compte qu'au lieu d'adapter juste des applications distribuées existantes, les services Web pourraient devenir la base d'une plate-forme architecturale séparée qui pourrait accroître les avantages de l'ensemble de technologies de services web pour réaliser le concept des services dans l'entreprise. Ainsi, l'architecture orientée services (SOA) est entrée au courant principal d'it. Un premier modèle de SOA, principalement inspiré par l'ensemble initial des standards de services Web, a défini SOA comme une architecture modelée 31

autour de trois composants de base : demandeur de service, fournisseur de service, et enregistrement de service (voir la figure suivante). [11] Figure I.10: composants de base d une SOA I.5.2 Principes De SOA Puisque le terme «Orienté Service» a existé depuis longtemps, il a été utilisé dans divers contextes et pour différents buts. Une constante pour son existence c est qu'il représente une approche distincte pour séparer les soucis. Ceci signifie que la logique exigée pour résoudre un grand problème peut être mieux construite, effectuée, et gérée si le problème est décomposé en collection de plus petites parties. Chacun de ces parties adresse un souci ou une partie spécifique du problème. Dans les points ci-après nous parcourons les principes de base de SOA. [11] I.5.2.1 SOA Et l Orienté Service Une fois couplée avec «Architecture», l Orienté Service prend une implication (connotation) technique. «L'Architecture Orientée Services» est un terme qui représente un modèle dans lequel la logique d'automation est décomposée en des petites unités distinctes. Collectivement, ces unités comportent une plus grande partie de la logique d'automation d'affaires. Individuellement, ces unités peuvent être distribuées. SOA encourage ces différentes unités à exister de façon qu'elles soient autonomes mais pas isolées entre elles. Les unités de logique doivent être conformes à un ensemble de principes qui leur permettent d'évoluer indépendamment, tout en maintenant toujours un niveau suffisant de normalisation et de standardisation. Dans SOA, ces unités de logique sont désignées par «services». 32

I.5.2.2 Encapsulation de la logique d automation Pour maintenir leur indépendance, les services encapsulent la logique d automation dans un contexte distinct. Ce contexte peut être spécifique à une tâche d'affaires, à une entité d'affaires, ou à un autre regroupement. Le souci abordé par un service peut être petit ou grand. Par conséquent, la taille et la portée de la logique représentée par un service peuvent varier. De plus, la logique de service peut englober la logique fournie par d'autres services. Dans ce cas, un ou plusieurs services se composent dans un collectif. Par exemple, les solutions d'automation d'affaires sont typiquement une implémentation d'un processus d'affaires. Ce processus est composé de la logique qui détermine les actions accomplies par la solution. La logique est décomposée en une série d'étapes qui s'exécutent dans un ordre prédéfini selon les règles d'affaires et les conditions d'exécution. Lors de la réalisation d'une solution d'automation consistant en services, chaque service peut encapsuler une tâche effectuée dans une étape individuelle ou un sous-processus comprenant un ensemble d'étapes. Un service peut même encapsuler la logique d'un processus complet. Dans les derniers deux cas, la portée la plus grande représentée par les services peut englober la logique encapsulée par d'autres services. I.5.2.3 Liens entre les services Dans SOA, des services peuvent être utilisés par d'autres services ou d'autres programmes. En tout cas, le lien entre les services est basé sur l assimilation pour que les services agissent l'un sur l'autre, ils doivent se rendre compte les uns des autres. Cette conscience est réalisée par l'utilisation des descriptions de services. La description de service dans son format de base établit le nom du service et les données attendues et renvoyés par le service. La façon dans laquelle les services utilisent les descriptions de service a comme conséquence un lien classifié comme légèrement couplé. Pour que les services agissent les uns sur les autres, ils doivent échanger l'information. Pour cela, un environnement de communications capable de préserver leur rapport légèrement couplé est indispensable pour assurer l échange de messages. I.5.2.4 Communication entre les services Après qu'un service envoie un message, il perd le contrôle de ce qui se passe au message ensuite. C'est pourquoi les messages doivent exister en tant que «unités de communication indépendantes». Ceci signifie que les messages, comme les services, devraient être autonomes. Les services qui fournissent leurs descriptions et 33

communiquent via des messages forment une architecture de base. Jusqu'ici, cette architecture ressemble aux architectures distribuées qui supportent la transmission de messages et la séparation entre l'interface et le traitement de la logique d automation. Ce qui distingue SOA c est comment ses trois principaux composants (services, descriptions, et messages) sont conçus. C'est là où l approche Orienté Service intervient. I.5.2.5 Conception des services Tout comme l Orienté Objet, l Orienté Service est devenue une approche de conception distincte qui présente des principes généralement admis qui régissent le positionnement et la conception des composants architecturaux. L'application des principes orientés service sur la logique de traitement a comme conséquence une logique de traitement orientée service standard. Quand une solution est composée des unités de traitement orientée service, elle devient une solution orientée services. Avec une connaissance des composants que comporte une architecture de base et un ensemble de principes de conception que nous pouvons utiliser pour former et standardiser ces composants, tout ce qui manque c'est une plate-forme d'implémentation qui permettra de rassembler ces derniers pour établir les solutions orientées services. L'ensemble de technologie de services Web offre une telle plate-forme. I.5.2.6 Réalisation des services Le terme «orienté service» et divers modèles abstrait de SOA ont existé avant l'arrivée des services Web. Cependant, la technologie la plus appropriée et réussie en manifestant SOA c'est celle des services Web. La majorité des plates-formes supportent actuellement la création des solutions orientées services, et la plupart des supports de SOA fournis sont basés sur l'utilisation des services Web. I.5.2.7 SOA primitive SOA primitive représente une architecture de technologie de base qui est supportée par la majorité des plates-formes courantes. Toutes les formes de SOA sont basées sur ce modèle primitif. Certaines extensions sont possibles par l'application des techniques de conception avancées, alors que d'autres se fondent sur la disponibilité de spécifications de services web prédéfinis et de support du vendeur correspondant. 34

I.5.3 Caractéristiques De SOA Les grands vendeurs de logiciels conçoivent, d'une façon continue, de nouvelles caractéristiques de services Web et développent des supports plus puissants pour XML et les services Web dans les plates-formes courantes. Le résultat est une variation d'extensions de SOA que nous nous référons en tant que SOA contemporaine. SOA contemporaine se base sur le modèle de SOA primitive et est influencée par les avancements d'industrie et de technologie. Bien que les technologies d'implémentation requises puissent varier, les SOAs contemporaines peuvent être associées par un ensemble de caractéristiques communes qui sont entamées dans les points suivants. [11] I.5.3.1 SOA est basée sur des standards ouverts Peut-être la caractéristique la plus significative des services Web est le fait que l'échange de données est régi par des standards ouverts. Après qu'un message soit envoyé d'un service Web à un autre, il est transmis par l'intermédiaire d'un ensemble de protocoles qui sont globalement standardisés et acceptés. De plus, le message lui-même est standardisé, dans le format et dans la façon dont il représente son contenu. L'utilisation du SOAP, WSDL, XML et Schéma XML permet aux messages d'avoir entièrement un seul bloc et de supporter l'agrément fondamental pour communiquer. Pour cela un service n'exige rien de plus qu'une connaissance des descriptions des autres services. Donc, SOA renforce entièrement les environnements de communications ouverts et limite le rôle de la technologie propriétaire à l'implémentation et l'hébergement de la logique d'application encapsulée par un service. L'opportunité pour la communication interservices est donc toujours une option. I.5.3.2 SOA est structurellement composable La possibilité de composition est une caractéristique de SOA qui peut être réalisé à différents niveaux. Par exemple, en stimulant le développement et l'évolution de services composables, SOA supporte l'automation de processus flexibles et fortement adaptatifs. Les services existent en tant qu'unités indépendantes de la logique. Un processus d'affaires peut donc être décomposé en une série de services, chacun est responsable de l'exécuter une partie du processus. Un exemple plus large est représenté par les environnements de seconde génération de services Web qui évolue hors l'apparition de nombreuses spécifications de WS-*. La nature modulaire de ces spécifications permet à une SOA de se composer seulement de 35

blocs fonctionnels nécessaires. Ce qui fournit cette flexibilité est le fait que les spécifications de seconde génération de services Web sont conçues spécifiquement pour supporter le modèle de transmission de messages SOAP. Pendant que les offres des extensions WS-* supportées par les plates-formes augmentent, la flexibilité de composition permet de continuer la réalisation des solutions qui implémentent seulement les fonctionnalités que vous avez besoin actuellement. En d'autres termes, la plate-forme de WS-* permet la création de SOA, applications, services, et même de messages d'une manière personnalisée et optimisée. I.5.3.3 SOA Augmente la qualité de service (QoS) Il y a un besoin certain d'apporter SOA à un point où elle peut implémenter des fonctionnalités de niveau d'entreprise, d'une manière sure et consistante, comme le font déjà les architectures distribuées les plus établies. Ceci se rapporte aux exigences générales de la qualité de service, à savoir : - La capacité pour que les tâches soient effectuées d'une façon sécurisée, protégeant le contenu d'un message, aussi bien que l'accès aux différents services. - Permettant aux tâches d'être effectuées sûrement de sorte que les messages livraison ou bien les messages d'erreurs de livraison puissent être garantis. - Les exigences de performance pour s'assurer que le temps imposé par le traitement de messages SOAP et de contenu XML n'empêchent pas l'exécution d'une tâche. - Possibilités transactionnelles pour protéger l'intégrité des tâches spécifiques d'affaires, avec une garantie que si une tâche échoue, une logique d'exception est exécutée. - SOA contemporaine essaye de combler les lacunes de QoS du modèle primitif de SOA. Plusieurs concepts et spécifications de WS-* fournissent des dispositifs qui adressent directement les exigences de qualité de service. I.5.3.4 SOA supporte la diversité de vendeurs L'environnement ouvert de communications a non seulement des implications significatives pour résoudre le problème d'hétérogénéité au sein (et entre) les sociétés, mais il permet également aux organisations de choisir le meilleur -parmi plusieurs environnements pour des applications spécifiques. Par exemple, indépendamment de la nature de l'environnement propriétaire de développement, tant qu'il supporte la création de services Web standards, il peut être utilisé pour créer une couche d'interface de service 36

non propriétaire, fournir des opportunités d'interopérabilité avec les autres. Ceci, par ailleurs, a changé le visage des architectures d'intégration, qui peuvent actuellement encapsuler la logique par des adaptateurs de service, et supportent des avancements d'intergiciels basés sur les services Web. Les organisations peuvent certainement continuer la réalisation des solutions avec les outils de développement et les produits de serveur existants. Cependant, le choix pour explorer les offres de nouveaux vendeurs est toujours là. Cette option est rendue possible par la technologie ouverte fournie par les environnements de services Web et est rendue plus possible par la standardisation et les principes introduits par SOA. I.5.3.5 SOA supporte l'interopérabilité intrinsèque Indépendamment qu une application a réellement des exigences immédiates d'intégration, des principes de conception peuvent être appliqués pour doter les services avec des caractéristiques qui favorisent naturellement l'interopérabilité. Lors de la réalisation d'une application SOA, les services, avec l'interopérabilité intrinsèque, deviennent des points finaux potentiels d'intégration. Cette caractéristique peut de manière significative alléger le coût et l'effort pour accomplir de futures exigences d'intégration. I.5.3.6 SOA supporte la découverte Quoique la première génération de standards de services web ait inclus UDDI, il n y a que quelques premières implémentations qui ont utilisé réellement des enregistrements de services en tant qu'élément de leurs environnements. Cependant, une autre raison probable est que le concept de la découverte de service n'a pas été simplement conçu dans l'architecture. Une fois utilisés dans des architectures distribuées traditionnelles, des services web ont été plus souvent utilisés pour faciliter les solutions point-à-point. Par conséquent, la découverte n'était pas un souci général. Après, les SOAs devenaient capable de supporter la publicité et la découverte des services dans toute l'entreprise et au-delà. Une SOA sérieuse compte, en préférence, sur une certaine forme d'enregistrement ou d'annuaire pour contrôler les descriptions de services. 37

I.5.3.7 SOA supporte la fédération L'établissement de SOA au sein d'une entreprise n'exige pas nécessairement que vous remplacez ce que vous avez déjà. Un des aspects les plus attirants de cette architecture est sa capacité d'introduire l'unité à travers les environnements précédemment non-fédérés. Tandis que les services web permettent la fédération, SOA favorise cette cause en établissant et en standardisant la capacité d'encapsuler les logiques d'applications héritées et non héritées, et en l'exposant par l'intermédiaire d'un environnement de communications commun, ouvert et standardisé. Évidemment, l'incorporation de SOA avec les plates-formes précédentes peut mener à une variété de solutions hybrides. Cependant, l'aspect clé est que les voies de communications réalisées par cette forme d'intégration orientée services sont toutes uniformes et normalisées. I.5.3.8 SOA supporte la réutilisabilité inhérente SOA établit un environnement qui favorise la réutilisation à plusieurs niveaux. Par exemple, les services conçus selon des principes orientés service sont encouragés à favoriser la réutilisation, même si aucune exigence immédiate de réutilisation n existe. Des collections de services qui forment les compositions d'un service peuvent être ellesmêmes réutilisées par d autres compositions plus larges. L'accent mis par SOA sur la création des services qui sont agnostiques aux processus d'affaires et aux solutions d'automation qui les utilisent mène à un environnement dans lequel la réutilisation est naturellement réalisée comme avantage supplémentaire pour fournir des services à un projet donné. I.5.3.9 SOA supporte l'extensibilité En exprimant la fonctionnalité encapsulée par une description de service, SOA encourage à penser au delà des exigences de communication point à point. Quand la logique de service est correctement divisée par l'intermédiaire d'un niveau approprié de granularité d'interface, la portée de la fonctionnalité offerte par un service peut être parfois étendue sans diviser l'interface existante. I.5.3.10 SOA supporte la modélisation d'affaires orientée service Dans la description de SOA primitive, nous avons brièvement exploré comment des processus d'affaires peuvent être représentés et exprimés par des services. La division de la logique d'affaires dans des services, qui pourraient être ensuite composés, a des implications significatives quant à la façon dont les processus d'affaires peuvent être 38

modélisés. Les analystes peuvent renforcer ces dispositifs (la division et la composition des services), en incorporant une ampleur de Service-Orientation dans les processus d'affaires pour l implémentation sous SOA. I.5.3.11 SOA implémente des couches d'abstraction Une des caractéristiques qui tend à évoluer naturellement sous l'application des principes de conception orientés services est celle de l'abstraction. Une SOA typique peut présenter des couches d'abstraction en plaçant des services comme points d'accès uniques à une variété de ressources et de logiques de traitement. Une fois appliquée sous une conception appropriée, l'abstraction peut être visée au niveau de la logique d'affaires et d'application. Par exemple, en établissant une couche de points finaux qui représentent les solutions et les plates-formes de technologie entières, tous les détails propriétaires liés à ces environnements disparaissent. Le seul souci restant est la fonctionnalité offerte par l'intermédiaire des interfaces de service. I.5.3.12 SOA favorise le couplage faible dans toute l'entreprise Le grand avantage de réaliser une architecture technique avec des services légèrement couplés est l'indépendance obtenue de la logique de services. Les services exigent seulement une connaissance entre eux, leur permettant d'évoluer indépendamment. Dans une organisation où les principes de Service-Orientation sont appliqués à la modélisation d'affaires et à la conception technique, le concept de l'accouplement faible est amplifié. En implémentant des couches d'abstraction de service standardisées, une relation de couplage faible peut également être réalisée entre les affaires et les domaines de technologie d'application d'une entreprise (le schéma 3.15). Chaque extrémité exige seulement une conscience de l'autre, donc permettant à chaque domaine d'évoluer plus indépendamment. Le résultat est un environnement qui peut mieux adapter aux affaires et au changement de technologies connexes une qualité connue sous le nom d'agilité organisationnelle. I.5.3.13 SOA favorise l'agilité organisationnelle Que ce soit le résultat d'une réorganisation interne, d'une fusion de corporation, d'un changement de la portée des affaires d'une organisation, ou du remplacement d'une plateforme de technologie, la capacité d'une organisation de s'adapter au changement détermine l'efficacité avec laquelle elle peut répondre aux événements non planifiés. 39

Le changement de la logique des affaires d'une organisation peut affecter la technologie d'application qui l'automatise. Le changement de l'infrastructure de technologie d'application d'une organisation peut affecter la logique d'affaires automatisée par cette technologie. Plus sont les dépendances qui existent entre ces deux parties d'une entreprise, plus est le point auquel le changement impose la rupture et les dépenses. D'autres avantages réalisés par la standardisation de SOA contribuent également à minimiser les dépendances et à augmenter globalement la réaction au changement: notamment, l'interopérabilité intrinsèque entre les plates-formes hétérogènes. I.5.4 SOA Et Les Architectures Précédentes Maintenant, nous retournons en arrière dans notre historique pour jeter un coup d'œil sur la différence entre SOA et les plates-formes architecturales précédentes (voir l annexe : historique sur les architectures d applications). Cette étude est intéressante, dans la mesure où elle nous permet d'identifier comment SOA a dérivé plusieurs de ses caractéristiques courantes. Pour cela, nous effectuerons des comparaisons entre l'architecture SOA et d autres architectures (architecture client-serveur, architecture distribuée d'internet) selon les caractéristiques suivantes : logique d application, traitement d application, technologie, sécurité et administration. Ainsi, nous parlerons de la différence et la relation entre SOA et l architecture de service web hybride. [11] I.5.4.1 SOA vs. l architecture client-serveur N'importe quel environnement dans lequel un logiciel demande ou reçoit l'information d'un autre peut être désigné comme «client-serveur». Chaque variation d'architecture d'application (y compris SOA) comprend un élément d'interaction client-serveur. Cependant, le terme «architecture client-serveur» se rapporte généralement à une génération particulière des premiers environnements dans lesquels le client et le serveur ont joué des rôles spécifiques et ont eu des caractéristiques d'implémentation distinctes (Voir l annexe : Historique sur les architectures des applications). a-logique d application Les environnements client-serveur placent la majorité de la logique d'application dans le logiciel du client. Ceci a comme conséquence un exécutable monolithique qui commande l'expérience d'utilisateur, aussi bien que les ressources principales. Une exception est la distribution des règles de gestion. Une tendance populaire était d'inclure et maintenir des règles de gestion concernant les données dans des procédures et des 40

déclenchements stockés avec la base de données. Ceci a légèrement simplifié la programmation de l'accès aux données. Généralement, c est le client qui exécute la présentation. La couche de présentation dans les solutions orientées services peut varier. N'importe quel logiciel capable d'échanger des messages SOAP selon des contrats de service peut être classifié en tant que demandeur de service. Tandis qu'on s'attend généralement à ce que des demandeurs soient des services, les conceptions de la couche de présentation sont complètement ouvertes et spécifique aux exigences d'une solution. Dans l environnement de serveur, des options existent à savoir là où la logique d'application peut résider et la façon dont elle peut être distribuée. Ces options n'excluent pas le recours aux déclencheurs de base de données ou aux procédures stockées. Cependant, les principes de conception orientés services entrent dans le jeu, dictant souvent la division de la logique de traitement en unités autonomes. Ceci facilite les qualités spécifiques de conception, telles que l'apatridie de service et l'interopérabilité, aussi bien que la future composition et la réutilisabilité. En plus, il est plus ordinaire dans une SOA pour ces unités de logique de traitement pour être une solution-agnostique. Ceci soutient l'objectif ultime de favoriser la réutilisation et l'accouplement faible à travers les frontières d'application. b-traitement d'application Puisque la plupart de la logique d'application client-serveur réside dans le composant client, le poste de travail client est responsable de la grande partie du traitement. Le rapport de 80/20 souvent est employé en général. Ainsi, un serveur de base de données effectuant typiquement vingt pour cent du travail. Malgré cela, c'est la base de données qui devient fréquemment le goulot de performance dans ces environnements. Une solution client-serveur à deux tiers avec une grande base d'utilisateurs exige généralement que chaque client établit son propre connexion à la base de données. La communication est synchrone, et ces connexions sont souvent persistantes (c.-à-d qu'elles sont créées à l'ouverture des sessions d'utilisateurs et restent actives jusqu'à ce que les utilisateurs quittent l'application). Les connexions aux bases de données sont chères, et les demandes de ressource accablent parfois des serveurs de base de données, imposant une latence de traitement à tous les utilisateurs. En plus, étant donné que les clients sont assignés par la majorité de ces responsabilités de traitement, ils exigent trop souvent des 41

ressources importantes. Ainsi, les exécutables coté client consomment une partie régulier de mémoire de PC. Donc, les postes de travail d'utilisateur sont souvent exigés pour lancer exclusivement des programmes clients de sorte que toutes les ressources disponibles puissent être offertes à l'application. Le traitement dans SOA est fortement distribué. Chaque service a une frontière fonctionnelle explicite et des exigences de ressources relatives. En modelant une architecture orientée services technique, vous avez beaucoup de choix quant à la façon dont vous pouvez placer et déployer des services. Les solutions d'entreprise se composent de plusieurs serveurs, chacun héberge des ensembles de services web et de logiciels. Il n'y a, donc, aucun rapport de traitement fixe pour SOAs. Les services peuvent être distribués selon les besoins, et les demandes de performance sont l'un de plusieurs facteurs pour déterminer la configuration physique de déploiement. La communication entre le service et le demandeur peut être synchrone ou asynchrone. Cette flexibilité permet au traitement d'être encore rationalisée, particulièrement quand des modèles asynchrones de message sont utilisés. En plus, en plaçant de plus d'intelligence dans les messages, des options pour réaliser la gestion de contexte au niveau de message sont fournies. Ceci favorise la nature apatride et autonome des services et allège de plus le traitement en réduisant le besoin de mise en mémoire cache d'information d'état. c-technologie L'apparition des applications client-serveur a favorisé l'utilisation des langages de programmation de 4ème génération, tels que Visual Basic et PowerBuilder. Ces environnements de développement ont profité des avantages du système d'exploitation Windows, en fournissant la capacité de créer esthétiquement des interfaces d'utilisateurs riches et plus interactives. Les langages de troisième génération traditionnelles, telles que C++, étaient également encore employés, particulièrement pour les solutions qui ont eu des exigences de performance plus rigides. Les vendeurs principaux de base de données ont fournit des SGBDRs robustes qui pourrait contrôler plusieurs connexions, tout en offrant un stockage de données flexible et des dispositifs de gestion de données. L'ensemble de technologies utilisées par SOA n'a pas été changé réellement autant qu'il a été augmenté. Des nouvelles versions de langages de programmation plus anciens, tels que Visual Basic, peuvent encore être utilisées pour créer des services web, et l'utilisation des bases de données relationnelles est toujours ordinaire. Le paysage de technologie SOA, est devenu de plus en plus divers. En plus de l'ensemble de 42

technologies web standards (HTML, CSS, HTTP, etc.), SOA contemporaine apporte la condition absolue pour établir une architecture de représentation de données XML, avec les environnements de transmission de messages SOAP et les plateformes de services web qui sont en expansion. d-sécurité Outre le stockage et la gestion des données et les règles de gestion incluses dans des procédures et des déclencheurs stockées, l'autre partie de l'architecture client-serveur qui est fréquemment centralisée au niveau de serveur est la sécurité. Les bases de données sont suffisamment sophistiquées pour gérer des comptes et des groupes d'utilisateurs et pour assigner ces derniers aux différentes parties du modèle de données physiques. La sécurité peut être également contrôlée avec l'exécutable du client, particulièrement quand elle se rapporte aux règles de gestion spécifiques qui dictent l'exécution de la logique d'application (telle que la limitation d'accès à une partie d'une interface utilisateur). En plus, le niveau de sécurité du système d'exploitation peut être incorporé pour réaliser un accès simple, quand l'autorisation d accès à l'application est dérivée des informations de la session d'ouverture du système d'exploitation. Bien qu'on puisse se vanter au sujet des avantages de SOA, la plupart des architectes envient la simplicité du degré de sécurité client-serveur. Les données sont protégées par l'intermédiaire d'un seul point d'authentification établissant une seule connexion entre le client et le serveur. Dans le monde distribué de SOA, ce n'est pas possible. La sécurité devient une complexité significative directement apparentée au degré de mesures de sécurité exigées. De multiples technologies sont typiquement impliquées, dont beaucoup comporte le support WS-Sécurité. e-administration Une des raisons principales pour lesquelles l'ère du client-serveur s'est terminée était les coûts de maintenance, de plus en plus grands, liés à la distribution et à la maintenance de la logique d'application au niveau des postes de travail d'utilisateurs. Puisque chaque client a hébergé le code d'application, chaque mise à jour de l'application a exigé une redistribution du logiciel client à tous les postes de travail. Dans les plus larges environnements, ceci a eu comme conséquence une procédure d'administration fortement onéreuse. Les issues de maintenance ont couvert les extrémités de client et de serveur. Les postes de travail clients étaient sujets à des problèmes spécifiques à l'environnement, 43

parce qu ils pourraient avoir plusieurs logiciels installés et fournis par différents fournisseurs de matériel. Puisque les solutions orientées services peuvent avoir une variété de demandeurs, elles ne sont pas nécessairement immunisées contre les défis de maintenance coté client. Tandis que leur nature distribuée prend en compte l'évolutivité pour les serveurs d'application et les bases de données, de nouvelles exigences d'administration peuvent être introduites. Par exemple, une fois que SOAs évoluent à un état où les services sont réutilisés et deviennent une partie de plusieurs compositions de services, la gestion des ressources de serveurs et des interfaces de services peut exiger des outils d'administration puissants, y compris l'utilisation d'un enregistrement privé. I.5.4.2 SOA vs. l architecture distribuée d'internet Cette comparaison peut sembler comme une contradiction, parce que SOA peut être vue comme une forme d'architecture distribuée d'internet et puisque nous avons établi, plus tôt, que les types précédents d'architecture distribuée pourraient également être conçus comme des SOAs. Bien que possible, et bien qu'il y ait des environnements distribués en existence qui ont pu être fortement influencé par les principes orientés services, cette variation de SOA est toujours rare. Considérer la comparaison fournie ici en tant qu'une qui contraste l'architecture distribuée traditionnelle d'internet de la façon qu'elle a été généralement conçue (voir l annexe: (Voir l annexe : Historique sur les architectures des applications). a-logique d application Sauf quelques applications rares qui incluent des extensions en navigateurs, les applications réparties d'internet placent toute leur logique d'application du côté de serveur. Même les scripts coté client prévus pour s'exécuter en réponse aux événements sur une page Web sont téléchargés à partir du serveur web au moment de la requête HTTP initiale. Sans aucune logique existant sur le poste de travail client, la solution entière est centralisée. L'importance est donc focalisée sur : - Le partitionnement de la logique d'application, - L hébergement des unités de la logique de traitement partitionnées, - Les interactions entre les unités de la logique de traitement. D'une perspective physique, SOA est très semblable à l'architecture distribuée d'internet. La logique de fournisseur réside sur l'extrémité de serveur où elle est 44

décomposée en unités séparées. Les différences se situent dans les principes utilisés pour déterminer les trois considérations primaires de conception déjà énumérées. Les applications distribuées traditionnelles consistent en une série de composants qui résident sur un ou plusieurs serveurs d'application. Les composants sont conçus avec des divers niveaux de granularité fonctionnelle, selon les tâches qu'ils exécutent, et selon leur degré de réutilisabilité par d'autres tâches ou applications. Les composants hébergés sur le même serveur communiquent par l'intermédiaire des API, selon des interfaces publiques qu'ils présentent. Les protocoles RPC sont utilisés pour accomplir la même communication à travers les frontières de serveurs. Ceci est rendu possible par l'utilisation de Proxys locaux qui représentent des composants dans des sites éloignés. Au moment de conception, les composants d'interaction prévus sont pris en compte de telle sorte que les références actuelles aux autres composants physiques puissent être incluses dans le code de programmation. Cela implique une forme d accouplement étroit entre les composants. Il est efficace qu'un peu de traitement soit gaspillé pour essayer de localiser un composant requis au moment d'exécution. Cependant, l'accouplement inclus mène à un réseau de composants étroitement liés qui sont, une fois mis en application, difficiles à être modifiés. SOAs contemporaines utilisent et se basent toujours sur des composants. Cependant, l'approche de modélisation entière prend en compte la création des services qui encapsulent ces composants. Ces services sont conçus selon des principes orientés service et sont stratégiquement placés pour exposer des ensembles spécifiques de fonctionnalités. Tandis que ces fonctionnalités peuvent être fournies par des composants, elles peuvent également provenir des systèmes existants et d'autres sources, telles que des connecteurs aux packages de logiciels, ou même aux bases de données. Le but d'envelopper une fonctionnalité dans un service est d'exposer cette fonctionnalité via une interface ouverte et standard indépendamment de la technologie utilisée pour implémenter la logique sous-jacent. L'interface standard supporte l'environnement de communications ouvert qui se repose dans le noyau de SOA. De plus, l'utilisation de services Web établit un environnement légèrement couplé qui fonctionne contrairement aux plusieurs conceptions traditionnelles d'applications réparties. Une fois correctement conçus, les services légèrement couplés supportent un modèle de composition, permettant aux différents services de participer aux assemblées globales. Ceci présente des opportunités persistantes pour la réutilisation et l'extensibilité. 45

Un autre décalage significatif lié à la conception et au comportement de la logique d'application répartie est dans la façon dont les services échangent l'information. Tandis que les composants traditionnels fournissent des méthodes qui, une fois invoquées, envoient et reçoivent des paramètres, les services Web communiquent avec des messages SOAP. Quoique SOAP supporte des structures de message style-rpc, la majorité de conceptions orientées services comptent sur des messages style-document. Également les messages sont structurés pour être aussi autosuffisants que possible. En utilisant des en-têtes SOAP, le contenu de message peut être accompagné d une gamme importante de méta informations, d'instructions de traitement et de règles de sécurité. Par rapport à l'échange de données dans le monde de composant pur, l'environnement de transmission de messages utilisé par SOA est plus sophistiqué et tend à avoir comme conséquence de moins de transmissions individuelles. En conclusion, bien que la réutilisation soit généralement soulignée dans des approches de conception distribuées traditionnelles, SOA supporte l'interopérabilité et la réutilisation inter-application à un niveau profond, en favorisant la création de services pour des solutions agnostiques. b-traitement d application L'architecture distribuée d'internet favorise l'utilisation des protocoles de communication propriétaire, tels que DCOM et des implémentations de CORBA pour l'échange de données à distance. Tandis que ces technologies historiquement ont eu des défis, elles sont considérées relativement efficaces et fiables, particulièrement une fois qu'une connexion active est établie. Elles peuvent supporter la création des composants qui interagissent principalement avec des échanges de données synchrones (la communication asynchrone est supportée par quelques plates-formes mais n'est pas utilisé généralement). SOA, d'un autre coté, se fonde sur la communication à base de message. Ceci implique la sérialisation, la transmission, et la dé-sérialisation des messages SOAP contenant des charges utiles de document XML. Les étapes de traitement peuvent impliquer la conversion des données relationnelles dans une structure conforme à XML, la validation du document XML, la transmission et l'analyse du document et l'extraction des données par le destinataire. Bien que des avancements, tels que l'utilisation des parseurs d'entreprise et des accélérateurs de matériel, soient continus, la communication RPC reste sensiblement plus rapide que SOAP. Puisqu'un réseau de serveurs SOAP peut 46

effectivement remplacer des canaux de transmission RPC dans les environnements d'application orientés services, le coût de traitement encourus devient une issue de conception significative. Les conventions de modélisation de documents et de messages et le placement stratégique de la logique de validation sont des facteurs importants qui forment la couche de transport de SOA. c-technologie La technologie derrière l'architecture distribuée d'internet est passée par un certain nombre d'étapes au cours de ces dernières années. Les architectures initiales incluent des composants, des scripts coté serveur, et des technologies web, telles que HTML et HTTP. Les améliorations d'intergiciels ont permis d'augmenter la capacité de traitement et le contrôle de transaction. L'apparition de XML a introduit une représentation de données sophistiquée qui a donné réellement la substance au contenu transmis par l'intermédiaire des protocoles d'internet. La génération suivante des services web a permis aux applications distribuées d'internet de traverser les frontières des plates-formes propriétaires. Puisque beaucoup d'applications distribuées courantes utilise XML et les services web, il peut y avoir peu de différence entre la technologie derrière ces solutions et celle derrière les applications basées sur SOA. Une distinction claire est qu'un SOA contemporaine sera très probablement construit sur la représentation de données XML et une plate-forme de technologie de services web. Au delà d'un ensemble de noyaux de technologies d'internet et de l'utilisation des composants, il n'y a aucune obligation concernant la technologie utilisée par des applications traditionnelles d'internet. Ainsi XML et les services web sont facultatifs pour l'architecture distribuée d'internet mais ce n est pas le cas pour SOA contemporaine. d-sécurité Quand la logique d'application est répandue à travers des frontières physiques multiples, l'implémentation des mesures de sécurité fondamentales telles que l'authentification et l'autorisation devient plus difficile. Dans un environnement client-serveur à deux tiers, une connexion coté serveur facilite l'identification des utilisateurs et le transport des données. Cependant, quand l'exclusivité de cette connexion est enlevée, et quand les données ont besoin d'être transportées à travers différentes couches physiques, les nouvelles approches de sécurité 47

sont nécessaires. Pour assurer le transport sûr d'information et l'identification des qualifications d'utilisateur, tout en préservant le contexte original de sécurité, les architectures de sécurité traditionnelles incorporent des approches telles que la délégation et l'imitation. Le cryptage est également ajouté au protocole ouvert HTTP pour permettre aux données d'être protégé pendant la transmission au delà du serveur web. SOAs s'écartent de ce modèle en introduisant des changements en gros à la façon dont la sécurité est incorporée et appliquée. Comptant fortement sur les extensions et les concepts établis par l'environnement WS-Sécurité, les modèles de sécurité utilisés dans SOA soulignent le placement de la logique de sécurité au niveau de transmission de messages. Les messages SOAP fournissent des blocs d'en-tête dans lesquels la logique de sécurité peut être stockée. De cette façon, n'importe où le message disparaît, il y a ainsi son information de sécurité. Cette approche est exigée pour préserver l'autonomie individuelle et le couplage faible entre les services, aussi bien que le point auxquels un service peut rester entièrement apatride. e-administration La maintenance des applications à base de composants implique de garder la trace des instances individuelles de composant, tracer les problèmes de communication locale et à distance, surveiller les demandes de ressource de serveur, et, naturellement, les tâches standards d'administration de base de données. L'architecture distribuée d'internet introduit aussi le server web et avec lui un environnement physique additionnel qui exige l'attention tandis que les applications sont en fonction. Puisque les clients, soit locaux ou externes à une organisation, se connectent à ces solutions en utilisant HTTP, le server web devient le premier point officiel de contact. Il doit donc être conçu pour l exigence d extensibilité qu'ait menée à la création des fermes de serveurs web qui mettent des ressources en commun. Les SOAs de niveau d'entreprise exigent typiquement une administration d'exécution additionnelle. Les problèmes avec des environnements de transmission de messages (particulièrement en travaillant avec les modèles d'échange asynchrones) ne peuvent pas être facilement détectés comme dans le cas des échanges de données à base de RPC. C'est parce que tant de variations existent quant à la façon dont des messages peuvent être échangés. La communication RPC exige généralement une réponse du composant initial, indiquant le succès ou l'échec. En rencontrant un état d'échec, une routine de traitement d'exception s'exécute. La manipulation d'exception avec des environnements 48

de transmission de messages peut être plus complexe et moins robuste. Bien que des extensions WS-* soient placés pour améliorer le traitement de ces situations, l'effort d'administration est encore prévu de rester élevé. D'autres tâches de maintenance telles que la gestion des ressources (semblable à la gestion de composant), sont également exigées. Cependant, pour mieux supporter la réutilisation et la composition, une partie utile d'une infrastructure d'administration pour des entreprises établissant de grands nombres de services web est l'enregistrement privé. UDDI est l'une des technologies utilisées pour standardiser ce dépôt d'interface, qui peut être accédé manuellement ou par programmation pour découvrir les descriptions de services. I.5.4.3 SOA vs l'architecture hybride de services web Tandis que les SOAs peuvent varier en taille et en qualité, il y a des caractéristiques tangibles qui distinguent un SOA d'autres architectures qui utilisent les services web. Pour l'instant, Il suffit de déclarer que fondamentalement, les SOAs sont construits avec un ensemble de services Web conçus pour automatiser collectivement (ou participer à l'automation de) un ou plusieurs processus d'affaires et que SOA supporte l'organisation de ces services dans des couches d abstraction des parties spécifiques de la logique d'automation d'entreprise. Au lieu de refléter les interfaces de composants et d'établir des connexions point à point avec des services web, SOA fournit un support important pour une variété de modèles de transmission de messages (basés sur des échanges synchrones et asynchrones). En plus, les services web dans SOAs sont sujets à des exigences de conception spécifiques, comme ceux fournis par les principes orientés service. Ceux-ci et d'autres caractéristiques supportent la poursuite d'un couplage faible consistant. Une fois achevé, un service unique n'est jamais limité à la communication point à point ; il peut s'adapter à n'importe quel nombre de demandeurs actuels et futurs. I.5.5 Conclusion En optant pour SOA dans une entreprise, une interopérabilité naturelle émerge et dépasse les plates-formes d'application. Ceci permet pour des environnements hétérogènes d'être composés dans un support de processus d'automation évolutifs. Outre SOA, il y a d autres technologies d intégration importantes qui ont connu un grand succès, à savoir les Mashups. Cette technologie sera abordée dans la section suivante. 49

I.6 INTEGRATION WEB AVEC LES MASHUPS I.6.1 Introduction aux mashups À l origine, le Web était composé de pages HTML statiques qui devaient être mises à jour manuellement par un webmestre. L apparition des systèmes de gestion de contenu permettant la création de pages dynamiques à partir de bases de données aura permis une première évolution vers ce qui est parfois appelé le Web 1.5, mais malgré ces améliorations, le Web était toujours un simple outil de diffusion de données et d information. [14] Depuis quelques années, le concept de Web 2.0 a fait son apparition. Ce concept fait référence à une seconde génération du Web où celui ci est passé de l état d outil de diffusion à celui de plateforme collaborative, les outils collaboratifs tels les réseaux sociaux ou les wikis facilitant la collaboration et le partage entre les internautes. De plus en plus, l'utilisation du Web s'oriente vers l'interaction entre les utilisateurs, la création de réseaux sociaux et le crowdsourcing qui consiste à utiliser la créativité, l'intelligence et le savoirfaire d'un grand nombre d'internautes. [14] Le mouvement du Web 2.0 est une raison importante du succès des mashups. Les mashups ont été identifiés explicitement (sous les expressions «remixable data source» et «the right to remix») par Tim O' Reilly dans «What is Web 2.0?». [15] Dans les sections suivantes, nous parlons des mashups dans le Web 2.0, explorant les principaux aspects de cette technologie. I.6.2 Généralités Sur Les Mashups I.6.2.1 Définitions des mashups a-définition 1 : Une application composite (ou mashups ou encore mash-up) est une application qui combine du contenu ou du service provenant de plusieurs applications plus ou moins hétérogènes. On parle de mashups dans le cadre d'une superposition de deux images provenant de sources différentes, superposition de données visuelles et sonores différentes par exemple dans le but de créer une expérience nouvelle. Dans le cas de site Web, le principe d'un mashups est donc d'agréger du contenu provenant d'autres sites, afin de créer un site nouveau. [16] b-définition 2 : Il y a plusieurs interprétations sur ce que sont les mashups et ce que signifient-ils pour le Web, pour l'innovation, et pour créer des propositions de valeur pour 50

l'utilisateur. De façon générale, un mashups est une application qui consomme des données de différentes sources et les combine dans une seule expérience d'utilisateur. Ceci peut être afin d'ajouter une valeur à des données préexistantes ou d avoir plus d'amusement et de créativité. [18] c-définition 3 : Afin de fournir une définition plus précise et plus complète de ce terme, nous avons extrait les termes les plus appropriées incluses dans plusieurs définitions trouvées dans l'internet. Ces termes incluent: page Web ou application, intégration, combinaison, réutilisation, sources de données, API, tiers de données, Web 2.0 et informatique. En tenant compte de ces termes, un mashups peut être défini comme une application basée sur le WEB qui est créée en combinant et en traitant un tiers de ressources en ligne. Ce tiers contribue avec des données, des présentations ou des fonctionnalités. [22] I.6.2.2 Facteurs de croissance des mashups Comment, en juste quelques années courtes, les mashups soudainement ont-ils pris naissance partout? L'histoire mène juste depuis quelques années. Après le problème financier de l'industrie de technologie en 2001, les firmes d'internet sont regroupées et se sont redéfinies. Il y avait des leçons d'affaires à apprendre, des technologies à réévaluer, et les perceptions des personnes avaient changé. [17] - Par le milieu de la décennie, beaucoup de tendances et de différences sont devenues claires. Le terme le «Web 2.0» a commencé à apparaître, de dessiner la séparation entre les nouveaux sites et les sites qui ont gagné la popularité vers la fin des années 90. Le terme était vague et semblait soupçonneusement de réclame au début. Cependant, les différences entre l'ancien et le nouveau web étaient vraies. Elles n'étaient pas simplement historiques et chronologiques. Des sites comme Google, YouTube, et Flickr ont démontré de nouvelles approches à établir des affaires de web (web business). Ces sites ayant souvent des interfaces simples, ont entièrement embrassé des services Web, et ont renvoyé beaucoup de contrôle aux utilisateurs. Plusieurs de ces sites ont compté seulement sur leurs utilisateurs pour le contenu. En septembre 2005, l'éditeur de technologie Tim O'Reilly a écrit un article intitulé «What is Web 2.0» pour déclarer brièvement les traits du Web 2.0 vis à vis les sites web 1.0. Il y avait deux caractéristiques qui étaient les catalyseurs directs 51

pour la croissance des mashups: l importance des données et les Communautés d'utilisateurs. [17] a- Importance des données : Le premier facteur est l'importance des données. La question de qui est le propriétaire des données et de quoi faire avec ces données est devenue une grande issue. En plus, pourquoi les compagnies investiraient des millions de dollars pour recueillir leurs données et leurs systèmes de base de données, mais d'autre part elles les donnent gratuitement aux autres pour l'utilisation? La réponse est la suivante: en ouvrant leurs systèmes, les développeurs de mashups aident à augmenter la portée des propriétaires de données. [17] O'Reilly a employé l'exemple de MapQuest pour illustrer ceci. MapQuest était le leader dans la cartographie dans la seconde moitié des années '90. Cependant, son système était fermé et n'a permis aux parties extérieures de faire rien avec ses données. Dernièrement, les sites de cartographie ont commencé de prendre en considération cette faiblesse. Yahoo! Maps, Virtual earth de Microsoft, et Google Maps sont rentrés dans le marché, et chacune a eu ses propres APIs. Malgré son avantage énorme dans le marché, MapQuest a rapidement perdu ça place au profil de plusieurs sites de cartographie ouverts. [17] Ainsi, Amazone a ouvert ses données par le service de commerce électronique d'amazone (ECS). Beaucoup de mashups ont employé ce service Web pour créer leurs propres applications. Amazone obtient les ventes et donne un pourcentage aux réalisateurs de mashups. Ceci a créé beaucoup plus de canaux pour qu'amazone vende ses marchandises en dehors de «www.amazon.com». On peut contraster ceci avec le site «BarnesAndNoble.com» qui n'ouvre pas ses données. Le seul canal de ses ventes est le site Web principal. Non seulement il a perdu des opportunités commerciales, mais il a manqué de la fidélité que seule d'amazone. [17] b- Communautés d utilisateurs Le deuxième facteur est que les données ajoutées par les utilisateurs sont plus valables que nous avons pensé à priori. La question importante est comment les sites web exploitent ces informations et qui possède ces données. Par exemple, le site de location de films "Netflix" a toujours permis aux utilisateurs d'évaluer des films qu'ils ont observés. Basé sur ces recommandations, "Netflix" suggérera d'autres films que vous pourriez 52

aimer. Récemment, ils ont ajouté un nouveau dispositif de gestion de réseau social appelé «Friends», où vous pouvez voir comment vos amis ont évalué des films et ce qu'ils observent. Ce dispositif «Friends» est basé sur des estimations de compatibilité entre les utilisateurs. Comparant les recommandations de deux utilisateurs, «Netflix» est soulevé avec un pourcentage de leurs goûts partagés de films. [17] D'autres sites dépendent complètement des données ajoutées par les utilisateurs. YouTube et Flickr fournissent respectivement, l'hébergement gratuit des vidéos et des images. Leur adoption répandue n'est pas simplement due à l hébergement de données. Avant Flickr, il y avait beaucoup de sites qui ont hébergé des images gratuitement. La différence, encore, est ce que les deux sites font avec ces données. Les deux sites fournissent des dispositifs de gestion de réseau sociaux. Vous pouvez laisser vos estimations et vos commentaires sur un item hébergé et vous pouvez les souscrire au profil d'une autre personne. Lorsque cette personne télécharge quelque chose, vous serez avisé du nouveau contenu. Les deux sites permettent également l'étiquetage folksonomic, qui laisse fondamentalement des utilisateurs décrire le contenu avec leurs propres motsclés. Les visiteurs peuvent employer ces mots-clés pour la recherche du contenu. [17] c- Les développements récents du web : Les développements récents ont permis aux utilisateurs de recombiner le contenu numérique et des services : [15] - Disponibilité croissante des sources de données XML dans les applications d'affaires, personnel et de consommateurs, - Large déploiement des services Web XML, - Intérêt répandu pour le mixage de données ou les mashups, - La disponibilité d Ajax, des widgets (basées sur Javascript) et des micros applications, - Évolution des navigateurs Web pour permettre une plus grande extensibilité, - Croissance explosive de contenu généré par les utilisateurs et d'innovation menée par les utilisateurs, - Une conceptualisation plus large de l'internet comme plate-forme («Web 2.0») - Croissance de l'accès à bande large. 53

Dans le point suivant, nous donnons quelques exemples des applications des mashups qui sont accessibles sur internet. I.6.2.3 Exemples sur les mashups Mashups ont été embrassés par beaucoup de compagnies d'internet, y compris Google, Yahoo, et Amazone, qui ont toutes fourni de diverses méthodes aux développeurs pour réaliser les fonctionnalités de leurs applications web. Dans les exemples suivants, on montre quelques sites originaux et innovateurs des mashups qui sonta- accessibles sur le Web. [18] a- Picnik :http://www.picnik.com/: Après la tendance de fournir des applications de bureau traditionnelles en ligne, le site Picnik (qui est une application basée sur Flash) permet d'éditer des photos et d'effectuer des tâches de traitement d'images simples toutes du confort de votre navigateur web. Récemment, cette fonctionnalité a été ajoutée à Flickr, en permettant de choisir une photo, cliquer sur le bouton d'édition de photo, et éditer la photo directement dans l'interface de Picnik. Picnik montre comment une application WEB peut être intégrée avec des sources de données sous forme d'un mashups. b- Chicago Crime: http://www.chicagocrime.org/: Le site «Chicago Crime» permet de trouver l'itinéraire le plus sûr vers la maison après une session de fin de nuit à Chicago. Ce mashups classique utilise des données de crimes du Département de Police de Chicago et intègre ces données dans une carte de Google Map. Les utilisateurs peuvent choisir de regarder un endroit géographique ou filtrer les résultats par type de crime. c- Flash Earth : http://www.flashearth.com/: Flash Earth est un exemple intéressant. Plutôt que de combiner de différents types de données, il permet à l'utilisateur de choisir entre différentes sources de mêmes données. Dans ce cas, l'application peut rechercher des données dans des collections étendues de cartes et de photos aériennes à Google, à Yahoo, à Microsoft, à Ask.com, et à NASA (voir la figure suivante). 54

Figure I.11: Possibilité de choisir entre différentes sources de mêmes données. d- Adactio Elsewhere : http://elsewhere.adactio.com/: Adactio Elsewhere est un aggrégateur de données qui recherche les données des activités en ligne d une personne de Flickr, Amazone, Del.icio.us. Toutes ces données sont extraies des Feeds RSS (Figure I.12) ou des APIs d'applications et présentées dans une interface utilisateurs Ajax. Figure I.12: Agrégation de données concernant les activités d une personne en ligne. I.6.3 Classification Des Mashups Les mashups peuvent être classifiés à base des quatre questions suivantes : [22] Quoi?, Où?, Comment? et Pour qui?. 55

I.6.3.1 Classification a base de la question «quoi?» Selon le type des éléments qui sont combinés ou intégrés, les mashups sont assignés à une des trois catégories suivantes : présentation, données ou fonctionnalité d'application. Mashups de présentation : Un mashups de présentation se concentre sur la recherche d'information et la disposition de différentes sources de Web sans considérer les données importantes et la fonctionnalité fondamentale de l'application. Pour ce type de mashups préconstruit, les widgets (gadgets) sont simplement des drags&drops dans une interface d utilisateur commune. Habituellement, la création d'un mashups de présentation exige peu ou pas de connaissances des langages de programmation. Mashups de donnée : Un mashups de données fusionne des données fournies par différentes sources (par exemple, services de Web ou page HTML) dans une page web. Cela permet à l'utilisateur de mélanger des données provenant de plusieurs sources et de personnaliser ce flux de données dans une page Web. Mashups de fonctionnalité : Un mashups de fonctionnalité combine des données et des fonctionnalités d'applications fournies par différentes sources, en obtenant un nouveau service. Les fonctionnalités sont accessibles par l'intermédiaire des APIs. En se basant sur le type des éléments combinés, on peut trouver d autres classifications des mashups telles que : - Mashup de cartographie : combinaison d'informations dans des cartes, par exemple, cartes de Google), - Mashups de Photo/Video : combinaison d'informations dans le photo/dossiers visuels par exemple, du flickr), - Mashups de Recherche/Achats : intégration des mécanismes pour la comparaison des prix de produits dans des pages Web, - Mashups de Nouvelles : intégration des nouvelles dans les pages Web personnelles. I.6.3.2 Classification a base de la question «ou?» Selon l'endroit où ils sont mixés, les mashups peuvent être classifiés en deux catégories : mashups coté-serveur et mashups coté-client. Mashups coté-serveur : Les mashups de côté-serveur intègrent des ressources (par exemple, services et données) sur le serveur. 56

Mashups coté-client : Les mashups côté-client intègrent des ressources sur le client, qui est souvent un navigateur. I.6.3.3 Classification a base de la question «comment?» Les Mashups peuvent être encore classifiés par catégories selon la modalité d intégration ou de combinaison des ressources dans une représentation. A base de cette modalité, on peut distinguer deux catégories : les mashups d extraction et les mashup de flux (flow mashups). Mashups d extraction : un mashups d'extraction peut être considéré comme un récipient de données rassemblant et analysant des ressources de différentes sources et fusionnant ces ressob-urces dans une page web. Mashups de flux : Dans un mashup de flux (flow mashup), l'utilisateur adapte le flux d une page Web combinant des ressources de différentes sources. Ensuite, ces ressources seront transformées et intégrées dans une application de mashup. Dans ce type de mashups, l actualisation du résultat s est effectuée d une manière continue. I.6.3.4 Classification a base de la question «pour qui?» La question «pour qui?» concerne le groupe d utilisateurs étant concerné par le mashups, Dans ce contexte, les mashups peuvent être classés par catégorie dans des mashups de consommateur et des mashups d'entreprise (business mashups). Mashups de consommateur : Un mashups de consommateur est prévu pour une utilisation publique. Il permet de combiner des ressources de différentes sources, publiques ou privées, et de les organiser dans une interface simple accessible par le navigateur. Mashups d entreprise : Les mashups d'entreprise permettent de fusionner de multiples ressources dans un environnement d'entreprise. Ces mashups combinent des données et des fonctionnalités de différentes applications, afin de répondre à leurs objectifs. La création des mashups d'entreprise exige la considération des politiques de sécurité et de gouvernement d'entreprise (administration, partage, stockage, mise à jours, ). Les mashups d'entreprise fournissent une manière rapide pour fusionner et représenter les ressources internes et externes de l'entreprise sans intermédiaire. 57

I.6.4 Architecture Des Mashups Dans cette partie on décrit quelques architectures de mashups, en commençant par une architecture générale. Ensuite, on présente deux types d architectures, issues de cette architecture générale. Et nous terminons par la description d une architecture de référence de tout un environnement de mashups d entreprise. I.6.4.1 Architecture générale d un mashup La figure I.13 [24] illustre une architecture générale d un système de mashups. Les composants principaux de cette architecture sont les suivants : - les Web services APIs, - les Feeds RSS, - les données locales, - le mashup, - le navigateur, - les clients. Les trois premiers composants représentent les ressources de données. Ces dernières seront mixées au niveau du composant «Mashups». Le Client c est le composant destinateur qui exploite les résultats obtenus, en utilisant le navigateur. Figure I.13: une architecture générale d un mashup. Le composant «mashups» de cette architecture, qui représente là où sera effectué le mixage de ressources de données, peut être construit de deux façons : soit au niveau 58

d un serveur ou bien au niveau du navigateur. Cela permet de distinguer deux types d architectures de mashups: - Architecture coté-serveur, - Architecture coté-client. I.6.4.2 Architecture coté-serveur Dans cette architecture, des données de différentes sources sont intégrées sur un serveur de mashups, qui renvoie la page agrégée au client. Par exemple, des APIs de mashups de Facebook sont principalement basées sur l'intégration côté-serveur. Cependant, l'inconvénient principal des mashups côté-serveur est la condition de la confiance complète du client sur le serveur de mashups. Typiquement, le client doit déléguer l'autorisation au serveur d'agir pour son propre compte [23]. Cette architecture est illustrée dans la figure I.14 [24]. Figure I.14: architecture de mashups coté-serveur. I.6.4.3 Architecture coté-client L'architecture côté-client permet aux consommateurs et aux prestataires de services de communiquer à travers un navigateur. Cela permet d éviter le problème de confiance avec un autre tiers d intégration (serveur de mashups) [23]. Cette architecture est illustrée dans la figure suivante [24]. 59

Figure I.15: architecture de mashups coté-client. Dans un contexte d entreprise, les mashups peuvent être vus comme étant une extension des applications d'entreprise. Dans le point suivant, nous présenterons une architecture d un environnement de mashups d entreprise, qui est proposée par le groupe GARTNER [25]. I.6.4.4 Architecture d'un environnement de mashups d'entreprise Cette architecture est prévue pour capturer les possibilités critiques exigées pour un environnement de mashups d'entreprise. Dans cet environnement, les utilisateurs peuvent découvrir les composants de haute valeur de mashups et les assembler dans des mashups efficaces. Ils peuvent, également, partager, évaluer, et modifier des mashups et des composants de mashups. Un environnement de mashups d'entreprise devrait permettre la construction et l'utilisation de trois entités fondamentales de mashups : composants de mashups, mashups et applications de mashups. Une application de mashups se compose d'un ou plusieurs mashups. Un mashups se compose de deux composants ou plus de mashups (souvent appelés des gadgets, des widgets, des blocs ou des pipes). Cette architecture permet de décrire un environnement robuste de mashups d'entreprise. Elle se compose de huit couches (voir Figure I.16 [25]): - sources de Mashups, - assemblage de Mashups, - visualisation de Mashups, - accès, augmentation et livraison d informations, - développement de Mashups, 60

- traitement de Mashups, - infrastructure de Mashups, - communauté de Mashups. Figure I.16: architecture d un environnement de mashups d entreprise. a-sources de Mashups : Les mashups n ont pas leurs propres données et fonctionnalités. Elles sont obtenues d autres systèmes, en utilisant les APIs, les Feeds (comme RSS), Atom et XML sous le protocole HTTP. Les Mashups d'entreprise nécessitent l'accès à une plus grande collection de sources de fonctionnalités et de données. Cependant, les mashups exigent une architecture orientée Web (WOA). Par conséquent, la transformation est exigée pour rendre ces sources non Web disponibles pour des mashups. Ces possibilités de transformation sont prises en charge dans la couche «accès, augmentation et livraison d informations». b-assemblage de Mashups : La couche de mashups est le noyau d'un environnement de mashups. Les possibilités fondamentales de cette couche incluent l'accès aux composants de mashups, les moyens d'assembler les composants dans un mashups et la capacité de visionner préalablement le résultat. Les composants de Mashups ont de différentes appellations selon le fournisseur (par exemple, des widgets, des gadgets, des pipes, des blocs et des cords), mais ils atteignent le même objectif de base. Un composant de mashups est l'encapsulation des données ou des fonctionnalités de base pour faciliter le mixage. 61

Quelques environnements d'assemblage ajoutent également un aspect de la communauté du Web 2.0, où d'autres utilisateurs peuvent vendre des composants et ajouter des informations sur la possibilité de mixer un composant avec d'autres. Cette couche permet aux utilisateurs de visionner au préalable les résultats de leur mashups avant de le publier pour un usage général ou de le rendre disponible pour usage au sein de la communauté de mashups. Ces offres préalables donnent aux utilisateurs la chance de voir si le mashups a répondu à leurs objectifs ou s'il nécessite des ajustements. Ces possibilités peuvent s'étendre de la visualisation simple à de divers niveaux d'essai et d'assistance. Cette fonctionnalité de visualisation préalable peut recouvrir avec, ou influencer, la couche de visualisation de mashups. c-visualisation de Mashups : Cette couche couvre la destination de visualisation pour un mashups. Cette destination est une interface d utilisateur qui présente le résultat final de mashups dans un navigateur web. L'interface utilisateurs est habituellement une page web, un site web, un portail web ou une application web. d-accès, augmentation et livraison d informations : Les Mashups d'entreprise nécessitent l accès à une plus grande variété de sources structurés et non structurés, tels que des applications, des bases de données, des documents, des bilans, des dossiers et des pages HTML. Ces sources ne sont pas souvent orientées web, en conséquence, ne supportent pas les mashups. La couche AAD (Information Access, Augmentation and Delivery) rend ces sources disponibles pour le mixage. Les technologies de cette couche incluent des adaptateurs, des robots et d'autres technologies pour accéder aux différentes sources. Bien que non obligatoire, la source d'information est souvent passée par le nettoyage et le traitement. En conclusion, l'information est rendue disponible pour la livraison (comme sortie) dans un format «mashable» orienté Web. Plusieurs fournisseurs offrent des possibilités seulement dans cette couche, sans fournir les possibilités de base pour créer et assembler des composants de mashups. Ces fournisseurs ne sont pas des véritables fournisseurs de mashups. Ils sont classés comme des «mashups enablers» et s'appellent souvent des «fournisseurs de mashups de données» ("data mashups vendors."). Kapow, 62

Denodo, Dapper, Ponyfish, screen-scraper, FeedYes et Apatar sont des exemples des «mashups enablers». e-développement de Mashups La couche de développement de mashups fournit aux développeurs professionnels des dispositifs pour construire et contrôler des composants de haute valeur, pour que les utilisateurs créent rapidement des applications de mashups. L'environnement de mashups peut soit avoir une couche de développement de mashups intégrée, ou bien s intégrer avec un environnement de développement existant. Ces dispositifs sont cruciaux car un environnement de mashups est aussi valable que si les composants de mashups le supportent. Les développeurs créent des composants de mashups comme blocs de données et de fonctionnalités qui sont souhaitables pour le mixage. Le dépôt de ces composants de mashups doit être de haute performance, de haute valeur et fortement utilisable. f-traitement de Mashups Les dispositifs de base des mashups ont besoin souvent de perfectionnement en tant qu'élément d'une solution d'entreprise. Ces perfectionnements impliquent souvent le prétraitement du mashups pour incorporer un mashups dans une application de mashups ou dans une autre solution. Un exemple est l'emploi des mashups comme un dispositif de visualisation dans une architecture orientée services. Le traitement de Mashups peut comporter l'addition des dispositifs de workflow aux mashups et leur intégration dans d'autres systèmes d'entreprise. L'évolution potentielle peut adresser la mise en couches des dispositifs de croisement de mashups, tels que la gestion des données principale, la surveillance d'activité économique, l'analyse de business intelligence et la médiation sémantique. g-infrastructure de Mashups Un environnement robuste de mashups d'entreprise exigera un certain niveau de support d'infrastructure de mashups. Des dispositifs telles que la sécurité, le gouvernement, l'administration, la gestion de dépôt, le support des utilisateurs et la qualité du service sont considérés infrastructure. Ils permettent de gérer l'environnement de mashups comme un capital de corporation. L'entreprise doit stratégiquement définir quels services d'infrastructure à fournir pour supporter cet environnement. L'entreprise doit développer un noyau de compétence en déterminant, en gérant et en facilitant ces 63

aspects d'environnement de mashups, ceux qui sont délégués aux utilisateurs et ceux qui peuvent être gérés par la communauté des participants. h-communauté de Mashups Beaucoup d'environnements de mashups adhèrent au Web 2.0 et forment une communauté de mashups. Ceci signifie que l'environnement de mashups est également géré en tant que communauté où les participants peuvent construire, partager, employer, évaluer, et modifier des mashups et des composants de mashups. L'approche de communauté fournit une quantité significative de valeur à l'environnement de mashups et débarque une grande partie de gouvernement et de gestion. La communauté peut se contrôler par l'aide à déterminer quels mashups sont les plus efficaces et les plus faciles à employer. La Communauté augmente la valeur des mashups et des composants de mashups en réduisant les dispositifs redondants, en diminuant le temps de développement et en augmentant l'efficacité. Dans la section suivante, nous présenterons certains concepts relatifs aux développent des mashups. I.6.5 Développement Des Mashups Dans cette section, nous présentons des concepts relatifs au développement des mashups, qui a connu une grande évolution. En commençant par l énumération des membres participants dans le développement des mashups. Ensuite, nous parcourrions les différentes étapes du cycle de développement des mashups. Après, nous dériverons de multiples catégories des outils permettant la construction et la gestion des mashups. Ainsi, nous signalerons quelques statistiques concernant le développement des mashups. Et avant de conclure, nous résumerons les différences entre le développement traditionnel et le développement des mashups. I.6.5.1 Equipe de développement des mashups Plusieurs personnes participent à la création de mashups. Elles collaborent au sein d une même chaîne de valeur. Ces participants sont les suivants: [19] a-professionnels du secteur informatique Ils créent des applications à usage interne et gèrent les bases de données et les actifs informationnels internes. Ils sont responsables de la sécurité des données et de la gouvernance. 64

b-analystes métier Ils sont l interface entre le service informatique et les utilisateurs des différents secteurs, et collaborent avec les informaticiens pour définir les coûts et les exigences en matière d applications, de solutions et de reporting. Ils doivent répondre aux besoins d informations exprimés par les différents secteurs d activité. c-utilisateurs métier Ils ont besoin d un meilleur accès aux informations pour pouvoir optimiser leurs performances. Les utilisateurs métier incluent les membres des différents secteurs d activité ne possédant que peu d expérience en matière de solutions techniques (endehors des logiciels Microsoft Office), qui travaillent souvent avec les analystes métier pour déterminer les besoins des unités commerciales. I.6.5.2 Cycle de développement des mashups Si les développeurs traditionnels restent largement dans la boucle, le cycle de développement des mashups est grandement allégé par rapport à une approche classique basée sur une architecture orientée services (SOA). Un projet d'intégration de type SOA nécessite un effort d'au moins six à neuf mois, alors qu'un projet de mashups sera bouclé en trois ou quatre mois. De plus, une fois le catalogue terminé, les utilisateurs sont entièrement autonomes, ce qui n'est pas le cas lorsqu'il s'agit d'agréger des services Web. [20] Donc, les mashups se justifient quand l'approche SOA se révèle trop lourde pour être raisonnablement mise en œuvre. Il reste que les mashups peuvent être vus comme un pis-aller dans la mesure où ils font l'impasse sur les spécifications fonctionnelles, ainsi que sur une véritable démarche d'urbanisation. [20] Le cycle de développement comprend quatre étapes (voir figure I.17): [19] - Développement et déverrouillage, - Recherche, - Transformation, - Création et exploration. 65

Figure I.17: cycle de développement des mashups Développement et déverrouillage : La première étape de création de centres de mashups d entreprise consiste à développer et à partager les ressources figurant dans un catalogue. Les informaticiens et les analystes métier développent des favoris interactifs, déverrouillent de nouvelles sources d informations, ou encore les deux. Ces nouveaux favoris sont créés par des professionnels du secteur informatique (qui leur appliquent un code crypté), ou encore par les analystes métier (à travers l utilisation d assistants pour non-développeurs). De nouvelles sources d informations sont déverrouillées et actives via des interfaces REST (Representational State Transfer), aux formats Atom ou RSS. Recherche : Les nouvelles ressources pouvant être utilisées dans des mashups sont insérées dans le catalogue; des balises Web 2.0 leur sont appliquées, ainsi que des caractéristiques propres aux réseaux sociaux. Ensuite, chacun peut rechercher et réutiliser ces ressources pour constituer de nouveaux mashups d entreprise, en s aidant pour cela des balises et de l expérience collective des utilisateurs précédents. Ces caractéristiques associent des aspects sociaux (indications et commentaires) et la possibilité de partage de mashups. Transformation : Les professionnels du secteur informatique et les analystes métier peuvent ensuite accéder à l étape de transformation, qui consiste à combiner les différentes sources d informations. A ce stade, une grande variété de sources d informations est automatiquement normalisée et convertie en flux d informations. Les opérateurs utilisés sont nombreux : filtrage, fusion, combinaison, regroupement, tri, annotation et augmentation. Il est possible de créer rapidement et de façon très simple 66

des regroupements d informations spécialisées et nouvelles, pour répondre aux besoins exprimés. Ces opérations s effectuent toutes via l utilisation d un outil graphique qui permet d afficher l aperçu des informations au fur et à mesure de leur création. Le format des données peut également être transformé (quelle que soit la source d origine) aux formats RSS, XML ou Atom. Création et exploration : Ensuite vient l étape de la création, souvent associée aux mashups : un navigateur est utilisé pour l assemblage et la liaison entre les différents éléments qui constitueront le mashups. Cette étape implique la création (sans programmation) de menus déroulants, et peut être réalisée par des utilisateurs, des analystes métier et des informaticiens. Pendant l étape de création, les clients effectuent des explorations proches des activités d assemblage, mais ici l objectif final est la recherche de problèmes contextuels complexes, et non la définition de l utilisation future. I.6.5.3 Outils De développement des mashups Plusieurs outils de mashups, qui ont été publiés, fournissent des fonctionnalités pour construire, stocker et publier des mashups. Ces outils ont été conçus comme des applications Web 2.0 permettant aux utilisateurs de partager leurs mashups créés et de les fournir par des simples opérations de cliquer-glisser. La gamme de ces outils de mashups comprend quelques outils Open-source et d'autres de licence très chères. Certains des fournisseurs offrent des éditeurs de codage tandis que d'autres se concentrent sur les utilisateurs non qualifiés en programmation. [22] En se basant sur le schéma de classification des mashups présenté dans la deuxième section, nous discutons dans cette section des outils supportant la création des types correspondants de mashups. Habituellement, les propriétaires de ressources facilitent l'accès à leurs données en offrant des APIs. Ces APIs suivent des protocoles standards et peuvent être facilement employées pour combiner des ressources de multiples sources, en utilisant un outil de mashups. La gamme entière des APIs pour les mashups est énumérée sur la page Web «programmableweb.com». Les APIs peuvent être explorées par les langages de programmation préférés (PHP, JAVA,.NET, ) ou par catégories prédéfinies où les APIs de «Google Maps» semblent les plus populaires [22]. Les ressources combinées peuvent être rapidement affichées aux utilisateurs dans un navigateur web, en utilisant les techniques: SOAP, REST, Screen scraping ou des 67

langues tels que JSON1 [22]. Le tableau I.3 [09] montre une vue d'ensemble des outils de mashups classés par catégorie, selon le modèle de classification dans la section 2. Tableau I.3: classification des outils de mashups Dans cette section, nous présentons quatre outils couvrant les différentes catégories de mashups. En plus, nous parlons brièvement d un langage qui permet la création de mashups. [22] a-outils d extraction et présentation des mashups de consommateur : L'exemple pour un tel outil de mashups est Dapper. Le terme Dapper résulte des deux termes: "Data" et "mapper", qui décrit exactement la fonctionnalité de l'outil qui permet de cliquer-glisser des widgets préconstruits dans une interface d'utilisateur. Cet outil permet de réutiliser et partager les résultats ultérieurement. L'utilisation de Dapper est très simple et n'exige aucune connaissance des langages de programmation. Initialement, l'utilisateur doit rechercher les pages Web desquelles il voudrait extraire le contenu. Après, il localise la zone qu'il vaudrait extraire. Finalement, en utilisant Dapper, il compose le contenu extrait dans une nouvelle représentation. L'utilisateur peut partager le résultat 68

pour qu'il soit réutilisé par d'autres environnements de mashups. La figure I.18 [09] montre l interface de Dapper, permettant à un utilisateur d explorer un site Web et d y extraire son logo. Figure I.18: interface de l outil Dapper. b-outils de données et de flux des mashups de consommateur : L'exemple d un tel outil de mashups qui permet de mixer les flux de données de multiples sources est «DERI pipes». L'implémentation de cet outil a été inspirée par «Yahoo! Pipes», mais l'avantage de cet outil (contrairement à l'outil de Yahoo) est que «DERI pipes» peut manipuler le format de RDF et ainsi permet de construire des mashups sémantiquement améliorés. «DERI pipes» n'a pas besoin d'aucune connaissance des langages de programmation mais exige la compréhension des formats de données comme RDF. Le mashup final obtenu est défini dans XML ou RDF et peut être publié sur internet et partager avec d'autres utilisateurs. c-outils de Données, fonctionnalités et flux des mashups d entreprise : L'exemple d'un outil offrant des fonctionnalités pour créer des mashups d'entreprise est "Serena Mashups Composer", qui est inclus dans "Serena Mashups Suite". Selon les fournisseurs de cet outil, Serena considère l'intégration d'informations, de données et de processus d'affaires, dans une représentation commune. c-outils de présentation, données et flux des mashups de consommateur : L'exemple de tels outils est "Microsoft Popfly". Popfly n'est pas limité à la génération des fichiers XML, mais offre également des possibilités pour visualiser les données (à l'aide des modules tels que Microsoft Virtual Earth). L utilisation de Microsoft Popfly 69

n'exige aucune qualification dans les langages de programmation mais elle exige la compréhension des formats de données. La figure I.19 montre un exemple pour créer un mashups avec Popfly. Dans cet exemple l'api du Facebook est employé pour visualiser des images de Facebook dans un carrousel. Figure I.19: interface de Microsoft Popfly. d-langage de création des mashups. : Plusieurs langages ont été proposés pour la construction des mashups. Parmi tous ces langages, "Orc" semble être le plus documenté et le plus développé. La page Web d'orc offre un éditeur pour le codage du programme. Le code peut être directement exécuté, parce que l'éditeur est connecté à un serveur. Orc est également disponible sous forme d'un fichier JAR ou sous forme d'une application Java. Pour écrire une application de mashups dans Orc, l'utilisateur devrait avoir une connaissance sur les langages de programmation fonctionnels, puisqu'orc est un langage de programmation fonctionnel. Les auteurs d'orc définissent trois domaines d'application appropriée. Orc peut être employé comme langage de programmation d'usage universel pour le codage des applications distribuées, comme langage web de script pour créer un mashups de service web et comme langage de spécification exécutable pour des applications de workflow et des problèmes de coordination de processus. Ainsi, Orc convient pour construire des mashups orientés processus. 70

Le tableau suivant [21] récapitule les produits de mashups de pointe. Editeur Produit Catégorie Commentaire IBM Lotus Mashups Composeur Assemblage de widgets, création de widgets Java. IBM Websphere smash Développement Création de widgets REST, de composants. IBM Infosphere mashuphub Serveur de mashup Expose les données de l entreprise et du web, les transforme et les mixe en de nouveaux flux. JackBe Presto Wires Visual Composer Composeur Assemblage de services web SOAP ou REST, de flux RSS, ect. JackBe Presto Studio Développeur Environnement de développement visuel de mashups basé sur Eclipse Kapow Mashup OnDemand Composeur/ serveur Version SaaS de Kapow Mashup Server, transformation de données. Kapow Kapow Mashup Server Serveur de mashups Existe en 04 versions : Data Collection, Portal, Content Migration Et Web 2.0 Edition. Serena Mashup Composer Composeur Création de mashups de données et de processus avec la possibilité de les héberger chez Serina. Serena Serina mashup Server Serveur de mashups Moteur d exécution de mashups, gestion des changements, sécurité de données, authentification, etc. Twinsoft Convertigo studio Développement Studio graphique basé sur Eclips : découpage d applications web : web clipping, webisation des applications existantes, etc.. WS02 WS02 Mashup Server Serveur de mashups Projet open source. Intégration de services web SOAP et REST, de page web, de mail, de SMS, etc. Tableau I.4: produits de pointe de création et de gestion des mashups. I.6.5.4 Statistiques sur le développement des mashups Dans cette section, nous montrons quelques statistiques sur les mashups, sont fournies par le site web «www.programmableweb.com». En commençant par seules qui 71

concernent les mashups les plus utilisées, et en citant en suite des statistiques sur les APIs utilisées par les mashups. a-statistiques sur l utilisation des mashups : La figure I.20 illustre les taux d utilisation des mashups les plus populaires sur Internet. Figure I.20: taux d utilisation des mashups. b-statistiques sur les APIs utilisées par les mashups : La figure suivante montre les taux d utilisation des APIs les plus exploitées pour les applications de mashups. Figure I.21: taux d utilisation des APIs pour les mashups Ces statistiques traduisent la diversité des applications de mashups et la domination des mashups de cartographie, comme «GoogleMaps». I.6.5.5 Développement de mashups vs le développement classique 72

Dans le tableau suivant [19], en récapitule les différences entre le développement des mashups et le développement traditionnel. Tableau I.5: développement des mashups vs développement traditionnel I.6.6 Les Mashups Vs Les Portails web Avant les mashups, les portails web ont été utilisés pour faire l agrégation de contenu. Des informations, des applications et des services collaboratifs sont intégrés dans un site unique, et ils sont individualisés selon des buts d utilisation. Les portails web sont basés sur la technologie du web dynamique traditionnel [28]. Pour illustrer la différence entre les mashups et les portails web, nous décrivons dans cette section les modèles d agrégation des contenus de ces deux technologies d intégration. I.6.6.1 Modèle d agrégation d un portail web Le processus d agrégation des informations dans un portail web est divisé en deux phases (voir figure I.22): [28] 73

- Phase 1 : les portlets acquièrent les données à partir de plusieurs sources différentes et ils créent des fragments pour les contenir. - Phase 2 : ces fragments sont intégrés dans un site (portail web). Figure I.22: modèle d agrégation d un Portail web. Donc, le portail est un site d agrégation dans lequel les contenus obtenus à partir de plusieurs sources sont placés côte à côte. Ils sont presque indépendants. Mais quand une requête de mise à jour est envoyée à un portlet, ce seul portlet va réaliser une opération de mise à jour. Ensuite, le reste des portlets sur la page réalisent immédiatement des opérations de mise à jour. C est-à-dire, que toute la page est rechargée. I.6.6.2 Modèle d agrégation d un mashup Figure I.23: modèle d agrégation du Mashups. Un mashups utilise des technologies de web 2.0, typiquement Ajax. Alors, il est plus souple. Quand une partie de la page reçoit une requête de mise à jour, seule cette partie est mise à jour, pas toute la page. Les contenus obtenus de plusieurs sources peuvent être traités et mélangés pour créer un nouveau contenu avant le présenter (voir figure I.23). [28]. Par conséquent, les contenus sont très variés et de multiformes. De plus, les 74

opérations sur les données du mashups se basent principalement sur l architecture REST (Representational State Transfer), elles ne sont pas limitées par des API de portlets. I.6.7 Défis De Construction Des Mashups Pour utiliser les mashups comme technologie efficace pour l'intégration de ressources, les sept (07) défis suivants devraient être résolus où certains de ces défis concernent non seulement les mashups mais également le World Wide Web. [09] I.6.7.1 Cataloguing Quelques pages Web sont déjà disponibles permettant d énumérer des mashups et de fournir une interface pour la recherche des mashups tels que "programmableweb.com". Les créateurs de Mashups peuvent insérer leurs mashups dans la liste et partager ainsi leurs mashups avec d'autres. Mais ce qui est absent est la possibilité de stocker et cataloguer ces mashups dans un annuaire d'une manière cohérente et consistante. I.6.7.2 Intégrité des données Les Mashups sont une manière rapide de créer de nouvelles applications, mais ils peuvent soulever des problèmes d'intégrité de données quand les changements des utilisateurs sont invalides contre l'engagement fondamental. Un autre souci peut soulever des problèmes d'intégrité si par exemple, un utilisateur trouve un service qui apporte une certaine valeur aux données ou aux fonctionnalités incluses dans le mashups. Alors les mashups doivent être modifiés au cours d'exécution. Ainsi, lors de l'exécution, les mécanismes de contrôle des mashups doivent assurer l'intégrité du mashups contre les changements d'utilisateur. I.6.7.3 Accessibilité de données par le web Mashups sont construites de différentes ressources qui sont disponibles sur le Web. Cependant, actuellement beaucoup de données et fonctionnalités ne sont pas installées sur le Web et ne sont pas ainsi accessibles par l'intermédiaire des Feeds, web services ou HTML. Pour rendre plus de ressources accessibles par le web (Web-enabled), il faut avoir des formats et des outils qui facilitent l'accès efficace et la connexion des ressources au Web. En plus, certaines données qui sont disponibles sur le Web ne peuvent pas être réutilisées pour le mixage, parce que les données sont encapsulées avec la couche de présentation. Ainsi, Des mécanismes sont nécessaires pour supporter la création des mashups à partir d autres ressources que les données, et également des outils qui offrent 75

des fonctionnalités pour découpler des données, de multiples sources, de leurs présentations. I.6.7.4 Sécurité Et Identité Tandis que des défis de sécurité ont été identifiés pour les mashups, seulement peu d'approches existent et essayent d'aborder le problème de sécurité et d'identité des mashups. «Lawton» [28] conteste que le défi de la sécurité émerge quand l'utilisateur se connecte dynamiquement aux sites Web et pas nécessairement sous le contrôle du fournisseur. Des défis additionnels de sécurité surgissent si le mashups contient des données confidentielles ou des authentifications sont exigées pour entrer quelques données. Ceci exige des mécanismes pour contrôler la connexion d'utilisateur et la sécurité de données. I.6.7.5 Partage et réutilisation Le prochain souci pour la construction de mashups est que les fournisseurs des outils de mashups devraient fournir des mécanismes pour permettre aux utilisateurs de partager leurs mashups avec d'autres et de faciliter la réutilisation des mashups préconstruits. Ceci signifie également que les propriétaires de mashups doivent donner leur permission avant de rendre le mashups disponible pour la communauté. Autrement, les utilisateurs doivent faire face à des implications légales d'employer cette technologie, et doivent s'attendre à des conséquences [27]. Pour faciliter le partage (légal) d une ressource, le mashups doit être défini dans un format qui est lisible par différentes machines et doit aussi considérer la responsabilité. Les défis qui doivent être relevés dans ce contexte sont: un accès facile pour utiliser les mashups, des fonctionnalités efficaces de recherche de mashups et des formats légers qui permettent même pour des nonprogrammeurs une réutilisation douce de mashups. I.6.7.6 Certificats de confiance Le propriétaire d'un tel service d'annuaire peut émettre une licence qui certifie le mashups. Jusqu'ici, aucun mécanisme de certification n'existe, qui garantie aux utilisateurs la fidélité du mashups. Semblable aux certificats de confiance pour des achats en ligne, il est imaginable que les propriétaires de mashups accordent une licence au propriétaire du service d'annuaire. En cas d une certification positive, le propriétaire de mashups peut assurer aux utilisateurs la fidélité du contenu et également l'intégrité de l'application de cartographie. 76

I.6.7.7 Mécanismes de contrôle des versions Les Mashups se composent de différentes ressources rassemblées de diverses sources. Les propriétaires de ressources sont responsables de leur contenu et peuvent changer et mettre à jour leur contenu ou respectivement leur logiciel tant qu'il est nécessaire. Pour maintenir le contenu du mashups à jour, un mécanisme de contrôle de version est recommandé qui informe automatiquement le propriétaire de mashups au sujet des mises à jour du logiciel intégré. Malgré les grandes évolutions des technologies l intégration web, le développement dans ce domaine est encore confronté à des enjeux, qui seront détaillés dans la section suivante. I.7 ENJEUX D INTEGRATION WEB Les entreprises sont contestées avec des problèmes d'intégration de plus en plus importants et difficiles. Malgré les grands efforts de normalisation et de coordination dans les entreprises, la plupart des organisations d'it sont confrontées aux nombreuses applications intérieurement développées et empaquetées qui n'ont pas été conçues pour communiquer les unes avec les autres. Avec les applications web, elles sont maintenant confrontées à un défi encore plus grand : la nécessité d'accéder et d intégrer avec des applications externes supportées par des clients, des partenaires et des fournisseurs. Traditionnellement, des approches standard d'intégration d'application ont été utilisées pour résoudre ces problèmes. Récemment, des experts et des médias ont proposé des services web comme solution d'intégration d'application. Cependant, la plupart des organisations font face à un certain nombre de problèmes avec cette méthode : [02] I.7.1 Temps Malgré les contraintes des budgets et les ressources limitées, la plupart des besoins des utilisateurs exigent aujourd'hui de leurs groupes technologiques de fournir des solutions plus rapidement que possible. Dans le monde de l'intégration, déterminant quel API à utiliser pour l'intégration est une étape critique. Des approches telles que les services Web favorisent une interface programmable uniforme à toutes les applications, pourtant touts les problèmes habituels de développement demeurent. Les services Web ou même les solutions main-codées doivent être développées et complètement testées 77

avant qu'ils soient déployés. Normalement ceci implique une modification de l'application pour exposer sa logique, une ressource intensive et une consommation du temps de développement. Plus pragmatique, cette approche est seulement possible quand votre compagnie a la propriété de l'application entière. [02] I.7.2 Maintenance Pour les applications Web en dehors de l'entreprise, les modifications exigées par des méthodes traditionnelles d'intégration ne seront pas souvent possibles. Même lorsqu'un partenaire ou un client est prêt à ouvrir ses systèmes, la capacité d'intégration peut être impraticable. En conséquence, la plupart des projets d'affaires critiques exigeant l'intégration aux applications externes sont extrêmement difficiles ou impossibles au pire des cas. Pour la plupart des organisations, ceci peut impliquer directement un manque d'opportunités d'affaires et une augmentation des coûts d'exploitation. [02] I.7.3 Coût L'intégration traditionnelle d'application compte sur le contrôle total de l'application, ainsi elle peut être modifiée intérieurement. Ceci a souvent comme conséquence des coûts significatifs, puisque la plupart des projets d'intégration d'application représentent des grands efforts de développement assurés par des staffs fortement qualifiés. Inhérent à ces plus grands projets est un haut risque de retard et d'un impact possible sur l'infrastructure globale de l'organisation. [02] I.8 CONCLUSION A travers l étude d état de l art menée au cours de cette première partie, nous avons pu connaitre les raisons pour les quelles la communauté de développement s est orientée vers l intégration web pour faire face aux enjeux d intégration d applications d entreprises. En plus elle nous a permis d explorer les principaux concepts des technologies d intégration web qui ont connu un grand succès, à savoir: les services web, SOA et les mashups. Enfin, nous avons décelé les enjeux de l intégration web, surtout les problèmes de l interopérabilité, le temps, la maintenance et le cout de développement. Ceci nous a poussés à réfléchir à une démarche qui permet de remédier à ces enjeux, en focalisant sur le problème de l interopérabilité. Cette démarche repose sur l élaboration d un méta modèle d intégration web, qui permet de représenter les concepts de ce domaine et les relations entre ces concepts. Ceci fait l objet de la partie suivante. 78

II APPROCHE MDA POUR L INTEGRATION WEB II.1 INTRODUCTION Après avoir étudié le domaine d intégration web dans la première partie, nous présentons, ainsi, une démarche d application de l approche MDA pour l élaboration d un méta-modèle d intégration. Dans notre travail, nous avons appliqué cette approche pour les raisons suivantes : - Profiter de la complémentarité entre les technologies d intégration web, - Prise en compte de l interopérabilité dés le début du cycle de développement, - Réduction du temps de développement, - Réduction du coût de développement, - Flexibilité de développement, - Diversification des groupes de travail, - Facilité de la maintenance des applications d intégration web, - Augmentation la réactivité des applications d intégration web, - Augmentation de l indice du rendement sur investissement en technologies d intégration web. Dans cette partie, nous commençons tout d abord par un aperçu sur l approche de développement MDA. Ensuite, nous décrivons les étapes de l application de cette approche, à partir de la création d un méta-modèle global d intégration web, jusqu à la génération d un modèle PSM, en passant par les différentes transformations de modèles nécessaires. Enfin, nous concluons notre travail, en citant les difficultés rencontrées, les avantages et les inconvénients de notre approche. II.2 APERÇUS SUR L ARCHITECTURE ORIENTEE MODELE (MDA) II.2.1 Introduction A MDA L'OMG (Object Management Group) a été formée comme une organisation de normalisation pour aider à réduire la complexité, diminuer le coût, et à accélérer l'introduction de nouvelles applications logicielles. Une des initiatives principales par lesquelles l'omg accomplit ce but est par la promotion de MDA (Model Driven Architecture) comme environnement architectural pour le développement de logiciel. Cet environnement est établi autour d'un certain nombre de spécifications détaillées d'omg, qui sont largement utilisées par la communauté de développement. [08] 79

En 2001, l'omg a adopté MDA comme approche pour l'utilisation des modèles dans le développement de logiciel. Ses trois buts primaires sont la portabilité, l'interopérabilité et la réutilisabilité par la séparation architecturale des soucis. [08] Vue l importance de cette initiative d OMG pour faire face aux enjeux connus par la communauté de développement d une manière générale et en particulier la communauté web, nous avons introduit ce chapitre pour rappeler les principaux concepts de l architecture MDA. D où, nous commençons par des notions générales, en insistant sur la relation entre MDA et d autres initiatives d OMG (UML : Unified Modeling Language, et MOF: Méta-Objet Facility). Par la suite, nous énumérons les concepts de base utilisés dans MDA. En plus, nous explorons les standards, les types de modèles, les transformations de modèles et les étapes à parcourir dans la démarche MDA. II.2.2 Notions Générales Sur MDA II.2.2.1 historique sur MDA Onze (11) compagnies ont fondé l'omg en avril 1989. En octobre 1989, l'omg a commencé des opérations indépendantes. Par l'engagement de l'omg à développer des spécifications techniquement excellentes, commercialement viables et indépendantes aux fournisseurs pour l'industrie de logiciels, le consortium inclut maintenant 800 membres. L OMG est siégée dans Framingham et les Etats-Unis et a des bureaux de commercialisation internationaux dans plusieurs pays partout dans le monde avec un représentant gouvernemental dans Washigton. [29] L'OMG a été initialement formée pour créer un marché de logiciels à base de composants en supportant l'introduction de logiciels orientés objet standards. La charte de l'organisation inclut l'établissement des directives d'industrie et des spécifications détaillées de gestion d'objet pour fournir un Framework commun pour le développement d'applications. La conformité à ces spécifications permet la possibilité de développer un environnement informatique hétérogène à travers tous les plates-formes matérielles et les systèmes d'exploitation importants. Aujourd'hui, les implémentations des spécifications d'omg peuvent être trouvées dans plusieurs systèmes d'exploitation à travers le monde. Les séries de spécifications d'omg détaillent les interfaces standards nécessaires pour le calcul distribué orienté objet. [29] L'OMG a fourni aux l'entreprises des standards d'interopérabilité indépendants aux vendeurs et aux langages. Son but est de fournir un dispositif global de l'information. À cet 80

effet, l'infrastructure standard CORBA et le standard de modélisation UML ont été présentés par OMG. En plus de ceci, un processus très bien admis de standardisation a été établi, qui a été amélioré au cours des années récentes pour un développement - aussi bien raffiné que - CORBA et UML. L'architecture orientée modèle (MDA: Model Driven Architecture) est la prochaine étape. [29] II.2.2.2 Principe de MDA Généralement MDA vise à séparer la logique d'affaires d'une application ou d un domaine (modèle indépendant de plate-forme «PIM») de la technologie d'implémentation (modèle spécifique à une plate-forme «PSM» et l'implémentation). La séparation de PIM, de PSM et d'implémentation est conforme à la règle la plus importante dans le développement de systèmes d'information : la séparation des soucis. En plus, l'utilisation du PIM nous permet de soustraire de la technologie d'implémentation, telle que le développement de système d'information atteint un haut niveau d'abstraction. Cette augmentation dans l'abstraction est comparable à l'évolution des langages de programmation, à partir du langage machine à l'assembleur, à la procédure et au langage orienté module et aujourd'hui au langage orienté objet.. Le schéma suivant montre les principaux concepts utilisés par l approche MDA. [07] Figure II.1: principaux concepts du MDA. Afin de modéliser les PIMs et/ou les PSMs, l'omg, créateur de MDA, suggère l'utilisation du langage de modélisation UML (Unifed Modeling Language), qui vient 81

également à l'origine de cette organisation. L'utilisation d'uml n'est pas une nécessité et actuellement il y a un grand intérêt pour le développement de ce qu'on appelle Domain Specific Langage (DSL). [07] Pour avoir la capacité de définir un DSL ou d'utiliser UML pour des objectifs spéciaux, les concepts : modèles, méta-modèles et méta-méta-modèle jouent un rôle fondamental. Également, des règles de transformation dans MDA sont basées sur les mêmes concepts. A ce propos, OMG définit Méta-Objet Facility (MOF) qui inclut une architecture à quatre couches. Cette dernière est illustrée avec un exemple dans la figure suivante. [07] Figure II.2: architecture MOF à quatre couches. Le niveau le plus bas M0 montre un objet de monde réel d'un étudiant qui a le nom : «Lofi Dewanto». Pour pouvoir décrire cet objet, nous devons déclarer une classe d'étudiant au niveau M1. Cette classe d'étudiant comporte tous les objets qui ont des caractéristiques similaires. Au niveau M1 nous utilisons UML en tant que langage de modélisation. C'est l'approche typique actuellement pour modéliser et implémenter les systèmes d'information orientés objet. Le niveau m2 décrit le méta-modèle d'uml qui sert d'outil pour vérifier l'exactitude de la sémantique du modèle développé au niveau M1. Un exemple de ceci serait : 82

- Une classe peut avoir une association seulement avec d'autres classes. - Une classe peut être une extension d une autre classe (généralisation). Au niveau m2, le méta-modèle d'uml offre l'élément de modélisation "classe" comme une Méta-classe pour décrire une classe au niveau plus bas M1. Le niveau M3, la couche de méta-méta-modèle, est la couche la plus élevée. Le méta-modèle d'uml du niveau m2 a besoin d'une description et c'est où MOF joue son rôle. Dans notre exemple, " classe " du MOF décrit "classe " du méta-modèle d'uml. Depuis MOF lui même, il n'exige pas d'autres méta-modèles. MOF a un ensemble réduit de constructions pour décrire d autres modèles audessous du niveau 3. Les constructions les plus importantes sont : Classe, Association, Type de donnée et Package (17). En utilisant MOF, on peut définir des méta-modèles pour n importe quel DSL (Domain Specific Langage), juste de la façon dont MOF décrit le méta-modèle d UML. Par conséquent, il est clair que MDA ne dépond pas d UML comme un langage de modélisation. Ainsi, il est possible de créer votre propre DSL qui est décrit par MOF. Donc MDA est très flexible. Dans la section suivante, on va jeter un coup d œil sur les principaux concepts de l architecture MDA. II.2.2.3 Concepts de l architecture MDA Les concepts de l architecture MDA sont issus, d un coté, de certains concepts utilisés dans le domaine de développement d une manière générale. D un autre coté, d autres concepts de MDA sont originaires des différents aspects de la modélisation et la transformation de modèles. Les concepts les plus utilisés dans MDA seront discutés dans les points suivants. [08] Système : Le contexte de MDA est le système logiciel, soit préexistant ou en construction. Modèle : Un modèle est une spécification formelle de la fonction, de la structure et du comportement d'un système dans un contexte donné, et d'un point de vue spécifique (ou d'un point de référence). Un modèle est souvent représenté par une combinaison de schémas et de textes, typiquement en utilisant une notation telle qu'uml, enrichi avec des expressions de langage naturel. Une spécification est dite formelle quand elle est basée 83

sur un langage qui a une signification sémantique bien définie liée à chacune de ses constructions, pour le distinguer d'un simple diagramme montrant des boîtes et des lignes. C'est ce formalisme, qui permet au modèle d'être exprimé en format tel que XML, conformément à un schéma bien défini (XMI). L Orienté Modèle (Model Driven) : Ce concept décrit une approche de développement de logiciels par lequel des modèles sont utilisés comme source primaire pour documenter, analyser, concevoir, construire, déployer et maintenir un système. Architecture : L'architecture d'un système est des spécifications des parties et des connecteurs du système et des règles pour les interactions des parties en utilisant les connecteurs. Dans le contexte de MDA ces parties, ces connecteurs et ces règles sont exprimés par l'intermédiaire d'un ensemble de modèles en corrélation. Point de vue (Viewpoint) : Un point de vue est une technique d'abstraction pour se concentrer sur un ensemble particulier de soucis dans un système tout en supprimant tout le détail non pertinent. Un point de vue peut être représenté par l'intermédiaire d'un ou plusieurs modèles. Point de vue MDA (MDA viewpoints) : MDA spécifie trois points de vue par défaut sur un système : indépendant de l'informatique, indépendant des plates-formes et spécifique à une plate-forme. Le point de vue indépendant de l'informatique (computation independent viewpoint) se concentre sur le contexte et les conditions du système sans considération pour sa structure ou traitement. Le point de vue indépendant de plate-forme (platform independent viewpoint) se concentre sur les possibilités opérationnelles d'un système en dehors du contexte d'une plate-forme spécifique (ou de l'ensemble de plates-formes), en montrant seulement les parties de ces spécifications complètes qui peuvent être soustraites hors de cette plateforme. Un point de vue spécifique à une plate-forme (platform specific viewpoint) renforce un point de vue indépendant de plate-forme avec des détails concernant l'utilisation d'une plate-forme spécifique. Platforme : Une plate-forme est un ensemble de sous-systèmes et des technologies qui fournissent un ensemble logique de fonctionnalités par des interfaces et des modèles 84

d'utilisation. Les clients d'une plate-forme l'utilisent sans souci pour ses détails d'implémentation. Les exemples des plates-formes incluent les systèmes d'exploitation, les langages de programmation, les bases de données, les interfaces utilisateurs, les solutions middleware etc. Indépendance de plate-forme (Platform independence) : L'indépendance d une plate-forme est une qualité qu'un modèle peut montrer quand il est exprimé indépendamment des dispositifs d'une autre plate-forme. L'indépendance est un indicateur relatif en termes de mesurer le degré d'abstraction, qui sépare une plate-forme des autres. Modèle de plate-forme : Un modèle de plate-forme décrit un ensemble de concepts techniques représentant ses éléments constitutifs et les services qu'elle fournit. Il spécifie également des contraintes sur l'utilisation de ces éléments et de ces services par d'autres parties du système. Transformation de modèle : La transformation de modèle est le processus de conversion d un modèle à un autre dans le même système. La transformation combine le modèle indépendant de plate-forme avec des informations supplémentaires pour produire un modèle spécifique à la plate-forme. Implémentation : Une implémentation est des spécifications qui fournissent toutes les informations exigées pour construire un système et pour le mettre en service. Elle doit fournir toutes les informations requises pour créer un objet, et pour permettre à l'objet de participer à fournir un ensemble approprié de services en tant qu'élément du système. II.2.2.4 Standards d OMG pour MDA Pour obtenir une telle efficacité, plusieurs outils conceptuels sont mis à la disposition des équipes de développement. Parmi ces outils, on peut situer : UML, XMI, MOF et CWM. Ces outils sont proposés par OMG. [30] : UML : Largement utilisé par ailleurs, qui permet une mise en œuvre aisée de MDA en offrant un support connu comme étant un langage de modélisation qui fournit plusieurs constructions permettant de spécifier la structure et le comportement d un système. XMI : XML Metadata Interchange, propose un formalisme de structuration des documents XML de telle sorte qu'ils permettent de représenter des méta données d'application de manière compatible. 85

MOF : Meta Object Facility, spécification qui permet le stockage, l'accès, la manipulation et la modification de méta données. Cette spécification a été illustrée dans la figure «II.2» CWM : Common Warehouse Metamodel, pour définir une base de données pour des métadonnées. L'OMG n'a pas jugé utile de standardiser un processus associé à ces outils. Leur rôle est de répondre aux besoins des utilisateurs de manière générique, et non de proposer de solutions définitives pour certains types d'applications précises. Un processus de génie logiciel exploitant les possibilités de MDA a cependant été proposé : le 'Model- Driven Software Development' (http://www.mdsd.info/). II.2.3 Types Des Modèles Utilisés Dans MDA MDA spécifie trois modèles par défaut d'un système correspondant aux trois points de vue de MDA définis ci-dessus. Ces modèles peuvent être plus exactement décrits comme étant des couches d'abstraction, puisque dans chacune de ces trois couches un ensemble de modèles peut être construit, chacun correspond à un point de vue plus focalisé du système (interface utilisateurs, information, technologie, architecture, etc.). [08]. Dans MDA, les modèles sont classifiés en : CIM, PIM, PSM, qui sont expliqués dans les sections suivantes. II.2.3.1 Computation Independent Model (CIM) Un CIM est désigné souvent sous le nom d'un modèle d'affaires ou de domaine, parce qu'il utilise un vocabulaire qui est bien connu par les experts de domaines. Il présente exactement ce qu'on s'attend à ce que le système fasse, mais cache toutes les informations des spécifications technologiques pour rester indépendant de la façon dont ce système sera (ou est actuellement) implémenté. Le CIM joue un rôle important en établissant le lien qui existe typiquement entre ces experts de domaine et les responsables des technologies de l'information pour implémenter le système. II.2.3.2 Platform Independent Model (PIM) Un PIM montre un degré suffisant de l'indépendance afin de permettre son mapping à une ou plusieurs plates-formes. Ceci est généralement réalisé en définissant un ensemble de services d'une manière de soustraire en dehors les détails techniques. D'autres modèles spécifient alors une réalisation de ces services d'une façon spécifique à une plate-forme. 86

II.2.3.3 Platform Specific Model (PSM) Un PSM combine les spécifications dans le PIM avec les détails exigés pour stipuler comment un système utilise un type particulier de plate-forme. Si le PSM n'inclut pas tous les détails nécessaires pour produire une implémentation de cette plate-forme on le considère abstrait (signification qu'elle se fonde sur d'autres modèles explicites ou implicites qui contiennent les détails nécessaires). II.2.4 Transformations De Modèles Dans MDA MDA permet de définir des transformations d un PIM en plusieurs PSMs (voir la figure II.3). Ceci facilite le développement d'un système dans l'abstraction, et simplifie l'implémentation de ce système à travers diverses plates-formes cibles. [31] : Figure II.3: transformation d un PIM en plusieurs PSMs dans MDA Par exemple, une MDA qui transforme d'un PIM à un DDL créera les éléments de table DDL à partir une classe, tandis que la même classe transformée à une entité EJB aura comme résultat un package contenant les éléments de la classe et de l'interface exigés par EJB. [31] La transformation d un modèle MDA se fait par mapping entre un modèle initial et un modèle cible. Chaque modèle doit être décrit par un méta-modèle, qui recense les caractéristiques de ce modèle. Le mapping est alors définit comme une traduction entre le méta-modèle initial et le méta-modèle cible. Pour effectuer la transformation, un moteur de transformation est indispensable. La figure suivante présente le principe de la transformation. [30] 87

Figure II.4: principe de transformation de modèles dans MDA. On distingue deux types de mappings : les mapping verticaux, qui changent le niveau d'abstraction, et les mapping horizontaux, qui le conservent. [30] II.2.4.1 Mappings verticaux On en distingue deux sortes : - Mappings de modèle d'analyse vers le modèle d'implémentation (ou mappings de raffinement). Ils permettent de préciser le modèle de l'application, en fonction de l'implémentation souhaitée. Souvent, un seul modèle initial suffit. Parfois, des contraintes sont nécessaires (sinon le modèle cible est incomplet), ou bien plusieurs modèles sont utilisés comme source. - Mappings d'abstraction. C'est la transformation inverse. Elle permet une meilleure compréhension du code (reverse engineering), ou la migration d'une plate-forme vers une autre. II.2.4.2 Mappings horizontaux On distingue trois sortes de mapping horizontaux : - Mappings de représentation : on l'utilise pour passer d'un format à un autre, le second disposant de plus d'outils de manipulation et de représentation. Peu utile si les formats de modèles ne sont pas réversibles. - Mappings d'optimisation, pour améliorer la performance. - Mappings de reconstruction, pour améliorer la maintenance et la lisibilité du code. 88

Les mappings sont réalisés soit par des règles générales, soit par corrélation, c'est à dire par appariement de propriétés du modèle source avec des propriétés des modèles cibles. II.2.5 Etapes D application De MDA Un certain nombre d'étapes et de transformation sont identifiables dans un processus MDA (voir la figure suivante): [30] Figure II.5: étapes d application de MDA. Cette figure montre que les transformations de base sont les suivantes: modélisation, transformation intermédiaires, génération de code. II.2.5.1 Modélisation C'est une étape préalable. Elle se fait en utilisant les outils conceptuels d'uml (Unified Modeling Language). Elle aboutit à un ensemble de modèles de la future application, représentés par des diagrammes de classes. Chaque domaine fonctionnel de l'application est représenté indépendamment des autres. A partir de ces diagrammes de classes UML, des modèles manipulables sont générés (au format XMI). II.2.5.2 Intégration Plusieurs modèles sont utilisés pour la création d'une application. Typiquement, il s'agit de modèles représentant des fonctionnalités différentes. Ils sont assemblés en un seul modèle, qui représente l'application, et sont à partir de là manipulables comme un unique modèle. 89

Ils existent deux méthodes d intégration de modèles : Intégration par assemblage, et intégration par marquage. II.2.5.3 Transformation A partir de modèles génériques, il s'agit de préciser ce que sera l'application : format de données, réalisation des fonctionnalités. Le(s) modèle(s) de l'application sont donc complétés, affinés. Typiquement, il s'agit à ce niveau là de transformer un méta-modèle (modèle de modèle, qui indique les contraintes que doit respecter l'application), en modèle fonctionnel, dotés de services particuliers. Il peut également s'agir de transformer un modèle fonctionnel indépendant de l'application (PIM Platform Independant Model) en modèle prenant en compte les contraintes de déploiement (PSM - Platform Specific Model). II.2.5.4 Génération de code Lorsque le modèle est complet, le code est généré. L'application peut alors être déployée. Dans la pratique, le code généré doit être complété : l'implémentation des différentes méthodes, par exemple, n'est pas explicitée dans le modèle. En cas d'extension ultérieure du modèle, il est indispensable de disposer d'un environnement de développement qui conserve le code ajouté. Si ce n'est pas le cas, le développement incrémental est rendu beaucoup plus laborieux, et la création de grandes applications est compromise. II.2.5.5 Stockage et accès Les modèles peuvent être réutilisés pour le développement d'autres applications, mais ils sont également accessibles par les applications elles-mêmes. La spécification MOF (Metadata Object Facility) permet de définir des bases de données de modèles accessibles de manière transparente par les applications. II.2.6 Avantages Et Inconvénients De MDA Dans cette partie, nous avons pu tirer les principales caractéristiques de MDA, comme étant une initiative d OMG qui dessine le cycle de développement sous forme d une chaine de transformations appliquées, indépendamment des plateformes, sur des modèles pour mener enfin à l implémentation des applications. Ainsi, MDA présente des avantages qui sont significatif aux partenaires d'affaires et aux développeurs : [32] : - Coût réduit tout au long du cycle de vie d'application 90

- Temps de développement réduit pour de nouvelles applications - Qualité améliorée d'application - Rondement plus élevé de l'investissement en technologie - Intégration rapide de nouvelles technologies dans les systèmes existants Cependant MDA présente certains inconvénients qui sont, principalement, en relation avec le degré de maitrise des transformations de modèles. Ainsi, le problème exact c est comment conserver les aspects sémantiques lors de ces transformations de modèles d un niveau d abstraction vers un autre ou entre plusieurs formats. Malgré ces inconvénients, MDA reste un choix important pour faire face aux enjeux de développement et d intégration des applications, parce qu elle permet d aborder la conception d applications indépendamment des plates-formes de développement avant de penser à leurs implémentations. C est pour cette raison que nous avons opté pour l application de l approche MDA pour l intégration web, ce qui sera entamé dans la troisième partie de notre mémoire. II.3 DESCRIPTION DE NOTRE DEMARCHE II.3.1 Les grandes étapes de notre approche MDA Afin d élaborer un méta modèle d intégration web, selon une approche MDA, nous parcourons les étapes suivantes : - Elaboration des modèles PIMs pour les technologies d intégration web : les services web, SOA et les mashups, - Intégration de ces modèles dans un modèle PIM globale pour obtenir un métamodèle d intégration web qui fait l objet de notre travail, - Vérification de ce méta modèle, en termes de non redondance des concepts et de complémentarité, - Mise en place de notre méta modèle, en générant un modèle PIM pour un cas d utilisation au moyen d un outil MDA. Bien que notre objectif principal focalise sur l élaboration d un méta-modèle d interopérabilité entre les technologies d intégration web (ce qui représente la première étape de l approche MDA), nous avons pensé à avancer plus dans le cycle de développement MDA, dont l objectif est de mettre en place notre méta-modèle, en le 91

projetant sur un cas d utilisation spécifique. Ces différentes étapes sont schématisées dans la figure II.6, et seront détaillées respectivement dans les quatre sections suivantes. Modèle d intégration de SOA Modèle d intégration de Service Web Modèle d intégration de Mashups Intégration Méta Modèle globale d intégration Web Vérification Méta Modèle d intégration Web vérifié Instanciation Modèle conceptuel pour un cas d utilisation. Transformations Modèles d implémentation Figure II.6: Approche d application de MDA pour l intégration web. 92

II.3.2 Schéma détaillée des différentes transformations de modèles MOF Instanciation Instanciation Instanciation M3 Modèle d intégration de SOA Modèle d intégration de Service Web Modèle d intégration de Mashups Intégration Méta Modèle global d intégration Web Conversion M2 PIMs Profil UML d intégration Web Conversion Modèle graphique (Boite à outil) Instanciation Modèle conceptuel pour un cas d utilisation Intégration Modèle Spécifique à une plateforme M1 PSMs Modèles d implémentation Finition Implémentation finale M0 Figure II.7: Schéma détaillée des différentes transformations de modèles. 93

Ce schéma illustre les différents modèles (PIMs et PSMs) utilisés, leurs niveaux d abstraction (M0, M1, M2 et M3) selon l architecture MOF, ainsi que transformations appliquées sur ces modèles. Pour cela, nous avons utilisé l outil MDA : «Entreprise Architect», qui sera présenté brièvement dans la section suivante. II.4 APERÇU SUR L OUTIL MDA UTILISÉ : «ENTREPRISE ARCHITECT» L organisation «Sparx Systems» s est engagée pour le développement et l évolution d un support MDA dans son outil de modélisation basé sur UML 2.1 : Enterprise Architect (EA). EA fournit un nombre d outils de développement orienté MDA, incluant un moteur de transformation des PIMs aux PSMs, permettant de générer de multiples modèles PSMs à partir d un modèle PIM et de mettre à jours le PSM en fonction des changements du PIM. Couplé avec une Template de génération de code, les Profils UML, les modèles UML, et les Frameworks, EA fournit une plateforme MDA extensible et solide. La figure suivante illustre le logo, la page de démarrage, et autres fenêtres d Enterprise Architect : [31] Logo Explorateur de projet EA Boites à outils Fenêtre de démarrage / modélisation Explorateur de ressources Figure II.8: interface de l outil Enterprise Architect. II.5 DESCRIPTION DES MODELES PIMs D INTEGRATION WEB Dans la première étape, nous avons conçu trois modèle PIMs qui concernent respectivement les services web hybrides, SOA et les Mashups. Ces modèles sont construis à partir des modèles génériques que nous avons évoqués dans la première partie du mémoire. Ces modèles sont décrites dans les trois sections suivantes. 94

II.5.1 Modèle D intégration Des Services Web Le modèle d intégration d une architecture de services web hybrides repose sur quatre concepts clés (voir la section I.3.3 : Architecture de services web) : service web, message, ressource web et sécurité. Une architecture de services web hybrides comprend un ou plusieurs services web qui permettent d exposer les fonctionnalités d une entreprise, d une manière indépendante. Sur le plan d intégration, un service web ce n est enfin qu une ressource web. Les communications entre les services web et les autres applications sont assurées par l intermédiaire des messages (SOAP par exemple). Le concept de sécurité est prévu pour protéger les services web contre différents risques et attaques lors de leur utilisation et pour garantir une certaine qualité de service. Le modèle d intégration des services web hybrides est résumé dans la figure suivante : Figure II.9: modèle d intégration des services web. II.5.2 Modèle D intégration Des SOAs Concernant le modèle d intégration d une SOA, il se construit principalement sur le concept «service» qui a son origine du paradigme «orienté service» (Voir la section I.3.1 : paradigme orienté service). Dans le but de respecter l un des principes de base de SOA qui est «le faible couplage des services», le concept «service» est éclaté en deux concepts : «service fournisseur» et «service demandeur». Le concept «service 95

fournisseur» signifie un service qui est en position d offrir une fonctionnalité, alors que le concept «service demandeur» désigne un service qui réclame une fonctionnalité. Enfin, et dans le but de satisfaire le principe de découverte de services, SOA prévoit un autre concept aussi important qui est «le catalogue» (service registry). Ce dernier permet de décrire et publier les services fournisseurs pour qu ils soient découverts et utilisés par les services demandeurs. Ce modèle d intégration de SOA est résumé dans la figure suivante. Figure II.10: modèle d intégration de SOA II.5.3 Modèle D intégration Des Mashups Une architecture de mashups se base sur trois concepts de base : «mashup», «composant de mashup» et «ressource web». Le concept «mashup» signifie une application composite et le concept «composant de mashup» désigne l unité élémentaire qui participe dans la composition d un mashup. Le concept «ressource web» représente tout élément accessible et utilisable par une application web. En plus, une architecture de mashups permet de couvrir tous les points d accès web au moyen des trois concepts «présentation», «données» et «fonctionnalité» qui sont des extensions du concept «ressource web». Le concept «données» est en relation de généralisation avec les deux concepts: «données XML» et «flux de données XML». Enfin, les concepts «service web» 96

et «API» permettent d étendre le concept «schématise le modèle d intégration des mashups. fonctionnalité». La figure suivante Figure II.11: modèle d intégration des mashups. Dans la section suivante, nous décrirons la procédure d intégration des modèles d intégration de services web, SOA et mashups, pour obtenir un méta-modèle global d intégration web. II.6 INTEGRATION DES MODELES PIMs D INTEGRATION WEB II.6.1 Procédure D intégration Des Modèles PIMs Dans cette étape, nous avons appliqué la technique d intégration par assemblage des trois modèles décrits dans les sections précédentes. Ainsi, nous avons pris en compte les concepts communs entre ces modèles et nous avons établi les liens nécessaires entre les concepts d un modèle avec leurs analogues dans les autres modèles. D un coté, nous avons opté pour la relation entre le concept «service» et le 97

concept «service web» pour assembler le modèle de SOA avec celui des services web hybrides. D un autre coté, nous avons exploité le concept «service web» et le concept «ressource web» pour mettre en relation le modèle de mashups avec le modèle de services web hybrides. Enfin, les trois concepts «service», «service web» et «ressource web» forment le réseau des concepts qui permet de relier d une manière explicite le modèle de SOA avec celui des mashups. Par conséquent, les concepts «système d intégration web» «SOA», «architecture de services web hybrides», «mshups», «service», «catalogue», «service web», «message», «sécurité» et «ressource web» forment le réseau de concepts qui constitue le cœur d un méta-modèle global d intégration web. Ce dernier fait l objet de la section suivante. II.6.2 Description Du Meta-Modèle D intégration Web Elaboré Au cours de l intégration des modèles de services web, de SOA et de mashups, nous avons pris en compte les considérations suivantes : - Le concept «système d intégration web» permet de décrire d une manière abstraite un système qui favorise l échange de contenu entre plusieurs applications de services web, SOAs ou de mashups ; - Le concept «service web» généralise le concept «service» (et pas l inverse!), parce qu on est dans le cadre du domaine web qui reconnait la technologie de service web comme meilleur moyen permettant de supporter les principes du paradigme orienté service et les caractéristiques de l architecture SOA concernant le concept «service». Par contre, le concept «service web» peut dépasser les principes du paradigme orienté service ; - Le concept «service web» c est le même que se soit dans une architecture de services web hybrides que dans une architecture de mashups ; - Les deux concepts «SOA» et «architecture de service web hybrides» sont des concepts abstrais que nous avons ajoutés pour qu ils forment avec leur analogue, le concept «mashups», les éléments de base d un «système d intégration web». Le méta-modèle d intégration web obtenu est schématisé par la figure suivante : 98

Figure II.12: méta-modèle global d intégration web. En dotant ce dernier méta-modèle avec des enrichissements concernant certains concepts clés, à savoir «service web», «ressource web», «message» et «sécurité», nous obtenons une version détaillée du méta-modèle d intégration web élaboré qui sera présentée dans la section II.8. II.6.3 Vérification Du Méta-Modèle Elaboré La vérification de notre méta-modèle passe par deux étapes : - La vérification de la non redondance des concepts ; - La vérification de complémentarité ; II.6.3.1 Vérification du non redondance des concepts L objectif de cette étape est de vérifier la non redondance des concepts dans le méta-modèle global. Pour cela nous avons distingué entre le concept «service» issu du modèle de SOA et le concept «service web» issu des modèles de services web et de 99

mashups. En plus nous avons séparé entre le concept «fonctionnalité» issu du modèle de mashups et le concept «service web» issu du modèle de services web. Enfin, nous avons vérifié que chaque concept dans le modèle global a une sémantique différente de celles des autres concepts. II.6.3.2 Vérification de Complémentarité La vérification de complémentarité sert à vérifier la capacité de notre méta-modèle de couvrir, d une manière complémentaire, certains aspects sémantiques concernant l intégration web, à savoir : - Le méta-modèle supporte plusieurs paradigmes de développement d applications : orienté objet, orienté service, orienté composant. - Le méta-modèle prend en compte tous les types des ressources web au moyen des concepts «présentation», «donnée», et fonctionnalité», - Le méta-modèle supporte le cycle de développement traditionnel et le cycle de développement Ad Hoc, en permettant la génération de modèle conceptuels d une manière rapide et planifiée ou non planifiée, - Le méta-modèle supporte le développement et la maintenance de nouvelles applications et leur intégration avec les applications existantes, - Le méta-modèle reflète les aspects statiques (la structure) et les aspects dynamiques (le comportement, la communication, les interactions) d un système d intégration web, - Ce méta-modèle permet de participer plusieurs environnements hétérogènes pour la résolution des problèmes d intégration web, à savoir : environnement de mashups, environnement SOA, etc.) II.7 GENERATION D UN PIM SPECIFIQUE POUR UN CAS D UTILISATION II.7.1 Choix D un Cas D utilisation L objectif de cette étape est de montrer la possibilité d instancier des modèles conceptuels spécifiques à un certains cas d utilisation. Pour cela, nous avons choisi un cas d utilisation qui nécessite la contribution de plusieurs technologies d intégration web d une façon complémentaire. En plus, nous avons fais recours à l outil MDA «Enterprise Architect» qui supporte les transformations de modèles jusqu à la génération de code source pour une plate-forme spécifique. Au cours de cette étape, nous avons opté pour le cas d utilisation décrit par le modèle suivant : [33] : 100

Figure II.13: cas d utilisation Buyer, Seller, CreditAgency et Shipper. Ce cas d utilisation consiste en un système de commerce simple qui inclut les quatre acteurs suivants : Buyer (client), Seller (vendeur), CreditAgency (Agence de crédit), Shipper (transporteur). Avec les approches classiques, chaque partenaire conçoit et implémente, à sa manière, son propre système. Après, le problème de l interopérabilité sera résolu au niveau technologique. Avec l approche MDA, les modèles conceptuels et d implémentation seront générés à partir du méta modèle d intégration web. Ainsi, dans le but de générer un modèle PIM spécifique pour ce cas d utilisation à partir de notre méta modèle, nous sommes passés par la transformation de ce dernier en un profil UML (voir la section ciaprès) qui sera utilisé ultérieurement pour instancier le modèle PIM spécifique II.7.2 Génération D un Profil UML A Partir Du Méta-Modèle La transformation du méta-modèle en un profil UML est prise en charge par l outil «Enterprise Architect», en générant des «stéréotypes» à partir des différentes classes du méta-modèle. Ces «stéréotypes» sont figurés sous formes de balises dans un fichier XML. Le profil UML obtenu est apparu dans la figure suivante sous forme de fichier XML. 101

Figure II.14: profil UML d intégration web, sous forme de fichier XML. 102

Maintenant ce profil UML est prêt à être réutilisé pour instancier des modèles PIMs spécifiques à n importe quel système qui exploite les technologies d intégration web : SOA, services web et mashups. Dans la section suivante, nous explorerons un exemple sur la génération d un PIM spécifique à notre cas d utilisation simplifié de commerce électronique. II.7.3 Génération D un PIM Spécifique A Partir Du Profil UML Dans cette étape, nous avons supposé que chaque acteur (sauf le client) dispose de son propre SOA qui prend en charge la gestion de son métier. Les acteurs échangent des informations entre eux par l intermédiaire des interfaces de services web. Bien que ces services web soient hétérogènes, ils forment ensemble une architecture de service web hybrides. Concernant le client, nous avons envisagé qu il puisse consulter des informations concernant les offres des autres acteurs en utilisant des mashups qui sont accessibles sur internet. Ainsi, l architecture de ce système d intégration web spécifique à notre cas d utilisation est composée des éléments suivants : - Trois SOAs pour les trois acteurs : Buyer, Seller, CreditAgency et Shipper ; - Une architecture de services web hybrides contenant les services web servant comme interfaces d échange d informations entre les acteurs, - Deux mashups qui permettent de présenter les offres des deux acteurs : Seller et CreditAgency. Afin de concrétiser la génération d un modèle PIM spécifique à ce système, nous avons importé le profil UML qui est généré dans l étape précédente. Cela permet en fin de compte de transformer le profil UML en une boite à outil qui sera utilisée pour l instanciation du modèle PIM spécifique à notre cas d utilisation. Ce modèle est illustré dans la figure II.15. 103

Figure II.15: modèle PIM spécifique au cas d utilisation 104

Enfin, ce modèle PIM spécifique peut être transformé, d une manière semi automatique, en un modèle PSM (spécifique à une plate-forme comme java,.net, CORBA, etc.). Cela doit passer par la spécification de la plate-forme souhaitée pour que l outil MDA puisse générer le modèle PSM. Ce dernier sera complété manuellement pour générer le code source final. A ce niveau là, nous avons utilisé une version simplifiée de notre méta-modèle, dont l objectif est d expliquer notre démarche. Dans la section suivante, nous proposerons une version détaillée de notre méta-modèle, en passant par la description des différents modèles utilisés. II.8 VERSION DETAILLEE DU META MODELE ELABORE Dans cette section, nous visons à élaborer une version générique plus détaillée de notre méta modèle. Pour cela nous avons utilisé des versions détaillées qui correspondent aux différents modèles utilisés dans les sections précédentes. L objectif de cette étape est d obtenir un méta modèle assez complet qui couvre des détailles en relation avec les technologies d intégration web concernées par notre étude. Ainsi, nous présenterons au premier lieu les modèles d intégration des services web, de SOA et des Mashups en leurs versions détaillées, puis nous les intègrerons dans un schéma globale qui représente un méta modèle (générique) d intégration web en version plus détaillée. Dans ces modèles génériques, chaque concept sera représenté par un rectangle contenant son désignation. Ainsi, chaque relation sera représentée par une flèche orientée (entre le concept source et le concept destinateur) étiquetée par sa désignation. Par la suite, nous commenterons brièvement ces concepts et ces relations. II.8.1 Versions détaillées Des Modèles D'intégration Des Services Web Comme ce que nous avons signalé précédemment, ce modèle repose sur les quatre modèles suivants: Modèle orienté message, Modèle orienté service, Modèle orienté ressource, Modèle orienté sécurité. II.8.1.1 Modèle orienté message Le modèle orienté message focalise sur les aspects en relation avec les messages et leur traitement. Spécifiquement, dans ce modèle, on n est pas concerné à aucune signification sémantique du contenu du message ou bien ces relations avec les autres messages. Cependant, ce modèle focalise sur la structure des messages, sur les relations 105

entre l expéditeur et le récepteur du message, et sur la façon de transmission des messages. Ce modèle est illustré dans la figure suivante : Figure II.16: modèle orienté message de l architecture de services web. Les concepts de ce modèle sont expliqués dans le tableau suivant : Concept Définition «Address» : c est l information requise au mécanisme de transport de Address message pour délivrer un message à son destinateur. «delivery policy» : c est le mécanisme de sécurité qui définit des Delivery Policy contraintes sur les méthodes par lesquelles les messages sont délivrés par le mécanisme de transport de message. «message» : c est l unité de données de base émise par un agent de Message service web à un autre. «message body» : c est la structure qui représente le contenu principal, Message Body spécifique à l application, que l expéditeur de message veut le délivrer au destinateur. 106

Concept Définition «Message correlation» : c est l association d un message à un contexte. Il Message assure que l agent demandeur peut lier une réponse à la demande, Correlation spécifiquement dans le cas où plusieurs réponses sont possibles. Message «message envelope» : c est la structure qui encapsule les parties qui Envelope composent le message : «message body» et «message headers». «Message Exchanage Pattern» (MEP) : permet de décrire un modèle Message générique d échange de messages entre les agents. Il décrit des relations Exchange (de temporisation, de causalité, de séquensement, etc) entre des Pattern (MEP) messages échangés conformément au modèle, en plus, la terminaison normale ou anormale d échange de n importe quel message. Message «message header» : c est la partie de message qui contient des Header informations sur des aspects spécifique au message. Message «message receiver» : c est un agent qui reçoit le message Receiver «Message reliability» : c est le degré de certitude que le message soit Message délivré et que l expéditeur et le récepteur aient la même compréhension de Reliability l état de livraison. Message «message sender» : c est l agent qui transmet le message. Sender Message «message sequence» : c est la l enchainement de plusieurs messages en Sequence relation les uns avec les autres. Message «Message Transport» : c est le mécanisme qui peut être utilisé par les Transport agents pour délivrer les messages. Tableau II.1: définitions des concepts du modèle orienté message. II.8.1.2 Modèle orienté service Ce modèle se concentre sur les aspects qui concernent les services et les actions. Le premier objectif est d expliquer les relations entre un agent et les services fournisseurs et demandeurs. Ce modèle se base sur le modèle orienté message, mais focalise sur l action plutôt que le message. Ce modèle est illustré dans la figure suivante : 107

Figure II.17: modèle orienté service de l architecture de services web. Les concepts de ce modèle sont illustrés dans le tableau suivant: Concept Définition «action» : c est n importe quel action qui peut etre accompli par un agent, Action possiblement le résultat de la réception d un message, ou le résultat d envoi d un message ou bien un autre changement d état observable. «agent» : c est un programme qui représente une personne ou une Agent organisation. Il correspond à la notion des agents logiciels. «choreography» : défini la séquence et les conditions dans lesquelles Choreography plusieurs agents coopérants échangent des messages dans le but d accomplir une tache. «capability» : c est une partie d une fonctionnalité bien déterminée qui est Capability déclarée offerte ou demandée par un agent. «goal state» : c est l état de quelque services ou ressources qui sont Goal State désirables par une personne ou une organisation. 108

Concept Définition Provider «provider agent» : c est un agent qui est capable d accomplir des actions Agent associés avec un service au nom de son propriétaire. Provider «provider entity» : c est la personne ou l organisation qui fournit un service Entity web. Requester «requester agent» : c est l agent logiciel qui interagit avec l agent Agent fournisseur pour demander une tache au profil de son propriétaire. Requester «requester entity» : c est le personne ou l organisation qui veut utiliser le Entity service web du fournisseur «Provider Entity». «service» : c est une ressource abstraite qui montre la capacité d accomplir des taches qui représente une fonctionnalité cohérente du point Service de vue de l entité demandeur et de l entité fournisseur de service. Pour qu il soit utilisé, il doit être réalisé par un agent fournisseur concret. Service «service description» : c est un ensemble de documents qui décrivent Description l interface et la sémantique d un service. «service interface» : c est la frontière abstraite exposée par un service. Service Elle défini les types et les modèles d échange des messages qui sont Interface impliqués dans l interaction avec le service. Service «service intermediary» : c est un service web dont les messages sortants Intermediary sont équivalents aux messages entrants. «service role» : c est un ensemble de taches définies par une personne ou Service Role une organisation offrant un service. «service semantics» : c est le comportement attendu lors de l interaction Service avec un service. La sémantique exprime un contrat entre le fournisseur et Semantics le demandeur du service. Elle exprime les effets réels de l invocation d un service. «service task» : c est une action ou une combinaison d actions associée Service Task avec l objectif désiré. l accomplissement d une tache implique l exécution des actions, et est attendu pour achever un objectif particulier. Tableau II.2: définitions des concepts du modèle orienté service II.8.1.3 Modèle orienté ressource Le modèle orienté ressource focalise sur les aspects en relation avec les ressources. 109

Une ressource est un concept fondamental pour le Web et particulièrement pour les services web, par exemple, un service web est un type particulier de ressources. Ce modèle concentre sur les aspects relatifs au concept ressource, indépendamment de son rôle dans le contexte de services web, à savoir le propriétaire d une ressource, la sécurité d une ressource. Ce modèle est illustré dans la figure suivante : Figure II.18: modèle orienté ressource de l architecture de services web. Les concepts de ce modèle sont illustrés dans le tableau suivant: Concept Discovery Discovery Service Identifier Définition «Discovery» : c est l acte de localiser une description, traité par machine, d une ressource en relation avec un service web, qui est inconnu auparavant et réuni certains critères fonctionnels. Cela implique la correspondance entre un ensemble de critères fonctionnels ou autres avec un ensemble de descriptions de ressources. «discovery service» : c est un service qui active des agents pour récupérer des descriptions d une ressource liée à un service web. «identifier» : c est un nom non ambigu pour une ressource. Representation «representation» : c est une partie de données qui décrie l état d une ressource. 110

Concept Définition «resource» : c est tout ce qui peut avoir un identifiant. L architecture de service web n est concernée que par les ressources en relation avec les services web. Ainsi, elles ont certaines caractéristiques additionnelles. En Resource particulier, elles incorporent les concepts de propriétaire et de contrôle. Le propriétaire c est celui qui peut être connecté avec le droit de sécuriser cette ressource. «resource description» : c est une collection de données lisible par machine qui permet aux ressources d être découvertes. La description Resource d une ressource peut prendre plusieurs formes, personnalisées pour de description buts spécifiques, mais elle doit contenir un identificateur de ressource «ressource identifier». Tableau II.3: définitions des concepts du modèle orienté ressource II.8.1.4 Modèle orienté sécurité Ce modèle s occupe des aspects en relation avec la sécurité et la qualité de service. La sécurité concerne principalement des contraints sur le comportement en action et sur l accès aux ressources. Similairement, la qualité de service adresse également des contraints sur le service. Ce modèle est représenté dans le schéma suivant : Figure II.19: modèle orienté sécurité pour une architecture de services web. 111

Les concepts de ce modèle sont expliqués dans le tableau suivant : Concept Définition «audit guard» : c est un mécanisme utilisé de la part du Audit Guard propriétaire pour surveiller les actions et les agents afin de vérifier la satisfaction des obligations. «domain» : c est un ensemble défini d agent et/ressourecs qui sont Domain sujet aux contraints d un ou plusieurs mécanismes de sécurité. «obligation» : c est un type de mécanismes de sécurité qui prescris Obligation des actions et/ou des états d un agent et/ou d une ressource. «permission» : c est un type de mécanismes de sécurité qui Permission prescris des actions et/ou des états alloués à un agent et/ou une ressource. «permission guard» : c est un mécanisme déployé de la part du Permission Guard propriétaire pour mettre en vigueur les permissions. Person or «person or organization» : c est le propriétaire des agents qui Organization fournissent ou demandent des services web. «policy» : c est une contraint sur le cmportement d agents, de Policy personnes ou d organisations. «policy description» : c est description, compréhensible par la Policy Description machine, pour un plusieur mécanismes de sécurité. «policy guard» : c est un mécanisme qui mis en vigueur un ou Policy Guard plusieur mécanismes de sécurité. Il est déployé de la part du propriétaire. Tableau II.4: définitions des concepts du modèle orienté sécurité II.8.2 Version Détaillée Du Modèle D'intégration SOA Dans ce modèle, nous avons juste introduit le concept «service description», en le reliant avec le concept «service» par la relation «hase», et avec le concept «service registry» par la relation «contains». Ce modèle est illustré dans la figure ci-après. 112

SOA contains contains contains Service requestor is contains discover Exchange messages Service registry publish Service provider is Service description Service has Figure II.20: modèle d intégration d une SOA. II.8.3 Version Détaillée Du Modèle D'intégration Des Mashups Dans ce modèle, nous avons introduit des détailles concernant la communauté des mashups qui est classifiée en trois classes d «agents» : «consomer» (consomateur), «intermediary» (intermédiaires) et «provider» (fournisseurs). Ces derniers concepts sont reliés respectivement avec le concept «composant» par les relations : «consume» (consomme), «monitor» (surveille) et «provide» (fournit). Ainsi, le concept «consumer» est relié avec le concept «intermediary» par la relation «discover» (dicouvrir ), et le concept «provider» est associé avec le concept «intermédiary» par la relation «publish» (publier). Ce modèle est illustré dan le schéma suivant : isconnected is is Agent Consumer consume A discover monitor Intermediary Component is Mashup contains is widget is Presentation Data is publish Provider provide is contains Ressource is is Function Figure II.21: modèle d intégration des mashups. 113

II.8.4 Description de quelques relations entre les concepts Cette section définit quelques relations qui apparaissent dans les modèles, mais elles ne sont pas spécifiques aux différentes architectures. Cependant, elles sont définis dans le tableau suivant pour éclaircir leurs utilisation dans les différents modèles. Relation Définition is La relation «X is a Y» signifie que tout X est aussi un Y. describes La relation «Y describes X» signifie que Y est une expression, telle que les valeurs de Y sont des instances de X. has La relation «X has a Y» signifie que n importe quel instance de X est associée avec une instance de Y owns La relation «X owns Y» signifie que X a le droit et l autorité de controler, utiliser et se dispose de Y. realized La relation «X is realized as Y» signifie que X c est une abstraction de Y, c-à-d : X est implémenté en utilisant Y. Tableau II.5: définitions de certaines relations utilisées dans les différents modèles II.8.5 Version Détaillée Du Méta-Modèle Global D'intégration Web Ce méta modèle est obtenu en passant les mêmes étapes parcourus pour élaborer le méta modèle dans sa version simplifiée, en remplaçant les différents modèles intégrés par leurs versions détaillées. Dans le but d éviter l encombrement des relations entre les concepts et d assurer la lisibilité du méta modèle globale, nous avons préféré de garder la redondance des concepts communs entre les différents modèles intégrés, en les reliant par des relations non étiquetées (vides). Le résultat obtenu est illustré dans la figure suivante : 114

Figure II.22: version détaillée d un modèle d intégration web. (Voir la page suivante en format plus grand). 115

II.9 CONCLUSION Finalement, nous avons pu adapter une démarche MDA que nous avons présentée dans la deuxième partie (section II.7). Cette adaptation consiste dans l instanciation d un PIM spécifique pour un cas d utilisation à partir d un méta-modèle globale. Pour cela, nous avons fait un autre passage qui sert à générer un profil UML à partir de notre métamodèle, dont l objectif est de produire une boite à outil qui permet d instancier le modèle PIM spécifique. Il est à signaler que notre méta-modèle est construit à partir des modèles des technologies d intégration web (service web, SOA et mashups), après leur adaptation et leur assemblage dans un modèle global. Les difficultés que nous avons rencontrées, pour concrétiser notre démarche, sont : le choix d un cas d utilisation et le choix d un outil MDA, parce que le cas d utilisation doit demander le couplage de ces trois technologies, et l outil doit supporter tous les transformations prévues dans un ordre bien défini. 116

CONCLUSION GENERALE En résumé, notre travail se positionne dans le domaine d intégration web. A ce propos, nous l avons abordé par une étude d état de l art sur ce domaine qui a fait l objet de la première partie du mémoire. A travers cette étude d état de l art menée au cours de la première partie, nous avons pu connaitre les raisons pour les quelles la communauté de développement s est orientée vers l intégration web pour faire face aux enjeux d intégration d applications d entreprises. En plus, elle nous a permis d explorer les principaux concepts des technologies d intégration web qui ont connu un grand succès, à savoir: les services web, SOA et les mashups. Enfin, nous avons décelé les enjeux de l intégration web, surtout les problèmes de : l interopérabilité, le temps, la maintenance et le coût de développement. Cela nous a poussés à penser à une démarche qui permet de remédier à ces problèmes. Cette démarche consiste en une approche de développement appelée MDA (Model Driven Architecture). Cette dernière c est une initiative proposée par OMG qui repose sur une série de transformations appliquées sur des modèles, permettant de générer le code source à partir d un modèle initial. La dédite approche a fait l objet du premier chapitre de la deuxième partie. Dans ce chapitre, nous avons donné un aperçu général sur la démarche MDA, en discutant les principaux aspects de cette initiative. Ainsi, nous avons vu qu elle repose sur des transformations de modèles durant tout le cycle de développement des applications. Cette étude de la démarche MDA nous a permis de dégager ses différents avantages qui sont significatifs aux profils de développeurs et de partenaires d'affaires, à savoir: la réduction du coût tout au long du cycle de développement d'application, la réduction du temps de développement pour de nouvelles applications, l amélioration de la qualité d'application, l augmentation de l indice de rondement sur investissement en technologie, et l accélération de l intégration de nouvelles technologies dans les systèmes existants. Par conséquent, nous avons constaté que MDA fournit un Framework solide qui libère les infrastructures de systèmes pour évoluer indépendamment des plates-formes. Il permet de définir des stratégies d'intégration de systèmes qui sont meilleures, plus rapides et moins chères. Cependant, MDA présente certains inconvénients qui sont, principalement, en relation avec le degré de maitrise des transformations de modèles. 117

Ainsi, le problème exact c est comment conserver les aspects sémantiques lors de ces transformations de modèles d un niveau d abstraction vers un autre? Malgré ces inconvénients, MDA est considéré comme une bonne alternative pour remédier au problème de l interopérabilité entre les applications, parce qu elle permet d aborder la conception d applications indépendamment des plates-formes de développement avant de penser à leurs implémentations. C est pour cette raison que nous avons opté pour l application de l approche MDA pour élaborer un méta-modèle d intégration web, ce qui a été entamé dans la suite de la deuxième partie de notre mémoire. Finalement, nous avons pu adapter une démarche MDA que nous avons présentée dans la deuxième partie (section II.2.5). Cette adaptation consiste en l instanciation d un PIM spécifique pour un cas d utilisation à partir d un méta-modèle globale. Pour cela, nous avons fait un autre passage qui sert à générer un profil UML à partir de notre métamodèle, dont, l objectif est de produire une boite à outil qui nous a permis d instancier le modèle PIM spécifique. Il est à signaler que notre méta-modèle est construit à partir des modèles d intégration des technologies web (service web, SOA et mashups), après leur adaptation et leur assemblage dans un modèle global. Les difficultés que nous avons rencontrées, pour concrétiser notre démarche, se résument dans les deux points suivants : le choix d un cas d utilisation et le choix d un outil MDA, parce que, d un coté, le cas d utilisation doit demander le couplage et la contribution de ces trois technologies, et d un autre coté, l outil MDA doit supporter toutes les transformations prévues dans un ordre bien défini. Concernant les perspectives à notre travail, nous les avons projetées sur deux axes : le premier vise le domaine d intégration web, hors que le deuxième axe cible la démarche MDA, elle-même. Pour le domaine d intégration web, nous avons envisagé d étudier le problème de la sécurité dans les applications d intégration web, dans la mesure où il a été traité séparément par le biais du modèle orienté sécurité de l architecture de services web. Ce dernier prévoie des mécanismes pour la sécurisation des ressources, des actions et des messages. Cependant, l introduction des principes orientés service peut avoir un impact sur les mesures de sécurité offertes par ce modèle. A ce propos, il est nécessaire de proclamer, à titre d exemple, l influence du principe de couplage faible des services sur la QoS (qualité de service), dans la mesure où il implique une augmentation d échanges de messages, ce qui est traduit par une perte de temps surtout dans les applications distribuées. 118

Sur le volet de la démarche MDA, nous avons envisagé de penser à des définitions formelles des transformations de modèles qui supportent la réutilisation, la composition, l évolutivité, la flexibilité (l adaptabilité) des modèles. Cela, doit passer par : - Premièrement, une définition formelle adéquate d un modèle, - Deuxièmement, une classification des transformations de modèles, afin de spécifier les particularités de chaque classe de transformations, - Troisièmement, spécification de la nature des modèles qui forment les entrées et les sorties de chaque classe de transformations, - Finalement, définition des formalismes pour l automatisation de ces transformations. 119

ANNEXES A. APERÇU SUR LE PARADIGME ORIENTE SERVICE 1) Principes du paradigme orienté service Les principes du paradigme orienté service sont résumés dans les points suivants :[11] Les services sont réutilisables : indépendamment des opportunités de leurs réutilisation immédiate, les services sont conçus pour soutenir une réutilisation potentielle. Un service partage un contrat formel: pour que les services agissent les uns sur les autres, ils n'ont besoin de partager qu'un contrat formel qui décrit chaque service et définit les limites d'échange de l'information. Les services sont faiblement couplés : les services doivent être conçus pour agir les uns sur les autres d'une manière indépendante. Un service peut abstraire la logique fondamentale: la seule partie d'un service qui est visible au monde extérieur est ce qui est exposé par l'intermédiaire du contrat de service. La logique fondamentale, au-delà de ce qui est exprimé dans le contrat, est invisible et non pertinente aux demandeurs de service. Les services sont composables : Les services peuvent composer d'autres services. Ceci permet à la logique d application d'être représentée aux différents niveaux de granularité et favorise la réutilisabilité et la création de couches d'abstraction. Les services sont autonomes : La logique régie par un service réside dans une limite explicite. Le service a le contrôle dans cette limite et ne dépend pas d'autres services pour qu'il exécute son fonctionnalité. Les services sont apatrides (sans état) : Les services devraient réduire au minimum la quantité de l'information d'état qu'ils contrôlent et la durée dans laquelle ils la tiennent. L'information d'état c'est une donnée spécifique à une activité courante. Si un service est responsable de maintenir l'état pendant de plus longues périodes, sa capacité de rester disponible à d'autres demandeurs sera diminuée. Les services sont découvrables : Les services devraient permettre à leurs descriptions d'être découvertes et comprises par les humains et les demandeurs de services qui peuvent se servir de leurs logiques. 120

Dans la section suivante, on présente une comparaison entre le paradigme orienté service et le paradigme orienté objet. 2) Le paradigme orienté service vs le paradigme orienté objet Ceux qui se sont familiarisés avec l'analyse et la conception orientée objet auront reconnu probablement une similitude entre un certain nombre de principes du paradigme orienté service discutés et les principes du paradigme orienté objet. Le paradigme orienté objet et le paradigme orienté service ne sont pas nécessairement des paradigmes concurrentiels. Le paradigme orienté service a clairement plusieurs racines dans le paradigme orienté objet, et les solutions orientées services contemporaines typiques se composeront d'un mélange de services (qui adhèrent aux principes orientés service) et les composants orientés objet. Donc, chaque ensemble de principes peut être correctement utilisé pour compléter et supporter l'autre ensemble de principes. Le tableau suivant fournit un aperçu général sur les liens entre les principes du paradigme orienté objet et les principes du paradigme orienté service que nous avions discutés. [11] Principes orientés service Réutilisabilité de service contrat de service Couplage faible de service Abstraction de service Principes du paradigme orienté objet relatifs L'Orienté Objet est adaptée à la création de classes réutilisables. Le principe de la modularité de l'orienté Objet a normalisé la décomposition comme un moyen de conception d'application. Autres principes relatifs, tels que l'abstraction et l'encapsulation, supportent davantage la réutilisation en exigeant la séparation entre l'interface et l'implémentation. La nécessité d'un contrat pour un service est très comparable à l'utilisation des interfaces lors du développement des applications orientées objet. Bien que la création des interfaces découple légèrement une classe de ses consommateurs, le couplage en général est l'une des qualités primaires du paradigme orienté service qui dévie du paradigme orienté objet. Le principe d'abstraction du paradigme orienté objet exige qu'une classe fournit une interface au monde externe et qu'elle soit accessible par l'intermédiaire de cette interface. L'encapsulation supporte ceci, où toute logique dans la classe en dehors de ce qu'est exposé par l'interface n'est pas accessible au monde externe. 121

Principes orientés service Composition de service Autonomie de service Apatridie de service Découverte de service Principes du paradigme orienté objet relatifs L orienté objet supporte des concepts d'association, tels que l'agrégation et la composition. Ceux-ci, dans un contexte faiblement couplé, sont également supportés par le paradigme orienté service. La qualité d'autonomie est plus soulignée dans la conception orientée service que dans le cas des approches orientées objet. Les dépendances d'héritage dans la conception orientées objet supportent un degré inférieur d'autonomie d'objet. Les objets se composent d'une combinaison de classe et de données et ont naturellement des états. La promotion de l'apatridie dans des services tend donc à dévier de la conception orientée objet. Bien qu'il soit possible de créer des services ayant des états et des objets apatrides (sans états), le principe de l'apatridie généralement est souligné davantage avec le paradigme orienté service. la conception d'une classe interface pour être consistante et autodescriptive c'est un autre principe orienté objet qui fournit un moyen pour identifier et distinguer les unités de traitement. Tableau III.1: liens entre les principes orientés objet et les principes orientés service 122

B. HISTORIQUE SUR LES ARCHITECTURES D APPLICATIONS 1) C est quoi une architecture? Depuis qu'il y a eu des solutions d'automation informatisées, l'architecture de technologie a existé. Cependant, dans des environnements plus anciens, la construction de la solution était si franche que la tâche d'abstraction et de définition de son architecture ait été rarement effectuée. Avec l'apparition d'applications à plusieurs tiers, les variations, avec lesquelles des applications pourraient être fournies, ont commencé à augmenter considérablement. Les départements d'it ont commencé à identifier le besoin d'une définition standardisée d'une application de base qui pourrait agir en tant que modèle pour tous les autres. Cette définition est abstraite en nature, mais a spécifiquement expliqué la technologie, les frontières, les règles, les limitations et les caractéristiques de conception qui s'appliquent à toutes les solutions basées sur ce modèle. C'était la naissance de l'architecture d'application. [11] 2) Architecture d'application L'architecture d'application est pour une équipe de développement d'applications ce qu est un plan pour une équipe de travailleurs de construction. Différentes organisations documentent différents niveaux d'architecture d'application. Certaines la maintiennent à haut niveau, fournissant les représentations physiques et logiques abstraites du modèle technique. D'autres incluent plus de détail, tel que les modèles de données, les organigrammes de flux de communications, les exigences de sécurité des grandes applications, et les aspects de l'infrastructure. [11] Une organisation peut avoir plusieurs architectures d'application. Un document simple d'architecture représente typiquement un environnement distinct de solution. Par exemple, une organisation qui loge des solutions de.net et de J2EE aurait très probablement des spécifications d'architecture d'application séparées pour chacune. [11] La partie fondamentale de n'importe quelle architecture d'application est celle qu'elle reflète les exigences immédiates d une solution, aussi bien que les buts stratégiques d'it à long terme. C'est pour cette raison que quand plusieurs architectures d'application existent dans une organisation, elles sont, presque toujours, accompagnées et alignées avec une architecture de gouvernement d'entreprise. [11] 123

3) Architecture d'entreprise Dans les grandes organisations, la nécessité de contrôler et diriger l'infrastructure d'it est critique. Si plusieurs architectures d'application hétérogènes coexistent et s'intègrent parfois même, les exigences vis-à-vis les plates-formes d'hébergement sousjacentes peuvent être complexes et onéreuses. Par conséquent, il est utile de créer des spécifications principales, fournissant une vue d'ensemble de haut niveau de toutes les formes d'hétérogénéité qui existent au sein d'une entreprise, aussi bien qu'une définition de l'infrastructure. Continuant notre analogie précédente, une spécification d'architecture d'entreprise est pour une organisation ce qu un plan urbain est pour une ville. Par conséquent, la relation entre un plan urbain et un plan d'un bâtiment sont comparable à celui des spécifications d'architecture d'entreprise et d'application. Typiquement, les changements aux architectures d'entreprise affectent directement les architectures d'application. De plus, les architectures d'entreprise contiennent souvent une vision à long terme de la façon dont l'organisation prévoit l évolution de sa technologie et ses environnements. [11] 4) Architecture client-serveur : une brève historique Les systèmes de mainframes monolithiques originaux qui ont permis aux organisations d'être sérieusement automatisées souvent sont considérés le premier commencement de l'architecture client-serveur. Ces environnements, dans lesquels des grandes mainframes servant des clients léger, sont considérés une implémentation de l'architecture client-serveur un tiers. Les systèmes de mainframes ont supportés nativement les communications synchrones et asynchrones. La dernière approche a été employée principalement pour permettre au serveur de recevoir sans interruption des caractères d un terminal en réponse aux différentes frappes. Seulement dans certaines conditions, le serveur répondrait réellement. La domination de mainframe comme première plate-forme de calcul a commencé à diminuer quand une variation «deux tiers» de la conception client-serveur a émergée vers la fin des années 80s. Cette nouvelle approche a introduit le concept de la délégation de la logique et des fonctions de traitement sur différents postes de travail. Encore supportés par l'innovation des interfaces utilisateurs graphique (GUI), l architecture client-serveur à deux tiers a été considérée comme un grand pas en avant, et a continué de dominer le monde d'it pendant les premières années 90s. La configuration commune de cette architecture s'est composée de multiples clients, chacun avec son propre connexion à une base de données sur un 124

serveur central. Le logiciel coté client a effectué la partie du traitement, y compris la présentation et la logique d'accès aux données. Un ou plusieurs serveurs ont facilité la tache de ces clients en hébergeant des Systèmes de Gestion de Base de Données Relationnelles (SGBDR) extensibles. [11] 5) Architecture distribuée d'internet : une brève historique En réponse aux coûts et aux limitations liées à l'architecture client-serveur à deux tiers, le concept de réalisation des applications à base de composants s'est apparu. Les architectures client-serveur multi-tiers ont apparu, divisant l'exécutable client monolithique en composants conçus à certaines mesures de conformité à l'orienté-objet. La logique de distribution d'application sur plusieurs composants (certains résidant au niveau du client, d'autres sur le serveur) a réduit le problème de déploiement en centralisant une plus grande partie de la logique sur des serveurs. Les composants coté serveur, maintenant placé sur des serveurs d'application dédiés, partageraient et contrôleraient des groupes de connexions de base de données, allégeant la charge d'utilisation concurrente sur le serveur de base de données. Une seule connexion a pu facilement prendre en charge plusieurs utilisateurs. Ces avantages sont venus au coût de la complexité accrue et ont fini par le décalage de l'augmentation des dépenses et de l'effort à partir des issues de déploiement vers les procédés de développement et d'administration. Réaliser des composants capables de traiter de multiples requêtes concurrentes était plus difficile que de développer un exécutable franc destiné à un utilisateur simple. En plus, le remplacement des connexions de base de données clientserveur était la connexion client-serveur "Remote Procedure Call" (RPC). Les technologies RPC telles que CORBA et DCOM ont permis la communication à distance entre les composants résidant sur des postes de travail clients et des serveurs. Les issues semblables aux problèmes d'architecture client-serveur comportant des ressources et des connexions persistantes ont émergé. En plus, était un effort accru de maintenance résultant de l'introduction de la couche d'intergiciel. Par exemple, les serveurs d'application et les moniteurs de transaction ont exigé une attention significative dans les grands environnements. [11] À l'arrivée du World Wide Web comme moyen viable pour la technologie de calcul dans la seconde moitié des années 90s, les environnements client-serveur multi-tiers ont commencé à incorporer la technologie d'internet. Le plus significatif était le remplacement du composant client du logiciel personnalisé avec le navigateur. Non seulement ce 125

changement a-t-il radicalement modifié (et limité) la conception d'interfaces d'utilisateurs, il a pratiquement décalé 100% de la logique d'application au serveur. [11] L'architecture distribuée d'internet a également introduis un nouveau tiers physique, le serveur web. Ceci a eu comme conséquence le remplacement des protocoles RCP par HTTP pour la communication entre le poste de travail d'utilisateur et le serveur. Le rôle du RPC a été limité à permettre la communication entre le Web et les serveurs d'application à distance. A partir des dernières années 90s au mi 2000s, les architectures distribuées d'internet ont représenté la plate-forme de calcul de fait pour les solutions personnalisées d'entreprise. L obtention des qualifications de programmation à base de composants et la sophistication croissante d'intergiciel ont éventuellement diminué une partie de la complexité globale. Puis, comment cette architecture populaire et familière se compare-telle avec SOA? Les sections suivantes contrastent l'architecture distribuée d'internet et les caractéristiques de SOA. [11] 6) Services web en tant qu'emballages de composants Le rôle principal des services web dans ce contexte a été d'introduire une couche d'intégration qui se compose de services d'emballage qui permettent une communication synchrone via des canaux d'intégration conformes à SOAP. En fait, la version initiale des spécifications SOAP et la première génération de serveurs SOAP ont été spécifiquement conçus pour reproduire une communication de modèle-rpc en utilisant des messages. Ces canaux d'intégration sont principalement utilisés dans des architectures d'intégration pour faciliter la communication avec d'autres applications ou avec des partenaires externes. Ils sont également utilisés pour permettre la communication avec d'autres solutions (orientées services) et pour profiter de certains caractéristiques offertes par des services Web à trois tiers. Indépendamment de leur utilisation ou leur but dans des architectures traditionnelles, il est important de clarifier qu'une architecture distribuée d'internet qui incorpore des services web de cette manière ne qualifie pas comme vrai SOA. C'est simplement une architecture distribuée d'internet qui utilise des services Web. Donc, l'utilisation des services web dans des architectures traditionnelles est complètement légitime. Grâce aux supports de développement des services web dans beaucoup de langages de programmation, ils peuvent être facilement adaptés avec des conceptions d'application plus anciennes. Pour les environnements existants qui ne supportent pas le développement de services web, des adaptateurs sont souvent disponibles. [11] 126

7) Architecture orientée service Simplement, l'architecture orientée services couvre les domaines d'architecture d'entreprise et d'application. Le potentiel d'avantage offert par SOA peut seulement être vraiment réalisé, quand elle est appliquée à travers plusieurs environnements de solution. Le terme «SOA» n'implique pas nécessairement une portée architecturale particulière. Un SOA peut se rapporter à une architecture d'application ou à une approche utilisée pour standardiser l'architecture technique dans l'entreprise. En raison de la nature composable de SOA, il est absolument possible qu'une organisation ait plus d'une SOA. [11] 127

C. HISTORIQUE : XML, SERVICES WEB, SOA Nous commençons cette section en couvrant l'historique des principaux développements qui ont émergé pour former la plate-forme courante de SOA. Nous prenons alors un regard à la façon dont l'émergence de SOA comme plate-forme architecturale a changé les rôles de XML et de technologies de services Web. [11] 1) XML Comme HTML, Extensible Markup Language (XML) était une création de W3C dérivée du Standard Generalized Markup Language (SGML) qui a existé depuis les dernières années 60s. Ce méta langage a permis aux organisations d'ajouter de l'intelligence aux données brutes. [11] XML a gagné la popularité pendant le mouvement de commerce électronique dans les dernières années 90s, où les langages de script, coté serveur, ont rendu le commerce viable par l'intermédiaire de l Internet. En utilisant XML, les développeurs pouvaient attacher un sens et un contexte à n'importe quelle information transmise à travers des protocoles d'internet. [11] N'est pas seulement XML qui a été utilisé pour représenter des données d'une façon standard, le langage lui-même a été utilisé comme base pour une série de spécifications additionnelles. XML Schema Definition Language (XSD) et XML Transformation Language (XSLT) étaient tous deux écrits en utilisant XML. Ces spécifications, en fait, ont devenue des parties fondamentales de l'ensemble de technologies XML. [11] L'architecture de représentation de données XML représente la couche de base de SOA. Dans laquelle, XML établit le format et la structure des messages transmis entre les services. Les schémas XSD préservent l'intégrité et la validité des données de message, et XSLT est utilisé pour permettre la communication entre les représentations de données hétérogènes par la mise en correspondance de schémas. En d'autres termes, XML est indispensable dans toute démarche SOA. [11] 2) Services web : En 2000, le W3C a reçu une soumission pour les spécifications du Simple Object Access Protocol (SOAP). Ces spécifications ont été à l'origine conçues pour unifier (et remplacer dans certains cas) la communication RPC. L'idée était pour paramétrer les 128

données transmises entre les composants afin de les sérialiser dans XML, les transporter, et puis les dé-sérialiser de nouveau dans leur format originaire. [11] Bientôt, les sociétés et les vendeurs de logiciels ont commencé à voir un grand potentiel pour avancer l'état de technologie de commerce électronique, en développant leurs propres environnements de communications libres sur Internet. Finalement, ceci a mené à l'idée de créer une technologie distribuée basée sur le WEB qui pourrait accroître le concept d'environnement standard de communications, pour faire face à l'énorme disparité qui existe entre et dans les organisations. Ce concept s'est appelé les services Web. [11] La partie la plus importante d'un service Web est son interface publique. C'est une partie centrale de l'information qui assigne au service une identité et permet son invocation. Par conséquent, une des premières initiatives des supports de services Web était le Web Service Description Language (WSDL). Le W3C a reçu la première soumission du WSDL en 2001 et a continué de mettre à jour ces spécifications. [11] Pour promouvoir la vision de l'interopérabilité ouverte, les services Web ont besoin de communications conformes à XML, qui pourraient établir un environnement standard pour la transmission de messages. Bien que des solutions alternatives, telles que XML- RPC, aient été considérées, le SOAP reste le premier standard de transmission de messages à utiliser avec les services Web. [11] Le complément de la première génération de la famille des standards de services Web était les spécifications UDDI. À l'origine développé par UDDI.org, elle a été soumise à l'oasis, qui a continué son développement en collaboration avec UDDI.org. Ces spécifications tiennent compte de la création des enregistrements normalisés de description de service aussi bien à l'intérieur qu'à l'extérieur des frontières d'organisations. UDDI fournit le potentiel pour que les services Web soient enregistrés dans un endroit central, d'où ils peuvent être découverts par des demandeurs de service. À la différence de WSDL et de SOAP, UDDI n'a pas encore atteint l'acceptation à l'échelle industrielle, et reste une prolongation facultative à SOA. [11] Des services Web personnalisés ont été développés pour s adapter à une série de conditions spécialisées d'affaires, et un tiers marché a émergé favorisant de divers services d'utilité à vendre ou à louer. Les plates-formes existantes de transmission de messages, telles que les produits Messaging Oriented Middleware (MOM), ont incorporé 129

des services Web pour supporter SOAP en plus d'autres protocoles de message. Quelques organismes pouvaient également incorporer immédiatement des services Web pour faciliter les conditions d'échange de données B2B, souvent comme alternative à EDI (Electronic Data Interchange). [11] 3) SOA : Il n'était pas longtemps que les organisations ont commencé à se rendre compte qu'au lieu d'adapter juste des applications distribuées existantes, les services Web pourraient devenir la base d'une plate-forme architecturale séparée qui pourrait accroître les avantages de l'ensemble de technologies de services Web pour réaliser le concept des services dans l'entreprise. Ainsi, l'architecture orientée services (SOA) est entrée au courant principal d'it. Une SOA a été fréquemment classifiée de différentes manières, souvent selon la technologie utilisée pour l'implémentation des services. Un premier modèle, principalement inspiré par l'ensemble initial des standards de services Web, a défini SOA comme une architecture modelée autour de trois composants de base : demandeur de service, fournisseur de service, et enregistrement de service. [11] La première génération des standards de services Web a accompli ce modèle de la manière suivante : [11] - WSDL permet la description du service, - SOAP permet de fournir le format de transmission de messages utilisés par le service et son demandeur, - UDDI permet de fournir le format standard d'enregistrement de service. Ce modèle primitif de SOA est facilement atteint aujourd'hui, car il est supporté par les plates-formes importantes de développement et d'exécution. Plusieurs caractéristiques de SOA, qui ont été présentées dans «la section I.5.3» sont le résultat du développement agressif et des initiatives de collaboration qui ont proposé une série d'extensions de la plate-forme de services Web de première génération. Connues sous les spécifications "WS-*" ou "de deuxième génération", ces extensions adressent des secteurs spécifiques de fonctionnalité avec le but global d'élever la plate-forme de technologie de services Web à un niveau d'entreprise. [11] 130

D. LISTE D ABREVIATIONS - AJAX: Asynchronous Javascript and XML - API: application programming interface - CIM : computation independant model - CORBA: Common Object Request Broker Architecture - CSS: Cascading Style Sheets - CWM : Common Warehouse Metamodel - DCOM: Distributed Component Object Model - DSL: Domain Specific Langage - DTD : Document Type Definition - DUNS : Data Universal Numbering System - HTML : Hypertext markup language - HTTP :Hypertext Transfer Protocol - ISO: International Organization for Standardization - JSON: JavaScript Object Notation - MDA : Model Driven Architecture - MOF : Meta-Object Facility - NAICS: North American Indestry Classification System - OMG : Object Management Group - PIM : Platform-Independent Model - PSM : Platform Specific Model - RDF: Resource Description Framework - REST:Representational State Transfer - RSS: Really Simple Syndication - RPC : Remote Procedure Call - SMTP : Simple Mail Transfer Protocol - SOA: Service Oriented Architecture. - SOAP : Simple Object Access Protocol - UDDI : Universal Description Discovery and Integration - UML : Unified Modeling Language - UN/SPSC: Universal Standard Product and Service Classification - URI : Uniform Resource Identifier - URL : Uniform Resource Locator - WSDL : Web Services Description Language - WS-*: Web Service Extensions - W3C: World Wide Web Consortium - XMI : XML Metadata Interchange - XML : Extensible Markup Language 131

BIBLIOGRAPHIE [01]: «Data Integration Is Key to Realizing the Full Potential of SOA», www.tibco.com/.../wp-data-integration-is-key-to-realizing-the-full-potential-ofsoa_tcm8-2446.pdf], décembre 2010. [02]: «Web Integration Technologies, Application and Benefits», www.redoaksw.com/ products /webclipper/redoak_webintegrationoverview.pdf. [03]: «An Introduction to Web-Integration Technology», White paper, www.attachmate.com/../050149_intro_web_integ_wp.pdf, 2006. [04]: Bertino, E., Martino, L., Paci, F., Squicciarini, A., «Security for Web Services and Service - Oriented Architecture», Springer, 2010. [05]: Salah Baina, Hervés Panetto, Khalid Benali, «Apport de l approche MDA pour l interopérabilité des systèmes d entreprises», Ingénierie des Systèmes d'information (ISI) 11/13, 2006, 11-29. [06]: Jean Bézivin, Xavier Blanc, «MDA : vers un important changement de paradigme en génie logiciel», Développeur Référence, http://www.devreference.net/../mda.partie1.jbxb.last.prn.pdf, Septembre 2002. [07]: Heinz Lothar Grob, Frank Bensberg, Blasius Lofi Dewanto, «Model Driven Architecture (MDA) : Integration and Model Reuse for Open Source elearning Platforms», http://eleed.campussource.de/../eleed - Model Driven Architecture (MDA) Integration and Model Reuse for Open Source elearning Platforms.mht, Mars 2005. [08]: Frank Truyen, «The Fast Guide to Model Driven Architecture, The Basics of Model Driven Architecture» www.omg.org/mda/mda_files/cephas_mda_fast_guide.pdf, 2006. [09]: Gable, Julie, «Enterprise application integration», http://www.bnet.com/../enterprise application integration Information Management Journal Find Articles at BNET.htm, Information Management Journal, Mars/Avril 2002. [10]: Jean-Marc Zuliani, Georges Abou Harb, «Les Web Services dans l EAI-BtoB : opportunité technique ou choix stratégique pour l intégration étendue?», White Paper, Centre de Compétences EAI, Juin 2003. [11]: Thomas Erl, «Service Oriented Architecture (SOA) Concepts, Technology, and Design», Prentice Hall PTR, 2005. 132

[12]: David Booth, Hugo Haas, Francis McCabe, Eric Newcomer, Michael Champion, Chris Ferris, David Orchard, «Web Services Architecture», www.w3.org/tr/wsarch/wsa.pdf, 2004. [13]: Elisa Bertino, LorenzoD.Martino, Federica Paci, Anna C.Squicciarini, «Security for Web Services and Service-Oriented Architectures», Springer, 2009. [14]: Guy Boulet, «Les applications pédagogiques des outils du Web 2.0», www.guyboulet.net/pages/docs/web20.pdf, 2008. [15]: Raymond Yee, «Pro Web 2.0 Mashups, Remixing Data and Web Services», apresse, 2008. [16]: «http://fr.wikipedia.org/wiki/application_composite», Août 2009, [17]: Shu-Wai Chow, «PHP Web 2.0 Mashups Projects», PACKT, 2007. [18]: Chris Korhonen, David Hassoun, John Crosby, «Creating Mashups with Adobe Flex and AIR», friendsofed, 2008. [19]: Nicole Carrier, Tom Deutsch, Chris Gruber, Mark Heid, Lisa Lucadamo Jarrett, «Etude de rentabilité des mash-ups d entreprise», ftp://ftp.software.ibm.com/software/fr/pdf/wp-mashuprentabilite-epw14002-frfr-00.pdf, 2008. [20]: ZDNet.fr, «Les mashups en entreprises: un concept complémentaire des SOA», http://www.convertigo.com/pdf/press/fr/zdnet.fr-mashup-060309.pdf, 2009. [21]: Pierre Tran, «Laissez-vous tenter parles mashups», 01INFORMATIQUE, Décembre 2008. [22]: Agnes Koschmider, Victoria Torres, Vicente Pelechano, «Elucidating the Mashups Hype: Definition, Challenges, Methodical Guide and Tools for Mashups», www.integror.net/mem2009/papers/paper14.pdf, 2009. [23]: Saman Zarandioon, Danfeng (Daphne) Yao, Vinod Ganapathy, «OMOS: A Framework for Secure Communication in Mashups Applications», Annual Computer Security Applications Conference, 2008. [24]: Martin Vasko, «Mashups Orchestration Revolution or Evolution?», http://www.infosys.tuwien.ac.at/teaching/courses/intappl/4_mashups.pdf, 2008. [25]: Anthony Bradley, «Reference Architecture for Enterprise 'Mashups'», http://liquidbriefing.com/pub/harmonia/industryanalysts/reference_architecture_for_e _151491.pdf, 2007. [26]: Lawton, G., «Web 2.0 Creates Security Challenges», IEEE Computer Society, pp.13-16, 2007. 133

[27]: Zou, J. and Pavlovski, Christopher J, «Towards Accountable Enterprise Mashups Services», IEEE Computer Society, pp. 205-212, 2007. [28]: Christian Bac, Nguyen Hong Quang, Nguyen Thanh Binh, «Mashing-up Forge Logicielle», http://www2.ifi.auf.org/rapports/tpe-promo13/tpenguyen_thanh_binh.pdf, 2008. [29]: Andreas Tolk, «Avoiding another green eliphent- A proposal for the next generation HLA based on the model driven architecture», www.omg.org/mda/mda_files/02f- SIW-004-OMG.pdf, 2002. [30]: Pierre Parrend, «Introduction à MDA: Principe», http://pparrend.ftpdeveloppez.com/tutoriel/mda-intro//mda-intro.pdf, décembre 2006. [31]: «MDA overview», http://www.omg.org/mda/mda_files/mda_tool-sparx- Systmes.pdf, 2007.* [32]: «Model Driven Architecture, Executive Overview», http://www.enterprisearchitecture.info/../web MDA.htm. [33]: Steve Ross-Talbot, Tony Fletcher, «Web Services Choreography Description Language: Primer», www.w3.org/tr/ws-cdl-10-primer/../web Services Choreography Description Language Primer.mht, juin 2006. [34] Jon Siegel, «Using OMG s Model Driven Architecture (MDA) to Integrate Web Services», Object Management Group, 2002. [35] Christian Emig, Karsten Krutz, Stefan Link, Christof Momm, Sebastian Abeck, «Model-Driven Development of SOA Services», http://en.scientificcommons.org/41501856, 2007. [36] «OMG Document, OMG Request For Proposal: UML Profile and Metamodel for Services (UPMS)», http://www.omg.org/docs/soa/06-09-09.pdf, 2006. [37] «Simon Johnston: UML 2.0 Profile for Software Services», IBM develperworks, http://www-128.ibm.com/developerworks/rational/library/05/419_soa, April 2005. [38] Volker Hoyer, Katarina Stanoevska-Slabeva, «Generic Business Model Types for Enterprise Mashup Intermediaries», Americas Conference on Information Systems (AMCIS) Proceedings, 2009, 134