Architecture SOAcampus.hesge.ch/Daehne/CoursCTI2009/Presentation/ModuleI... · 2014. 10. 2. · Architecture SOA – Module IVa Connaissance et maîtrise des SI 4 Peter DAEHNE Cours

Architecture SOA – Module IVa

Connaissance et maîtrise des SI 1

Peter DAEHNE

Architecture SOA

Peter DAEHNE

Module IVa

Cours CTI – Printemps 2009 2Peter DAEHNE

Plan

Introduction.Évolution des systèmes d’information.Démarches d’intégration.L’approche SOA et ses objectifs.Les concepts.L’infrastructure.Standards, normes et protocoles.Conclusion.

Module IVa





Introduction

Agenda - 1 Module IVa


Introduction - 1

L’acronyme SOA a été inventé par le Gartner Group dès 1996.Objectif: décrire une nouvelle manière de concevoir et d’organiser les différents composants du SI de l’entreprise.SOA est un « buzz » actuel.

Module IVa




Introduction - 2

De la vision à la solution:

Module IVa

Raffinements successifs

Exemple signifiant concret exprimant un besoin

Enrichissement

Solution

Temps


Introduction - 3

L’organisation du SI a toujours été calquée sur celle de l’entreprise.Jusqu’aux années 1970, organisation compartimentée en silos fonctionnels:

Production, ventes, finances, etc.Fonctionnement indépendant.Applications informatiques monolithiques dédiées à la gestion de ces fonctions.

Module IVa




Introduction - 4

Dès la fin des années 1970, organisation matricielle.Des strates horizontales dont ajoutées àl’organisation verticale existante:

CRM, RH, Chaîne logistique (supply chain), etc.Les applications informatiques sont adaptées en conséquence.SI peu agile et rigidifié dans une matrice organisationnelle et fonctionnelle.

Module IVa


Introduction - 5

Aujourd’hui, organisation en réseau.Les composants sont couplés de façon lâche.Les unités fonctionnelles sont relativement indépendantes.Ce sont les besoins liés à ce nouveau type d’organisation qui sont à l’origine de l’architecture SOA.

Module IVa




Introduction - 6

Objectifs:Construire un SI flexible et agile;Au service de l’accomplissement du métier;Facilitant l’innovation;Réduisant les coûts.

Module IVa



Évolution des systèmes d’information





Évolution - 1

Jusqu’aux années 70-80: mainframeSite central;Applications monolithiques;Persistance, traitement et présentation forment un ensemble indissociable.

Haute disponibilité, intégrité des données.Système cohérent et fiable.Coûts d’acquisition et d’exploitation élevés.

Module IVa


Évolution - 2

Début des années 90: client / serveurPersistance gérée par le site central ;Présentation déportée sur les postes de travail;La localisation du traitement peut varier.

Système hétérocliteDéveloppement décentralisé sans gouvernance;Apparition sauvage d’applications transverses;Informations et règles de gestion dupliquées;Problèmes de déploiement des applications.

Module IVa




Évolution - 3

Vers 2000: les applications WebPartenaires et clients peuvent accéder àcertaines applications de l’entreprise;Intégration de ceux-ci aux processus métiers;Développement du commerce électronique.

L’entropie globale augmente.Les coûts (gestion, licences) diminuent.La sécurité devient un vrai problème.

Module IVa


Évolution - 4

BilanAucune entreprise n’a fait table rase à chaque changement technologique;Les parcs informatiques sont morcelés;Les applications communiquent peu ou pas;Les systèmes patrimoniaux (legacy) constituent souvent les fondations du SI.

Il faut organiser cette hétérogénéité pour en reconquérir la maîtrise.

Module IVa




Évolution - 5 Module IVa



Démarches d’intégration





Intégration - 1

Aucune démarche méthodologique sérieuse jusqu’au milieu des années 1990.Les applications sont organisées comme l’entreprise: en silos.Chaque silo est autonome et isolé en terme de:

Processus;Interface homme / machine;Base technique.

Module IVa


Intégration - 2

Problèmes:Pratiquement impossible de mettre en place des processus métier transversaux.Duplication d’objets et de règles métier.Double saisie.Évolutions difficiles à mettre en œuvre car:

Complexité de l’architecture;Variété de technologies (hardware et software).

Réutilisation de composants impossible.

Module IVa




Intégration - 3

Développement de connecteurs et de protocoles ad hoc au fur et à mesure de l’apparition des besoins.Développement et maintenance coûteux.Aucune vision des flux d’information pour une processus métier donné.Architecture accidentelle.

Module IVa


Intégration - 4

Intégration: cas de l’architecture accidentelle.

Module IVa




Intégration - 5

Une démarche d’intégration efficace devrait permettre aux applications de se connecter au système de façon indépendante.Dès le milieu des années 1990, les outils d’EAI proposent des solutions de ce type.EAI = Enterprise Application Integration.Une outil d’EAI est une sorte de « cœur »auquel les applications se connectent de façon indépendante.

Module IVa


Intégration - 6

Intégration: cas de l’EAI.

Module IVa




Intégration - 7

Fonctionnalités d’un EAI:Transport des données;Connexion entre applications;Transformation des données;Orchestration les processus;Services techniques:

Monitoring des données échangées;Annuaire des applications connectées.

Module IVa


Intégration - 8

Avantages:Architecture du SI simplifiée;Échange d’informations plus facile.

Inconvénients:Onéreux et paramétrage compliqué;Logique d’intégration propriétaire;Ne résout pas la problématique du silo;Single Point of Failure.

Module IVa




Intégration - 9

Autres approches: le tout intégréLes ERP du début des années 1990;Plate-forme technologique commune;Base de données centrale;Squelettes d’applications pré-implantées àconfigurer.

Les processus doivent parfois être adaptés au logiciel.Difficulté de prendre en compte l’existant.

Module IVa


Intégration - 10

Autres approches: l’urbanisation du SITransformer de façon continue le SI pour le simplifier durablement.Il s’agit principalement:

De définir un SI cible idéal en fonction de la stratégie de l’entreprise (et d’autres facteurs);De déterminer les étapes de la transformation du SI actuel pour atteindre la cible fixée.

Cette approche sera traitée en détail dans un autre module (Ch. Aïdonidis).

Module IVa





L’approche SOA etses objectifs



Approche - 1

SOA n’est pas une technologie.SOA est:

Une philosophie de conception indépendante de tout produit, technologie ou tendance;Un paradigme, une approche pour construire le système d’information informatisé;Qui s’appuie sur les processus métier de l’entreprise et sur le concept de service.

SOA définit un modèle d’interaction entre les composants du SI.

Module IVa




Approche - 2 Module IVa

SOA définit un style d’architecture du SI.L’objectif général est de faire évoluer le SI en évitant les écueils énoncés plus haut.Les composants logiciels sont connectés par un couplage lâche.Le style d’architecture:

Favorise la réutilisation des composants;Lutte contre le syndrome des silos.


Approche - 3

Comme déjà mentionné dans l’introduction, les objectifs de SOA sont donc:

Construire un SI flexible et agile;Au service de l’accomplissement du métier;Facilitant l’innovation;Réduisant les coûts.

Des études ont montré qu’un réel retour sur investissement pouvait être dégagé àmoyen terme [Ibm06].

Module IVa





Les concepts



Introduction.Service.Message.Annuaire des services.Granularité et typologie des services.Applications composites.

Les concepts - Plan Module IVa





Introduction

Les concepts - 1 Module IVa


Concepts / Introduction - 1 Module IVa

État de l’art actuel des réflexions menées sur la conception et le développement.L’écriture de logiciel est un problème de plus en plus complexe.Évolution de la réutilisation:

Sous-programme;Programmation modulaire;Programmation orientée objet;Programmation orientée composants.




Concepts / Introduction - 2 Module IVa

Élévation du niveau d’abstraction:De la réutilisation de code à celle de fonctionnalité;Solutions organisationnelles pour tenter de conserver la maîtrise du SI.

Le contexte a évolué:Systèmes distribués;Plateformes hétérogènes et interopérabilité;Internet et périphériques mobiles.



Service





Concepts / Service - 1 Module IVa

Le service est l’entité fondamentale.Unité fonctionnelle avec les propriétés:

Ensemble de fonctionnalités définies par une interface indépendante de la plateforme;Peut être localisé et invoqué dynamiquement;Est autonome et sans état.

Caractéristiques supplémentaires:Couplage faible, réutilisable, composable et performant.



Un service propose une interface de distribution,Basée sur un ensemble de composants métiers,Constitués d’objets implantant des méthodes de bas niveau.





ResponsabilitésObjet:

Implantation des traitements.Composant:

Modèle de composants proposé par les plateformes de développement utilisées.

Service:Mise à disposition des opérations;Protocole de communication pour l’accès.



InterfaceContrat que le service s’engage à satisfaire vis-à-vis de ses clients.Boîte noire.L’indépendance de la plateforme garantit …

… qu’un client quelconque …… écrit dans n’importe quel langage …… hébergé par n’importe quel système d’exploitation …… peut invoquer le service.





Localisation et invocation dynamiqueEffectués par l’entremise d’un annuaire.L’annuaire répertorie les services.Les clients peuvent l’interroger pour obtenir la référence d’un service sur la base d’un certain nombre de critères.D’un jour à l’autre, le service physique invoqué par une application peut changer.



Autonome et sans étatLe service ne gère donc aucun contexte.Une unique instance suffit, indépendamment du nombre de ses clients.Se distingue donc des composants usuels dont il existe autant d’instances que de clients qui consomment leurs fonctionnalités.





Couplage faibleNombre de dépendances et de relations explicites avec d’autres services minimisé.En cas de recours à un autre service, invocation par l’entremise de l’annuaire.

RéutilisableFonctionnalité suffisamment primitive implantée de façon générale.Brique élémentaire pour la construction d’applications complexes.



ComposableCaractéristique parente de la réutilisabilité.On peut construire de nouveaux services (services composites) en assemblant et coordonnant des services existants.

PerformantFondamental, car appelé à fonctionner dans le cadre d’une infrastructure nécessitant des ressources importantes.





FonctionnementSynchrone

Le code du client est interrompu dans l’attente du résultat fourni par le service.

AsynchroneLe code du client poursuit son exécution après l’invocation.Un protocole est défini pour spécifier comment le service indique qu’il a terminé sa tâche et comment se procurer les résultats.



Message





Concepts / Message - 1 Module IVa

Le message est l’entité de communication entre les clients et les services.Emploi

Invocation d’un service par un client.Retour des résultats au client par le service.Transmission des informations en entrée et en sortie.Coordination des activités de services composites.


Concepts / Message - 2 Module IVa

Indépendance de la plateformeL’interface est indépendante de la plateforme.Elle définit les messages qu’un service accepte et retourne.La technologie pour décrire les messages doit également être indépendante:

Des langages de programmation;Des systèmes d’exploitation.





Annuaire des services



Concepts / Annuaire - 1 Module IVa

L’intermédiaire entre clients et fournisseurs de services est l’annuaire des services.Caractéristiques:

Les fournisseurs publient les services:Enregistrement auprès de l’annuaire.Sous la forme d’une interface (contrat).

Les clients interrogent l’annuaire:Localiser et découvrir un service dont le contrat satisfait certaines contraintes.Dans le but de l’invoquer.





Pattern publish-find-bind-execute



Informations associées à un serviceVersion.Type (voir [Hef05]).Caractéristiques fonctionnelles.

Nom, paramètres, exceptions, pré-conditions.Chemin d’accès (URL).

Aspects non fonctionnels.Sécurité.Critères qualitatifs (temps de réponse moyen, …).Informations sémantiques.





Autres caractéristiques de l’annuaire:Adjonction dynamique et incrémentale de services ainsi que mise à jour en cours d’exécution du système.Élément clé du découplage de par son rôle d’intermédiaire entre fournisseur et client.Le client accède au service de façon indirecte et peut choisir ce dernier en fonction de critères répertoriés dans la description et connus du client qu’en cours d’exécution.



Granularité et typologie des services





Concepts / Typologie - 1 Module IVa

Granularité des servicesIl faut un bon niveau de granularité.Ne peut être obtenu qu’en effectuant une analyse métier.Les tâches métier identifiées guideront le découpage en différents services.Granularité trop faible: peu d’intérêt.Granularité trop forte: peu réutilisable.



Typologie des services





Service technique:Donne accès à une ressource technique donnée.

Messagerie, imprimante.Base de données relationnelle, EAI.

Est générique, c’est-à-dire lié à une catégorie de ressources.Granularité moyenne à forte.Réutilisabilité forte.



Service métier:Offre un ensemble cohérent de traitements métier.Exemple: vision client – un tel service permet d’obtenir

Les informations de base du client;L’état de ses comptes;La liste de ses commandes en attente;L’historique de ses relations avec l’entreprise;…





Service de persistance:Créer, rechercher, mettre à jour et supprimer de l’information des référentiels du SI.Associé à un objet métier racine (point d’entrée dans le système d’information).Pour lire ou écrire un objet métier racine, le service accèdera en général à plusieurs tables.Granularité faible.Réutilisation forte.



Service fonctionnel:Encapsule tout ou partie des règles de gestion et des traitements métier.Implante un ensemble de fonctions métier.S’appuie en général sur des services de persistance pour accéder aux informations métier dont il a besoin.Granularité moyenne à forte.Réutilisabilité moyenne à forte.





Service applicatif:Service de façade de haut niveau masquant aux applications composites concernées les services de bas niveau.Coordonne les appels aux services fonctionnels.Spécifique d’une application composite interactive (satisfait un besoin métier précis).Granularité forte.Réutilisabilité nulle.



Dépendance des services





Effectuer un bon découpage



Applications composites





Concepts / App. Composites - 1 Module IVa

Les services étant identifiés et définis, il faut les consommer.Dans une approche SOA, on définit un nouveau type d’applications:

les applications compositesCe sont des applications construites en composant des appels de services.Elles apportent la valeur ajoutée aux utilisateurs finaux du système.



On identifie principalement trois types d’applications composites:

Application composite interactive (impliquant une interaction avec un utilisateur).Processus métier.Système traditionnel (batch ou application).

Une application composite peut à son tour s’exposer sous la forme d’un service.





Processus métierL’ensemble des activités que l’entreprise doit réaliser pour traiter un événement métier.SOA: enchaînement automatisé de services.Appelé orchestration du processus et exécutépar le moteur BPM.L’orchestration décrit:

La logique de contrôle.Le flux de données internes du processus métier.



Topologie de déploiementClient lourd.

L’application composite réside sur le poste client.Elle élabore les vues en local.Elle appelle des services hébergés par des serveurs.





Client léger.L’application composite réside sur le serveur.Elle élabore les vues et les envoie à un moteur graphique distant: le browser.Technologie de pages Web dynamiques.



Client distant.L’application composite devient un service.Le client est un portail distant.Le portail utilise un protocole dédié pour le dialogue avec ce service.L’application composite transmet ses vues au portail.





L’infrastructure



Infrastructure - 1 Module IVa

SOA est un concept architectural.Il définit l’organisation du SI.Principes généraux:

Les fonctions métier sont encapsulées dans des services.Les fonctionnalités de ces services sont exposées via des interfaces:

Indépendantes de la plate-forme;Indépendantes du langage d’implémentation.





Principe généraux (suite):Interaction et interopérabilité des services par l’intermédiaire de l’échange de messages:

Indépendamment de la localisation des services dans un environnement distribué;Indépendamment du protocole de communication employé.

Implantation au moyen d’une infrastructure qu’on appelle Enterprise Service Bus.

Description du concept: [Gar02] et [Cha04].



L’ESB est avant tout un design pattern.Propose une couche d’abstraction pour implanter les principes généraux.Implantations possibles (3):

Message broker existantFournit la fonctionnalité d’échange de messages.Les autres éléments organisationnels sont réalisés au moyen de solutions ad hoc.





Implantations possibles (suite):Solution hybride en assemblant

Composants développés en interne.Composants open source.Composants commerciaux.

Solution logicielle complète spécifiqueCommerciale ou open source.

Critères de choix: [Ful06]Offres commerciales existantes: [Vol06]



ESB: épine dorsale de la plateforme SOA




(1) PortailsReprésentent une application composite interactive à l'usage des utilisateurs du SII.Plusieurs types peuvent être envisagés:

Application en ligne destinée au grand public.Application métier destinée aux employés.Portail à l’usage des partenaires commerciaux.

Ligne graphique unifiée.Single sign-on et personnalisation en fonction du rôle et du type d’utilisateur.




(2) ConteneurEncapsulation des fonctionnalités et des attributs non fonctionnels d’un service.Exposés par l’entremise d’une interface.Chargé de gérer l’échange de messages entre l’implantation technique du service et l’ESB.Outils pour gérer les transactions, la sécurité et la reconfiguration dynamique du service.Contrôle le fonctionnement et l’état interne du service.





(3) Annuaire des servicesChargé de la localisation et de l’invocation dynamique des services.Une description complète de ses fonctions a déjà été effectuée plus haut.



(4) Accès aux donnéesService technique distribué.S’appuie sur un moteur SQL et/ou XQuery.Permet la création de services de persistance pour les objets métier.Son rôle est d’abstraire les caractéristiques techniques de bas niveau.




Infrastructure - 10

(5) AdaptateurPermet d’exposer les applications existantes comme un service.Chargé d’effectuer la connexion entre l’application et le conteneur.Peut-être mis en œuvre pour n’importe quel type d’application écrite dans n’importe quel langage, moyennant un adaptateur ad hoc.L’ESB généralise ainsi l’EAI.

Module IVa



(6) Web-ServicesCandidats « naturels » à fonctionner dans le cadre de cette architecture.On considère souvent à tort que c’est l’unique réalisation possible du concept de service.Permet l’implantation de services ouverts qui peuvent transiter par le Web (http, ftp, smtp).Les échanges avec des partenaires externes (ex: e-commerce) s’en trouvent facilités.





(7) Applications J2EEUn adaptateur transforme le protocole et les messages de l’ESB dans le standard JMS.Souvent proposé en standard dans des solutions complètes en raison de la très large diffusion de J2EE et de sa portabilité naturelle.



(8) Moteur BPMResponsable de la chorégraphie des processus métier et de l'orchestration des services associés.Modélisation et exécution des processus sans avoir recours à du développement de code.What you model is what you run.Gère le suivi (contrôle, mesures, optimisation du flux des activités, alertes en cas de problème).





(9) & (10) Communication entre systèmesL’ESB peut communiquer par le réseau avec celui d’un autre système:

Les systèmes d’une même entreprise sont dispersés géographiquement.Cas de relations B2B.

Objectif: consommer ou fournir des services àl’autre système.La communication est assurée par un protocole standard de l’Internet (ou protocole propriétaire).



(11) Superviseur SOACollecte des informations sur les éléments matériels et logiciels de la plateforme.Identification et traitement des problèmes.Statistiques et reporting (amélioration continue).SAM (Service Activity Management):

On observe les services.BAM (Business Activity Management):

On observe les processus.





L’infrastructure est adaptée au support d’outils de workflow et de messagerie.

Ils sont intégrés au système sous forme de services ou de portails particuliers.

L’ESB – élément central de l’architecture:Technologies de tolérance de pannes.Il est impensable que le défaillance d’un composant bloque l’ensemble du système.



Chaîne de fabrication logicielle.Ensemble d’outils permettant de concevoir, modéliser, développer, déployer et tester les différents éléments:

Atelier de modélisation.Atelier de fabrication.Atelier d’assemblage et de déploiement.Atelier d’homolgation.Etc…

Les composants de cette chaîne sont choisis parmi les offres du marché les plus adaptées.





Standards, normes et protocoles



Standards - 1 Module IVa

L'infrastructure décrite est structurée en différentes couches de normes et de protocoles.Ceux-ci peuvent bien sûr être définis de façon propriétaire.La plupart d’entre eux sont standardisés:

W3C: World Wide Web ConsortiumOASIS: Organization for the Advancement of Structured Information Standards




Standards - 2 Module IVa

Protocoles réseau:HTTP [Htt99], FTP [Ftp85], SMTP [Smt01].

Représentation des messages:XML [Xml06].

Description des services et de leurs interfaces:WSDL [Wsd01].

Invocation des services et transport des messages:SOAP [Soa07], WS-I [Wsi07].

Découverte des services:UDDI [Udd04], WSIL [Wsl07].

Chorégraphie / orchestration des services:WS-BPEL [Wsb05].



Conclusion





Conclusion - 1 Module IVa

La mise en œuvre de SOA dans l’entreprise est un voyage, une stratégie planifiée sur plusieurs années (de 2-3 ans à 10 ans).Cette stratégie

Implique de faire évoluer le SII de l’entreprise.Implique de bouleverser la structure organisationnelle de l’entreprise.Doit reposer sur des objectifs précis et clairs en termes de gestion d’entreprise.[Hef04]: 6 approches pour effectuer cette (r)évolution.



La migration vers une architecture SOA ne peut être que graduelle.Elle implique des modifications fondamentales dans l’organisation de l’entreprise en général …… et de son département informatique en particulier !





Le chemin vers l'adoption de SOA n'est pas dépourvu d'embûches. Ce parcours du combattant est très bien illustré par la déclaration suivante:

« Après une phase d'adhésion, les entreprises passent souvent par une phase de désillusions puis un refondement qui conduit enfin à la sortie du tunnel, jusqu'à un plateau de productivité »

P. Maliverno, Gartner Group.



Lorsque la décision est prise et que la conversion philosophique a eu lieu se pose la question du choix technologique.

Les systèmes installés peuvent-ils évoluer ?Sont-ils frappés d’obsolescence ?Les vendeurs de solutions proposent-ils des produits en adéquation avec la stratégie ?L’architecture hardware est-elle adaptée au pas conceptuel envisagé ?Etc.





Aucun vendeur ne propose de solution magique clés en mains.La solution idéale est souvent un assemblage de produits.[Vol06]: étude de produits du marché.[Jon07]: une étude plus récente se basant sur des critères tels que visions businesset IT du produit, standards et maturité.


Merci de votre attention

Module IVa


Peter DAEHNE, Version 1.0, 09.03.2009

Bibliographie [Bon08] Pierre Bonnet, Jean-Michel Detavernier, Dominique Vauquier, Le système d’information

durable – La refonte progressive du SI avec SOA, Lavoisier, 2008, ISBN 978-2-7462-1829-1.

[Cha04] David A. Chappel, Enterprise Service Bus, O'Reilly, Juin 2004, ISBN 0-596-00675-6. [Fou08] Xavier Fournier-Morel, Pascal Grojean, Guillaume Plouin, Cyril Rognon, SOA, Le guide de

l’architecte du SI, 2e édition, Dunod, 2008, ISBN 978-2-10-051708-4. [Ful06] Larry Fulton, The Case For An Enterprise Service Bus, Forrester Research,

http://www.forrester.com/Research/Document/0,7211,40859,00.html, 12.12.2006. [Gar02] Gartner Group, Roy W. Schulte, Predicts 2003 : Enterprise Service Bus Emerge, 9.12.2002. [Hef04] Randy Hefner, Your Paths To Service-Oriented Architecture, Forrester Research,

http://www.forrester.com/Research/Document/0,7211,34813,00.html, 7.12.2004. [Hef05] Randy Hefner, A Taxonomy Of Service Types For SOA, Forrester Research,

http://www.forrester.com/Research/Document/0,7211,38105,00.html, 25.10.2005. [Ibm06] IBM Global Business Services : Nicole Baker, Rolando Franco, Maria Stein-Marrison, Service-

Oriented Architecture, A practical guide to measuring return on that investment, http://www-935.ibm.com/services/us/gbs/bus/pdf/g510-6320-soa-roi.pdf, 2006.

[Jon07] Steve Jones, SOA Vendor Ratings - Q1 2007, http://service-architecture.blogspot.com/2007/03/soa-vendor-ratings-q1-2007.html, 22 mars 2007.

[Mar07] Tiziana Margaria, Service Is in the Eyes of the Beholder, Computer, pp. 33-37, Novembre 2007, ISSN 0018-9162.

[Rou07] José Rouillard, Thomas Vantroys, Vincent Chevrin, Architecture Orientée Services – Une approche pragmatique des SOA, Vuibert, 2007, ISBN 978-2-7117-4868-6.

[Vol06] Ken Vollmer, Mike Gilpin, The Forrester Wave™ : Enterprise Service Bus, Q2 2006, Forrester Research, http://www.forrester.com/Research/Document/0,7211,38696,00.html, 30.06.2006.

Normes et standards (W3C : http://www.w3.org et OASIS : http://www.oasis-open.org) [Ftp85] International Engineering Task Force (IETF), File Transfer Protocol (FTP), RFC 959,

http://www.ietf.org/rfc/rfc959.txt, octobre 1985. [Htt99] W3C, Hypertext Transfer Protocol -- HTTP/1.1,

http://www.w3.org/Protocols/rfc2616/rfc2616.html, juin 1999. [Smt01] International Engineering Task Force (IETF), Simple Mail Transfer Protocol, RFC 2821,

http://www.ietf.org/rfc/rfc2821.txt, avril 2001. [Soa07] W3C, SOAP Version 1.2, http://www.w3.org/TR/soap, 27.04.2007. [Udd04] OASIS, UDDI Version 3.0.2, http://www.oasis-open.org/committees/uddi-

spec/doc/spec/v3/uddi-v3.0.2-20041019.htm, 19.10.2004. [Wsb05] OASIS, Web Services Business Process Execution Language Version 2.0, http://www.oasis-

open.org/committees/download.php/14616/wsbpel-specification-draft.htm, 1.09.2005. [Wsd01] W3C, Web Services Description Language (WSDL) 1.1, http://www.w3.org/TR/wsdl,

15.03.2001. [Wsi07] Web Services Interoperability Organization, WS-I Basic Profile Version 1.2, http://www.ws-

i.org/Profiles/BasicProfile-1_2(WGAD).html, 24.10.2007. [Wsl07] IBM, Web Services Inspection Language,

http://www.ibm.com/developerworks/library/specification/ws-wsilspec, Janvier 2007. [Xml06] W3C, Extensible Markup Language (XML) 1.0 (Fourth Edition), http://www.w3.org/TR/REC-

xml/, 29.09.2006.

Documents

Architecture SOAcampus.hesge.ch/Daehne/CoursCTI2009/Presentation/ModuleI... · 2014. 10. 2. · Architecture SOA – Module IVa Connaissance et maîtrise des SI 4 Peter DAEHNE Cours