La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Les Services Web Introduction Concepts fondamentaux Éléments darchitecture Université Paris 5 - M2 - 2007 Introduction Concepts fondamentaux Éléments darchitecture.

Présentations similaires


Présentation au sujet: "Les Services Web Introduction Concepts fondamentaux Éléments darchitecture Université Paris 5 - M2 - 2007 Introduction Concepts fondamentaux Éléments darchitecture."— Transcription de la présentation:

1 Les Services Web Introduction Concepts fondamentaux Éléments darchitecture Université Paris 5 - M Introduction Concepts fondamentaux Éléments darchitecture Université Paris 5 - M

2 Stratégie dentreprise Processus, modèles métier Système dinformation, applications Infrastructure (serveurs, réseaux…)

3 Larchitecture SOA Architectures orientées services (SOA) : Distribuées A base de composants interopérables Services autonomes et indépendants Accessibles via les technologies de lInternet Dynamiques, modulaires « Scallables »

4 Pourquoi les SOA ? Complexité grandissante des infrastructures Réduire le time to market : Promouvoir la réutilisation Réutiliser des services existants Use before buy, buy before build, build for reuse Évolution des interfaces Nouveaux types dapplications (BI, KM…)

5 Core Business Serveurs dapplications Composants Interfaces Mobile Vocal server Intranet Internet Web TV WS

6 Un héritage important… CORBA (OMG) protocole IIOP : Multi langages, multi plates-formes, multi vendeurs DCOM (Microsoft) : Multi langages, mono plate-forme, mono vendeur Java RMI (Sun + …) : Mono langage (Java), multi plates-formes DCE (OSF), DCST (MIT)… Principes issus de lapproche Objet Technologies dinteropérabilité issues du Net

7 Services Web Multi : Multi langages Multi plates-formes Multi vendeurs Format client-serveur contextuel Utilisation systématique du langage XML Transport sur HTTP, MOM (JMS), SMTP Spécification indépendante et ouverte (W3C)

8 Services Web Rien de nouveau au niveau des modèles … et de larchitecture Mais repose sur des standards (Internet, XML…) En devenir pour les couches hautes : Sécurité, workflow, transactions distribuées Processus métier

9 Caractéristiques des Services Web Accessibles via le Web Exportent une interface publiée en XML (WSDL) Localisables via un annuaire (UDDI…) Échangent des messages XML sur les protocoles classiques du Web Dynamiques : Liens tardifs, répartition dynamique de la charge…

10 Guerre des standards Enjeux : stratégiques, économiques et financiers… Organismes de normalisation : W3C, OASIS, WS-I, Nations Unies… Initiatives privées : Microsoft, BEA, IBM… Communauté Open Source : Apache AXIS, Open Office…

11 Schéma général darchitecture Processus métier (BPML, WSFL, XLANG…) Découverte / Localisation (UDDI) Description (WSDL) Echange de messages (SOAP) Transport (HTTP, HTTPR, SMTP, JMS…) Sécurité (XML Signature XML Encryption, XKMS…) Transactions (BTP, WS-Transaction…)

12 Mise en œuvre Annuaire Echange de messages (SOAP) Transport (HTTP, HTTPR, SMTP, JMS…) ServiceClient Recherche (UDDI) Publication (WSDL, UDDI) Lien (XML)

13 Exemples de plates-formes Apache AXIS (open source) Microsoft.Net IBM Web Services Architecture (WebSphere) Oracle Dynamic Services Sun ONE, NetBeans… BEA Web Services Architecture (WebLogic) IONA SilverStream, CapeClear…

14 Lespéranto des SI distribués Le langage XML Concepts fondamentaux Rappels Concepts fondamentaux Rappels

15 eXtensible Markup Language Sous-ensemble de SGML Plus généraliste, moins complexe… Orienté « Web » Recommandation du W3C (1996 XML 1.0) A la base de plus de 150 dialectes

16 XML et ses dialectes dérivés XML META DTD Schémas Parcours Transform. API XPath XLink XPointer XSL XSLT SAX DOM Interrog. XQL XQuery

17 Objectifs Utilisation sur le réseau Internet Lisible par un humain Description formelle et concise Support de plusieurs types dapplications Aisément manipulable par des programmes de gestion de contenus Compatibilité avec SGML

18 Le document XML Règles strictes de construction Document bien formé (well formed) Document valide (valid) Structures logique et physique Physique : structuré autour de la notion dentités Logique : structuré autour des notions : Déclarations, éléments, commentaires, instructions de traitement…

19 Structure du document XML Un prologue Des entités imbriquées, structurées hiérarchiquement Un élément racine unique Chaque élément : Nom, attributs (facultatifs) Contenu (des éléments ou du texte) Prologue

20 Le contenu dun document XML Balises (markup tags) : Attributs : D. Seret A. Seigneur Rappel Texte… Texte… Texte…

21 Les espaces de noms (namespaces) G é rer des proximit é s s é mantiques É viter les conflits de noms Espace de nom implicite

22 Valider un document : les DTD Document Type Definition Renforcer la puissance sémantique dun document Passer dun document bien formé à un document valide Exemple simpliste de DTD interne : <…

23 Exemple de DTD interne ]> Bonjour à tous Si les deux déclarations (internes et externes) sont utilisées, les déclarations internes sont prioritaires

24 Spécification du nombre doccurrences Symbole + : au moins une fois Symbole * : facultatif, peut apparaître plusieurs fois Symbole ? : au plus une fois Aucun symbole : une et une seule fois

25 Déclaration des attributs CDATA : données textuelles sans balises (v1|v2…) : liste de valeurs possibles ENTITY : entité déclarée dans la DTD ENTITIES : liste dENTITY ID : identificateur unique IDREF : référence à un ID IDREFS : liste de références à des ID NMTOKEN(S) : nom XML (élément ou attribut) NOTATION : notation déclarée dans la DTD

26 Déclaration des attributs #REQUIRED : valeur requise #IMPLIED : valeur facultative #FIXED " valeur " : valeur obligatoire et fixée Exemple complet contenant une erreur :

27 ]>

28 Limites des DTD Syntaxe non nativement XML 1.0 Typage faible, non évolutif : 10 types de données (datatypes) Pas de contrainte dintégrité de domaine "lélément doit contenir un entier compris dans lintervalle [0, 12,000]" Incompatibilité avec le typage fort propres aux langages et SGBD

29 Schémas XML Décrire la structure dun document et les types de données utilisées (classe -> instance) Structure des instances de documents : Cet élément contient les éléments XXX, lesquels contiennent dautres éléments… Types de données à associer aux éléments / attributs du modèle de document : Cet élément peut contenir un entier (integer) dans lintervalle [0, ]

30 Validation dun document XML Contrôle syntaxique Suntaxis : ranger ensemble, ensemble des caractères et mots significatifs du langage Rôle et disposition des mots dans une phrase Vocabulaire des DTD :

31 Contrôle grammatical Règles dassemblage et daccord des mots permettant à un langage dexprimer des idées Les erreurs de grammaire : Ordre du sens décriture Contre-sens Fautes daccord et de logique Utilisation des types et unités de mesure Validation dun document XML

32 Contrôle structurel Structure du langage, i.e., poupées russes en XML Contrôle des types de données Dissociation entre nom et type Impossible en XML 1.0 avec les DTD Possible avec les schémas XML Création de types indépendants Utilisation des types Validation dun document XML

33 Puissance sémantique des schémas 44 types de données en version 1.0 Création possible de nouveaux types : Extension / restriction de types existants "Le type Heure est basé sur le type string et doit respecter le design-pattern hh-hh, où h représente un chiffre (digit) » Notion densembles déléments (pas dordre) Syntaxe XML 1.0 native

34 Permettent de spécifier des contraintes dunicité : Portant sur le contenu dun élément Y compris entre portions de documents Permettent de définir des éléments null Permettent de décrire des règles et contraintes de substitution entre éléments Puissance sémantique des schémas

35 Conversion dune DTD simple CatalogueLivres en un schéma XML Conversion réalisée en mode « 1 pour 1 » Les éléments Titre, Auteur, Date, ISBN et Editeur contiendront des chaînes de caractères

36 Schéma CatalogueLivres Prologue…

37 Schéma CatalogueLivres Déclaration de lélément racine…

38

39 Éléments feuilles et fin de document

40

41 Typage fort Les schémas XML permettent de définir des types de données complexes

42 Éléments connecteurs Les éléments connecteurs permettent de décrire lordre et la fréquence dapparition des éléments dans les documents instances = même ordre = ou exclusif = tous les éléments doivent être utilisés, quel que soit leur ordre dapparition

43 Exemple un peu plus complexe

44 Restriction des types de base Dépend des « facettes » du type de base Exemple: le type string possède six facettes de restriction : pattern enumeration length minLength maxlength whitespace (preserve | replace | collapse)

45 Exemple de restriction simple

46 Exemple de restriction plus complexe

47 SOAP Simple Object Access Protocol

48 SOAP 1.2 Standard du W3C (origine : Microsoft) Protocole déchange de messages Véhicule du contenu au format XML Analogue à un protocole dobjets distribués Plusieurs éléments dans la spéc. : Enveloppe SOAP = représentation des msg Implémentation des échanges au dessus dun protocole Internet (binding) Implémentation native en HTTP Modèle de données en XML (encoding)

49 SOAP : en route vers la maturité Évolution rapide du standard Ancêtre : XML-RPC (www.xmlrpc.com/spec) SOAP 1.1 en mai 2000 (www.w3.org/…) Modèle de données supportant les entiers, réels, booléens, chaînes et dates Structures, tableaux, listes, pointeurs Un protocole basique : POST HTTP SOAP 1.2 en décembre 2002 Modularité et abstraction Séparation modèle de données de représentation en XML

50 Est-ce utile de connaître SOAP ? NON : Les API et outils le font pour nous Qui maîtrise parfaitement TCP-IP ? OUI : Savoir lire les messages permet de déboguer les applications Pour comprendre limplémentation profonde dun Service Web, un exemple dinteraction SOAP est très parlant

51 Messages SOAP Transmission unidirectionnelle (émetteur vers récepteur) Notion de routage : un message passe éventuellement par des récepteurs intermédiaires qui peuvent modifier son contenu Format prévoit des messages dédiés à la gestion des erreurs

52 Codage XML Espace de noms spécifique (préfixe env) Élément racine : env:Envelope En-tête : env:Header Corps : env:Body Envelope SOAP Header SOAP Body Header Field Body Field

53 En-tête SOAP Optionnel Plusieurs entrées dont le format nest pas spécifié par la norme Chaque entrée doit définir son espace de noms Permet détendre les mécanismes de base fournis pas SOAP (par exemple, WS-Security, WS-RP) Attributs facilitant le traitement des entrées Exemple : env:mustUnderstand 1 (true en SOAP 1.2) = le récepteur du message doit comprendre lentrée désignée 0 = élément optionnel pour lapplication réceptrice

54 Modèle de données SOAP propose un encoding au format XML de son modèle de données Lutilisation de cette traduction est facultative Mais il faut impérativement que lémetteur et le récepteur exploitent la même traduction Lencoding XML sappuie sur les schémas du W3C, étendus avec la notion de type composé

55 Le modèle RPC Lappel dune fonction (opération dans la terminologie WS) est décrite par un msg SOAP particulier Appel représenté par une struc (structure) : Nom = nom de la fonction Paramètre = champ de la structure Résultat représenté dans une structure 3 modes de passage des paramètres In : utilisé mais non modifié (appel seulement) In/out : utilisé et modifié (appel et réponse) Out : retour uniquement (réponse)

56 Exemple de requête HTTP POST ListeDUs HTTP/1.1 Host: Content-Type: text/html; charset=utf-8 Content-Length: 1250 SOAPAction: monAction MINT

57 Exemple de réponse HTTP/ OK Content-Type: text/html; charset=utf-8 Content-Length: 1250 XML Gestion de Projets J2ME Services Web

58 Pour ou contre SOAP ? Contre : Très volumineux et verbeux 10 fois plus gourmand quun appel binaire Protocole HTTP déconnecté peu adapté Ne couvre pas tout (garbage, regroupement de messages, passages par référence…) Pour : Réelle interopérabilité (Windows, Unix…) Souplesse (HTTP, SMTP…) Extensibilité native

59 WSDL Web Services Description Language

60 WSDL Standard du W3C (origine Ariba, IBM, Microsoft) Langage XML permettant de décrire les services Ensemble dopérations et de messages abstraits reliés (bind) à des protocoles et des serveurs réseaux Rôle semblable à lInterface Definition Language (IDL) de CORBA Description du service indépendante du langage et de la plate-forme de production

61 Vocabulaire WSDL Vocabulaire : : définition des types utilisés : Noms et types dun ensembles de champs (paramètres dun appel, valeur de retour…) : Ensemble dopérations (<=1 msg en entrée, n messages en sortie) : Liaison entre un et un protocole (SOAP, HTTP, MIME…) : Point dentrée comme combinaison dun et dune adresse sur le réseau : Collection de points dentrée

62 Document WSDL Un espace de noms : Préfixe : wsdl Elément racine : wsdl:definitions Enfants : wsdl:types (*) : les types de données wsdl:messages (*) : les messages échangés wsdl:porttype (*) : opérations wsdl:binding (*) : bindings wsdl:service (*) : Services Web

63 WSDL : Possibilité de définition de types faisant référence à de nouveaux types

64 WSDL :

65 WSDL : Types dopérations supportées : One-Way : le point dentrée reçoit un message Request-response : Le point dentrée reçoit un message et retourne un message corrélé Solicit-response : Le point dentrée envoie un message et reçoit un message corrélé Notification : Le point dentrée envoie un message de notification Les champs des messages constituent les paramètres (in, out, inout) des opérations

66 WSDL : >

67 WSDL : Exemple de binding sur HTTP

68 WSDL : Exemple de déclaration de service

69 Génération du code WSDL Tous les environnements de développement orientés SOA proposent des générateurs de code WSDL : A partir de modèles de déploiement, de source EJB… Parfois nécessaire de retoucher le code généré Attention à ne pas perdre la traçabilité ! Ces environnements proposent également des générateurs de squelettes de code permettant dexploiter des WS à partir de contrats WSDL (exemple : Axis WSDL2Java)

70 Un langage plutôt verbeux… Comme SOAP, WSDL parle beaucoup pour dire peu de choses… Exemple, lAPI du WS proposé par Amazon.com : lignes de code WSDL Pour 23 opérations (34 lignes de code Java) Engendre lignes de code Java avec WSDL2Java dAxis, dont lessentiel décrit les types et leur correspondance en Java)

71 UDDI Universal Description, Discovery and Integration

72 Pourquoi UDDI ? Origine : Ariba, IBM, Microsoft sociétés Créer un annuaire mondial de Services Web afin dautomatiser les communications entre sociétés tierces Fournir un identifiant unique et une description détaillée des composants (WSDL) UDDI définit un modèle de données (XML) et des interfaces SOAP pour lenregistrement et la localisation des WS

73 Principes opérationnels ISV Comité de standardisation … Définition des types de services et modèles de données Fournisseurs de Services Web Enregistrement des Services proposées Places de marché Moteurs de recherche Entreprises … Interrogation de lannuaire UDDI Assemblage des services, consommation Des services à travers le réseau Internet Types de services Services White pages Yellow pages Green pages UDDI WSDL

74 Principes opérationnels Pages blanches : Nom du fournisseur, contacts (noms, téléphones, sites web…), identifiant Pages jaunes : Catégories dentreprises (classification, taxonomie) Industrie, Produits/Services, localisation Pages vertes : Informations métier et techniques sur les services : Processus métier, description, information de binding…

75 API SOAP Recherche : find_business, find_service, find_binding… Recherche détaillée : get_businessDetail, get_serviceDetail… Publication : save_business, save_service, save_binding… Sécurité : get_authToken, discard_authToken…

76 Principes opérationnels Types de services Services White pages Yellow pages Green pages UDDI WSDL Client Appli. cliente Rechercher Stub WSDL WS 1 WS 2 WS 3 Publication Bind + appels métier

77 Une architecture en devenir

78 Gérer la sécurité Confidentialité : XML Encryption (W3C) – chiffrement WS-Security SSL Autorisation et authentification Intégrité (ACIDité) Non répudiation : XML Signature (W3C) SOAP SecExt (digital signature W3C)

79 Gérer les transactions Business Transaction (BT) : Transactions longues, multi-acteurs Gestion des incidents, interruptions, erreurs… Support de services transactionnels plus complexes que ceux fournis par les moniteurs transactionnels Résignation Gestion de timeout Processus discontinues

80 Gérer les transactions Plusieurs protocoles et propositions : Oasis BTP (consortium) Protocole XML dorchestration de TP longues, mode B2B UN 2PC flexible WS-T (Microsoft, IBM et BEA) Sappuie sur le protocole WS- Coordination Pourrait remplacer BTP

81 Gestion des processus métier Cœur de lactivité dune entreprise (modèle analytique issu de la théorie du signal) Il convient de les : Modéliser, Informatiser, Piloter, Administrer Tel est le rôle du BPM – Business Process Management

82 XLANG, WSFL, BPML… De nouveaux standards pour un langage formel de définition des processus métier Description formelle des modèles comportementaux Rester indépendant des modèles dimplémentation Prendre en charge les contraintes : Temps dexécution longs (dépassant les frontièrs de lentreprise) Gestion des erreurs et des exceptions

83 XLANG Origine : Microsoft Langage (XML) utilisé pour la description des processus dans BizTalk Server Forts liens avec WSDL : Processus XLANG = assemblage de WS, orchestrées (connecteurs Sequence, Switch, All, While…) Service XLANG = service WSDL + extension décrivant le comportement du processus (échanges successifs de messages)

84 WSFL Web Services Flow Language Origine : IBM Langage (XML) utilisé pour la description des processus dans MQSeries et WebSphere Forts liens avec WSDL Très proches de XLANG Mais extensions intéressantes : Modèles de transformation des données Détermination dynamique des participants

85 BPML Business Process Management Language Origine : BPMI.org Dialecte XML de description de processus Processus = flux de messages entre participants Applications, utilisateurs, WS… Fonctions étendues : Gestion des transactions (courtes et longues) Gestion des exceptions Nombreux connecteurs dorchestration Transformation des données

86 Conclusion

87 Une architecture en devenir - points forts Un modèle darchitecture prometteur Des fondements solides, déjà bien normalisés (XML, Schémas, SOAP, WSDL, UDDI) Une volonté marquée douverture et dindépendance technique Forte montée en puissance des outils pour les éléments fondamentaux

88 Une architecture en devenir - points faibles De nombreux éléments manquent pour généraliser le déploiement des WS Guerre des standards - BPM, sécurité… Encore trop peu doutils pour la partie BPM Un problème de taille : intégration des applications existantes (core business) La complexité de lensemble pénalise son adoption

89 Front Office Middle Office Back Office XML SOAP Business Obj Tech Obj FrameworkFront Services ODBC Call ODBC Response Legacy Call Legacy Response Legacy+ POST/GET HTTP HTML HTTP XML Databases

90 Middle Office Back Office Soap Call (XML) Soap Response (XML) XML Parser XSLT Oracle DB Stored Procedures PL/SQL COM object XSLT Pre-Processor MSXML3 SOAP ENCAPSULATION ODBC Driver COM object OPG Mainframe OPG 1 Bus Obj Tech Obj COM object COM object ODBC Call ODBC Response


Télécharger ppt "Les Services Web Introduction Concepts fondamentaux Éléments darchitecture Université Paris 5 - M2 - 2007 Introduction Concepts fondamentaux Éléments darchitecture."

Présentations similaires


Annonces Google