Introduction Concepts fondamentaux Éléments d’architecture

Présentation au sujet: "Introduction Concepts fondamentaux Éléments d’architecture"— Transcription de la présentation:

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

2 Stratégie d’entreprise
Processus, modèles métier Système d’information, applications Infrastructure (serveurs, réseaux…)

3 L’architecture SOA Architectures orientées services (SOA) :
Distribuées A base de composants interopérables Services autonomes et indépendants Accessibles via les technologies de l’Internet 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 d’applications (BI, KM…)

5 Serveurs d’applications
Composants Core Business Interfaces Intranet WS Vocal server Web TV Internet Mobile

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 l’approche Objet Technologies d’interopérabilité issues du Net

7 Services Web Multi : Format client-serveur contextuel
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 l’architecture 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 d’architecture
XML Encryption, XKMS…) (XML Signature Sécurité Processus métier (BPML, WSFL, XLANG…) (BTP, WS-Transaction…) Transactions Découverte / Localisation (UDDI) Description (WSDL) Echange de messages (SOAP) Transport (HTTP, HTTPR, SMTP, JMS…)

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

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 L’espéranto des SI distribués Le langage XML
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
META Parcours Transform. API Interrog. DTD XPath XSL SAX XQL Schémas XLink XSLT DOM XQuery XPointer

17 Objectifs Utilisation sur le réseau Internet Lisible par un humain
Description formelle et concise Support de plusieurs types d’applications 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 d’entité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 Prologue

20 Le contenu d’un document XML
Balises (markup tags) : <nom_elem> Attributs : <img src="computer.gif" /> <?xml version="1.0"?> <note> <to importance="haute">D. Seret</to> <from>A. Seigneur</from> <heading>Rappel</heading> <body>Texte…</body> <body>Texte…</body> <body for=“GR” font=“Arial”>Texte…</body> </note>

21 Les espaces de noms (namespaces)
Gérer des proximités sémantiques Éviter les conflits de noms <espace_de_nom:element> <espace_de_nom:element xmlns:espace_de_nom="URI"> Espace de nom implicite <stylesheet xmlns=" <template match="Y"/> </stylesheet>

22 Valider un document : les DTD
Document Type Definition Renforcer la puissance sémantique d’un document Passer d’un document bien formé à un document valide Exemple simpliste de DTD interne : <?xml version="1.0"?> <!DOCTYPE hello SYSTEM "hello.dtd"> <…

23 Exemple de DTD interne <?xml version=1.0" encoding=UTF-8"?> <!DOCTYPE hello [ <!ELEMENT hello (#PCDATA)> ]> <hello>Bonjour à tous</hello> Si les deux déclarations (internes et externes) sont utilisées, les déclarations internes sont prioritaires

24 Spécification du nombre d’occurrences
Symbole + : au moins une fois Symbole * : facultatif, peut apparaître plusieurs fois Symbole ? : au plus une fois Aucun symbole : une et une seule fois <!ELEMENT elem1 (elem11, (elem12?, elem13)*)>

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 d’ENTITY 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 : <!ATTLIST elem attrib (vrai|faux) #REQUIRED> <!ATTLIST elem attrib (vrai|faux) "faux"> <!ATTLIST elem attrib ID #FIXED="A">

27 <. DOCTYPE journal [. <. ELEMENT journal (article+)>. <
<!DOCTYPE journal [ <!ELEMENT journal (article+)> <!ELEMENT article (titre, chapo, riviere, notes)> <!ELEMENT titre (#PCDATA)> <!ELEMENT chapo (#PCDATA)> <!ELEMENT riviere (#PCDATA)> <!ELEMENT notes (#PCDATA)> <!ATTLIST article auteur CDATA #REQUIRED> <!ATTLIST article editeur CDATA #IMPLIED> <!ATTLIST article date CDATA #IMPLIED> <!ATTLIST article edition CDATA #IMPLIED> <!ENTITY journal "Le Monde"> <!ENTITY editeur "XXX"> <!ENTITY copyright "Copyright 1998 XXX"> ]>

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

29 Schémas XML Décrire la structure d’un 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 d’autres é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 l’intervalle [0, ]

30 Validation d’un 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 : <! & * ? ELEMENT ATTLIST CDATA #REQUIRED #FIXED #IMPLIED… Vocabulaire des schémas : xs:element name xs:complexType xs:simpleType xs:extension base xs;sequence maxOccurs type xs:anyURI…

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

32 Validation d’un document XML
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 <xscomplexType name=‘‘t’’> Utilisation des types <xs:element name=‘‘e’’ type=‘‘t’’>

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 d’ensembles d’éléments (pas d’ordre) Syntaxe XML 1.0 native

34 Puissance sémantique des schémas
Permettent de spécifier des contraintes d’unicité : Portant sur le contenu d’un é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

35 Conversion d’une 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 <!DOCTYPE CatalogueLivres [ <!ELEMENT CatalogueLivres (Livre)*> <!ELEMENT Livre (Titre, Auteur, ISBN, Editeur)> <!ELEMENT Titre (#PCDATA)> <!ELEMENT Auteur (#PCDATA)> <!ELEMENT ISBN (#PCDATA)> <!ELEMENT Editeur (#PCDATA)> ]>

36 Schéma CatalogueLivres
Prologue… <?xml version="1.0"?> <xsd:schema xmlns:xsd= " targetNamespace= " xmlns=" elementFormDefault="qualified">

37 Schéma CatalogueLivres
Déclaration de l’élément racine… <xsd:element name=“CatalogueLivres"> <xsd:complexType> <xsd:sequence> <xsd:element ref=“Livre" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element>

38 <xsd:element name=“Livre">
<xsd:complexType> <xsd:sequence> <xsd:element ref=“Titre" minOccurs="1" maxOccurs="1"/> <xsd:element ref=“Auteur" minOccurs="1“ maxOccurs="1"/> <xsd:element ref="ISBN" minOccurs="1“ maxOccurs="1"/> <xsd:element ref=“Editeur" minOccurs="1“ maxOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element>

39 Éléments feuilles et fin de document
<xsd:element name=“Titre" type="xsd:string"/> <xsd:element name=“Auteur" type="xsd:string"/> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name=“Editeur" type="xsd:string"/> </xsd:schema>

40 <?xml version="1.0"?> <xsd:schema xmlns:xsd=" targetNamespace=" xmlns=" elementFormDefault="qualified"> <xsd:element name=“CatalogueLivres"> <xsd:complexType> <xsd:sequence> <xsd:element ref=“Livre" minOccurs="0" …"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name=“Livre"> <xsd:element ref=“Titre" minOccurs="1" maxOccurs="1"/> <xsd:element ref=“Auteur" minOccurs="1" maxOccurs="1"/> <xsd:element ref="ISBN" minOccurs="1" maxOccurs="1"/> <xsd:element ref=“Editeur" minOccurs="1" maxOccurs="1"/> <xsd:element name=“Titre" type="xsd:string"/> <xsd:element name=“Auteur" type="xsd:string"/> <xsd:element name="ISBN" type="xsd:string"/> <xsd:element name=“Editeur" type="xsd:string"/> </xsd:schema> <!ELEMENT CatalogueLivres (Livre)*> <!ELEMENT Livre (Titre, Auteur, ISBN, Editeur)> <!ELEMENT Titre (#PCDATA)> <!ELEMENT Auteur (#PCDATA)> <!ELEMENT ISBN (#PCDATA)> <!ELEMENT Editeur (#PCDATA)>

41 Typage fort Les schémas XML permettent de définir des types de données complexes <xs:complexType name=“monType”> <xs:all> <xs:element name=“crea” type=“xs:date”> <xs:element name=“maj” type=“xs:date”> </xs:all> <xs:attribute name=“ URL” type=“xs:anyURI”/> </xs:complexType>

42 Éléments connecteurs Les éléments connecteurs permettent de décrire l’ordre et la fréquence d’apparition des éléments dans les documents instances <xs:sequence> = même ordre <xs:choice> = ou exclusif <xs:all> = tous les éléments doivent être utilisés, quel que soit leur ordre d’apparition

43 Exemple un peu plus complexe
<xs:element name=“siteWeb”> <xs:complexType> <xs:sequence> <xs:element name=“dataCreation” type=“xs:date”/> <xs:element name =“dateMaj” type=“xs:date”/> </xs:sequence> <xs:attribute name=“URL” type=“xs:anyURI”/> </xs:complexType> </xs:element>

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
<xs:simpleType name="Telephone"> <xsd:restriction base="xs:string"> <xsd:length value=“6"/> <xsd:pattern value="\d{2}-\d{3}"/> </xsd:restriction> </xsd:simpleType>

46 Exemple de restriction plus complexe
<xs:simpleType name=“Couleurs-drap"> <xs:restriction base="xs:string"> <xs:enumeration value=“bleu"/> <xs:enumeration value=“blanc"/> <xs:enumeration value=“rouge"/> </xs:restriction> </xs:simpleType>

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 d’objets distribués Plusieurs éléments dans la spéc. : Enveloppe SOAP = représentation des msg Implémentation des échanges au dessus d’un 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 ( SOAP 1.1 en mai 2000 ( 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 l’implémentation profonde d’un Service Web, un exemple d’interaction 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 Header Field Header Field SOAP Body Body Field Body Field

53 En-tête SOAP Optionnel
Plusieurs entrées dont le format n’est 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 l’entrée désignée 0 = élément optionnel pour l’application réceptrice

54 Modèle de données SOAP propose un encoding au format XML de son modèle de données L’utilisation de cette traduction est facultative Mais il faut impérativement que l’émetteur et le récepteur exploitent la même traduction L’encoding XML s’appuie sur les schémas du W3C, étendus avec la notion de type composé <element name=‘‘llivre’’><complexType> <element name=‘‘auteur’’ type=‘‘xsd:string’’> <element name=‘‘titre’’ type=‘‘xsd:string’’> </complexType></element>

55 Le modèle RPC L’appel d’une 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/ Host: Content-Type: text/html; charset=‘‘utf-8’’ Content-Length: SOAPAction: ‘‘monAction’’ <SOAP-ENV:Envelope xmlns:SOAP-ENV=‘‘ <SOAP-ENV:Body> <p5:GetAllDUs xmlns:m=‘‘…’’> <symbol>MINT</symbol> </p5:GetAllDUs> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

57 Exemple de réponse HTTP/ OK Content-Type: text/html; charset=‘‘utf-8’’ Content-Length: <SOAP-ENV:Envelope xmlns:SOAP-ENV=‘‘ <SOAP-ENV:Body> <p5:GetAllDUs xmlns:m=‘‘…’’> <DU>XML</DU> <DU>Gestion de Projets</DU> <DU>J2ME</DU> <DU>Services Web</DU> </p5:GetAllDUs> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

58 Pour ou contre SOAP ? Contre : Pour : Très volumineux et verbeux
10 fois plus gourmand qu’un 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 d’opérations et de messages abstraits reliés (bind) à des protocoles et des serveurs réseaux Rôle semblable à l’Interface Definition Language (IDL) de CORBA Description du service indépendante du langage et de la plate-forme de production

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

62 Document WSDL Un espace de noms : http://schemas.xmlsoap.org/wsdl/
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 : <types> <types> <xsd:complexType name=‘‘livre’’> <xsd:element name=‘‘auteur’’ type=‘‘xsd:string’’/> <xsd:element name=‘‘titre’’ type=‘‘xsd:string’’/> <xsd:element name=‘‘date’’ type=‘‘xsd:date’’/> <xsd:complexType> </types> Possibilité de définition de types faisant référence à de nouveaux types

64 WSDL : <message>
<message name=‘‘CreerDUrequest’’> <part name=‘‘nom’’ type=‘‘xsd:string’’/> <part name=‘‘responsable’’ type=‘‘xsd:string’’/> <part name=‘‘niveau’’ type=‘‘xsd:int’’/> </message> <message name=‘‘CreerDUresponse’’> <part name=‘‘acceptation’’ type=‘‘xsd:string’’/> </message> <message name=‘‘AssocierSupport’’> <part name=‘‘support’’ type=‘‘typens:livre’’/> </message>

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

66 WSDL : <porttype>
<portType name=‘‘GestionDU’’> <!-- One-way --> <operation name=‘‘AssociationSupport’’> <input message=‘‘AssocierSupport’’/> </operation> <!-- Request-reponse ->> <operation name=‘‘CreationDU> <input message=‘‘CreerDUrequest’’/> <output message=‘‘CreerDUresponse’’/> </message> </porttype>

67 WSDL : <binding>
Exemple de binding sur HTTP <binding name=‘‘GestionDUBinding’’ type=‘‘GestionDU’’ <soap:binding style=‘‘rpc’’ transport=‘‘ <operation name=‘‘creationDU’’> <soap:operation soapAction=‘‘’’/> <input><soap:body use=‘‘encoded’’…/></input> <output><soap:body use=‘‘encoded’’…/></output> </operation> <operation name=‘‘… > </operation> </binding>

68 WSDL : <service>
Exemple de déclaration de service <?xml version= ‘‘1.0’’ ?> <definitions name=‘‘localName’’…> <service name=‘‘GestionDUService’’> <port name=‘‘creationDU’’ binding=‘‘GestionDUBinding’’> <soap:address location=‘‘ </port> </service> </definitions>

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 d’exploiter 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, l’API du WS proposé par Amazon.com : 1 150 lignes de code WSDL Pour 23 opérations (34 lignes de code Java) Engendre lignes de code Java avec WSDL2Java d’Axis, dont l’essentiel décrit les types et leur correspondance en Java)

71 UDDI Universal Description, Discovery and Integration

72 Pourquoi UDDI ? Origine : Ariba, IBM, Microsoft + 260 sociétés
Créer un annuaire mondial de Services Web afin d’automatiser 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 l’enregistrement et la localisation des WS

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

74 Principes opérationnels
Pages blanches : Nom du fournisseur, contacts (noms, téléphones, sites web…), identifiant Pages jaunes : Catégories d’entreprises (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 : Recherche détaillée : Publication : Sécurité :
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
UDDI Types de services WSDL Publication White pages Services Yellow pages Green pages WS 1 Rechercher WSDL WS 2 Appli. cliente Bind + appels métier Stub WS 3 Client

77 Une architecture en devenir

78 Gérer la sécurité Confidentialité : Autorisation et authentification
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 d’orchestration de TP longues, mode B2B UN 2PC flexible WS-T (Microsoft, IBM et BEA) S’appuie sur le protocole WS-Coordination Pourrait remplacer BTP

81 Gestion des processus métier
Cœur de l’activité d’une 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 d’implémentation Prendre en charge les contraintes : Temps d’exécution longs (dépassant les frontièrs de l’entreprise) 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 d’orchestration Transformation des données

86 Conclusion

87 Une architecture en devenir - points forts
Un modèle d’architecture prometteur Des fondements solides, déjà bien normalisés (XML, Schémas, SOAP, WSDL, UDDI) Une volonté marquée d’ouverture et d’indé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 d’outils pour la partie BPM Un problème de taille : intégration des applications existantes (core business) La complexité de l’ensemble pénalise son adoption

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

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