XML pour l'entreprise Didier Girard Tanguy Crusson [email protected]
Version provisoire 0.91 Ce document est disponible à l'adresse suivante : http://www.application-servers.com/livresblancs/xml/
Copyright (c) 2001, Improve, Didier Girard et Tanguy Crusson. Le contenu de ce document peut être redistribué sous les conditions énoncées dans la Licence pour Documents Libres Improve version 2.0 ou ultérieure.
Définitions et domaine d'application Cette licence s'applique à tout document, quelle que soit sa forme, comprenant la notice standard associée à cette licence. La "notification de licence" désigne la section du texte où sont mentionnés le fait que le document est soumis à la présente licence ainsi que le copyright du document. Un document est produit par un ou plusieurs auteurs. Un document peut être constitué de plusieurs contributions mises en commun. Dans ce cas, l'éditeur désigne la personne morale ou physique qui assure la mise à disposition du document sous diverses formes. 1
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
3
S'il n'y a qu'un auteur, il est son propre éditeur. Conformément au code de la propriété intellectuelle, chaque auteur conserve la propriété intellectuelle sur sa contribution. Toutefois, l'éditeur a toute liberté pour faire évoluer le document dans le respect des dispositions de la présente licence. La notice de copyright mentionne l'éditeur si il existe ainsi que les noms des auteurs. On appellera "version dérivée" tout document comprenant le document de départ partiellement ou dans son intégralité. Une traduction est aussi considérée comme une version dérivée. La "section historique" du document désigne une partie du document comprenant un historique de sa genèse et de son évolution. Dans le cas d'un document dérivé, la section historique contient le descriptif du ou des documents originaux et des modifications qui y ont été apportées. Elle peut également contenir des éléments non factuels comme des considérations éthiques ou politiques concernant l'historique et les motivations du document. La section historique peut donc n'avoir aucun rapport avec l'objet principal du document. La "Page de titre" désigne pour un document imprimé la page de titre au sens usuel plus les pages de couvertures. Dans le cas de documents pour lesquels ces notions de s'appliquent pas, c'est le texte proche de l'endroit où apparaît le titre du document et la fin du document. La notification de licence sera placée dans la page de titre. La notice standard minimale aura la forme suivante : "Copyright (c) ANNEE, EDITEUR et AUTEURS. Le contenu de ce document peut être redistribué sous les conditions énoncées dans la Licence pour Documents Libres version x.y ou ultérieure." Un document peut contenir des "sections invariantes". La liste des titres de sections invariantes est précisée dans la notice spécifiant que le document est soumis à la présente licence. Par exemple : "Le présent document contient un certain nombre de sections invariantes qui devront figurer sans modification dans toutes les modifications qui seront apportées au document. Leurs titres sont: TITRES DES SECTIONS INVARIANTES". Nous distinguons trois modes de diffusion de documents électroniques: • une forme "transparente", ce qui désigne tout format électronique dont les spécifications sont disponibles dans le domaine public ou qui peut être édité par des programmes éventuellement commerciaux largement disponibles à la date de publication du document. Exemples: ASCII, Texinfo, TeX et LaTeX, RTF, HTML, XML, SGML avec une DTD publique. • une forme "opaque", ce qui désigne tout format électronique permettant l'affichage ou l'impression du document de manière simple au moyen de logiciels du domaine public ou du moins très largement disponibles à la date de publication du document. Un tel format ne permet pas la modification dudit document de manière simple. Exemples: Postscript, PDF, tout format de traitement de texte nécessitant un logiciel propriétaire, ou tout déclinaison de SGML dont la DTD n'est pas publique. • une forme "cryptée" ce qui désigne le cas où une partie (ou la totalité) du document est sous un format électronique qui n'est pas lisible sans la possession d'une clef logicielle ou matérielle qui en permet le décodage. La forme cryptée peut être utilisée à des fins d'authentification. Une fois décodé le document peut être sous une forme transparente ou opaque.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
4
Dans le cas d'une forme cryptée, si l'éditeur n'est plus en mesure de fournir la clef de décodage, il doit rendre disponible le document sous une forme transparente ou opaque non cryptée.
Conditions communes aux versions modifiées et intégrales La distribution de versions intégrales et modifiées du présent document sous n'importe quelle forme est autorisée aux conditions suivantes : • Les notices de copyright spécifiant que le document est soumis à la présente licence ainsi que les sections invariantes doivent être préservées. • Les sections invariantes ne peuvent être altérées. • Les sections historiques ne peuvent être que complétées. • La localisation4 du document original doit être mentionnée dans la page de titre et de manière visible. • Un document disponible sous forme transparente ne peut être rediffusé sous forme opaque. • Vous ne devez mettre en place aucun dispositif visant à restreindre l'accès au document ou la possibilité de reproduire les copies que vous distribuez. En particulier vous ne pouvez rendre disponible tout ou partie du document sous forme cryptée si l'auteur l'a expressément interdit. • La redistribution dans un cadre commercial ne peut être effectuée sans l'accord préalable des auteurs et de l'éditeur du document original. • Si la distribution de copies du document entraîne des frais de reproduction (photocopies, impressions, pressage de médias), vous pouvez néanmoins les imputer au lecteur. Mais vous ne pouvez pas percevoir de droits d'exploitation liés au contenu, ni à l'utilisation du document. Si vous effectuez une diffusion en nombre du document (diffusion sur le WEB, par FTP, ou à plus de 99 exemplaires imprimés, par courrier électronique, sur CDROM, ou sur d'autres supports magnétiques ou optiques), vous devez inclure une copie de la présente licence. Dans ce cas, vous devez également prévenir les éditeurs du document original afin de définir avec eux comment veiller à la diffusion de versions à jour du document.
Modifications Dispositions générales Vous pouvez utiliser une partie du présent document, en la modifiant éventuellement, pour produire un nouveau document. Les dispositions de la section 3 s'appliquent. Vous devez en plus : • lister un ou plusieurs auteurs ou entités responsables des modifications apportées au document. • mentionner sur la page de titre que le document dérivé est une modification d'un ou plusieurs documents originaux. Vous devez préciser leurs titres ainsi que l'entité éditrice ou les principaux auteurs. • préciser sur la page de titre que vous êtes l'éditeur de la version dérivée. Vous ne devez en aucun cas : • altérer une mention d'un nom d'auteur présent dans le document original et concernant une partie que vous avez réutilisée. 4
URL ou adresse postale
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
5
•
donner au document dérivé le même titre que le document original sans autorisation de l'éditeur de celui-ci. Nous recommandons de plus que les titres de sections ne soient altérés qu'en cas de changement du plan du document rendus nécessaire par les modifications apportées. Fusion ou combinaison de documents Dans le cas ou le document que vous produisez est issu de la combinaison de plusieurs documents (après modifications éventuelles) soumis eux aussi à la présente licence, vous pouvez remplacer les diverses notifications de licence par une seule. De même, vous pouvez regrouper les diverses sections historiques pour n'en faire qu'une seule. Elle doit mentionner explicitement les documents originaux auxquels vous avez fait appel et indiquer leur localisation. Si un des documents utilisés est disponible sous une forme transparente alors la totalité du document dérivé doit aussi l'être. Vous devez respecter les points listés en sections 3 et 4.1. Inclusion dans d'autres travaux Si le Document ou une de ses versions dérivées est agrégée avec des travaux indépendants, de sorte que plus de 50 % du document final ainsi produit ne soit pas soumis à la présente licence, le document final n'est pas considéré comme une version dérivée soumise dans son ensemble à la présente licence. Néanmoins, la ou les portions du document final qui sont issues d'un document soumis à la présente licence restent soumis à cette licence. Les recommandations des sections 3 et 4 s'appliquent. Traduction Une traduction d'un document est considérée comme une version dérivée. Dans ce cas, vous pouvez néanmoins traduire les sections invariantes. Si vous ne laissez pas les versions originales de ces sections, vous devez prendre contact avec l'éditeur de la version originale afin d'obtenir son accord pour les traductions de ces sections.
Dispositions concernant la garantie Cette licence ne définit que les droits de reproduction modification et diffusion du document. Elle n'y associe aucune garantie : sauf mention expresse du contraire, qui n'engagerait alors que l'éditeur du document, et dans la mesure où le contenu est en conformité avec la législation française, il est entendu que ni l'éditeur ni les auteurs du document ne sauraient être tenus pour responsables des éventuels dommages et préjudices que l'utilisation du document aurait entraînés. Ces dispositions s'appliquent même si il s'avère que le document contient naturellement ou par obsolescence une inexactitude, une imprécision ou une ambiguïté. Tout auteur ou éditeur souhaitant doter un document soumis à la présente licence de dispositions de garantie doit joindre à chaque copie distribuée du document un certificat de garantie précisant exactement les dispositions de garantie et mentionnant explicitement les noms des personnes morales ou physiques assumant les responsabilités de la garantie. Les dispositions de libre copie de la présente licence restent valable pour un document avec garantie mais toute rediffusion par une autre personne que l'auteur du certificat de garantie se fait sans garantie.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
6
Cessation de la licence Vous ne pouvez redistribuer le présent document ou une de ses versions dérivées sous une licence différente. Cela entrainerait l'annulation des droits de copie, modification et distribution du document. En soumettant un document à la présente licence, vous conservez les droits de propriété intellectuelle liés à votre qualité d'auteur et vous acceptez que les droits de reproduction, diffusion et modification du document soient régis par la présente licence.
Évolution de la licence Improve se réserve le droit de faire évoluer la présente licence. Elle s'assurera de la compatibilité ascendante des différentes versions. Chaque version de la licence est numérotée. Sauf mention explicite, il est sous entendu que si le document précise un numéro de licence, cela signifie que toute version ultérieure convient. Si aucun numéro n'est précisé, cela signifie que toute version de la licence convient.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
7
Contributions « La culture hackeur » est une « culture du don » dans laquelle les participants rivalisent pour le prestige en donnant du temps, de l'énergie, et de la créativité5. La communauté des développeurs d'application-servers.com a participé à la rédaction du document. Nous tenons à remercier les personnes suivantes pour leurs remarques ou commentaires. Jean-Jacques Dubray Emmanuel Dupouy David Duquenne Bruno Fauré Laurent Forêt Sébastien Letélié Alexis Moussin-Pouchkine Herve Ange Ngouoni-Épigat Bruno Paul Thierry Roussel Sylvie Ramon Najib Ben Seffaj Stève Sfartz
Ce document n’étant encore qu’en version Beta il vous est toujours possible de devenir contributeur en apportant des commentaires, demandes de précisions, demandes de modifications, demandes d’ajouts,… Pour plus d’informations se reporter à la rubrique « Livres Blancs » de application-servers.com6.
5
« À la conquête de la noosphère » par Eric S. Raymond http://www.linux-france.org/article/these/noosphere/homesteadingfr_monoblock.html 6 http://www.application-servers.com/livresblancs/xml/
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
Historique Version
0.90
Objet Intégration des remarques de Jean-Jacques Dubray, 07/06/2001 Alexis Moussin-Pouchkine, Emmanuel Dupouy, Bruno Fauré, Laurent Forêt, Herve Ange Ngouoni-Épigat, Sylvie Ramon ,Najib Ben Seffaj 07/06/2001 Version beta soumise à la communauté.
0.89
29/05/2001 Dernière version avant la version beta.
0.91
Date
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
8
XML et les applications d’entreprise
9
Table des matières LICENCE POUR DOCUMENTS LIBRES IMPROVE....................................................... 2 CONTRIBUTIONS .................................................................................................................. 7 HISTORIQUE .......................................................................................................................... 8 TABLE DES MATIERES ....................................................................................................... 9 INTRODUCTION .................................................................................................................. 12 1
XML – GENERALITES ................................................................................................ 13 1.1 XML = EXTENSIBLE MARKUP LANGUAGE ............................................................... 13 1.1.1 Historique ......................................................................................................... 13 1.1.2 Définition .......................................................................................................... 13 1.1.3 A quoi ressemble un document XML ................................................................ 14 1.2 LES ESPACES DE NOMMAGE ....................................................................................... 15 1.3 UTILISATION DE LIENS AVEC XLINK, XML BASE ET XPOINTER .............................. 17 1.3.1 XLink................................................................................................................. 17 1.3.2 XML Base ......................................................................................................... 19 1.3.3 XPointer............................................................................................................ 19 1.4 GRAMMAIRE XML : DTD VERSUS XML-SCHEMA ................................................... 20 1.4.1 Une grammaire qu’est ce que c’est ? ............................................................... 20 1.4.2 DTD = Document Type Definition ................................................................... 20 1.4.3 XML-Schema .................................................................................................... 24 1.4.4 Conclusion ........................................................................................................ 32 1.5 MODELISER UN DOCUMENT XML ............................................................................. 32
2
MANIPULATION DES DOCUMENTS XML............................................................ 33 2.1 LES PARSEURS ........................................................................................................... 33 2.1.1 SAX ................................................................................................................... 34 2.1.2 DOM ................................................................................................................. 36 2.1.3 Utilisation des parseurs SAX et DOM : Sun JAXP .......................................... 39 2.1.4 Un système d’arbre 100% Java : JDOM ......................................................... 40 2.1.5 Conclusion ........................................................................................................ 43 2.2 LE DATA BINDING...................................................................................................... 44 2.3 LANGAGES DE REQUETES ........................................................................................... 44 2.3.1 XPath................................................................................................................ 46 2.3.2 XQuery.............................................................................................................. 50
3
B2C................................................................................................................................... 55 3.1 XHTML.................................................................................................................... 55 3.1.1 Règles à respecter............................................................................................. 55 3.1.2 Les différents types de XHTML ........................................................................ 57 3.2 XSL........................................................................................................................... 57 3.3 XSLT ........................................................................................................................ 58 3.3.1 XSL Transformation ......................................................................................... 58
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
10
3.3.2 Rédiger une feuille de style XSLT : .................................................................. 59 3.3.3 TrAX : Transformation API for XML – sous partie de JAXP........................... 65 3.4 XSL-FO .................................................................................................................... 65 3.4.1 Architecture utilisée pour générer du PDF avec XSLFO et FOP.................... 66 3.4.2 Exemple :.......................................................................................................... 66 3.5 SVG .......................................................................................................................... 68 3.6 XUL.......................................................................................................................... 69 4
LES SERVICES WEB ................................................................................................... 70 4.1 SOAP ........................................................................................................................ 70 4.1.1 Avant SOAP : XML-RPC.................................................................................. 71 4.1.2 Principe de SOAP............................................................................................. 73 4.1.3 Structure de l'enveloppe SOAP ........................................................................ 74 4.1.4 SOAP RPC........................................................................................................ 75 4.1.5 La Gestion des erreurs : ................................................................................... 77 4.1.6 Pattern d’utilisation : ....................................................................................... 77 4.1.7 Pas de modèle de composants.......................................................................... 78 4.1.8 La sécurité ........................................................................................................ 78 4.1.9 Implémentation de référence : Apache SOAP .................................................. 79 4.1.10 Deux API Java de Sun...................................................................................... 85 4.1.11 Outils facilitant l’utilisation de SOAP (cf annexes) ......................................... 86 4.2 WSDL ....................................................................................................................... 86 4.2.1 Structure d’un document WSDL ....................................................................... 86 4.2.2 WSDL et la gestion des fautes .......................................................................... 89 4.3 REFERENCEMENT DES SERVICES W EB : UDDI .......................................................... 90 4.3.1 Principe ............................................................................................................ 90 4.3.2 Six types d’annuaires UDDI : .......................................................................... 92 4.3.3 UDDI4J ............................................................................................................ 93 4.3.4 API de Sun : JAXR............................................................................................ 97 4.3.5 Outils facilitant l’utilisation de UDDI : ........................................................... 97 4.4 ARCHITECTURE ......................................................................................................... 97 4.4.1 L'architecture multicouche ............................................................................... 97 4.4.2 Services web et architecture à 5 couches ......................................................... 99
5
EAI ................................................................................................................................. 100 5.1 EAI - DEFINITION .................................................................................................... 100 5.2 EAI – GERER : LES PROCESSUS METIERS ................................................................ 101 5.2.1 Définition des processus métiers :.................................................................. 101 5.2.2 Les Dialogues : ............................................................................................... 102 5.2.3 Les processus e-business : .............................................................................. 103 5.2.4 BPMI.org : définition et exécution des processus métiers ............................. 104
6
B2B................................................................................................................................. 106 6.1 NORME D'INFRASTRUCTURE : EBXML .................................................................... 107 6.1.1 Architecture .................................................................................................... 107 6.1.2 Scénario d’utilisation ..................................................................................... 108 6.1.3 La modélisation des processus métier (ebBPSS): .......................................... 108 6.1.4 Le protocole de messagerie :.......................................................................... 112 6.1.5 Les accords de protocole de collaboration .................................................... 114 6.1.6 Conclusion ...................................................................................................... 114
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
11
6.2 B2B - LES SPECIFICATIONS DE CONTENU : .............................................................. 114 6.3 EXEMPLE DE SPECIFICATION VERTICALE : ROSETTA NET......................................... 115 6.3.1 Les PIP : Partner Interface Processes : ......................................................... 116 6.3.2 Le modèle de convergence RosettaNet :......................................................... 121 6.4 AUTRES SPECIFICATIONS VERTICALES ..................................................................... 122 6.5 EXEMPLE DE SPECIFICATION HORIZONTALE : OAGIS ............................................. 122 6.5.1 Business Objects Document (BOD)................................................................ 124 6.5.2 Exemple de BOD : S3_003 : PROCESS PO .................................................. 126 6.6 AUTRES SPECIFICATIONS HORIZONTALES ................................................................ 127 6.6.1 Places de marché............................................................................................ 127 6.6.2 Autres : ........................................................................................................... 128 7
POUR RESUMER : MATRICE DES NORMES XML ........................................... 129
CONCLUSION ..................................................................................................................... 130 XML ET LE B2C.................................................................................................................. 130 XML ET L’EAI.................................................................................................................... 130 XML ET LE B2B.................................................................................................................. 130 GLOSSAIRE......................................................................................................................... 131 INDEX ................................................................................................................................... 134
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
12
XML et les applications d’entreprise
Introduction XML est une technologie incontournable dans l’entreprise. On retrouve XML dans des contextes aussi divers que les applications distribuées, la configuration de produits, les annuaires, l’édition de documents, la diffusion de contenu sur le web ou la gestion de la connaissance7. Tant et si bien qu’il est devenu difficile d’avoir une vision globale de cette technologie sans passer des heures en veille technologique. D’où l’idée de faire gagner du temps à la communauté en écrivant un livre blanc qui synthétise des heures et des heures de veille. B2C, services web, EAI et B2B XML est plus qu’un langage, c’est une famille de langages. Actuellement on estime que plusieurs centaines de langages basés sur XML ont été décrits 8, preuve que XML répond à un véritable besoin. Le problème est qu’actuellement le monde XML est proche de la tour de Babel. Dans cette cacophonie, où le marketing est roi, il est difficile de comprendre ce qui se passe. L’objectif est donc d’arriver à rapidement classer une technologie. Pour ceci nous proposons quatre catégories, les langages XML pour le Business to Customer (B2C), les langages XML pour les services web, les langages XML pour l’Enterprise Application Integration (EAI) et les langages XML pour le Business to Business (B2B). Cette taxonomie permet de graduer la complexité d’un système, le B2C étant le plus simple et le B2B étant le plus complexe (voir Figure 1), et d’y associer les langages correspondants (voir Figure 2). Services Web
B2C
EAI
B2B
Complexité
Figure 1 Complexité des systèmes utilisant XML B2C RosettaNet
OAGIS RDF ebXML
XAML
tpaML UDDI
ICE
RSS
XSL
xCBL
WSDL
cXML
XSL -FO
XSLT
SOAP Acord
XUL BPML
XHTML
Services Web
EAI
B2B
Figure 2 Langages XML présentés dans ce document
7 « The State of XML: Why Individuals Matter » par Edd Dubill : http://www.xml.com/lpt/a/2001/05/30/stateofxml.html 8 « Will Your XML Talk To Mine? »: http://www.xml.org/xmlorg_news/will-xml-talk.shtml
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
13
1 XML – Généralités 1.1 XML = eXtensible Markup Language 1.1.1 Historique L’utilisation d’Internet a considérablement augmenté ces dernières années. Cette croissance est à associer à la naissance de deux standards : • HyperText Markup Language (HTML) : cette spécification décrit un langage associant des données et la manière de présenter ces données • HyperText Transfer Protocol (HTTP) : cette spécification décrit un protocole de transport d’informations sur internet. Contrairement au HTTP, le HTML est un standard qui a beaucoup évolué depuis son apparition. A l’origine dans un document HTML il n’y avait pas de prédominance entre les données et la présentation de ces données, un document était constitué à part égale entre les données et la présentation. Rapidement les normes successives de HTML ont laissé la présentation prendre de plus en plus de place dans un document HTML. Il est donc apparu nécessaire de définir un nouveau langage qui serait centré sur la description des données : eXtensible Markup Language (XML). Actuellement dans un document HTML, 95% du contenu est constitué d’éléments de présentation.
1.1.2 Définition XML9 (eXtensible Markup Language) est une recommandation du W3C. C’est est un langage à balise définissant un format universel de représentation des données. Un document XML contient à la fois des données et les indications sur le rôle que jouent ces données. Ces indications permettent de déterminer la structure du document : ce sont des balises. XML est une sous partie de SGML (Standard Generalized Markup Langage) définit par l’ISO (ISO 8879). SGML est un langage international de documentation normalisée, standard de fait dans le milieu de la gestion documentaire. On a souvent coutume de dire que "XML présente 80% des fonctionnalités de SGML pour seulement 20% de sa complexité".
9
Spécification de XML en français : http://babel.alis.com/web_ml/xml/ Spécification de XML en anglais : http://www.w3.org/TR/REC-xml
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
14
XML - Les dix commandements Tu seras utilisable sur internet Tu supporteras une grande diversité d’applications Tu seras compatible SGML Il devra être aisé d’écrire des programmes qui te manipulent Tu auras le minimum de fonctions optionnelles Tu seras lisible par l'homme Tu seras disponible rapidement La spécification qui te décrira devra être simple et concise Un document te respectant devra être facile à construire Tu pourras ne pas être concis.
1.1.3 A quoi ressemble un document XML Toute personne ayant déjà vu un document HTML sera familiarisée avec les documents XML. Voici un exemple simple de document. Il s’agit d’un document XML décrivant un annuaire simple : une liste d’entrées, chaque entrée étant composée d’un nom de personne et d’un numéro de téléphone. Paul Lafargue06 03 02 01 00Lorédan Larchey06 00 01 02 03
Le document commence par une entête. Cette entête n’est pas obligatoire. Elle contient des informations sur la version de XML et le jeu de caractères utilisés. L’entête peut aussi faire référence à une DTD (Déclaration de Type de Document Document Type Definition). Une DTD est une grammaire qui définit la structure d’un document XML. Elle permet de valider que chaque composant d’un document XML est à la bonne place. Les DTD sont par exemple utilisées pour valider les flux XML entrants d'un programme. Le document XML suit l'entête. Ce document est composé d’un ou plusieurs éléments. Les limites des éléments sont marquées soit par des balises ouvrantes (<…>) et fermantes (), soit, pour les éléments vides, par une balise d'élément vide (<…/>). Chaque élément est identifié par un nom. Il peut contenir des attributs. Exemple d’élément vide avec attribut :
Exemple d’élément non vide sans attribut :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
15
06 03 02 01 00
Exemple d’élément non vide avec attribut : Paul Lafargue06 03 02 01 00Lorédan Larchey06 00 01 02 03
Un document XML doit toujours être bien formé. S'il n’est pas bien formé, par définition ce n’est pas un document XML. Pour être bien formé un document XML est composé de six types de balisage : les balises (balises ouvrantes, balises fermantes et balises d'éléments vides), les appels d'entité (entity reference), les commentaires, les délimiteurs de section CDATA, les déclarations de type de document, et les instructions de traitement. Il existe d’autres règles définissant un document XML bien formé. Pour en avoir une description complète se reporter à la recommandation du W3C 10. W3C Le processus de production des recommandations du W3C est composé de quatre types de documents : "les notes (Notes), les documents de travail (Working Drafts), les recommandations proposées (Proposed Recommendations) et enfin les recommandations (Recommendations)". Un document est stable lorsqu’il a atteint le statut de recommandation. XML est une recommandation depuis 1998 Pour tout savoir sur le W3C : “Le World Wide Web Consortium (W3C)” de Frédéric PELLETIER http://www.lexum.umontreal.ca/internet99/p1c4.html
1.2 Les espaces de nommage Les "espaces de nommage" (XML Namespaces) sont spécifiés dans une recommandation11 du W3C. Ils permettent : • de mélanger du vocabulaire XML provenant de plusieurs grammaires, • d’identifier de manière unique les balises XML. Pour illustrer l’utilisation des espaces de nommage, prenons le cas d’une entreprise décrite par deux documents XML. Un document qui contient les informations générales à l’entreprise :
10
http://babel.alis.com/web_ml/xml/REC-xml-1-2.fr.html#sec-well-formed Spécification sur les espaces de nommage: http://www.w3.org/TR/REC-xml-names/ FAQ sur les espaces de nommage de très bonne qualité : http://www.rpbourret.com/xml/NamespacesFAQ.htm
11
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
16
Bizib inc …
Un document qui contient les informations sur le personnel de l’entreprise : LafarguePaulPDG0102030405
On remarque que la balise peut contenir deux types d’informations : nom de l’entreprise ou nom d’une personne. Si l’on désire créer un document unique décrivant l’entreprise et ses employés, un moyen permettant d’identifier les balises est nécessaire (par exemple et ). C’est l ‘objectif des espaces de nommage, ou XML Namespace (xmlns). Le principe est d’associer une URI (Uniform Resource Identifier – voir Figure 3) à un nom. Par exemple l’espace de nommage "personne" peut être déclaré de la façon suivante : xmlns:personne="http://www.personne.org". Ce nom est ensuite utilisé pour caractériser les balises. Par exemple signifie que la balise appartient à l’espace de nommage "personne". Le document XML unique décrivant l’organisation de l’entreprise est alors : Bizib incLafarguePaulPDG
L’URI de l’espace de nommage (ici http://www.entreprise.org et http://www.personne.org) peut être fictive : elle n’est pas vérifiée, toutefois elle pointe généralement sur la grammaire de l'espace de nommage. Nous étudierons par la suite plusieurs grammaires XML définies dans des DTD ou XMLSchema. L’utilisation d’espaces de nommage permet de préciser que des éléments d’un document XML sont associées à une grammaire, et de donner l’URI où la grammaire est spécifiée. URI, URL, URN et URC :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
17
XML et les applications d’entreprise
URI (Universal Resource Identifier) : identification de ressources sur le Web. Il y a trois types d'URI : URL (Uniform Resource Locator) : adresse et protocole d'accès d'une ressource sur le Web. URN (Universal Resource Naming) : nommage permanent d'une ressource. Le but est de garantir la possibilité de retrouver un document, même lorsque son URL a changé. La gestion des noms est centralisée. URC (Universal Resource Caracteristics) : description des caractéristiques d'un document. Ces caractéristiques pourront être la version, le format, mais également les localisations et les modes d'accès (plusieurs URL possibles pour un même document).
XML se devait de fournir un mécanisme permettant le lier les ressources. Mais on sent tout de suite que les possibilités du lien « type HTTP » sont limitées : liens unidirectionnels, non caractérisés, etc. Pour cette raison, trois initiatives visent à approfondir et formaliser la notion de lien en XML : XLink, XML Base et XPointer.
1.3.1 XLink XLink est une recommandation W3C. Cette spécification permet de modéliser les liens entre documents. Nous ne discuterons ici que de l’utilisation de XLink dans un document XML, et nous ne détaillerons pas les fonctionnalités plus dédiées au HTML qui sont liées aux actions à effectuer en cas de clic de l’utilisateur sur un lien - une des fonctionnalités requises par les XLink était d’être compatible avec les liens HTML 4.01. Il existe principalement trois types de liens, définis dans l’attribut xlink:type : • Les liens simples (xlink:type=”simple”) étendent la notion de lien HTML aux documents XML, avec des compléments (possibilité de catégoriser les liens, …) • Les liens étendus (xlink:type=”extended”) : permettent de définir des liens plus complexes (liens pointant vers des ressources multiples, etc.) • Les arcs (xlink:type=”arc”) : permettent de définir des relations entre les liens. Le lien XLink le plus simple est équivalent à un lien en HTML : Version HTML : Lien vers doc.xml
Version XLink :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
18
Lien vers doc.xml
XLink définit principalement une liste d’attributs qu’il est possible d’utiliser dans les éléments définis par l’utilisateur. Il est possible de les utiliser à partir du moment où on définit l’espace de nommage XLink :
Les attributs principaux sont : • xlink:type : type du lien (simple, extended, arc, …) ; • xlink:href : pointeur vers une ressource extérieure ; • xlink:title : titre du lien, permet de le caractériser de manière sémantique ; • xlink:role : description du lien, la forme est libre ; • xlink:from, to : utilisés dans les arcs pour définir une relation unidirectionnelle entre deux liens (du lien « from » vers le lien « to »). 1.3.1.1 Les liens simples Comme nous l’avons vu précédemment, les liens simples sont une extension des liens HTTP. Par exemple : Télécharger sur le site d’application servers
1.3.1.2 Les liens étendus Les liens étendus permettent de modéliser des liens plus complexes. Imaginons par exemple qu’un document soit disponible en plusieurs endroits. Un lien peut pointer sur plusieurs ressources :
Note : les liens de type locator sont utilisés dans les liens étendus pour pointer sur une ressource grâce à l’attribut xlink:href. Ce sont l’équivalent dans ce contexte des liens de type simple. Enfin, il est possible de définir des relations entre les liens contenus dans un lien de type étendu. Par exemple pour préciser que le site principal de téléchargement du livre blanc www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
19
pointe sur le site mirroir (on utilise pour cela l’attribut xlink:label qui permet de donner un identifiant à un lien) :
1.3.2 XML Base XML Base est une recommandation du W3C. Cette norme très simple prévoit l’ajout d’un attribut xml:base à un élément pour définir l’adresse de base de tous les liens définis dans ses sous éléments. Par exemple :
Ainsi, le livre blanc est téléchargeable à l’adresse http://www.applicationservers.com/livresblancs/xml, concaténation de l’URI précisée dans l’attribut xml:base et de celle précisée dans xlink:href.
1.3.3 XPointer Comme nous venons de le voir, XLink permet de modéliser des liens plus complexes que ceux qu’il est possible de faire avec HTML. Pour compléter cette spécification, il était nécessaire d’avoir un moyen de pointer sur des éléments spécifiques d’un document XML : c’est l’objectif de XPointer. XPointer n’est pas un langage de requête mais utilise XPath pour permettre de pointer vers un élément particulier d’un document XML. Si vous ne connaissez pas XPath, nous vous conseillons de revenir sur cette partie après avoir lu la section 2.3 sur les langages de requêtes). Avec XLink il est possible de créer des liens vers d’autres documents (XML, HTML, texte, etc.), mais aussi de pointer sur une partie précise d’un document XML. Par exemple, le lien suivant pointe sur l’entrée de l’annuaire annuaire.xml contenant le numéro de téléphone de Harry Cover : www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
20
Numéro de téléphone de Harry cover dans l’annuaire
Un lien XLink utilise un pointer XPointer dans son attribut href :
XPointer définit aussi des extensions à XPath pour pouvoir pointer sur des éléments de façon plus précise. Ces extensions sont détaillées dans le tutorial Zvon « XPointer Tutorial »12.
1.4 Grammaire XML : DTD versus XML-Schema 1.4.1 Une grammaire qu’est ce que c’est ? Une grammaire définie la syntaxe d’un langage. En XML le langage est la liste des balises qui sont utilisables, la syntaxe correspond à l’organisation de ces balises. Par conséquent, un document XML est compréhensible si sa grammaire est définie. Les documents DTD et XML-Schema13 permettent de décrire des grammaires de documents XML. Ce sont deux approches différentes, les DTD étant plus simples à mettre en place mais décrivant un document XML de manière moins complète. Si deux documents XML respectent la structure définie dans une DTD ou un XML-Schema, on dit qu’ils respectent la même grammaire. Document valide, document bien formé • •
Un document XML bien formé est un document qui respecte la syntaxe XML. Un document XML valide est un document bien formé qui se conforme à la définition de la grammaire (DTD ou Schéma) à laquelle il est associé.
1.4.2 DTD = Document Type Definition DTD signifie Document Type Definition (ou définition de type de document), c'est la grammaire historique des documents XML. La puissance de description des DTD est faible : une DTD permet uniquement de décrire la structure d'un document XML (liste des balises et organisations des balises),, et non la typologie des données contenues (chaîne de caractère, date, entier, etc).. Les DTD sont donc à utiliser lorsque la typologie des 12 13
Tutorial Zvon sur XPointer : http://www.zvon.org/xxl/xpointer/tutorial/OutputExamples/xpointer_tut.html Spécification XML-Schema : http://www.w3.org/XML/Schema
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
21
données contenues dans le document XML est sans importance. On appelle validation le mécanisme qui vérifie qu’un document XML respecte une DTD. 1.4.2.1 Exemple de DTD Dans l’exemple ci-dessous, le document XML (1) est valide par rapport à la DTD (2) : 1) Harry Cover0102030405
2)
Il est possible de préciser la cardinalité des données. « nom » signifie qu’une entrée contient un et un seul élément nom, « telephone* » signifie qu’une entrée contient 0 à n numéros de téléphone. Par contre, on ne peut pas typer les données : « telephone » est censé être un champ numérique et non une chaîne de caractères, mais il n’est pas possible de modéliser cette contrainte dans une DTD. 1.4.2.2 Référer à une DTD dans un document XML 1. DTD externe : Un document XML peut préciser qu’il respecte une DTD définie dans un document à part, on parle alors de DTD externe. Cette information doit être insérée dans l’entête du document : …
On fait référence à la DTD par son nom et son URL. Les parseurs XML pourront alors la retrouver et valider ou non ce document (c’est à dire vérifier que le document respecte la grammaire fixée par la DTD). Notons que seul les parseurs dits « validant » peuvent valider un document par rapport à sa DTD. 2. DTD interne : il est aussi possible de définir la DTD dans le corps du document XML, on parle alors de DTD interne. Dans ce cas, on utilise l’élément . Reprenons l’exemple du document XML annuaire.xml précédemment décrit, et ajoutons lui sa DTD interne :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
22
XML et les applications d’entreprise
]> ...
Cette solution est rarement utilisée. 1.4.2.3 Les constituants d’une DTD 1. Types de données : Les DTD définissent 10 types de données. Les deux types les plus fréquemment utilisés sont : PCDATA et CDATA : • PCDATA signifie Parsed Character Data (ou chaîne de caractères parsée). C’est le texte contenu dans un élément. Dans l’élément suivant : texte, « texte » est du type PCDATA. • CDATA signifie Character Data ou chaîne de caractères. Il s’agit de chaîne de caractères qui ne seront pas parsées lors de la validation. On les utilise dans les attributs : par exemple dans l’élément : ”>, est du type CDATA et sera donc traitée comme une chaîne de caractère, et non une balise XML. • ID et IDREF : permettent de lier différentes parties d’un document XML. Nous y reviendrons. 2. Eléments : Les éléments XML sont définis dans une balise . La syntaxe de base est . Un élément peut être vide, contenir une chaîne de caractères, ou contenir des sous éléments. Type Elément vide Elément contenant du texte Elément avec sous éléments Elément avec plusieurs sous éléments Elément avec contenu variable Elément à contenu non défini
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
23
XML et les applications d’entreprise
On peut déclarer la cardinalité des sous éléments : signifie que le sous élément s1 peut avoir une et une seule occurrence. signifie que le sous élément s1 peut avoir 0 à n occurrences.
signifie que le sous élément s1 peut avoir 0 ou 1 occurrence. signifie que le sous élément s1 doit avoir au moins 1 occurrence.
3. Attributs : Les attributs sont tous décrits dans une balise . La syntaxe de base est :
Il existe de nombreux types possibles pour l’attribut. On utilise généralement CDATA (Character Data, ou chaîne de caractères), ou une énumération de valeurs possibles : DTD
XML
Par défaut : ou (défaut) : par défaut:
2 valeurs possibles : “v1” et “v2”
La valeur par défaut permet de spécifier la valeur que prendra l’attribut s’il n’est pas renseigné par le constructeur du document XML qui respecte cette DTD. Cette valeur permet aussi de préciser des options : Type Attribut obligatoire
DTD
XML elt elt elt elt
EMPTY> att CDATA #REQUIRED> EMPTY> att CDATA #IMPLIED>
Attribut non obligatoire Attribut à valeur fixe
: OK : non
4. Entités :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
24
XML et les applications d’entreprise
Les entités peuvent être considérées comme des variables. Elles sont déclarées et non mutables, et peuvent être utilisées dans tout document XML respectant cette DTD. Elles peuvent être internes ou externes (c’est à dire faire référence à un autre document par le biais d’une URI). Leur déclaration est contenue dans l’élément . Type Interne
DTD
Utilisation XML
Externe
&nom; => valeur&nom; => www.coucou.org
5. Les identifiants Un attribut de type ID permet d’attribuer un identifiant à un élément d’un document XML. Cet élément peut être ensuite référencé dans une autre partie du même document en utilisant un attribut de type IDREF. Les identifiants permettent donc de lier différentes parties d’un document XML. Par exemple, la DTD suivante décrit une grammaire permettant de définir des personnes et leurs relations de parenté :
personne (#PCDATA)> parent (fils*)> fils EMPTY> personne identifiant ID #REQUIRED> parent identifiant IDREF #REQUIRED> fils identifiant IDREF #REQUIRED>
Exemple de document XML respectant cette DTD. On y définit deux personnes (Adam et Caïn) à qui on attribue un identifiant (respectivement « A » et « B »), et on précise que A est parent de B : AdamCaïn
1.4.3 XML-Schema XML-Schema14 est une recommandation du W3C, au même titre que XML et que les espaces de nommage. Les documents XML-Schema permettent de décrire la structure d'un document XML d'une façon beaucoup plus complète que les DTD. Il est par exemple possible de spécifier la typologie des données (String, Decimal, etc..) que va contenir le document XML décrit par le XML-Schema. Attention toutefois, sous le terme XML-Schema se cache plusieurs "normes". Dans la mesure du possible préférer celle du W3C car elle suit un processus de standardisation ouvert et clair. 1.4.3.1 Exemple de document XML-Schema : 14
Pour une présentation très complète de la spécification se reporter à l'url suivante (15300 mots): http://site.voila.fr/xmlschema/xschema.htm
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
25
Pour exemple, modélisons l’élément de l’annuaire précédemment décrit à l’aide de XML-Schema. Nous pouvons ici préciser le type des informations contenues dans les éléments (string) et (decimal). Le document XML : Harry Cover0102030405
Le document XML-Schema :
XML-Schema permet de gérer les occurrences d’un attribut, les types complexes, etc. De plus, un document XML-Schema respecte la syntaxe XML, à l’inverse des DTD pour lesquels il faut apprendre une nouvelle syntaxe. Par contre, comme on peut le remarquer sur l’exemple précédent, un document XML-Schema est généralement plus volumineux et plus difficile à lire qu’une DTD (pour un opérateur humain). Les opposants à cette norme lui reprochent sa trop grande complexité. Il existe des initiatives pour créer un langage plus facile d’utilisation et aussi complet (nous pouvons par exemple citer TREX de James Clark). 1.4.3.2 Référer à un XML-Schema dans une instance de document XML Un document XML peut préciser qu’il respecte un XML-Schema. Cela se fait dans l’entête de ce document : Harry Cover0102030405
L’espace de nommage xsi correspond aux instances de documents XML respectant les contraintes définies dans un document XML-Schema. Le W3C a défini une librairie de balises et attributs pouvant être utilisés par ces documents. 1.4.3.3 Les constituants d’un XML-Schema
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
26
Comme nous l’avons déjà précisé, XML-Schema est une norme assez complexe. Nous n’entrerons donc pas autant dans les détails que pour les DTD. 1. Déclaration : L’élément permet de déclarer un document XML-Schema. Son attribut targetNamespace permet de préciser l’espace de nommage de ce type de documents. L’attribut elementFormDefault précise si les documents XML respectant cette grammaire doivent référer à cet espace de nommage.
2. Types de données : XML-Schema définit plus de 40 types de données, et fournit un mécanisme de définition de types de données complexes. Parmi ces types définis par XML-Schema on retrouve string, integer, date, year, CDATA, float, double, binary, ENTITIES, token, byte, etc. Pour définir ses propres types de données, il est possible de créer un type de données totalement nouveau, de restreindre ou d’étendre un type de données existant. Note : une déclaration de type est visible par tous les descendants du nœud dans lequel il a été déclaré. Par exemple, un type qui a été déclaré sous le nœud sera par voie de conséquence visible dans tout le document. Pour créer un nouveau type de données, il faut utiliser la balise . Créons par exemple un type de données ’entree’ : stringdecimal
On utilise la syntaxe suivante :
Pour l’utiliser dans une déclaration d’élément on utilise la syntaxe suivante :
1. Restriction de type existant : utilisation de Le type de données string comprend 6 attributs optionnels : pattern, enumeration, length, minLength, maxlength, whitespace. Si on désire définir un type de string représentant un choix (oui/non) :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
27
Pour utiliser ce type de données dans une déclaration d’élément, on utilise l’attribut type :
Une instance de cet élément : oui Il est possible d’empêcher la restriction d’un type lors de sa déclaration : ...
2. Extension d’un type de données existant : utilisation de Il est aussi possible de créer des types dérivés, ajoutant des éléments aux structures déjà créées. Reprenons le type ‘entree’ défini précédemment. Il est possible de créer un type dérivé entreeAvecAdresse contenant en plus du nom et du numéro de téléphone une adresse sous la forme d’un string :
Il est possible d’empêcher la dérivation d’un type lors de sa déclaration (type final): ...
Pour empêcher l’extension et la dérivation d’un type : ...
3. Eléments : La définition d’éléments se fait dans une balise . Il existe deux possibilités pour définir un élément : 1. Définir un type de données et l’utiliser dans la définition de l’élément. Par exemple, on modélise l’élément d’un annuaire : XML : Harry Cover0102030405
Modélisation en XML-Schema :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
28
L’avantage de cette solution est que le type « entree » est réutilisable dans le reste du document XML-Schema où la déclaration du type est visible. 2. Définir le type de données à l’intérieur de l’élément.
XML-Schema permet de gérer la cardinalité des éléments beaucoup mieux que les DTD, mais de manière plus verbeuse. L’élément possède deux attributs optionnels minoccurs et maxoccurs qui précisent respectivement le nombre minimal et maximal d’occurrences d’un élément. Par exemple, on désire modéliser que l’élément possède un certain nombre de sous éléments :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
29
XML et les applications d’entreprise
XML-Schema
Equivalent en DTD
XML-Schema permet aussi de modéliser qu’un élément a un contenu mixte :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
30
XML et les applications d’entreprise
Type XML-Schema Elément avec contenu variable
Elément contenu défini
à non
Equivalent DTD
4. Attributs : La définition d’attributs associés à un élément se fait dans un élément . Chaque élément possède les attributs suivants : • name : nom de l’attribut • type : type de l’attribut. Par exemple xsd:string, xsd:boolean,... • use : permet de préciser si l’attribut est obligatoire ou optionnel. Valeurs possibles : required (obligatoire), implied (optionnel), fixed (valeur fixe) ou default. • value : valeur par défaut de l’attribut. Exemple : . On souhaite modéliser cet élément dans un XML-Schema. L’attribut att est optionnel et a comme valeur par défaut « a ». L’attribut at2 est obligatoire et a comme valeur par défaut « true ».
Il est aussi possible de définir des attributs plus complexes, en utilisant les possibilités qu’offre XML-Schema pour la définition de types.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
31
L’attribut choix peut alors uniquement prendre 3 valeurs : « oui », « non », et « ne sait pas ». Notons qu’il est possible de définir des attributs globaux pouvant être utilisés dans la déclaration de plusieurs éléments : Déclaration de l’attribut :
On utilise ensuite cet attribut dans la déclaration d’un élément :
5. Identifiants Comme pour les DTD, il est possible d’attribuer un identifiant aux éléments (attribut de type ID) pour les référencer dans la suite du document XML (attribut de type IDREF). Exemple de définition d’élément possédant un attribut identifiant :
Exemple de définition d’élément référençant un autre élément possédant un identifiant :
Exemple dans un document XML, où un élément fait référence à un élément :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
32
1.4.4 Conclusion Pour résumer, la DTD permet de définir facilement et rapidement des grammaires simples. XML-SCHEMA permet de définir de manière plus formelle et complète une grammaire, mais c’est au prix d’une complexité accrue. Voici les limitations des DTD qui peuvent pousser à utiliser XML-Schema malgré sa complexité : • Les DTD ne sont pas décrites en XML : il est nécessaire d’apprendre une nouvelle syntaxe ; • Les DTD ne sont pas extensibles : 10 types de base sont prédéfinis et il n’est pas possible d’en créer de nouveaux. XML-Schema apporte un modèle proche du modèle objet, avec des notions d’héritage de types et de réutilisabilité ; Tout le monde n’est pourtant pas satisfait de XML-Schema. James Clark, un des pionniers de XML, lui reproche sa trop grande complexité et sa difficulté d’utilisation. Face à la recommandation du W3C, il a développé TREX, qui a par la suite fusionné avec RELAX, une autre initiative concurrente à XML-Schema (sous le nom de RELAX NG). Même si ce langage de description est plus simple, il aura sûrement du mal à faire le poids face à une recommandation du W3C.
1.5 Modéliser un document XML A faire http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Dec-1997/index.html#367 http://www.oasis-open.org/cover/elementsAndAttrs.html http://sim3.univ-rennes1.fr/users/dameron/presentationXML/node9.html http://lists.xml.org/archives/xml-dev/200009/msg00121.html http://www.xmleverywhere.com/newsletters/20000525.htm http://www.oasis-open.org/cover/elementAttr9804.html
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
33
2 Manipulation des documents XML Dans cette partie, nous aborderons • les API permettant de lire et modifier le contenu des documents XML ; • les langages de requête permettant d’extraire des informations de documents XML, à la manière de SQL pour les bases de données.
2.1 Les parseurs Il existe principalement trois approches pour accéder à un document XML : • Les parseurs type « callback » : se basent sur un modèle d’envoi d’événements. Un parseur parcourt le document XML et renvoie un événement à chaque élément rencontré. Le programmeur définit le traitement à effectuer pour chaque événement, et peut ainsi construire sa propre structure de données. Cette approche n’est cependant pas adaptée lorsqu’on désire modifier le document XML. SAX (Simple API For XML) est l’API la plus connue se basant sur cette technique. Elle est indépendante du langage de programmation ; • Les parseurs type « arbre » : utilisent la structure arborescente d’un document XML. Le parseur charge le document XML en mémoire, sous la forme d’un arbre. DOM (Document Objet Model) est l’API la plus connue répondant à cette approche. L’utilisateur parcourt et modifie l’arbre à l’aide des interfaces définies par le W3C. Cette API est aussi indépendante du langage de programmation ; • Le databinding : cette méthode est une Java Specification Request15 de Sun, qui permet de charger un document XML en mémoire sous la forme d’un objet que l’on manipule en utilisant des accesseurs. On sauvegarde ensuite le document en sérializant l’objet en XML. Cette approche permet de manipuler uniquement des objets Java. Les outils permettant de faire du data binding sont assez récents : Castor de Exolab, Zeus de Enhydra, etc., mais cette approche est sans doute la plus intuitive pour les programmeurs Java. Dans la suite de cette partie nous aborderons les parseurs SAX et DOM ; l’API JAXP de Sun qui permet de s’affranchir de l’implémentation du parseur utilisé ; et JDOM, qui est une alternative intéressante à SAX et DOM si on travaille en Java. Nous utiliserons dans les exemples le fichier XML suivant :
15
JSR de Sun pour le data binding : http://java.sun.com/aboutJava/communityprocess/jsr/jsr_031_xmld.html
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
2.1.1 SAX 2.1.1.1 SAX = Simple API For XML SAX a été créé par Megginson Technologies 16. Le projet est hébergé par OASIS17. SAX est une API pour la manipulation de documents XML ne prenant pas en compte la structure d’arbre d’un document. Des événements sont renvoyés à chaque fois que le parseur rencontre une nouvelle balise. Le programmeur définit le traitement à effectuer en implémentant un « handler » (ou « gestionnaire d’événements ») qui récupère les événements. L’avantage de cette méthode est le gain de mémoire par rapport à un parseur de type DOM qui construit un arbre en mémoire. SAX1 versus SAX2 : SAX2 ajoute un support pour les espaces de nommage, et des options de configuration. Il y a eu de grands changements dans l’API. Pour éviter les problèmes de migration, il existe une API d’adapteurs pour que les applications utilisant SAX1 puissent interopérer avec SAX2. 2.1.1.2 Exemple d’utilisation On désire parser le document annuaire.xml et afficher ses informations à l’écran. La première étape est de créer un handler, qui récupérera les événements et effectuera les traitements adéquats. Pour cela il faut sous-classer « DefaultHandler », et de redéfinir les méthodes correspondant aux événements que l’on souhaite écouter. Dans notre exemple, nous écouterons 4 événements : • « Début de document » : on affiche ### Annuaire ### à l’écran ; • « Début d’un élément » : on affiche la balise suivie de ‘ :’ (sauf s’il s’agit de la balise racine « annuaire »). Par exemple : « nom : » ; • « Chaîne de caractère » : on l’affiche à l’écran ; • « Fin de document » : on affiche ### Fin annuaire ### à l’écran.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
35
public class SAXAnnuaireHandler extends DefaultHandler{ public void startDocument() throws SAXException{ System.out.println("### Annuaire ###"); } public void startElement(String uri, String name, String qName,Attributes atts) throws SAXException { if (name.equals("entree")) System.out.print("---"); else if (!name.equals("annuaire")) System.out.print(name + ": "); } public void characters(char ch[], int start, int length) { for (int i = start; i < start + length; i++) System.out.print(ch[i]); } public void endDocument() throws SAXException{ System.out.println("### Fin Annuaire ###"); } }
Une fois le SAXAnnuaireHandler codé, il faut instancier un parseur, lui associer une instance de SAXAnnuaireHandler et un fichier source, pour enfin débuter le décodage. Pour créer le parseur, il existe deux possibilités : 1. Instancier directement la classe représentant le parseur que l’on désire utiliser. L’inconvénient de cette méthode est que l’on lie notre code à un parseur particulier. Par exemple, si on utilise le parseur Apache Xerces : XMLReader xr = new org.apache.xerces.parsers.SAXParser();
2. Utiliser une Factory. La méthode createXMLReader de la classe XMLReaderFactory retourne une instance de parseur : XMLReader xr = XMLReaderFactory.createXMLReader();
Pour passer le nom de la classe du parseur en paramètre de l’exécution : java -Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser …
Voici le code pour effectuer le traitement du document : public static void main(String[] args) throws Exception { XMLReader xr = XMLReaderFactory.createXMLReader(); SAXAnnuaireHandler handler = new SAXAnnuaireHandler(); xr.setContentHandler(handler); xr.setErrorHandler(handler); FileReader r = new FileReader("annuaire.xml"); xr.parse(new InputSource(r)); }
Appliquons le traitement précédent au fichier annuaire.xml. Le résultat dans la console de test est :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
2.1.2 DOM 2.1.2.1 DOM = Document Object Model DOM est une initiative du W3C. DOM est une API pour la manipulation de documents XML. DOM représente un document XML sous la forme d’un arbre chargé en mémoire, et fournit les interfaces permettant de le manipuler. Les interfaces DOM sont indépendantes de tout langage de programmation. C’est un avantage, du point de vue de la standardisation, et un inconvénient car DOM n’est pas optimisé pour un langage particulier. Les implémentations de DOM utilisent des parseurs SAX pour charger l’arbre en mémoire. 2.1.2.2 Eléments de l’API DOM Les interfaces de base pour la manipulation de documents DOM sont : 1. Node Toutes les interfaces DOM dérivent de l’interface Node (nœud). Cette interface contient toutes les méthodes permettant : • D’ajouter ou de retirer des fils à un nœud : appendChild(), removeChild(), replaceChild(), insertBefore(), etc. • De consulter le type, le nom et la valeur d’un nœud : getNodeType(), getNodeName(), getNodeValue(), etc. • De parcourir l’arbre en récupérant les fils d’un nœud : getChildNodes(), getFirstChild(), getLastChild(), etc. De manière générale, le type de retour des méthodes permettant de récupérer les fils d’un nœud est Node. On effectue alors une conversion de type (cast) pour travailler sur l’objet récupéré avec l’interface qu’il implémente (sous interface de Node) : Element, Attr, Comment, etc. 2. Document Document est une interface très importante car il s’agit de la factory (fabrique) des éléments du document. Elle sert à instancier des nœuds, éléments, attributs, commentaires, etc. qu’il est ensuite possible d’ajouter au document DOM (en utilisant les méthodes des n i terfaces Node et Element). Ces nœuds n’existent donc pas hors du contexte d’un document. L’interface Document contient un lien vers le nœud racine du document DOM. Parmi ses méthodes on trouve : • Des méthodes de création : createElement(), createComment(), createAttribute(), etc.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
37
•
Une méthode permettant de récupérer la racine du document : getDocumentElement() • Des méthodes de recherche sur les nœuds contenus dans le document : getElementByTagName(), getElementById(). A retenir : on n’instancie pas les nœuds, attributs et autres constituants du document XML en utilisant un new. A la place on utilise cette interface comme factory. 3. Element Cette interface représente un élément de document XML. Un élément a été créé avec ou sans espace de nommage par la factory Document. La plupart des méthodes permettant de consulter et modifier les fils de ce nœud sont déjà fournis par l’interface Node, l’interface Element ajoute donc surtout les méthodes permettant de gérer les attributs (ajout, retrait, consultation) : getAttribute(), setAttribute(), removeAttribute(), etc. 4. Attr L’interface Attr représente un attribut. Elle dérive aussi de Node et est donc considérée comme un nœud, mais un nœud particulier car il est nécessairement une feuille de l’arbre : il ne peut avoir de sous éléments. 5. Text, CDATASection L’interface Text représente une chaîne de caractères qui sera parsée lors du parcours du document. C’est le contenu textuel d’un élément (Element) ou d’un attribut (Attr). CDATASection représente aussi une chaîne de caractères, mais le texte contenu dans cet élément ne sera pas parsé lors du parcours du document (on peut donc y ajouter des caractères spéciaux tels que < ou > et des fragments de XML sans qu’ils soient analysés par le parseur). 6. Comment L’interface Comment représente un commentaire inclut dans le document XML. 2.1.2.3 Exemple d’utilisation en java L’interface Document est l’interface de base de création de document XML. Elle possède un lien vers le nœud racine du document XML, et sert de factory18 (fabrique) pour créer de nouveaux éléments (Nœuds, attributs, espaces de nommage, …). 1. Création d’un document DOM : DOM ne standardise pas la création d’un objet de type Document. Pour rendre son code indépendant de l’implémentation utilisée, SUN propose JAXP (détaillé plus loin dans ce document). Pour notre exemple, nous avons choisi l’implémentation de DOM fournie par Xerces 19 en Java.
18
« Design Patterns, Elements of Reusable Object-Oriented Software » par Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley 1995, ISBN 0-201-63361-2. 19 http://www.apache.org/xml/xerces/
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
38
//création du document : dépendante de l'implémentation utilisée Document document = new org.apache.xerces.dom.DocumentImpl(); //Création de nouveaux éléments Element annuaire = document.createElement("annuaire"); annuaire.setAttribute(“type”, “pages blanches”); Element entree = document.createElement("entree"); //Création d'éléments contenant du texte Element nom =document.createElement("nom"); Text loredan = document.createTextNode("Lorédan Archey"); nom.appendChild(loredan); Element telephone = document.createElement("telephone"); Text tph = document.createTextNode("06 00 01 02 03"); telephone.appendChild(tph); //création de la structure arborescente de l'arbre entree.appendChild(nom); entree.appendChild(telephone); annuaire.appendChild(entree); document.appendChild(annuaire);
On obtient le document suivant : Lorédan Larchey06 00 01 02 03
DOM ne prend pas en compte la sauvegarde de ce document sous la forme de fichier XML. Pour se faire il faut se reporter sur des implémentations particulières, ou sur JDOM qui supporte la notion de Writer permettant d’exporter un document DOM sous la forme d’un document XML à travers un flux quelconque (par exemple vers un fichier). DOM ne permet pas non plus de charger un document XML en mémoire de manière standard, il faut pour cela se reporter sur les implémentations ou sur JAXP. 2. Parcours d’un document DOM : La manipulation d’un document DOM, s’effectue de la racine puis de nœud en nœud. Reprenons l’annuaire créé ci-dessus, et affichons la liste des entrées qu’il contient : Element annuaire = document.getDocumentElement(); NodeList entrees = annuaire.getChildNodes(); for (int i = 0; i < entrees.getLength(); i++){ Node entree = entrees.item(i); Element nom = (Element) entree.getFirstChild(); System.out.println("nom : " + nom.getFirstChild().getNodeValue()); Element telephone = (Element) entree.getLastChild(); System.out.println("tel : " + telephone.getFirstChild().getNodeValue()); }
On obtient le résultat suivant :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
39
nom : Lorédan Larchey tel : 06 00 01 02 03
2.1.3 Utilisation des parseurs SAX et DOM : Sun JAXP 2.1.3.1 JAXP = Java XML For Parsing JAXP20 est une API Java pour l’utilisation des parseurs XML. JAXP répond au problème de l’utilisation des parseurs SAX et DOM, ainsi que des transformateur XSLT de manière standard, indépendante de l’implémentation utilisée. • La version 1.0 de JAXP supporte les parseurs DOM Level 1 et SAX Level 1. • La version 1.1 de JAXP supporte les parseurs DOM Level 2 et SAX Level 2 ; et fournit TrAX, l’API de manipulation des transformateurs XSLT (nous y reviendrons dans la partie sur XSLT). 2.1.3.2 Utilisation de DOM avec JAXP : D’après l’exemple que nous avons vu dans la partie sur DOM, le choix de l’implémentation utilisée pour l’interface Document se fait au moment du codage : org.w3c.Document document = new org.apache.xerces.dom.DocumentImpl();
Si on désire changer d’implémentation, il faut recompiler le code. JAXP introduit des factory permettant de choisir le parseur lors du démarrage d’une application (variable d’environnement). Il n’y a donc pas à recompiler de code quand on change d’implémentation. JAXP introduit deux classes : DocumentBuilderFactory et Document Builder. • DocumentBuilder est la classe permettant de créer des documents DOM. • DocumentBuilderFactory permet d’instancier des DocumentBuilder. On lui précise quelle implémentation on désire utiliser. Cette classe permet aussi de préciser des options de configuration (validation du document grâce à sa DTD, gestion des namespaces). DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); //on précise qu’on ne tient pas compte de la validation, ni de la //gestion des espaces de nommage factory.setValidating(false); factory.setNamespaceAware(false); DocumentBuilder builder = factory.newDocumentBuilder();
JAXP répond à un deuxième problème : nous avons vu que DOM ne définissait pas un moyen de créer un document à partir d’un fichier XML. JAXP vient combler cette lacune avec la classe DocumentBuilder. Cette dernière permet de créer un document DOM à partir d’un fichier, d’un InputStream (fichier, String, …), etc. : 20
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
40
//création d’un document à partir d’un fichier Document document = builder.parse(new File(“annuaire.xml)); //création d’un document à partir d’un flux XML arrivant d’un //socket : Socket socket = ...; InputStream inputStream = socket.getInputStream() Document document = builder.parse(inputStream); //création d’un document vide Document document = builder.newDocument();
2.1.3.3 Utilisation de SAX avec JAXP : De même, on utilise deux classes de JAXP pour travailler avec SAX : SAXParserFactory et SAXParser. SAXParserFactory permet d’instancier des parseurs SAX. SAXParser est une interface commune à tous les parseurs. SAXParserFactory factory = SAXParserFactory.newInstance(); //On tient compte de la validation mais pas des espaces de nommage factory.setValidating(true); factory.setNamespaceAware(false); //instanciation du parseur SAXParser parser = factory.newSAXParser();
On peut ensuite déclencher l’opération de parsage avec la classe SAXParser : File fichier = ...; Handler monHandler = ...; parser.parse(fichier, monHandler);
Notons que JAXP est moins utile pour SAX que pour DOM. En effet, SAX fournit déjà la classe XMLReaderFactory, qui permet d’instancier un parseur (XMLReader) en précisant sa classe au moment de l’exécution. XMLReaderFactory est l’équivalent de SAXParserFactory et XMLReader est l’équivalent de SAXParser.
2.1.4 Un système d’arbre 100% Java : JDOM 2.1.4.1 Une API pour Java : JDOM21 est une API Java pour la manipulation de documents XML, se basant sur un arbre construit en mémoire. JDOM est un JSR22 (Java Specification Request). Contrairement à ce que son nom pourrait laisser croire, JDOM n’est pas basé sur DOM. L’objectif était de créer une API Java qui soit légère, rapide, facile d’utilisation, et qui interopère avec DOM et SAX (conversion facile JDOM->SAX/DOM et l’inverse). Le but de JDOM n’est pas de résoudre tous les problèmes de la manipulation de documents XML, mais de résoudre 80% des problèmes avec 20% de l’effort requis avec SAX et DOM.
21 22
Projet JDOM : http://www.jdom.org JSR-102 : http://java.sun.com/aboutJava/communityprocess/jsr/jsr_102_jdom.html
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
41
Les créateurs de JDOM reprochent à DOM d’être trop lourd en mémoire et de ne pas être optimisé pour le langage Java, et à SAX de ne pas permettre la modification de documents XML et l’accès à un élément particulier d’un document. JDOM offre différentes possibilités pour lire un document XML (à partir de parseurs SAX ou DOM), l’exporter (sous forme d’arbre DOM, flux événements SAX ou document XML), et le manipuler. JDOM possède sa propre structure de données pour manipuler un document XML. 2.1.4.2 Exemples d’utilisation : 1. Création d’un document XML : Créons une partie du document annuaire.xml précédemment défini : //création de l’élément racine Element root = new Element("annuaire"); root.addAttribute(“type”, “pages blanches”); //Création de la première entrée de l’annuaire Element entree = new Element("entree"); entree.addContent( new Element("nom").setText("Lorédan Larchey")); entree.addContent( new Element("telephone").setText("06 00 01 02 03")); //ajout de l’entrée au document root.addContent(entree); Document doc = new Document(root); //affichage du document à l’écran XMLOutputter outputter = new XMLOutputter(); outputter.output(doc, System.out);
On obtient le résultat suivant à l’écran : Lorédan Larchey06 00 01 02 03
2. Chargement d’un document XML : il est aussi possible de charger un document XML à partir d’une URL, d’un fichier, etc. Pour cela on utilise une factory, qui se sert d’un parseur pour charger un arbre JDOM en mémoire. Il existe deux factories : SAXBuilder, qui utilise un parseur SAX pour créer l’arbre JDOM, et DOMBuilder qui le fait à partir d’un parseur DOM. Il est possible de préciser quel classe on désire utiliser pour parser (parseur Xerces, Crimson, etc.).
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
42
DOMBuilder builder = new DOMBuilder(); Document doc = builder.build(new File("annuaire.xml"));
Manipulation d’un document XML : il est possible de modifier un document XML plus facilement qu’avec DOM (ajout, retrait d’élément, etc.). Par exemple : retrait d’un élément : Element annuaire = doc.getRootElement(); List allChildren = annuaire.getChildren(); allChildren.remove(0);
Résultat obtenu dans la console en utilisant le XMLOutputter : Paul Lafargue06 03 02 01 00
La gestion des espaces de nommage est aussi simple. Par exemple, on peut construire un document en ajoutant un espace de nommage : Namespace ns = Namespace.getNamespace( "pb", "http://www.pagesblanches.fr"); Element root = new Element("annuaire", ns); root.addAttribute(new Attribute("type", "pages blanches", ns)); Element entree = new Element("entree", ns); entree.addContent( new Element("nom", ns).setText("Lorédan Larchey")); entree.addContent( new Element("telephone", ns).setText("06 00 01 02 03")); root.addContent(entree); Document doc = new Document(root);
Le résultat : Lorédan Larchey06 00 01 02 03
2.1.4.3 Utilisation de JDOM avec DOM et SAX: Nous avons vu qu’il était possible de créer un document JDOM en utilisant un parseur SAX ou DOM (classes SAXBuilder et DOMBuilder). Il est aussi possible d’exporter un arbre JDOM en arbre DOM ou en flux d’événements SAX (déclenchement d’une opération de parsage) :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
43
XML et les applications d’entreprise
org.jdom.Document document = ...; //export sous la forme de document DOM DOMOutputter outputter = new DOMOutputter(); org.w3c.dom.Document document2 = outputter.output(document); //export sous la forme de flux d’événements SAX. Il suffit de //développer un handler qui récupère les événements. ContentHandler myContentHandler = ...; SAXOutputter outputter = new SAXOutputter(myContentHandler); outputter.output(document);
2.1.5 Conclusion JAXP, ne remplace ni SAX ni DOM, mais permet uniquement d’encapsuler l’implémentation du parseur. C’est une API utilisable uniquement sous Java. 2.1.5.1 Que choisir entre SAX et DOM ? Il apparaît clairement que SAX est plus rapide et facile d’utilisation. Ceci dit ses capacités sont limitées : • On accède au document XML uniquement en mode consultation ; • Il est impossible d’accéder à un élément particulier sans avoir parcouru tous les nœuds précédents. SAX est particulièrement adapté lorsqu’on désire travailler avec ses propres structures de données, et lorsque XML est uniquement le mécanisme de sérialization. Les objets sont créés à partir d’informations contenues dans un document XML à l’aide de SAX, et la sérialization se fait ensuite à la main. Chargement : SAX Fichier XML
Objet Sérialization : Propriétaire
En revanche, DOM est adapté lorsque l’on travaille sur une base de documents, où la structure arborescente a une importance (par exemple : contrats, factures, etc.). Il est alors possible de parcourir un fichier XML de façon structurée (avec une relation de nœud père – nœud fils). De plus, contrairement à SAX, il est possible de modifier directement la structure du document chargé en mémoire. Par contre : • DOM est plus lent ; • L’utilisation de DOM est coûteuse en mémoire. 2.1.5.2 Et JDOM ? JDOM permet de travailler avec SAX et DOM. Si vous travaillez en Java, JDOM semble être la solution optimale, car cet outil est optimisé pour Java. De plus il est possible de travailler sur une structure de données plus simple que celle imposée par DOM.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
44
2.2 Le data binding Le data binding est une approche assez récente. L’objectif est de pouvoir manipuler les documents XML par le biais d’objets Java. Par exemple pour le fichier XML : Harry Cover06 01 02 03 04
On utilise une classe implémentant l’interface suivante, dont les méthodes sont des accesseurs permettant de lire et modifier le document XML, soit directement, soit indirectement par un mécanisme de sérialization : public interface Entree { public String getNom(); public void setNom(String nom); public string getTelephone(); public void setTelephone(String tph); }
Cette méthode est beaucoup plus simple que de devoir utiliser directement un parseur pour lire ou modifier un document XML. Des mécanismes simples peuvent rapidement être mis en place pour faire du binding. Cependant pour des projets plus complexes, où la structure des documents est appelée à changer fréquemment, il est souvent préférable de s’appuyer sur des produits tels que : • Castor d’Exolab23 • Zeus du projet Enhydra24. Ces produits permettent en particulier de générer des classes Java à partir de DTD ou XML-Schema. Article d’IBM25 JSR de Sun26
2.3 Langages de requêtes Les langages de requêtes permettent d’extraire des informations de documents XML, à la manière de SQL pour les bases de données. Il y eu de nombreuses initiatives pour définir un langage qui réponde à tous les besoins de recherche dans un document XML : XQL27, XPath 28, Quilt29, XML-QL30, XQuery31, YATL32, Lorel33, … Il existe en fait deux types de 23
Projet Castor : http://castor.exolab.org Projet Zeus : http://zeus.enhydra.org/ 25 http://www-106.ibm.com/developerworks/library/data-binding1/index.html?dwzone=xml 26 http://jcp.org/jsr/detail/031.jsp 27 Spécification de XQL : http://www.ibiblio.org/xql/xql-proposal.html 28 Spécification de XPath : http://www.w3.org/TR/xpath 29 Une introduction à Quilt : http://www.almaden.ibm.com/cs/people/chamberlin/quilt_euro.html 30 Spécification de XML-QL : http://www.w3.org/TR/NOTE-xml-ql/ 31 Spécification XQuery : http://www.w3.org/TR/xquery/ 32 Site de YaTL : http://www-rocq.inria.fr/~simeon/YAT/ 33 Lorel : http://citeseer.nj.nec.com/cache/papers2/cs/553/http:zSzzSzwwwdb.stanford.eduzSzpubzSzpaperszSzlorel96.pdf/abiteboul97lorel.pdf 24
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
45
langages : les langages de requête simple, et les langages de requêtes ‘type SQL’. L’objectif de cette section n’est pas de rentrer dans les détails de chacun des langages, mais d’en présenter les plus importants. Pour les autres nous donnerons un exemple simple et des pointeurs vers les spécifications et les sites qui les présentent. Dans la suite de cette section nous utiliserons le fichier annuaire.xml suivant à titre d’exemple : Paul Lafargue06 03 02 01 00Lorédan Larchey06 00 01 02 03
Nous présenterons en premier lieu les différents langages en donnant un exemple d’utilisation de chacun d’eux : récupérer l’élément dont le sous élément a pour contenu « Harry Cover ». Le résultat des requêtes sera : Harry Cover06 00 01 02 03
1. Les langages de requêtes simples Ces langages se basent sur la structure du document XML, les plus célèbres sont XQL et XPath. Une requête ressemble globalement à l’adressage dans le système de fichiers. Exemple en XQL et XPath : /annuaire/entree[nom=”Harry Cover”]
Ces langages ne permettent pas de construire de nouveaux documents XML, mais uniquement de les consulter. 2. Les langages ‘type SQL’ Les langages ‘type SQL’ permettent de construire des requêtes similaires aux requêtes SQL (SELECT … FROM … WHERE …), adaptées à la structure des documents XML. Parmi ces langages on trouve XML-QL, Quilt, XQuery, Lorel et YaTL. Ces langages permettent généralement de construire de nouveaux documents XML en construisant le format de sortie des requêtes. Quelques exemples 34 :
34
Pour plus d’exemples sur ces langages : http://www.w3.org/1999/09/ql/docs/xquery.html
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
46
XML et les applications d’entreprise
Langage
Exemple de requête SELECT E FROM annuaire.entree E WHERE E.nom = “Harry Cover”
Lorel
XML-QL
WHERE $nom ELEMENT_AS $entree IN annuaire.xml $nom=”Harry Cover” CONSTRUCT $entree
Quilt XQuery
FOR $entree IN document(“annuaire.xml”)/annuaire/entree, $nom IN $entree/nom WHERE $nom=”Harry Cover” RETURN $entree
YATL
MAKE entree[nom [$nom], telephone [$tel]] MATCH “annuaire.xml” WITH entree[nom[$nom], telephone [$tel]] WHERE $nom=”Harry Cover”
Nous détaillerons dans la suite de cette partie uniquement deux langages : • XPath comme langage de requête simple, car c’est celui qui est utilisé par XSLT35. De plus XQL et XPath sont très similaires (cf. tutorial XQL36) ; • XQuery comme langage ‘type SQL’ car il s’agit d’une proposition récente d’un groupe de travail du W3C. Cette proposition se base sur Quilt et permet de répondre aux mêmes problématiques – souvent de manière plus simple – que les autres langages Lorel, YATL et XML-QL. Nous en profiterons aussi pour examiner XPointer plus en détails, après la partie sur XPath.
2.3.1 XPath XPath est utilisé par XSLT35 pour faire de la transformation de documents. C’est la raison pour laquelle c’est est le langage de requête dans un document XML le plus connu à ce jour. 2.3.1.1 Requêtes simples La syntaxe de base XPath est semblable à l’adressage dans un système de fichiers. Pour accéder par exemple à la liste des nœuds « nom » de l’annuaire, la syntaxe de la requête est : 35 36
XSLT sera examiné plus en détails dans la partie 2.2 Tutorial XQL : http://www.ibiblio.org/xql/xql-tutorial.html
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
47
XML et les applications d’entreprise
/annuaire/entree/nom
Un interpréteur XPath retournera la liste des nœuds répondant à cette requête, à savoir : Paul LafargueLorédan Larchey
Symbole Rôle /a/b Liste des éléments dont le chemin dans l’arborescence correspond à la requête // On ne tient pas compte de la profondeur de l’élément dans l’arborescence | Permet de composer les requêtes * Tous les éléments fils de la sélection
Exemple /annuaire/entree/ nom
Résultat Paul Lafargue Lorédan Larchey
//nom
Idem
/A/EE | //DE
//entree/*
Paul Lafargue … Lorédan Larchey …
Sont mis en gras les éléments sélectionnés avec la requête XPath. 2.3.1.2 Requêtes plus complexes XPath permet aussi de gérer des requêtes plus complexes. Par exemple, pour rechercher le numéro de téléphone de Paul Lafargue dans le document, on utilise la syntaxe suivante : /annuaire/entree[nom="Paul Lafargue"]/telephone
On utilise des expressions entre crochets pour indiquer des conditions sur les résultats obtenus. Dans l’exemple précédent, on a mis comme condition sur les entrées obtenues d’avoir un fils dont le contenu de l’élément nom est égal à « Paul Lafargue ». Dans la suite de cette partie, nous ferons une liste non exhaustive des fonctions de XPath (celles qui nous semblent être les plus importantes). Nous nous baserons sur un exemple plus complexe. Exemple :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
1. Prédicats Un prédicat est composé d’une expression booléenne mise entre crochets []. Il permet d’effectuer un tri sur des éléments obtenus par une requête simple. On peut effectuer un test sur le nom d’un élément, son contenu, ses attributs, sa position dans l’arbre, etc. Symbole Rôle Exemple Résultat [i] i ème élément de la sélection /A/*[4] [last()] Dernier élément de la /A/*[last()] sélection @att=… Condition sur les attributs /A/B[@att=’Eng’ Hello ]
Il est possible de faire des prédicats plus complexes en utilisant les opérations booléennes and et or. Par exemple : Requête: //*[@att=’Eng’ and name()=’B’] Réponse: Hello
Cette requête XPath recherche tous les éléments dont le nom est ‘B’ et qui contiennent un attribut att ayant la valeur ‘Eng’. Les prédicats ne se construisent pas seulement à partir d’égalités, et il est possible d’effectuer des opérations dans un prédicat : Type Booléen Logique Opérations
Opérateurs and, or !=, >=, >, <, <= +, -, *, div, mod
2. Recherche par contexte : Des opérations permettent aussi de rechercher des nœuds en fonction de leur contexte (c’est à dire leur positionnement dans l’arbre).
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
49
XML et les applications d’entreprise
Symbole descendant
Rôle Exemple Fils d’un noeud et leurs /A/D/descenda descendants nt::*
Résultat
ascendant
Père d’un noeud et ses //A/B/D/ancest ancetres or::*
3. Fonction Enfin, XPath fournit un certain nombre de fonctions pouvant être utilisées pour les requêtes plus complexes. Il est possible par exemple de rechercher un élément dont le nom contient une chaîne de caractères, etc. Il existe 4 catégories de fonctions : string, number, boolean et node, se référer a la recommandation du W3C pour en savoir plus Quelques exemples (non exhaustifs) :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
50
XML et les applications d’entreprise
Symbole Rôle text() Valeur d’un élément last()
Exemple Résultat Bonjour //B[@att='Fr']/C / text() la /A/*[last()]
Dernier élément de sélection position() Renvoi l’index de position //A/B[position() Hello du noeud relativement au =2] noeud parent. selectionne le ème 2 fils. count() Compte les éléments de la //*[count(*)=2] Bonjour sélection. Liste des éléments ayant 2 fils. name() Nom de l’élément //*[name()=’D’] équivalent de //D contains() Condition sur les chaînes de //*[contains( caractère name(),'E')] startsCondition sur les chaînes de //*[starts-with( with() caractère name(),'D')]
2.3.2 XQuery XQuery est une spécification réalisée par un groupe de travail du W3C, le Query Language Working Group. Cette spécification se base sur XPath, et les requêtes basiques XQuery sont identiques à celles définies par XPath. Requête //nom //annuaire[@type=”Pages Jaunes”]
/annuaire/entree/nom
Réponse Paul LafargueHarry Cover ... Paul LafargueHarry Cover
XQuery permet de faire des requêtes dans un fichier (comme ci dessus, dans le fichier annuaire.xml), ou dans une base de fichiers. Pour cela, la plupart des moteurs permettent d’indexer une liste de fichiers et d’effectuer des requêtes sur tous les fichiers indexés. On peut préciser que l’on effectue la requête sur un fichier particulier de la manière suivante :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
51
document(“annuaire.xml”)//nom
Si l’on désire faire des requêtes simples, XPath suffit. XQuery commence à devenir intéressant lorsque l’on utilise les expressions FLWR : For, Let, Where et Return. La construction des requêtes est récursive (une requête peut être imbriquée dans une autre), ce qui permet d’effectuer des requêtes plus complexes. L’ajout des expressions FLWR fait que XQuery peut être vu comme un hybride à mi chemin entre SQL et XPath, où il est possible de faire des requêtes du type : SELECT requeteXPath FROM fichier WHERE conditionBooleenne AND autreConditionBooleenne
2.3.2.1 Clause Let Examinons un exemple simple d’expression FLWR : pour obtenir la liste des personnes inscrites dans l’annuaire, il y a deux possibilités : • La requête simple, type XPath, document(“annuaire.xml”)//nom
•
L’utilisation d’une expression FLWR utilisant un LET : LET $noms := document(“annuaire.xml”)//nom RETURN $noms
Une expression FLWR permet d’utiliser des affectations de variables (ici $noms), et d’utiliser ces variables dans la suite de la requête. L’affectation se fait au moyen de la clause LET, et les variables sont ensuite non mutables. La requête précédente est donc simple à comprendre : le résultat de la requête //nom est affecté à la variable $noms, et le contenu de cette variable est renvoyée à l’utilisateur. Dans la suite de cette partie, on considérera que les requêtes se feront sur le fichier annuaire.xml. 2.3.2.2 Clause For Une troisième façon d’exprimer la requête précédente est : FOR $entree IN //entree RETURN $entree/nom
La clause For permet d’effectuer des itérations sur un ensemble de nœuds obtenus dans une requête. Ici, //entree renvoie la liste des entrées de l’annuaire. A chaque itération un élément de cette liste est affecté à la variable $entree, et le traitement explicité dans le For (ici Return $i) est appliqué à cette variable. 2.3.2.3 Clause Return 1. Pas d’interruption des boucles For
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
52
XML et les applications d’entreprise
Le fonctionnement de Return peut surprendre. En effet, rien à voir avec le return en Java. En Java, return provoque une sortie de la boucle for, il n’y a donc plus d’itération possible. Par exemple : public String doit() { String resultat = “résultat: ”; for(int i=1; i<3; i++) { resultat = resultat + i; return resultat; } }
Le return interrompant la boucle, la méthode doit() renvoie toujours : Résultat : 1
En XQuery le traitement est différent. Prenons pour exemple le document XML suivant : 012
Requête FOR $i IN //valeur RETURN $i
Réponse 012
A chaque itération le contenu de la variable $i est concaténée à une variable de sortie, qui est renvoyée à l’utilisateur lors de la dernière itération. Non seulement Return ne provoque pas de sortie de la boucle For, mais en plus le retour effectif à l’utilisateur se fait uniquement lors de la dernière itération ! 2. Construction du format XML de sortie Notons qu’il est possible de construire le format XML de sortie dans la clause Return : Requête FOR $i IN //valeur RETURN $i/text()
Réponse 012
2.3.2.4 Clause Where Optionnellement, il est possible de filtrer les nœuds obtenus par la requête dans une clause For, à la manière du Where SQL. Par exemple, si on désire obtenir le numéro de téléphone de Harry Cover, une des manières de procéder est la suivante : FOR $entree IN //entree WHERE $entree/nom = “Harry Cover” RETURN $entree/telephone
Le contenu de la clause Where est du type booléen. A ce titre, il est possible d’utiliser des opérations booléennes AND et OR. Par exemple, si on désire récupérer les entrées contenant les numéros de téléphone de Paul Lafargue et Harry Cover : www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
2.3.2.5 Imbrication de requêtes XQuery permet d’imbriquer les requêtes. Par exemple la requête suivante permet d’obtenir la liste des noms des personnes inscrites dans l’annuaire, dans un élément : LET $entrees:=//entree RETURN FOR $nom IN $entrees/nom RETURN $nom
Expression retournée : Paul LafargueHarry Cover
2.3.2.6 Requêtes XQuery avancées XQuery permet la construction de requêtes plus complexes que XPath ne saurait modéliser, mais qu’il serait possible de réaliser en utilisant conjointement XSLT37 et XPath, comme le montre l’article « XQuery : reinventing the wheel ? »38. Nous ne citerons ci dessous que quelques exemples, pour une énumération exhaustive des possibilités de XQuery se référer à l’article en question.
37 38
cf. Partie 2.2 : XSL « XQuery : reinventing the wheel ? » : http://www.xmlportfolio.com/xquery.html
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
54
XML et les applications d’entreprise
Intitulé Requête XQuery FOR $nom IN //nom Liste des personnes de RETURN l’annuaire, triées par ordre nom/text() alphabétique SORTBY(nom ASCENDING) Liste des noms des personnes APRES la première entrée Expression conditionnelle : Recherche du numéro de téléphone de Harry Cover avec IF THEN ELSE Recherche des entrées dont le nom contient « Harry »
Résultat Harry CoverPaul Lafargue
FOR $entree IN //entree AFTER //entree[1] RETURN $entree/nom
Harry Cover
FOR $entree IN //entree RETURN IF $entree/nom= “Harry Cover” THEN $entree/telephone
06 04 02 01 00
FOR $entree IN //entree WHERE contains($entree/nom, “Harry”) RETURN $entree
Harry Cover 06 04 02 01 00
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
55
XML et les applications d’entreprise
3 B2 C Serveur applicatif
Intranet/Internet
SGBD
Application
Figure 4 Le B2C Le Business to Consumer (B2C) est sans doute la forme d'e-business la plus commune. Dans le B2C l'utilisateur est le centre d'intérêt. Les services proposés par le B2C sont aussi divers que la vente en ligne, la diffusion d'informations pour ce qui est du B2C classique, que l’accès aux services collaboratifs (mail, agenda,…) et aux applications métiers (planning, tableaux de bord, applications de gestion/comptabilité,…) pour le B2E-Business to Employee. Il existe un grand nombre de spécifications pour le B2C, nous présenterons les plus communes ou représentatives : XHTML, XSL, SVG, et XUL.
3.1 XHTML XHTML39 (Extensible HyperText Markup Language) est une reformulation, en XML, de HTML 4.0. Ce langage est intéressant à deux titres, il a pour objectif la suppression du HTML mal codé et il apporte de la extensibilité. Le HTML mal codé est une source de problème constant pour les développeurs de navigateurs pour CLD (Connected Limited Device : PDA, téléphones portables,…). En effet, alors qu’un navigateur (IE, Netscape, Mozilla) pour micro-ordinateur dispose de la puissance suffisante pour tolérer les erreurs de syntaxe, un navigateur pour CLD ne dispose pas de la puissance suffisante pour détecter et corriger les même erreurs. Par exemple, les navigateurs pour micro ordinateur (IE, Netscape, Mozilla), présenteront correctement le code suivant, alors qu’il contient des erreurs de syntaxe (balises ouvrantes non fermées, …) :
Spécification
Date
XHTML
26 janvier 2000
En fixant des règles strictes d’écriture le XHTML va faciliter la diffusion d’informations vers les CLD.
3.1.1 Règles à respecter Voici quelques règles à respecter pour écrire du XHTML : 39
Spécification de XHTML en français : http://www.la-grange.net/w3c/xhtml1/ Spécification de XHTML en anglais : http://www.w3.org/TR/xhtml1/
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
•
Les éléments ne doivent pas être mal imbriqués
Code incorrect Code correct
•
Code correct
Code correct
Bonjour,
Comment allez-vous ?
Bonjour,
Comment allez-vous ?
Les éléments vides doivent aussi être fermés. Afin s’assurer une compatibilité ascendante avec les navigateurs, il est recommandé de mettre un espace devant le « / ».
Afin de prendre de bons réflexes, il est recommandé dès maintenant d’appliquer ces règles quand on code en HTML. XHTML est modulaire : alors que dans le HTML le jeu de balises est figé, il est possible en XHTML de rajouter des balises pour des besoins spécifiques. Ainsi il est possible de rajouter dans un document XHTML des balises MathML (Mathematical Markup Language) pour l’expression de formules mathématiques ou des balises SVG (Scalar Vector Graphics) pour l’expression de graphiques vectoriels. Par exemple le code XHTML suivant est correct :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
57
...
Hello World!
Ce code intègre une portion de SVG qui permet de dessiner un rectangle rouge. Attention toutefois pour l’instant aucun navigateur n’est capable d’afficher ce code.
3.1.2 Les différents types de XHTML Il existe quatre types de XHTML40, décrites dans des DTD différentes : • XHTML Strict : fournit les fonctionnalités de HTML sans les notions de style. Un fichier XHTML Strict est généralement utilisé avec une feuille de style CSS qui contient les informations nécessaires sur la présentation et les styles (police, couleur, etc.). Il est possible d’ajouter des images, des formulaires, des tableaux basiques, etc. XHTML 1.1, recommandation du W3C, est en fait très proche de XHTML Strict. • XHTML Transitional : utilisé lorsque le navigateur ne supporte pas les CSS. Il est possible d’ajouter des informations sur les styles dans un document XHTML 1.0 Transitional. • XHTML Frameset : utilisé lorsqu’on désire utiliser des frames pour la présentation (séparation de la page en plusieurs pages). Notons que les terminaux embarqués supportent rarement les frames. • XHTML Basic : sous ensemble de XHTML définissant les fonctionnalités minimales, pour une utilisation sur les terminaux mobiles embarqués (téléphones cellulaires, assistants personnels dont les capacités des navigateurs est limitée).
3.2 XSL Il y a un an, lorsque le WAP voulait envahir la planète, beaucoup de développeurs de sites web se sont demandés comment ils allaient pouvoir reprendre leur contenu HTML et le diffuser en WML. Bon nombre se sont alors tournés vers XSL (Extensible Stylesheet Language) et plus particulièrement vers XSLT (Extensible Stylesheet Language Transformations). XSL est une spécification composée de deux parties : • XSLT, qui permet de réorganiser des documents XML, • XSL-FO qui permet de gérer la présentation d’un document XML,
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
58
XML et les applications d’entreprise
3.3 XSLT 3.3.1 XSL Transformation XSLT41 est de loin la partie de XSL la plus utilisée. Ce langage déclaratif permet de transformer un document XML en un autre document XML, HTML, texte... Pour ceci un processeur XSLT lit un document XML et un document XSLT (encore appelé feuille de style) et génère un nouveau document. Le document généré sera en général du XML mais ce n’est pas obligatoire. Le processeur pourrait être amené à générer du HTML ou tout simplement du texte. La Figure 5 illustre ce processus. NB : La recommandation en est a sa version 1, une version 1 .1 est en « Working Draft »42.
XSLT
XML
Processeur XSLT
Document Transformé : XML, HTML ou texte
Figure 5 Le processeur XSLT L'exemple qui suit contient une portion d'un document XML décrivant un livre. Paul LafargueLe droit à la paresse
Si l'on souhaite présenter ce livre avec le HTML suivant :
Paul Lafargue Le droit à la paresse
on pourra utiliser le document XSLT suivant :
41
Spécifications XSLT : http://www.w3.org/TR/xslt.html Chapter 14 of the XML Bible: XSL Transformations (22000 mots)http://www.ibiblio.org/xml/books/bible/updates/14.html XSL Frequently Asked Questions : http://www.dpawson.co.uk/xsl/xslfaq.html 42 XSL Transformations (XSLT) Version 1.1 : http://www.w3.org/TR/xslt11/.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
59
XML et les applications d’entreprise
Un document XSLT peut être vu comme une succession de template. Un template étant du code XSLT qui permet de sélectionner une partie du document XML et de lui apporter une transformation. Dans l'exemple ci-dessus, il y a un seul template : ...
Il permet de sélectionner un "livre" et d'appliquer une transformation qui génère du HTML. La transformation est située entre les balises de début et de fin du template (xsl:template). Outre le code HTML, elle contient deux instructions XSLT, l'une permet de restituer l'auteur du livre
l'autre permet de restituer le titre du livre
Il existe de multiples instructions XSLT (xsl:when, xsl:otherwise, xsl:if,...) qui assurent à ce langage une grande puissance de transformation. Nous y reviendrons dans la partie suivante. L'écriture d'une feuille de style XSLT est encore très laborieuse, elle va être simplifiée par l'arrivée sur le marché de véritables environnements de développement comme "Stylus Studio" ou "Komodo". A l'origine XSLT était prévue pour générer du XSL-FO. Serveur applicatif
HTML
Processeur XSL
WML
Application
SGBD
XML XSL
Figure 6 Intégration d'un processeur XSLT dans une architecture Web
3.3.2 Rédiger une feuille de style XSLT : 3.3.2.1 Le format de sortie
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
60
Une feuille xslt permet de générer 3 formats : texte, XML ou HTML. La balise permet de définir le format de sortie, ainsi il est possible de gérer les caractères accentuées et spéciaux. Par exemple :
Cette déclaration précise que le document sera au format HTML et que les caractères du fichier XML d’entrée seront encodés selon la norme iso-8859-1. L’attribut indent permet d’indenter ou non le fichier de sortie. NB : la notion d’encoding a son importance si le fichier XML contient des caractères accentués et est déclaré avec l’entête < ?xml version=1.0 encoding=iso-8859-1 ?>. En effet le fichier XML sera correctement transformé si l’on déclare le même encodage au niveau du XML et du XSLT. 3.3.2.2 Les templates Un template définit les règles de la transformation à réaliser sur un ensemble de nœuds (d’un document XML source à un document résultat). L’attribut match définit le nœud (ou la requête Xpath) à transformer. L’attribut name permet de l’appeler via la balise . Un template peut se définir dans un autre document en faisant appel aux balises et : Exemple : Hello World
Ce template sera appliqué par le processeur XSLT lorsqu’il rencontrera la racine du document à transformer. La chaîne de caractère ‘Hello World’ sera alors écrite dans le document résultat. Il existe trois façons d’appeler un template : 1. Sélectionner les nœuds à traiter à l’aide d’une requête XPath, et leur appliquer les templates correspondants :
2. Appliquer les templates correspondants à tous les fils du nœud courant :
3. Appeler un template grâce à son nom (à la manière d’un sous programme). Contrairement aux deux autres méthodes, on ne l’applique pas à un ensemble de sous éléments du nœud courant, mais à ce même nœud. On dit alors qu’il n’y a pas de changement de contexte.
Reprenons notre exemple d’annuaire :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
On ne désire effectuer des transformations que sur les nœuds et . On ne désire pas traiter les nœuds et : Parcours de annuaire Parcours de nom
Le document résultant de cette transformation : Parcours de annuaire Parcours de nom Parcours de nom
Requêtes XPath et contexte : les requêtes XPath utilisées dans les select dépendent du contexte. Au lien d’utiliser la syntaxe , on aurait pu utiliser : . Les requêtes XPath sont relatives au nœud parcouru (ici est le contexte en question). 3.3.2.3 Les éléments XSLT Les éléments XSLT sont utilisés dans les templates pour réaliser les transformations. Il existe un grand nombre d’éléments, permettant de faire des tests conditionnels (if, switch, etc…), des boucles (for, while, …), etc. Nous présenterons dans cette partie quelques-uns uns des éléments fournis avec XSLT. 1. Sélection de texte: Cet élément est utilisé pour sélectionner une valeur simple dans un élément du document à transformer et l’écrire dans le document de sortie. Exemple : XSLT : Contexte : Résultat :
/annuaire/entree[1] Lorédan Larchey
Elément de la même catégorie : , qui permet de sélectionner une valeur complexe. www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
62
NB : à noter l’utilisation de l’attribut disable-output-escaping= yes|no, il permet de gérer l’interprétation en sortie des caractères & et <, par défaut il est à no. Exemple avec la balise xsl:text qui utilise aussi cet attribut: XSLT : Résultat :
< <
2. Boucles : Cet élément permet de parcourir une liste de nœuds et leur appliquer une transformation. Exemple : XSLT :
Contexte : Résultat :
Nom: / Nom: Lorédan Larchey Nom: Paul Lafargue
Element de la même rubrique : . 3. Tests conditionnels :
Cet élément permet d’effectuer un test avant transformation. Le test respecte la syntaxe XPath. Notons qu’il n’existe pas de . Exemple : XSLT :
Contexte : Résultat :
/annuaire/entree[2]/nom Paul Lafargue
, et
Ces éléments permettent d’effectuer des tests plus complets qu’avec l’élément . C’est l’équivalent d’un switch. permet de tester si une condition est réalisée. Dans un élément , on a un nombre non limité d’éléments et un élément . Exemple :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
XSLT :
Contexte : Résultat :
63
Annuaire de pages blanches Annuaire de pages jaunes Type d’annuaire inconnu /annuaire Annuaire de pages blanches
4. Autres : valeur contenu… Dans le cas où on utilise XSLT pour transformer un document XML en un autre document XML (ou HTML), on peut utiliser ces éléments pour rajouter un élément et ses attributs à un nœud du document XML de sortie. Exemple : XSLT :
Contexte : Résultat :
/annuaire/entree[1]
Note : cette syntaxe est équivalente à :
select=”requeteXPath” data-type=”text | number | Qname” order=”ascending | descending” case-order=”upper-first | lower-first”/>
Cet élément permet d’effectuer des tris sur un ensemble de nœuds résultant d’une requête XPath. Exemple : XSLT :
Contexte : Résultat :
/ Paul Lafargue Lorédan Larchey
3.3.2.4 Les variables et paramètres
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
64
XSLT permet aussi la création de variables ou paramètres. Ces éléments sont immuables, ils ne pourront pas être modifiés par la suite. Leur portée est limitée à l’élément dans lequel ils ont été définis. Il est possible d’utiliser les balises conditionnelles à l’intérieur des balises de variables. Les variables sont créées avec la syntaxe suivante : ou
Il en est de même pour les paramètres (remplacer ‘variable’ par ‘param’). Ils sont utilisables dans une requête XPath de la manière suivante : XPath : Résultat :
coucou coucou
La principale différence entre une variable et un paramètre est qu’un paramètre peut être passé (en paramètre :-) ) à un template. Cela se fait de la manière suivante : coucou
Le template peut récupérer et utiliser le paramètre de la manière suivante :
NB : l’appel des variables dans les attributs de balises se fait en mettant un $ devant le nom. Il est aussi possible de les appeler à l’extérieur en l’enfermant dans des accolades : {$phrase}. 3.3.2.5 Référer à une feuille de style XSLT dans un document XML Généralement, la transformation XSLT se fait au niveau du serveur. Toutefois, il est possible de référer à une feuille de style XSLT dans un document XML pour que ce traitement soit effectué par le navigateur. Il suffit alors de diffuser le document XML non transformé à l’utilisateur. ...
Pour l’instant, le seul navigateur permettant d’effectuer cette transformation est Internet Explorer.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
65
3.3.3 TrAX : Transformation API for XML – sous partie de JAXP TrAX est une API Java de transformation, indépendante du type de transformation (par exemple indépendant de XSLT) et des implémentations utilisées. TrAX fait partie de JAXP de Sun depuis sa version 1.1. On utilise TRAX pour effectuer des transformations XSLT indépendamment du transformateur choisi. Il est ainsi plus facile de changer de transformateur sans avoir à tout recoder. Les classes les plus importantes de cette API sont : • TransformerFactory : prend en compte des instructions de transformation, et produit des Templates, contenant les instructions de la transformation et fournissant un Transformer. Il est aussi possible de créer directement un Transformer à partir d’un TransformerFactory ; • Transformer : transforme une Source en un ou plusieurs Results. Un Transformer utilise un processeur XSLT Java (Saxon, Xalan, Oracle XSLT, …) • Source : représente un document XML que l’on désire donner en paramètre au parseur (document XML source ou fiche XSL). Le document XML source peut être sous la forme d’un stream (StreamSource), d’un arbre DOM (DOMSource) ou de flux d’événements SAX (SAXSource); • Results : le résultat de la transformation. Il peut s’agir d’un fichier (StreamResult), d’un document DOM (DOMResult), ou d’un flux d’événements SAX (SAXResult). Pour le moment, TrAX n’est supporté que par Xalan et Saxon. Exemple de code : on dispose d’un fichier source input.xml, et d’une fiche XSLT fiche.xsl, et on désire créer output.html à partir de ces deux éléments. On précise la classe du transformateur à utiliser dans une variable système : org.apache.xalan.transformer.TransformerImpl, qui permet à TransformerFactory d’instancier le transformateur adéquat. TransformerFactory factory = TransformerFactory.newInstance(); Source ficheXSLT = new StreamSource(new File("fiche.xsl")); Transformer transformer = factory.newTransformer(ficheXSLT); Source source = new StreamSource(new File("input.xml")); Result resultat = new StreamResult(new File("output.html")); transformer.transform(source, resultat);
3.4 XSL-FO XSL-FO 43 (XSL Formatting Objects) permet d'exprimer de manière très précise le rendu d'un document. Il gère la pagination d'un document, les notes de bas de pages, les marges,... Il est possible de préciser avec exactitude l’emplacement des différents objets sur la page, les polices de caractères, l’affichage de tableaux, etc. Un document XSLFO est assez pénible à réaliser à la main, c’est pourquoi on utilise XSLT dans le but de générer du XSLFO à partir de données au format XML. Ce langage, qui a failli tomber dans les oubliettes, doit sa renaissance à FOP (Formating Object Processor). Cet outil, développé dans le cadre du projet Apache, permet à partir d'un document XSL-FO de générer un document PDF (format Acrobat de la société 43
Extensible Stylesheet Language (XSL) : http://www.w3.org/TR/2000/CR-xsl-20001121/ Chapter 15 of the XML Bible: XSL Formatting Objects (17000 mots) : http://www.ibiblio.org/xml/books/bible/updates/15.html
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
66
XML et les applications d’entreprise
Adobe). Il représente la solution idéale pour l'édition de factures ou de contrats sur le Web. Nous n’entrerons pas dans les détails de la syntaxe XSLFO. Nous expliquerons par contre l’architecture utilisée pour générer du PDF à partir de données au format XML, et nous donnerons un exemple simple.
3.4.1 Architecture utilisée pour générer du PDF avec XSLFO et FOP Les données à présenter sont en XML. A partir d’une feuille de style XSLT, on génère un document XSLFO, à l’aide d’un processeur XSLT comme expliqué dans la partie précédente. On utilise ensuite un processeur FOP pour convertir le document XSLFO en PDF. XML - données
XSLT
Processeur XSLT
Document XSLFO
Processeur FOP
Document PDF
Figure 7 Processus de production d’un document pdf avec FOP et XSLT
3.4.2 Exemple : On souhaite présenter le fichier XML suivant dans un document PDF :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
67
Lorédan Larchey0600010203Paul Lafargue0603020100
Après transformation XSLT avec la feuille de style appropriée, on obtient le document XSLFO suivante (pour des détails sur la syntaxe XSLFO, se référer à la documentation fournie par Apache) : Annuaire pages blanches nom:Lorédan Larchey telephone:0600010203 nom:Paul Lafargue telephone:0603020100
On utilise le moteur FOP, et on obtient le document PDF suivant, composé d’une seule page :
Figure 8 Exemple de document pdf généré avec FOP
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
68
3.5 SVG SVG44 (Scalable Vector Graphics) est un nouveau langage qui va permettre aux infographistes de diffuser des dessins vectoriels sur le web. SVG permet à la fois de décrire des images 2D et de décrire des animations. SVG est un standard du W3C. Exemple de code SVG (voir le rendu Figure 9)
Figure 9 Le plug-in Adobe permet de visualiser des documents SVG
44
Spécification SVG : http://www.w3.org/Graphics/SVG/Overview.htm8 Plug-in adobe : http://www.adobe.com/svg/ Présentation des possibilités offertes par le SVG : http://www.carto.net/papers/svg/index_f.html
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
69
XML et les applications d’entreprise
3.6 XUL XUL45 (XML-based User Interface Language, prononcé "zool") est un langage de description d'interfaces homme/machine. Sa puissance de description est telle qu'elle permet de définir une application aussi complexe qu'un navigateur web (XUL est au cœur de Mozilla et de Netscape 6). Certains voient en XUL le concurrent de java sur le poste client : il existe des interpréteurs pour toutes les plates-formes, XUL est donc un langage de descriptions d'interface portable. De plus XUL étant un dialecte XML il ne nécessite pas de compétences en informatique pointues. Exemple de code XUL (voir le rendu Figure 10):
Figure 10 Onglets décrits en XUL Ce langage qui se fait encore discret pourrait très bien être à l'origine d'une nouvelle vague d'applications : étant écrit en XML il est diffusable sur le Web simplement. Il est donc le langage de description d'interface idéal des services Web dont tout le monde parle. Mais ceci n'est qu'une prédiction...
45
Site de référence sur la technologie XUL :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
70
XML et les applications d’entreprise
4 Les services Web Les services Web sont des composants logiciels encapsulant des fonctionnalités métier de l’entreprise et accessibles via des protocoles standards du Web. Un service Web est décrit dans un document WSDL (Web Service Description Language), précisant les méthodes pouvant être invoquées, leur signature, et les points d’accès du service (URL, port, etc.). Ces méthodes sont accessibles via SOAP : la requête et la réponse sont des messages XML transportés par HTTP. Un service Web est accessible depuis n’importe quelle plate-forme ou langage de programmation. On peut utiliser un service Web pour exporter des fonctionnalités d’une application et les rendre accessibles via des protocoles standards. Le service Web sert alors d’interface d’accès à l’application, et dialogue avec elle au moyen de middleware (Corba, RMI, DCOM, EJB, etc.). Service Web
HTTP Requête XML
Interface WSDL
Middleware
Application offrant des fonctionnalités métier
Réponse XML SOAP
Vue utilisateur du service
Vue application
Figure 11 Service Web Les services Web sont aujourd’hui associés à trois spécifications XML : • SOAP : pour le transport des données et l’infrastructure de communication ; • WSDL : pour la description des services offerts ; • UDDI : annuaire pour le référencement des services par les fournisseurs et leur découverte par les utilisateurs. Dans la suite de cette partie, nous détaillerons ces trois spécifications plus en détails et donnerons des exemples d’utilisation en Java.
4.1 SOAP SOAP46 est un protocole d’échange de messages dans un milieu distribué. SOAP définit aussi un RPC (Remote Procedure Call), mais n’est pas limité à cette utilisation : il est possible d’utiliser SOAP pour des systèmes asynchrones (SOAP ne fonctionne pas nécessairement sur le modèle requête – réponse). Le RPC définit par SOAP résoud certains problèmes soulevés par les technologies telles que CORBA ou DCOM pour les applications distribuées sur Internet. En effet, ces RPC sont 46
Spécification SOAP : http://www.w3.org/TR/SOAP/
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
71
XML et les applications d’entreprise
souvent difficiles à mettre en œuvre, et les messages échangés ne passent pas les firewall. De plus, ils ne sont pas adaptés aux besoins des applications distribuées sur Internet, où le seul pré-requis devrait être de pouvoir utiliser le protocole http (afin de pouvoir traverser les firewall). C’est l’objectif de la norme SOAP, qui a pour principe d’échanger des messages HTTP (ou SMTP) dont le corps est un fichier XML. SOAP se base sur la spécification XML-RPC. XP – XML Protocol XP (XML Protocol) est un protocole similaire à SOAP, en cours de développement par le W3C, destiné au transport de données formatées en XML via Internet. Il semble que l’apport de XP par rapport à SOAP est minime, on est donc en droit de se demander l’intérêt de ce nouveau protocole !
4.1.1 Avant SOAP : XML-RPC SOAP se base sur les spécifications de XML-RPC. XML-RPC est un RPC (Remote Procedure Call : appel de procédures à distance), au même titre que CORBA, IIOP ou DCOM. Cependant, contrairement à ces derniers, XML-RPC n’impose aucun modèle de composants, des deux côtés de la connexion. L’activation des objets exécutant les méthodes est aussi laissée à la charge des applications. Le scénario d’appel de méthode distant est le suivant : • L’application 1 envoie un message HTTP contenant du XML précisant le nom de la méthode à appeler et les paramètres éventuels à l’application 2 • L’application 2 récupère le destinataire du message, exécute la méthode, et envoie la réponse sous le même format : message HTTP dont le corps est du XML. HTTP Application 1 Application 2 Message XML
Internet
La norme XML-RPC précise l’enveloppe des messages échangés par les deux applications (envoi de requête et de réponse), et la manière d’utiliser ces messages dans le but de faire des appels de procédures distantes. XML-RPC précise aussi comment modéliser les retours d’erreur. 4.1.1.1 Un exemple simple : Prenons l’exemple de deux applications souhaitant communiquer. L’application 1 envoie une requête à l’application 2 pour exécuter la méthode getAnniversaire sur l’objet distant calendrier. Cette méthode renvoie la date d’anniversaire de la personne dont le nom est passé en paramètre, ici Fred. L’application 2 exécute la requête et retourne la réponse : 07/01/1964.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
72
XML et les applications d’entreprise
précise le destinataire du message, son type, etc.
POST HTTP/1.0 Host: improve.fr Content-Type: text/xml Content-length: 181
Header
calendrier.getAnniversaireFred Body
Nom de la méthode
Paramètre
Figure 12 Exemple de requête XML-RPC HTTP/1.1 200 OK Connection: close Content-Length: 158 Content-Type: text/xml Date: Fri, 5 Fev 2001 15:55:08 GMT 07/01/1964
Précise des informations sur la provenance du message, son type, etc.
Header
Valeur de la réponse
Body
Figure 13 Exemple de réponse XML-RPC XML-RPC fournit un mécanisme de retour d’erreur : les fautes. Une faute (fault) est composée d’un code (faultCode), d’une explication donnant les raisons de l’erreur (faultString). La Figure 14 est un exemple de message d’erreur, dans le cas où la signature de la requête ne correspond pas à celle de la méthode distante (mauvais nombre de paramètres).
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
73
XML et les applications d’entreprise
HTTP/1.1 200 OK Connection: close Content-Length: 158 Content-Type: text/xml Date: Fri, 5 Fev 2001 15:55:08 GMT
Header
faultCode4faultStringToo many parameters. Body
Code de l’erreur
Explication de l’erreur
Figure 14 Exemple de message d’erreur XML-RPC XML-RPC permet l’utilisation d’un nombre limité de types (string, integer, etc.), et permet l’utilisation de structures : un élément est liste de , chaque associant un nom à une valeur . Pour plus de détails sur les types de données XML-RPC, se référer à la spécification. 4.1.1.2 Avantages et limites de XML-RPC : XML-RPC est une spécification simple et facile à implémenter. Pour cette raison il existe de nombreuses implémentations stables disponibles gratuitement sur Internet. Une solution XML-RPC est simple à mettre en place, et suffit généralement pour faire du RPC en utilisant XML par dessus HTTP. Sa principale limitation est qu’il n’existe pas de mécanisme permettant de définir des types de données complexes. SOAP vient compléter cette spécification en introduisant des règles d’encodage, et la possibilité de travailler en mode asynchrone (et non plus seulement en mode RPC : requête – réponse). Mais l’essence même de SOAP, RPC XML via HTTP avec gestion des erreurs, était déjà présent dans XML-RPC. Un des grands atouts de SOAP est que ce protocole est poussé par les grands acteurs du marché (dont IBM et Microsoft).
4.1.2 Principe de SOAP La norme SOAP est composée de trois parties : • La structure de l’enveloppe SOAP (Payload) qui définit une structure générale décrivant le contenu, le destinataire, et la nature du message. • Les règles d’encodage SOAP qui définissent le mécanisme de sérialisation utilisé pour échanger des objets.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
74
XML et les applications d’entreprise
•
SOAP RPC qui définit, pour les utilisations synchrones, une convention de représentation des appels et des réponses des procédures distantes. Dans la partie suivante nous détaillerons la structure de l’enveloppe SOAP, et SOAP RPC.
4.1.3 Structure de l'enveloppe SOAP POST /Computer HTTP/1.1 Host: www.improve.fr Content-Type:text/xml; charset="utf-8" Content-Length: 10 SOAPAction: //contenu du header //contenu du body
HTTP enveloppe
HTTP Header
SOAP Enveloppe
SOAP Header
SOAP Body
Figure 15 Structure de l'enveloppe SOAP Un message SOAP est composé des parties suivantes : 1. Le HTTP Header : Le protocole HTTP envoie une requête POST. L’entête HTTP se trouve juste avant le message SOAP, et définit le destinataire du message, les règles d’encodage HTTP, etc. Le champ SOAPAction peut être utilisé pour indiquer l’intention de la requête SOAP. Cette information peut être utilisée par un firewall pour filtrer les messages. Ce champ est obligatoire mais peut être vide si on n’indique pas l’intention de la requête. 2. L’enveloppe SOAP : L’enveloppe contient l’espace de nommage définissant la version de SOAP utilisée, et les règles de sérialisation, et d’encodage. 3. Le header SOAP : Cette partie du message est optionnelle. Elle sert à transmettre des informations nécessaires pour l’exécution de la requête SOAP aux intermédiaires qui recevront le message. On y précise généralement des informations liées aux transactions, à l’authentification, etc.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
75
XML et les applications d’entreprise
Le header est composé d’un ou plusieurs champs : nom local, nom global, espace de nommage, et les attributs actor, désignant le destinataire du header, et mustUnderstand, qui indique si le processus est optionnel. L’attribut actor permet de préciser l’application à laquelle est destinée l’information contenue dans le header. L’URI http://schemas.xmlsoap.org/soap/actor/next précise en particulier que ces informations sont destinées à la première application qui reçoit le message. Dans le cas où l’actor n’est pas précisé, le header est analysé par le destinataire final du message. Exemple de header, on précise des informations sur l’identification de l’utilisateur et la transaction à laquelle appartient le message :
4. Le Body SOAP : Le body SOAP contient toutes les informations que l’on veut transmettre à l’application distante. Le contenu du Body est normalisé dans SOAP RPC, pour modéliser une requête et sa réponse. Le body de la requête contient l’identifiant de l’objet distant, le nom de la méthode à exécuter et les éventuels paramètres. Le body de la réponse contient le résultat de l’exécution de la requête.
4.1.4 SOAP RPC SOAP RPC définit les conventions permettant d’utiliser SOAP comme un RPC, et le format des messages pour effectuer une requête ou envoyer une réponse. SOAP RPC se base sur les spécifications de XML-RPC. 2. Exécution de la méthode
1. Requête XML
Application 1
HTTP
Application 2 Internet 3. Réponse XML
Figure 16 SOAP RPC 1. Préambule On appelle service SOAP une application dont les méthodes sont accessibles via SOAP. Ce service peut être développé dans n’importe quel langage de programmation. Un service est accessible via un identifiant unique, de type URN (cf. Figure 3). En Java toute classe peut être rendue accessible via SOAP (en utilisant Apache SOAP). Lors de l'appel d'une méthode sur le service déployé, c’est la méthode correspondante de la classe Java qui est exécutée. www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
76
Exemple de classe java que l’on désire rendre accessible via SOAP avec l'identifiant "urn:Echo" : public class Echo { public String echo(String expression) { return “message recu:” + expression ; } }
2. Requêtes / réponses SOAP : Pour appeler l’opération "echo", on précise dans le Body SOAP de la requête l’identifiant de l’objet distant, l’opération à exécuter et les éventuels paramètres : Hello World
Détails de la requête : • : l’espace de nommage défini a pour URN l’identifiant du service (« urn :Echo »). Le nom de l’élément (echo) correspond au nom de la méthode à exécuter ; • Les paramètres d’appel de la méthode sont ensuite ajoutés les uns à la suite des autres. Ici on n’a qu’un seul paramètre : « expression », de type string. Prenons l’exemple d’une méthode String ajouter(float valeur1, float valeur2) avec valeur1 = 12 et valeur2 = 15
Le body SOAP serait alors : 12 15
Revenons à notre appel de méthode echo. Le message SOAP est alors envoyé au service SOAP. Le service exécute la méthode précisée dans la requête et retourne ensuite un message SOAP dont le Body contient le résultat de l’opération :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
77
XML et les applications d’entreprise
message recu: Hello World
Le résultat est contenu dans un élément : • L’attribut type précise le type de retour de la méthode exécutée. • Le contenu de l’élément est le résultat de l’exécution de la méthode.
4.1.5 La Gestion des erreurs : En cas d’erreur lors du traitement de la requête, le serveur renvoie un message SOAP donnant les raisons de l’erreur, dans un message HTTP dont le header commence par : HTTP/1.1 500 Server Error
L’erreur est détaillée dans le Body SOAP, dans un élément Fault, donnant : • faultcode : le code de l’erreur, destiné à un traitement informatique ; • faultstring : une explication textuelle, à destination des opérateurs humains ; • faultactor (optionnel) : en cas d’erreur dans le transport, l’acteur mis en cause peut être précisé : firewall, serveur, proxy, etc. ; • detail (optionnel) : un détail de l’erreur (par exemple en Java la trace de l’exception renvoyée). Par exemple, dans le cas où la signature de la méthode de la requête ne correspond pas à la signature de la méthode du service : SOAP-ENV:Client Method signature does not match.
4.1.6 Pattern d’utilisation : La norme SOAP ne définit pas les patterns d’utilisation. Ceci dit, à l’image des RPC traditionnels, on pourra être amené à utiliser un objet distant par le biais d’un proxy effectuant les requêtes SOAP, ce qui permet de manipuler l’objet distant comme un objet local :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
78
XML et les applications d’entreprise
Application
1. Appel de echo
EchoProxy
2. Requête SOAP
echo
Echo echo
3. Réponse SOAP
4. Réponse à echo
Machine locale
Machine distante
Figure 17 Proxy SOAP 1. Une application locale veut appeler la méthode echo de l’objet distant Echo : elle instancie un proxy et appelle sa méthode echo ; 2. Le proxy est un « raccourci » vers l’objet distant : il effectue la requête SOAP destinée à l’objet distant. 3. L’objet distant décode le message XML reçu et exécute sa méthode echo. Il envoie sa réponse au proxy ; 4. Le proxy transmet la réponse reçue à l’application. L’avantage de cette méthode est que l’application n’a pas à se soucier de la localisation de l’objet distant et de la construction de la requête SOAP : elle l’utilise comme un objet local.
4.1.7 Pas de modèle de composants SOAP n’impose pas de modèle de composants. Ainsi, l’activation des objets, le ramasse miettes, les références sur objets, la gestion des versions, le contrôle de types, etc, sont de la responsabilité des applications utilisant SOAP. D’où la nécessité de redéfinir certains services déjà supposés acquis avec les RPC traditionnels tels que IIOP ou RMI. SOAP a pour vocation d’être une spécification simple à mettre en œuvre, et de fonctionner sur toutes les plates-formes et pour tous les langages de programmation. En définissant trop de services, on complique l’utilisation de SOAP et on risque de perdre la portabilité.
4.1.8 La sécurité Les éléments de sécurité pour la transmission de message sont généralement : • La confidentialité : s’assurer que l’intercepteur d’un message ne puisse pas lire les données. Les deux partis s’entendent sur un mécanisme d’encryption du message ; • L’autorisation/authentification de l’origine du message : authentification de l’expéditeur du message ; • L’intégrité du message : s’assurer que le contenu du message n’a pas été altéré, volontairement ou accidentellement, pendant le transport ; • La non répudiation : s’assurer que l’expéditeur du message ne puisse nier l’avoir envoyé. On utilise généralement à cet effet un mécanisme de signature digitale ; 4.1.8.1 SSL via HTTPS :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
79
Au niveau du transport, il est possible d’introduire un niveau de sécurité à SOAP en utilisant SSL via HTTPS. Cette solution permet d’authentifier l’expéditeur et d’assurer une confidentialité des données via un mécanisme d’encryption. 4.1.8.2 Signatures digitales : Les signatures digitales permettent de garantir l’origine du message. Ce mécanisme se base sur l’utilisation de clés publiques et privées. L’expéditeur a deux clés : une publique et une privée, les messages encryptés avec la clé privée peuvent être décryptés en utilisant la clé publique. L’expéditeur calcule une valeur de hachage du message, et encrypte cette valeur en utilisant la clé privée : on obtient alors la signature digitale du message. Cette signature est envoyée au destinataire avec le message et un certificat contenant la clé publique, délivré par un organisme de confiance. Le destinataire peut alors extraire la clé publique du certificat, décrypter la valeur de hachage, et comparer cette valeur à celle qu’il obtient. Le centre de recherche d’IBM à Tokyo définit une extension à SOAP pour l’utilisation des signatures digitales. La signature du message est ajoutée dans le header SOAP, et le contenu du body est encrypté. Pour un exemple d’utilisation de cette technique en Java, se référer au tutorial d’IBM « Digital Signatures for SOAP messages 47 ». Il existe aussi d’autres initiatives récentes visant à apporter des éléments de sécurité à XML, telles que : • XKMS - XML Key Management Specification48 • XACML - eXtensible Access Control Markup Language49 • XML Signature50 • SAML - Security Assertion Markup Language51
4.1.9 Implémentation de référence : Apache SOAP Apache SOAP est une implémentation de la note du W3C. Cette implémentation se base sur celle d’IBM connue sous le nom de SOAP4J. Apache SOAP fournit l’implémentation côté serveur (déploiement, management et exécution des services) et client (construction des requêtes, appel des services, décodage des réponses). 4.1.9.1 Architecture Service SOAP avec Apache SOAP Un service SOAP fournit une liste d’opérations qu’il est possible d’invoquer. Pour créer un service SOAP en Java, il y a 2 étapes : Définition d’une classe ; Déploiement de la classe sur un serveur SOAP. On donne un identifiant unique au service, et la liste des méthodes de la classe à exposer en tant qu’opérations. Il est ensuite possible d’appeler ce service en utilisant les requêtes/réponses SOAP, précisant l’identifiant unique du service, le nom de l’opération à invoquer, et les éventuels paramètres.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
80
XML et les applications d’entreprise
SOAP ne définit que le format des messages qui sont échangés pour faire du RPC en utilisant XML et HTTP. En aucun cas la norme n’impose un modèle d’architecture. C’est par contre ce que fait Apache SOAP. En effet, l’outil considère qu’un service SOAP est déployé sur un serveur avec un identifiant. Ce serveur (sous la forme d’une Servlet) reçoit les requêtes des clients, localise l’objet avec l’identifiant précisé dans la requête, gère son activation, appelle la méthode correspondante et retourne le résultat au client sous la forme d’une réponse SOAP. On se rapproche donc d’un système centralisé. Requête XML
Déploiement
Client Réponse XML
Serveur Apache SOAP
Service Echo (classe Echo)
Activation Appel de méthodes
SOAP
Figure 18 : Architecture Apache SOAP Comme on peut le voir sur la Figure 18, la seule responsabilité de la norme SOAP est le format des requêtes / réponses échangés entre le client et le serveur. La partie du serveur dont la responsabilité est de recevoir les requêtes SOAP des clients et de les dispatcher vers les objets correspondants est appelée à juste titre « routeur ». 4.1.9.2 Création / déploiement d’un service SOAP : Apache SOAP fournit un framework pour créer, déployer, et appeler un service SOAP avec Java. Prenons l’exemple d’un service Echo : le service contient une seule opération : echo, qui prend en paramètre d’entrée une chaîne de caractères, la modifie, et la retourne à l’utilisateur du service. 1. Création : Toute classe Java peut être exposée comme un service SOAP. Prenons pour exemple la classe Echo précédemment définie : package test; public class Echo { public String echo(String message) { return "message recu: " + message ; } }
2. Déploiement : Apache SOAP fournit deux possibilités pour déployer un service SOAP. La première est d’utiliser une servlet de configuration. Le problème est qu’en phase de développement, on est amené à redéployer fréquemment un service. Cette méthode n’est donc pas très pratique. La seconde méthode est le renseignement d’un fichier XML de configuration. Ce fichier de description contient les éléments nécessaires pour l’installation du service sur le serveur. On utilise ensuite une classe du framework pour déployer le service à l’aide des éléments contenus dans le fichier de configuration. Par exemple, pour notre service Echo : fichier DeploymentDescriptor.xml.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
81
Ce fichier précise • ID : le nom unique auquel l’utilisateur se référera pour appeler le service (identifiant). Il est préférable d’utiliser la convention de nommage définie par l’IETF : Unified Resource Naming. Ici : urn:Echo. • Provider : Le type du service SOAP. Apache SOAP supporte actuellement les classes Java et les Bean Script, et devrait supporter les EJB dans les prochaines versions. • Scope : le mode d’activation du service. Request signifie qu’une nouvelle instance du service est créée à chaque requête, les autres modes possibles sont Session et Application. • Methods : la liste des méthodes exposées par le service, séparées par des espaces. Cependant il y a deux limitations : on ne peut pas préciser les paramètres des méthodes déployées, et rien n’est précisé dans la spécification pour les méthodes polymorphes (on ne peut pas préciser si le service expose deux méthodes ayant le même nom) ; • : précise la classe java implémentant ce service. Cette classe doit être présente dans le classpath. L’attribut static permet de préciser si les méthodes doivent être considérées comme des méthodes de classe ou d’instance. Une classe est fournie par le framework pour effectuer le déploiement à partir de ce fichier, org.apache.soap.server.ServiceManagerClient : java org.apache.soap.server.ServiceManagerClient URL_du_routeur_SOAP deploy DeploymentDescriptor.xml
L’URL du routeur SOAP est généralement http://Adresse_du _serveur:8080/soap/servlet/rpcrouter. Dans le cas contraire, se référer à la documentation de Apache SOAP Il est ensuite possible de vérifier que le service est correctement déployé, en récupérant la liste des services déployés : java org.apache.soap.server.ServiceManagerClient URL_du_routeur_SOAP list
3. Retrait : Pour retirer le service du serveur, on a les deux mêmes possibilités, la servlet ou : java org.apache.soap.server.ServiceManagerClient URL_du_routeur_SOAP undeploy urn:Echo
Note : lors du redémarrage du serveur, il n’est pas nécessaire de redéployer les services. Cependant, le serveur ne gère pas automatiquement la persistence, et l’état du service au moment de son arrêt est perdu. Si on a besoin de persistence il faut le gérer à la main www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
82
(services statefull). Sinon un redémarrage et une reinitialisation des services peut être suffisant. 4.1.9.3 Utilisation d’un service SOAP : Le pattern classique est d’utiliser un proxy pour accéder au service distant. Ce proxy permet de manipuler l’objet distant comme s’il était en local, en implémentant la même interface. Cependant SOAP n’impose pas un tel pattern, le choix est donc laissé au programmeur. Pour notre exemple, nous construirons un proxy EchoProxy avec une méthode : String echo(String message). Le principe d’invocation d’une méthode distante est la construction d’un Objet de type Call comprenant tous les paramètres de la requête (service destinataire, méthode, paramètres, règles d’encodage), puis l’utilisation de Call.invoke pour invoquer le service. Un objet de type Response contient tous les éléments de réponse, y compris les éventuels messages d’erreur.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
public class EchoServiceProxy { protected url URLDuRouteurSOAP; public EchoServiceProxy(URL url) { URLDuRouteurSOAP = url; } public String echo (String message) throws SOAPException { Call call = new Call(); //définition du service destinataire call.setTargetObjectURI("urn:Echo"); //définition de la méthode appelée call.setMethodName("echo"); //définition des règles d’encodage call.setEncodingStyleURI( org.apache.soap.Constants.NS_URI_SOAP_ENC); //définition des paramètres de la méthode Vector params = new Vector(); params.addElement( new Parameter( "expression", String.class, message, null)); call.setParams(params); //appel de la méthode distante //le deuxième paramètre est SOAPAction, placé dans //l’entête HTTP pour préciser le but du message. Response resp = call.invoke(URLDuRouteurSOAP, ""); //s’il n’y a pas d’erreur on extrait le résultat et on //le renvoit if (!resp.generatedFault()) { Parameter val = resp.getReturnValue(); return (String) val.getValue(); } //traitement effectué en cas d’erreur else { Fault fault = resp.getFault(); throw new SOAPException( fault.getFaultCode(), fault.getFaultString()); } } }
Exemple d’utilisation de ce proxy :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
83
XML et les applications d’entreprise
84
Public static void main(String args[]) { EchoProxy echoService = new EchoProxy( new URL («http://localhost:8080/soap/servlet/rpcrouter»); String received = EchoService.echo(« Hello World ») ; System.out.println(received) ; }
Dans une console, on teste le résultat : >java test.EchoProxy >message recu: Hello World
Cette méthode devient rapidement fastidieuse si le service distant comporte un grand nombre de méthodes. Pour répondre à ce problème, le Web Services Toolkit d’IBM permet de générer automatiquement un proxy à partir d’un fichier WSDL décrivant le service, nous y reviendrons dans la suite de ce document. 4.1.9.4 Comment écouter les messages SOAP : Pour écouter les messages SOAP et ainsi contrôler les messages échangés entre les clients et le serveur SOAP, Apache SOAP fournit un outil : le TCP Tunneler, qui écoute sur un port particulier, affiche les messages reçus, et les redirige vers un autre port. La syntaxe d’utilisation est la suivante : java org.apache.soap.util.net.TcpTunnelGui PORT_ECOUTE URL PORT_REDIRECTION
• PORT_ECOUTE est le port sur lequel le TCP Tunneler écoute • URL est l’URL du serveur SOAP • PORT_REDIRECTION est le port sur lequel le serveur SOAP écoute L’outil affiche alors les messages sortant sur le panel de gauche, et les messages entrant (en provenance du serveur) sur le panel de droite. Exemple : utilisation du service echo : On lance le serveur Tomcat sur la machine locale sur le port 8080. Puis on démarre le TCP Tunneler sur le port 8007 : java org.apache.soap.util.net.TcpTunnelGui 8007 localhost 8080
ensuite il faut diriger toutes les requêtes destinées au serveur SOAP sur le port 8007, en instanciant le proxy adéquat : public class Test { public static void main(String args[]) { EchoProxy echo = new EchoProxy( New URL( «http://localhost:8007/soap/servlet/rpcrouter»); String received = echo.echo(« Hello World ») ; System.out.println(received) ; } }
On lance ce test dans une console :
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
85
>java Test >message recu: Hello World
On observe les échanges de message entre le client et le serveur : Message envoyé par le client : POST /soap/servlet/rpcrouter HTTP/1.0 Host: localhost:8007Content-Type: text/xml; charset=utf-8Content-Length: 442SOAPAction: "" Hello World
Réponse envoyée par le serveur : HTTP/1.0 200 OKContent-Type: text/xml; charset=utf-8Content-Length: 477 message recu: Hello World
4.1.10
Deux API Java de Sun
Sun a proposé deux JSR (Java Specification Request), d’APIs qui seront disponibles dans des packages optionnels dans la distribution J2SE et probablement J2EE : • Java API for XML Messaging52 (JAXM) : API pour l’utilisation standard de systèmes de messagerie hétérogènes, tels que SOAP ou le protocole de messagerie ebXML. Cette API adresse le transport de données XML ou non XML via des protocoles tels que FTP, SMTP ou HTTP. • Java API for XML RPC53 (JAX RPC) : API pour l’utilisation standard de RPC, tels que XML-RPC, SOAP, ou XP. L’avantage de ces API est de rendre les applications indépendantes des système de messagerie ou de RPC. Il n’y a pas a recompiler le code lorsqu’on change de système. Ces 52 53
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
86
API ne sont par contre pour le moment pas disponibles en téléchargement, de plus il faudra attendre des implémentations.
4.1.11 • • •
Outils facilitant l’utilisation de SOAP (cf annexes)
IBM Web Services Toolkit IBM Web Services Developement Environment GLUE de The Mind Electric
4.2 WSDL WSDL54 (Web Service Description Language) pour les services Web est l’équivalent de IDL (Interface Definition Language) pour la programmation distribuée (CORBA, DCOM). Ce langage permet de décrire de façon précise les services Web, en incluant des détails tels que les protocoles, les serveurs, les ports utilisés, les opérations pouvant être effectuées, les formats des messages d’entrée et de sortie, et les exceptions pouvant être renvoyées. Il y eut d’autres tentatives de langages pour résoudre le problème de la définition des services Web. Microsoft a d’abord proposé SDL (Service Definition Language) avec une implémentation fournie dans leur Toolkit SOAP, puis IBM a proposé NASSL (Network Accessible Service Specification Language), dont une implémentation est fournie dans SOAP4J. Microsoft modifia sa première spécification et proposa SCL (SOAP Contract Language), puis les différents acteurs s’accordèrent sur WSDL.
4.2.1 Structure d’un document WSDL … … … … … … …
54
Spécification WSDL : http://www.w3.org/TR/wsdl
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
XML et les applications d’entreprise
87
Figure 19 Structure d'un document WSDL •
: Cet élément contient la définition du service. C’est la racine de tout document WSDL. Cette balise peut contenir les attributs précisant le nom du service, et les espaces de nommage. contient trois types d’éléments : • et : Ces éléments définissent les opérations offertes par le service, leurs paramètres d’entrée et de sortie, etc. En particulier, un correspond à un paramètre d’entrée ou de sortie d’une . Un définit un ensemble d’opérations. Une définit un couple message entrée / message sortie. Par exemple, dans le monde Java, une opération est une méthode et un portType une interface. • : Cet élément associe les à un protocole particulier. Les bindings possibles sont SOAP, CORBA ou DCOM. Actuellement seul SOAP est utilisé. Il est possible de définir un binding pour chaque protocole supporté. • : Cet élément précise les informations complémentaires nécessaires pour invoquer le service, et en particulier l’URI du destinataire. Un est modélisé comme une collection de ports, un étant l’association d’un à un URI. Il est aussi possible de définir des types de données complexes dans une balise juste avant la balise . Enfin, chaque élément WSDL peut être documenté à l’aide de l'élément . Cet élément contient des informations liées à la compréhension du document par les utilisateurs humains du service.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
(5 – 11) La première partie du fichier définit les paramètres d’entrée et de sortie des opérations du service : echoInput et echoOutput. (13 – 18) Ensuite, la définition abstraite du service Web est faite par définition du portType, qui encapsule la définition de l’opération echo. On fait ici référence aux messages définis précédemment (paramètres d’entrée et de sortie de l’opération). On obtient une description abstraite du service, indépendante de tout protocole de communication. C’est l’interface du service définissant les méthodes exportées, et leurs paramètres d’entrée et de sortie.
www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
89
XML et les applications d’entreprise
(20 – 36) Il est ensuite possible d’associer ce service à un protocole existant, par la définition d’un binding (pour l’exemple qui nous intéresse : SOAP). Le binding définit les paramètres d’invocation du service spécifiques au protocole utilisé. On définit ici les paramètres nécessaires à l’utilisation du service via SOAP (lien vers les spécifications du transport utilisé, règles d’encodage pour la sérialization des messages échangés, etc.). (38 – 43) La définition du service se termine par la définition des paramètres restants. Par exemple pour un binding SOAP, il reste à définir l’adresse URL du service à invoquer. Notons qu’il est possible de définir plusieurs bindings, et d’associer ces bindings à plusieurs URL, et ce en utilisant la même définition abstraite du service. Ce service peut être représenté avec le schéma UML suivant (sauf que ce dernier ne permet pas de donner des détails sur les protocoles utilisés et le point d’accès du service) : EchoService + echo(String) : String
Figure 20 « Modèle UML » de représentation du service Echo Ainsi, l’interface WSDL est le point d’entrée du service : on y trouve la localisation du service, et les opérations qu’il est possible d’invoquer en utilisant SOAP. Service Web HTTP Requête XML
Interface WSDL
Réponse XML
SOAP
Figure 21 Le service Web et WSDL Les services Web servent surtout à l’intégration d’applications. Ils permettent d’exporter des applications existantes et de les rendre accessibles par le Web ou encore de créer de nouveaux composants que l’on peut appeler à partir d’autres applications. On les retrouve donc dans des projets d’EAI ou de B2B, concepts expliqués dans les parties suivantes.
4.2.2 WSDL et la gestion des fautes Les services Web ont un système équivalent à celui des exceptions en Java : les fautes. Nous avons vu dans la partie sur SOAP qu’une opération peut renvoyer une faute à l’utilisateur. WSDL permet évidemment de préciser les fautes renvoyées par les opérations d’un Service Web. Les fautes renvoyées sont précisées dans la définition abstraite du service : dans l’élément , encapsulé dans l’élément . Rappelons que l’élément précise aussi les types d’entrée et de retour des opérations du service. Le type de la faute est définie dans un élément . Il ne faut pas oublier non plus de préciser le protocole utilisé pour l’envoi de la faute dans le binding, comme pour les www.application-servers.com, votre portail sur les serveurs d’applications et le middleware. Copyright (c) 2001, Improve
