Polycopie CH1 les Concepts Fondamentaux de l'Analyse Financière
Les Services Web Introduction Concepts fondamentaux Éléments darchitecture Université Paris 5 -...
-
Upload
maddie-ferrari -
Category
Documents
-
view
110 -
download
0
Transcript of Les Services Web Introduction Concepts fondamentaux Éléments darchitecture Université Paris 5 -...
Les Services Web
IntroductionConcepts fondamentauxÉléments d’architecture
Université Paris 5 - M2 - 2007
IntroductionConcepts 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éesA base de composants interopérablesServices autonomes et indépendantsAccessibles 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…)
Core BusinessServeursd’applicationsComposants
Interfaces
Mobile
Vocal server
Intranet
Internet
Web TV
WS
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 :
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
Processus métier(BPML, WSFL, XLANG…)
Découverte / Localisation(UDDI)
Description(WSDL)
Echange de messages(SOAP)
Transport(HTTP, HTTPR, SMTP, JMS…)
Séc
urit
é(X
ML
Sig
natu
reX
ML
Enc
rypt
ion,
XK
MS
…)
Transactions
(BT
P, W
S-T
ransaction…)
Mise en œuvre
Annuaire
Echange de messages(SOAP)
Transport(HTTP, HTTPR, SMTP, JMS…)
ServiceClient
Recherche(UDDI)
Publication(WSDL, UDDI)
Lien (XML)
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 fondamentauxRappels
Concepts fondamentauxRappels
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
XML
META
DTD
Schémas
Parcours Transform. API
XPath
XLink
XPointer
XSL
XSLT
SAX
DOM
Interrog.
XQL
XQuery
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+)><!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">
]>
Limites des DTD
Syntaxe non nativement XML 1.0Typage 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…
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’’>
Validation d’un document XML
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
Permettent de spécifier des contraintes d’unicité :Portant sur le contenu d’un élémentY 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
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)>]>
<?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 • Prologue…
<xsd:element name=“CatalogueLivres"> <xsd:complexType> <xsd:sequence> <xsd:element ref=“Livre"
minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType></xsd:element>
Schéma CatalogueLivres • Déclaration de l’élément racine…
<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>
<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>
• Éléments feuilles et fin de document
<?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: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> <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 Titre (#PCDATA)><!ELEMENT Auteur (#PCDATA)><!ELEMENT ISBN (#PCDATA)><!ELEMENT Editeur (#PCDATA)>
<!ELEMENT Livre (Titre, Auteur, ISBN, Editeur)>
<!ELEMENT CatalogueLivres (Livre)*>
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
<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>
Exemple un peu plus complexe
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>
<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>
Exemple de restriction plus complexe
SOAPSimple 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
SOAP Body
Header Field
Header Field
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 : 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
WSDLWeb 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)
UDDIUniversal 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
ISVComité de
standardisation…
Définition des typesde services et modèlesde données
Fournisseurs deServices Web
Enregistrement des Services proposées
Places de marchéMoteurs de recherche
Entreprises… Interrogation de
l’annuaire UDDI
Assemblage des services, consommationDes services à travers le réseau Internet
Types deservices
Services
White pages
Yellow pages
Green pages
UDDI
WSDL
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 :
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
Types deservices
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
Une architecture en devenir
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)
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 flexibleWS-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
XML
SOAP
Business Obj
Tech Obj
Fra
mew
ork
Fro
nt
Se
rvic
es
ODBC Call
ODBC Response
Legacy Call
Legacy Response
Legacy+
POST/GET
HTTP
HTML
HTTP
XML
XML
XML
XML
XML
XML
Databases1
1
1
1
Middle Office Back Office
Soap Call
(XML)
Soap Response
(XML)
XML Parser
XSLT
Oracle DB
StoredProcedures
PL/SQL
COMobject
XSLT Pre-Processor
MSXML3
MSXML3
SO
AP
EN
CA
PS
UL
AT
ION
OD
BC
Dr i
ver
COMobject
OP
G
Mainframe
OP
G
1
Bus Obj Tech Obj
COMobject
COMobject
1
1
1
ODBC Call
ODBC Response