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

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

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 »

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…)

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

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

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)

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

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…

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…

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…)

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…)

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…

L’espéranto des SI distribués Le langage XML Concepts fondamentaux Rappels

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

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

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

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…

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

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>

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="http://www.w3.org/XSL/Transform/1.0"> <template match="Y"/> </stylesheet>

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"> <…

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

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)*)>

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

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">

<. 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"> ]>

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

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, 12 000]

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…

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

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’’>

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

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

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)> ]>

Schéma CatalogueLivres Prologue… <?xml version="1.0"?> <xsd:schema xmlns:xsd= "http://www.w3.org/2000/10/XMLSchema" targetNamespace= "http://www.publishing.org" xmlns="http://www.publishing.org" elementFormDefault="qualified">

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>

<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>

É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>

<?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" targetNamespace="http://www.publishing.org" xmlns="http://www.publishing.org" 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)>

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>

É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

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>

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)

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>

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>

SOAP Simple Object Access Protocol

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)

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

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

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

Codage XML Espace de noms spécifique (préfixe env) http://schemas.xmlsoap.org/sopa/envelope/ É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

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

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>

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)

Exemple de requête HTTP POST ListeDUs HTTP/1.1 Host: www.p5server.com Content-Type: text/html; charset=‘‘utf-8’’ Content-Length: 1250 SOAPAction: ‘‘monAction’’ <SOAP-ENV:Envelope xmlns:SOAP-ENV=‘‘http://schemas…> <SOAP-ENV:Body> <p5:GetAllDUs xmlns:m=‘‘…’’> <symbol>MINT</symbol> </p5:GetAllDUs> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Exemple de réponse HTTP/1.1 200 OK Content-Type: text/html; charset=‘‘utf-8’’ Content-Length: 1250 <SOAP-ENV:Envelope xmlns:SOAP-ENV=‘‘http://schemas…> <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>

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

WSDL Web Services Description Language

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

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

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

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

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>

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

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>

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

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=‘‘http://www.p5.com/soapservlet/rpcrouter’’/> </port> </service> </definitions>

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)

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 12 000 lignes de code Java avec WSDL2Java d’Axis, dont l’essentiel décrit les types et leur correspondance en Java)

UDDI Universal Description, Discovery and Integration

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

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

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…

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…

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

Une architecture en devenir

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)

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

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

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

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

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)

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

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

Conclusion

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

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

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

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