Interopérabilité XML

Définition des services de filtrage et transformation

Dans la coopération entre logiciels le middleware doit souvent filtrer les données qu'il prend à l'un pour les passer à l'autre. Ce filtrage consiste à reconnaître certaines données pour les retenir ou les éliminer.

En général, toutefois, le filtrage ne suffit pas: il faut transformer les données, à l'aide d'opérations de changement de structure, de format, de calcul, etc.

Les services proposés ici ont pour but de transformer des données d'entrée en données de sortie par récriture.

Exemple 1: transformer l'ensemble des lignes de table produites par une sélection dans la base de données de production en un document XML.

Exemple 2: transformer le document XML ci-dessus en un ensemble d'instructions SQL INSERT qui soit acceptable pour le SGBD du data warehouse et qui représente un certain niveau de consolidation (remplacement de lignes de détail par une ligne de total).

Dans les deux exemples ci-dessus il faut:

• Reconnaître les diverses colonnes du listing de sélection
• Choisir quelles lignes et quelles colonnes on retient pour la sortie, ce qui est une opération de filtrage
• Transformer les données retenues en une structure de sortie convenant aux besoins, ce qui est une opération de transformation.

Ce type de services est nécessaire de plus en plus souvent pour créer des statistiques, interfacer deux applications ou fournir des résultats avec une structure (pas une mise en page!) imposée. Nous décrivons ici un mécanisme assez général que l'on peut mettre en oeuvre en tant que service. Ce mécanisme étant destiné à permettre la coopération de deux logiciels (celui qui a fourni les données d'entrées et celui qui reçoit les données de sortie) c'est un mécanisme de middleware.

Mécanisme de transformation

Pour qu'une transformation soit automatique, il faut qu'elle s'applique à des données d'entrée dont la structure suit des règles précises permettant de reconnaître ses éléments. Le problème de reconnaissance d'une structure a été très bien étudié en théorie des langages, où on connaît divers types de grammaires. En pratique, les structures les plus puissantes (sur le plan sémantique) que l'on sache à la fois décrire, reconnaître et traduire automatiquement en une autre structure sont les structures arborescentes.

Le mécanisme de transformation de données proposé ici est donc basé sur la reconnaissance d'éléments de la structure des données d'entrée, et des valeurs que prennent certains éléments. Tout élément reconnu peut être récrit automatiquement en sortie selon des règles précises. Ces règles peuvent aussi prendre en compte:

• des valeurs lues en entrée
• des tests sur des valeurs d'entrée ou l'existence d'un élément
• des demandes d'itération jusqu'à ce qu'une condition soit remplie.

Par définition, un élément non reconnu sera rejeté au sens du filtrage et ignoré pour la transformation; il fera l'objet ou non d'un message d'erreur.

Voici des exemples de données que l'on sait décrire sous forme analysable, donc traduire automatiquement:

• un ouvrage technique illustré
• un objet logiciel, avec ses méthodes et ses données
• un message email avec pièces jointes
• une liste de lignes de sortie d'une sélection dans une base de données
• une fenêtre graphique affichée par une application
• un arbre de décision avec des liens vers d'autres données.

 

Les éditeurs de logiciel s'orientent en ce moment vers une approche de ces problèmes de filtrage et transformation basée sur le langage XML. Chaque éditeur fournira une passerelle entre ses structures de données propriétaires et le langage XML: Oracle fournira une passerelle entre les données de son SGBD et XML, SAP une passerelle entre ses propres données et XML, etc. Ces passerelles fonctionneront dans les deux sens: des données propriétaires vers XML et inversement.

La solution XML

XML est un langage de description de structures de documents recommandé par l'organisme de normalisation W3C (World Wide Web Consortium). Une structure est, par définition, un ensemble de sous-structures appelées éléments. Un document peut être un livre, avec comme éléments un titre, des chapitres, sections, paragraphes, figures, légendes, etc. Un document peut aussi être un message email, ses éléments étant alors une en-tête (émetteur, destinataire, date...), un corps de texte et des pièces jointes. Il peut, enfin, s'agir d'un message entre deux applications, par exemple entre une application commerciale et une application de comptabilité. Rédigé à l'aide du langage informatique XML, un document est comme un source de programme: il doit respecter les règles syntaxiques du langage.

Document XML et DTD

Sur le plan conceptuel, un document XML a deux parties:

• le document proprement dit, obligatoirement présent,
• une description formelle optionnelle, appelée Document Type Definition (DTD). Cette description contient les règles syntaxiques que doit respecter le document. Tout se passe comme pour un programme que l'on écrit dans un langage de programmation: le langage a une grammaire, qui décrit les structures syntaxiques permises pour un programme et les mots réservés que l'on emploiera. Comme HTML, XML dérive de SGML (Structured Generalized Markup Language); SGML aussi utilise des DTD.

Différence entre SGML et XML: SGML a été défini pour le stockage de documents dans de grandes bibliothèques centralisées, alors que XML a été fait pour une utilisation dans des environnements répartis, aussi bien pour le stockage de documents que pour l'interopérabilité par échange de données.

 

Accompagné de son DTD, un document XML est comme un programme: il doit se conformer strictement aux règles de sa grammaire. On dit qu'il est "valide" lorsqu'on peut en vérifier la syntaxe avec cette grammaire. Sans DTD, un document peut quand même être "bien formé": sa structure est alors réputée décrite par elle-même et peut se contenter de respecter les règles générales du langage XML.

Premier domaine d'utilisation de XML: le stockage

De ce qui précède on peut tirer une première conclusion: XML est bien adapté au stockage de documents quelconques: ouvrages techniques illustrés, emails, etc. Les données stockées en XML sont indépendantes des systèmes d'exploitation de stockage ou d'accès, des langages de programmation et des formats de mise en page. XML est donc un standard universel de stockage. Il est donc précieux pour la coopération, car tous les clients qui accéderont aux données XML les verront de la même façon, avec la même structure et la même sémantique.

Comparaison de XML et HTML

Le langage XML permet de définir et de nommer des éléments, avec leurs sous-éléments. Un document a forcément une structure arborescente, accessible en entier à partir de son élément de plus haut niveau. Ce type de structure est bien plus puissant et général que la structure relationnelle. Un arbre décrit la composition de chaque élément (ses sous-structures); un élément peut être un hyperlien pointant vers n'importe quel objet informatique n'importe où, y compris vers un élément de document XML (le même document ou un autre).

Une comparaison avec HTML s'impose:

• HTML définit le format de mise en page (affichage ou impression) d'un document, alors que XML en définit la structure, le contenu, la sémantique
• La grammaire de HTML est fixe, définie par le standard, avec ses mots réservés et ses structures entre balises (tags). XML, au contraire, permet de définir n'importe quelle structure dans la mesure où elle est arborescente, avec notamment les balises que l'on veut. On peut ainsi définir des structures standard au niveau d'une profession, comme on a défini des formats standard d'échange de documents dans la norme EDI. Cela permet, sans parcourir tout un texte mot à mot, de savoir par exemple si le texte a un élément de type "arbre à cames": XML permet des recherches sémantiques d'éléments basées sur le DTD d'un document, sans balayage mot à mot du document ou index sur tous ses mots, ce qui est très puissant et performant.

 

Les documents XML sont traités par des interpréteurs XML, analogues aux interpréteurs HTML. L'interpréteur XML s'appuie sur la description DTD du document (lorsqu'elle existe) pour accéder à celui-ci en comprenant sa structure.

Langage XSL

XML ne permettant pas, tel quel, de décrire le format d'affichage ou d'impression d'un document, la normalisation est en train de le compléter par un standard de mise en page, XSL (eXtended Style Language). Une description XSL (que l'on écrit en XML) s'applique à un document comme le fait son DTD, mais pour définir l'interprétation physique (pour l'affichage, par exemple) des divers éléments. XSL est un complément "feuille de style" de XML comme CSS est un complément feuille de style de HTML.

 

En fait, une description XSL permettra bientôt de définir toutes sortes de transformations à appliquer aux éléments du document. Par exemple, on pourra définir comment transformer automatiquement les données tabulaires d'un document en instructions INSERT du langage SQL.

 

La norme XSL sera stabilisée courant 1999, mais d'ores et déjà les parties qui sont publiées constituent une spécification utilisable. On peut prévoir, à terme, un remplacement de HTML + CSS par XML + XSL, solution plus puissante et plus générale. Techniquement, aujourd'hui, un document XML + XSL peut être traduit automatiquement en HTML + CSS pour affichage dans un navigateur, moyennant quelques extensions de CSS que Microsoft a faites pour OFFICE 2000. L'exemple ci-dessous montre une telle spécification de traduction écrite en XSL: elle traduit un document XML en HTML.

<xsl:stylesheet>
     <xsl:template match = "/">
         <HTML>
         <BODY>
             <xsl:process-children/>
         /BODY>
         </HTML>
     </xsl:template>
     <xsl:template match = "author">
         <H1>
             <xsl:process-children/>'s fabulous
         </H1>
     </xsl:template>
     <xsl:template match = "recipe_name">
         <H2>
             <xsl:process-children/>
         </H2>
     </xsl:template>
     <xsl:template match = "meal">
         <TABLE><TR><TD><H3>EAT FOR:</H3></TD>
             <TD><H3><xsl:process-children/></H3></TD>
         </TR></TABLE>
     </xsl:template>
</xsl:stylesheet>

Exemple de feuille de style XSL: c'est du XML et cela rappelle HTML
Ici, l'interpréteur XSL traduit le document XML en HTML pour affichage dans un interpréteur HTML

 

XML + XSL: une puissante solution d'interopérabilité

Le couple XML + XSL ouvre des perspectives considérables en matière d'interopérabilité. Il permet de définir des messages auto-descripteurs, permettant d'interfacer deux applications aussi distinctes qu'une facturation et une comptabilité, et de le faire indépendamment des systèmes d'exploitation, langages de programmation, formats de mise en page et protocoles réseau. Qui plus est, chaque application qui utilise des données en comprend la structure et la sémantique, contrairement à HTML: cela permet des architectures puissantes. XML permet à un client d'échanger des données avec de multiples sources ou serveurs, sans que le client connaisse à l'avance les formats et les types de données auxquelles il accédera.

 

XSL permet, au départ ou à l'arrivée d'un message, de définir et d'exécuter des transformations automatiques de données. De telles transformations peuvent servir à adapter les données d'une application émettrice A aux besoins d'une application réceptrice B.

• Exemple utilisé par Microsoft pour afficher du XML: le transformer en HTML + CSS, puis le passer à Internet Explorer pour affichage.
• Exemple d'utilisation de XML: l'organisme de standardisation des logiciels orientés-objets OMG (Object Management Group) a défini un mécanisme standard d'interopérabilité entre référentiels appelé SMIF (Structured Metadata Interchange Format). SMIF est basé sur XML pour pouvoir supporter toute la richesse des structures de données des référentiels de développement modernes.

Le mécanisme de transformation de données de XSL ressemble au mécanisme de traduction de langage utilisé par un compilateur:

• un analyseur syntaxique reconnaît des éléments de texte XML
• il leur applique des règles de transformation en générant du texte dans un langage arbitraire, défini en XSL par l'utilisateur
• la traduction peut prendre en compte des valeurs de données du texte source, et pas seulement la structure; la logique de prise en compte peut comprendre des conditions et des boucles, par exemple telles qu'elles existent en JavaScript
• le résultat de la traduction s'appelle un "arbre résultat" (results tree).

 

Interopérabilité XML avec transformations XSL

En résumé, XML + XSL est une solution d'interopérabilité permettant de:

• Créer des passerelles de données entre une application A et le format XML, même pour des structures de données fort complexes. Une telle passerelle peut:
• extraire des données de A et créer un document XML, ou
• charger un document XML créé par ailleurs dans A
• Filtrer et transformer des documents XML grâce à des opérations décrites en XSL, pour adapter son contenu aux besoins d'une autre application.

En principe, la coopération des applications se fera par messages asynchrones, mais étant donné la vitesse considérable d'interprétation et de transformation de XML/XSL on peut même l'envisager de manière synchrone, avec une session maintenue.

On parviendra ainsi à interfacer des progiciels d'application, des SGBD, des documents EDI, des data warehouses, des référentiels, etc. On pourra aussi construire des filtres puissants et souples pour bloquer les messages email ou faire des réponses automatiques, filtrer des données ou des transactions avant un processus de réplication, etc.

Accès à des documents XML par programme: standard DOM

Un document XML est un véritable objet, et ses éléments sont eux-mêmes des objets. Tous ces objets sont accessibles par programme. Le standard DOM (Document Object Model) définit les méthodes d'accès à ces objets et une API pour le langage Java. En tant que programme orienté-objets, l'interpréteur XML offre une API avec des méthodes permettant de parcourir le document, de rechercher un élément, d'ajouter, supprimer ou modifier des éléments, etc. Pour un programme accédant à cette API, l'interpréteur XML est un objet passerelle permettant d'accéder à un autre objet, le document, dont les éléments sont eux-mêmes des objets. Par conséquent, si on désire utiliser un langage orienté-objets pour les opérations de filtrage et de transformation des documents XML, c'est désormais possible à partir de Java et de Visual Basic, qui offrent tous deux des objets d'accès.

Notons que le même modèle DOM définit aussi l'accès aux éléments d'un document HTML: si on dispose d'un interpréteur HTML supportant un accès par programme semblable à celui d'un interpréteur XML, on peut dynamiquement, dans le client, modifier le contenu et la mise en page du document HTML. On dit alors qu'on utilise DHTML (Dynamic HTML). Chez Microsoft, Internet Explorer supporte DHTML et XML conformément au modèle DOM.

Différences entre XML+XSL et d'autres solutions d'interopérabilité

Interopérabilité dans l'architecture client-serveur classique

L'architecture client-serveur traditionnelle utilise des clients avec interface utilisateur à fenêtres Windows ou Java (portable). Entre un tel client et un serveur on utilise deux types de protocoles d'interopérabilité:

• Un protocole d'accès à un SGBD, comme Net8 de Oracle ou ODBC
• Un protocole d'appel de fonctions, comme les divers RPC, CORBA ou DCOM.

Ces protocoles ont été conçus pour des applications non extensibles, où un client parle avec un serveur unique ou un nombre réduit de serveurs. Ils ne permettent pas à un client d'attaquer un serveur quelconque, faute de certitude sur les données (structure, sémantique) et services qu'il y trouvera. Ces restrictions ne sont guère gênantes dans un environnement stable de production répétitive, mais elles sont insupportables lorsqu'on veut pouvoir coopérer avec n'importe qui.

XML apporte ici une ouverture considérable, impossible à obtenir avec les protocoles ci-dessus. C'est qu'un protocole est fait, par définition, pour supporter certains services et pas d'autres, certaines données et pas d'autres. XML n'est pas un protocole, c'est une structure de données.

Un échange XML transfère des données alors qu'un échange RPC, CORBA, ou DCOM transfère des appels de fonctions: ce n'est pas la même chose.

L'interopérabilité RPC, CORBA ou DCOM est binaire (chaque programme voit les données dans son format natif, le protocole assurant les conversions éventuellement nécessaires). Au contraire, XML est non binaire: une application qui s'en sert doit utiliser des données au format standard XML pour sa communication. Aujourd'hui, le standard XML ne supporte que les données ASCII 7 bits, mais les extensions en cours d'approbation permettront de supporter des données sur 8 et même 16 bits (UNICODE).

Un message XML est auto-descripteur, alors qu'un échange RPC, CORBA ou DCOM demande une entente préalable, figée (IDL ou équivalent).

Les protocoles ODBC, RPC, CORBA et DCOM sont techniques et faits pour utilisation à partir de programmes. XML, au contraire, est d'un niveau applicatif, plus proche de l'utilisateur.

Le modèle relationnel, avec ses tables, n'est adapté qu'à des structures de données simples. XML, au contraire, décrit des structures bien plus puissantes, dont les tables ne sont qu'un cas particulier.

Au sens de la sécurité, HTML et XML traversent les firewalls, car ils aboutissent à un interpréteur qui protège du code binaire éventuellement dangereux. CORBA et DCOM sont en général arrêtés par un firewall; pour leur permettre de passer, on peut les transporter par dessus HTTP, mais avec une perte de performance sensible.

Déport d'interface utilisateur

Lorsqu'on veut utiliser un client léger, l'une des solutions consiste à faire tourner l'application cliente sous Windows NT Terminal Server, en mode multiutilisateurs, et à déporter l'interface utilisateur à l'aide d'un protocole. Les trois protocoles disponibles sont X11 (venant du monde UNIX), RDP (de Microsoft) et ICA (de Citrix). Le plus économe de bande passante est ICA, mais une solution d'interface utilisateur à base de HTML (transporté par le protocole HTTP) est plus économe encore, ce qui est précieux par exemple sur réseau commuté. L'ajout de XML à HTML, toujours transporté par HTTP, permet au client de comprendre les structures de données, donc d'être plus intelligent.

Comparaison de XML avec EDI

XML est plus souple et plus facile à mettre en oeuvre que EDI, mais il ne dispense pas, lui non plus, de se mettre d'accord sur les données à transmettre!

Puissance

Associé à XSL et (voir plus bas) à XQL, XML est infiniment plus puissant que CORBA ou DCOM, qui n'ont pas de possibilité de structuration de données, ni de transformation, ni de stockage intelligent, ni de recherche.

Pluralité des fournisseurs

XML est un standard international, comme CORBA. Ce n'est pas, comme DCOM, la propriété d'un fournisseur unique qui peut le faire évoluer à sa guise.

Langage XQL

En plus de XSL, un autre futur standard est en cours d'étude: XQL (eXtended Query Language). XQL permet la recherche dans une arborescence XML. C'est une extension de XSL permettant, comme XSL, de décrire des critères de recherche. Exemple: "book/author" signifie "trouver les éléments "author" contenus dans des éléments "book". Les recherches concernent une partie de structure à reconnaître et dont certains éléments satisfont des critères de valeur.

Le résultat d'une recherche XQL est une arborescence XML.

Langage XLL

Autre futur standard, XLL (eXtended Link Language) permet d'étendre la notion d'hyperlien. Exemples de types de liens définis par XLL:

• lien indirect passant par un annuaire d'adresse fixe connue, où un lien logique est associé à un lien physique; lorsqu'on déplace une page, par exemple, il suffit de modifier son adresse physique dans l'annuaire et toutes les pages qui pointent logiquement vers elle sont automatiquement liées à la nouvelle adresse;
• lien bidirectionnel;
• lien à sémantique bien définie (exemples: composé de, utilisé dans...).

L'offre de Microsoft

Microsoft offre déjà, dans Internet Explorer 4.x, un interpréteur XML incomplet. Un interpréteur complet, conforme à la norme XML 1.0 et tout à fait utilisable, sortira au premier trimestre 1999, avec Internet Explorer 5. Il y aura aussi un interpréteur XML supportant XSL sous forme de dll utilisable dans toute application, MSXML. Ces interpréteurs seront indispensables pour OFFICE 2000, successeur de OFFICE 97 mi-99. En tant que composant COM, MSXML sera capable de tourner sous Windows NT dans un client comme dans un serveur. Avec des outils de Visual Studio, qui les supportera complètement en 99, ces interpréteurs permettront de construire des solutions d'interopérabilité puissantes et performantes. Et si l'on achemine les messages grâce au moniteur asynchrone MSMQ, ces solutions seront particulièrement robustes en cas d'indisponibilité d'un système ou d'un élément de réseau.

Serveurs de données XML

Lorsque l'interopérabilité XML est utilisée de manière asynchrone, ce qui est le cas le plus fréquent, il faut un mécanisme de stockage des données en format XML. Pour que ce mécanisme offre des fonctionnalités riches (puissance de recherche, gestion des conflits d'accès, atomicité des transactions, sécurité, etc.) on ne peut se contenter d'un simple gestionnaire de fichiers: il faut un gestionnaire de données à structure arborescente. Disons-le tout net: un SGBD relationnel est mal adapté à ce rôle, car il devrait mettre en oeuvre de nombreuses tables et d'innombrables jointures. Un SGBD orienté-objets, au contraire, convient parfaitement.

On arrive ainsi à la notion de serveur de données XML, version arborescente d'un SGBD pour données tabulaires. Ce type de serveur, avec ses fonctionnalités spécialement conçues pour XML, constituera une alternative à une solution à base de SGBD universel comme ceux de Oracle, Informix et IBM; dans un SGBD universel on peut gérer correctement des arbres XML à condition de disposer d'une extension ad hoc.

Exemple de serveur XML: eXcelon de ObjectStore

eXcelon est un serveur de données XML qui stocke ses données dans sa base de données, bâtie sur un moteur SGBD orienté-objets ObjectStore.

eXcelon reçoit ses données de toutes sortes de sources et les convertit en objets stockés sous forme d'arborescence dans sa base: voir figure ci-dessous qui montre la représentation arborescente d'un objet "book" et sa représentation XML, tels qu'ils apparaissent dans l'outil d'interface utilisateur Explorer de eXcelon.

eXcelon n'invente pas la structure des données: il faut la lui fournir sous forme de description XML (DTD) ou il la comprend via la structure du flux XML auto-descriptif.

eXcelon peut accéder à de nombreux types de données par l'intermédiaire de passerelles:

• Données XML
• Données de SGBD relationnels, accédées en ODBC
• Données de SGBD orienté-objets ObjectStore, accédées de manière native
• Données accessibles à travers la passerelle OLE DB de Microsoft, telles que email Exchange ou Lotus, feuilles de calcul EXCEL, etc.
• Images, graphiques et vidéo.

Les données de la base eXcelon sont accessibles à travers:

• des API orientées-objets Java ou COM
• une interface utilisateur Explorer (figure ci-dessous) qui en donne soit une vue arborescente, soit une vue XML
• un serveur Web Netscape ou Microsoft IIS, auxquels eXcelon s'interface par leurs API respectives NSAPI ou ISAPI comme à travers CGI

Enfin, eXcelon offre de puissants mécanismes d'indexation XML permettant de faire des recherches de structure en XQL (voir paragraphe XQL ci-dessous).

Interface utilisateur Explorer d'eXcelon et l'arborescence XML "book"

 

Autres offres

Standard officiel et solution d'interopérabilité puissante, XML est adopté par un nombre croissant de fournisseurs. Chacun offre une passerelle XML vers / depuis son progiciel. L'offre XSL démarrera en 1999.

• Divers éditeurs d'outils ont annoncé des offres d'interopérabilité XML: SAP, Netscape et IBM, par exemple.