La gouvernance des données XML en SOA

Préambule

Cette meilleure pratique est une introduction aux architectures qui soutiennent la gouvernance des données dans les environnements XML.
Elle permet de fixer un cadre d’action pour des chantiers détaillés de mise en œuvre. Nous considérons que le lecteur est déjà familiarisé avec les concepts SOA et Web services. (Voir les Guides Cadre de référence SOA et Cadre de référence Web services.)

Objectifs de la gouvernance des données

Les objectifs de la gouvernance des données sont similaires à ceux déjà connus, mais pas toujours bien pratiqués, de l’administration des données. Cependant, nous nous limitons ici à étudier les principes de gouvernance spécifiques aux données XML, c'est-à-dire les données qui ont une vocation d’exposition vers des organisations tierces et/ou vers des systèmes applicatifs. Ces données transitent donc dans la couche ‘haute’ du modèle SOA (coarse grained) qui correspond au ‘service métier’ de la typologie de services détaillée dans le guide ‘Cadre de référence SOA’.

Puisque les données XML sont exposées dans des contextes d’usage variés, leur administration est déterminante. A la différence des données qui restent dans le périmètre d’usage d’un nombre limité d’applicatifs, la mise en place de flux de données XML impose une démarche rigoureuse de gouvernance. L’absence d’une telle démarche rend difficile l’évolution vers le SOA, plus précisément, les problèmes suivants doivent être évités :

• Perte de la traçabilité sur le contenu des schémas exposés aux Consommateurs. On constate qu’une donnée XML est présente dans un Schéma mais on ne connaît plus son sens, sa légitimité au sein du schéma… La relation avec les Consommateurs devient difficile et le niveau de risque lié à ce que l’on expose augmente (est-on certain de ne pas exposer une donnée XML qui ne devrait pas l’être ?).
• Divergence de modélisation d’un même objet. Plusieurs schémas différents existent pour représenter le même objet exposé vers les Consommateurs, ce qui conduit à une multiplication des logiciels d’implémentation (un programme par type de schéma) et donc pénalise la maintenance, la documentation et le support.
• Divergence de valeurs. Un même objet présente des valeurs différentes selon qu’il soit consommé au titre d’un Schéma de données XML ou d’un autre.

Pour palier à ces risques (et d’autres qui ne sont pas cités ici) il faut en priorité :

• Référencer les schémas XML et les réutiliser plutôt que de les (re)construire de toutes pièces à l’occasion de chaque projet.
• Documenter chaque donnée XML afin d’en suivre la traçabilité.
• Créer une méta-représentation (ce que l’on nomme ‘Ontologie’) pour documenter la connaissance des schémas XML et leurs usages dans les Web services.

La suite de cette meilleure pratique précise l’architecture globale à mettre en place pour traiter ces risques.

Aperçu de l’architecture cible

La figure suivante montre l’architecture globale qui supporte la démarche de gouvernance des données XML.
Les paragraphes suivants fournissent les explications pour une compréhension du fonctionnement de chaque bloc étudié dans l’ordre suivant : Catégorie, Service métier, Couche physique, Ontology, Registry.

Catégorie

On rappelle que le concept de Catégorie est celui décrit par Grady Booch. Il permet d’organiser l’architecture du système autour des grands objets de gestion (voir meilleure pratique dans le Guide ‘Cadre de référence SOA’).

Pour chaque catégorie, on modélise ses données à l’aide d’un modèle conceptuel (Diagramme de classes UML) qui s’appuie sur un profile SOA adapté afin, par exemple, de définir les stéréotype ‘Catégorie’, ‘Service métier’, ‘Processus’ …

Le niveau conceptuel est dérivé en un premier niveau logique qui tient compte d’une future représentation en Schéma XML d’une partie du modèle initial.

Attention, il s’agit bien d’un sous-ensemble du modèle conceptuel de départ et pas de sa totalité. En effet, l’intérêt de l’usage d’XML concerne l’exposition de flux de données (en direct ou via des Web services) vers des Consommateurs (humains, systèmes) et pas la gestion des échanges d’information sur les couches applicatives proches de l’implémentation (Voir Cadre de référence Web services pour le détail du niveau d’usage de XML dans le modèle d’architecture). Le choix du sous-ensemble conceptuel candidat à une représentation en Schéma XML n’est pas une démarche évidente. Il s’agit d’un travail sur la sémantique et la nature d’emploi des données qui nécessite l’étude de la meilleure pratique spécifique à ce thème.

Afin d’optimiser l’usage de l’exposition XML aussi bien sur le plan sémantique (comprendre le modèle proposé) que sur le plan des performances d’exécution (plus le modèle exposé est vaste et plus la performance peut se dégrader) on construit des sous-ensembles du schéma XML initial afin de créer des vues qui seront directement exposées (voir figure ci-contre). Ces vues sont ensuite réutilisées au niveau des paramètres dans les messages des Web services et/ou directement par les systèmes applicatifs (Il ne faut pas se limiter à une modélisation « grande maille » des schémas XML dans l’optique de l’obtention d’une structure de données universelle. En effet, un schéma trop vaste rend caduque sa réutilisation à cause de sa complexité sémantique et des conséquences en terme de performance d’exécution. La création de vues XML est donc incontournables pour la gouvernance rationnelle des données).

Par exemple, pour la Catégorie Client on dispose des représentations suivantes :

• Un modèle conceptuel qui décrit ses données.
• Un modèle logique avec un profile XML Schéma (Voir par exemple celui proposé sur www.xmlmodeling.com) qui sélectionne un sous-ensemble du modèle précédent. On décrit donc ici les données du Client candidates à être exposées en XML.
• D’autres modèles logiques qui forment des sous-ensembles du précédent et plus précisément un modèle logique par vue XML exposée. Par exemple, on dispose d’une vue XML ‘ClientSynthèse’ et d’une autre ‘ClientDétail’ avec plus d’information.

Sur le plan opératoire, il faut que l’AGL de modélisation UML autorise la création de vues à partir d’un modèle initial avec des règles de synchronisation pertinentes entre les deux : il ne s’agit évidemment pas de faire du copier/coller entre les modèles des différentes vues.

Service métier

Il s’agit du service métier au sens de l’architecture SOA que nous définissons par ailleurs dans le Guide ‘Cadre de référence SOA’.
Chaque service métier est représenté par un modèle logique (éventuellement issu d’un modèle conceptuel initial) dont la classe réifie le service métier et ses méthodes réifie les opérations qu’il expose. Les paramètres manipulés par les messages des opérations proviennent de la description des modèles XML exposés par chaque Catégorie.

Lorsque l’on construit un service métier pour exposer un flux XML on ne crée pas de toute pièce la structure des données nécessaires mais on réutilise en priorité celles exposées par les Catégories.

Sur le plan du cycle de gestion des projets, on peut créer une nouvelle exposition sur une Catégorie (ie. une vue) à partir d’un besoin rencontré lors de la spécification d’un service métier, mais la règle de départ est la recherche de la réutilisation des vues existantes et exposées par les Catégories. L’enjeu de l’unification des données et de leur gouvernance est concrétisé par cette démarche.

L’objectif de cette note n’étant pas de détailler l’ensemble des mécanismes à mettre en place nous n’abordons pas le cas de la gestion du concept de processus, lui-même étant un orchestrateur d’appel vers les services métiers (voir Guide ‘Cadre de référence SOA’).

Couche physique

Cette couche de l’architecture permet de traduire les modèles logiques (Catégorie et Service métier) en représentations physiques utilisées par les implémentations du logiciel, ce qui participe à la démarche MDA (Model Driven Architecture).

CATEGORY

Grâce au profil XML Schéma utilisé lors de la modélisation des vues logiques exposées par la Catégorie, on peut générer automatiquement un schéma XML pour chaque vue (obtention d’un fichier .xsd).

Nous ne traitons pas ici des mécanismes d’importation (<import>) entre les vues qui néanmoins sont indispensables. Par exemple, si l’on dispose de deux Catégories Client et Commande et que la vue Client présente aussi les Commandes alors il faut déclarer un import XML Schéma entre le schéma Client et le schéma Commande. Dans ce cas, au niveau du modèle UML, les deux catégories sont reliées entre elle par une association de classes (une classe maîtresse côté Client et une classe esclave côté Commande).

Dès lors que le schéma XML est disponible (xsd) on utilise JAXB (Même principe dans le cas .NET avec l’outil XSD.EXE.) pour générer l’implémentation en Java des types XML ainsi que les classes qui permettront de réaliser le mapping des instances XML avec java (dans les deux sens).

Ce mode opératoire permet d’exposer aux applications java à la fois le XML et l’implémentation à utiliser. On peut aussi ne pas employer JAXB et exposer directement un schéma XML aux applications

Sur le plan organisationnel et de l’outillage associé, l’exposition se fait via la Registry dont nous parlons dans la suite.

SERVICE METIER

Grâce au profil SOA utilisé lors de la modélisation logique du Service métier on peut générer automatiquement l’implémentation Java correspondante (une classe avec une méthode par opération exposée). Les types de données utilisés dans les paramètres des messages des opérations proviennent de la réutilisation des vues XML exposées par les Catégories.

A partir de cette implémentation Java, on utilise un générateur SOAP JAX-RPC qui lui-même embarque JAXB afin de générer le Web service (wsdl, xsd, skeleton SOAP) (Même principe en .NET.).

Ce mode opératoire permet d’exposer le flux XML en Web service (WSDL, SOAP).

Sur le plan organisationnel et de l’outillage associé, l’exposition se fait via la Registry dont nous parlons dans la suite.

Ontology

Sur la figure de l’architecture cible (schéma du début du paragraphe) la couche de gestion de l’Ontology est située dans le cadrant du haut. Il s’agit d’une représentation de la façon dont s’opère le classement des concepts manipulés et notamment les Services métiers, les Catégories et les données dans les Catégories. On retrouve donc des mécanismes de taxonomies (Classification Schemes), de construction de thesaurus, et de description de la connaissance pour la gouvernance des données au sens ISO11179.

En complément de l’ISO11179, l’usage de XML pour créer des ontologies bénéficie de RDF (Resource Description Framework) et de OWL (Ontology Web Langage) qui sont intéressants bien que nouveaux et assez complexes (Septembre 2004).

L’idée générale est de masquer cette complexité à l’aide d’une représentation qui opère à un niveau plus conceptuel (UML) ou grâce à des outils spécialisés par exemple dans RDF comme http://protege.stanford.edu/index.html.

Nous rappelons de manière synthétique le positionnement de chacun des standards cités à l’instant et gérés par le W3C :

• RDF (Resource Framework Langage) permet de créer des triplets (objet, propriété, valeur) formés par des URL et/ou des URN. On peut ainsi bâtir un réseau sémantique qui associe des propriétés et des valeurs à des ressources web. RDF s’étend à RDF-Schéma qui permet d’augmenter la capacité d’expression sémantique en créant par exemple des types complexes de propriétés (Certaines critiques existent sur la légitimité de RDFS face à une représentation équivalente qui pourrait se réaliser en Schéma XML habituel. Néanmoins, l’extension de RDFS vers OWL (Ontology Web Langage) semble conforter l’intérêt et la légitimité de RDFS).
• OWL (Ontology Web Langage) pousse encore plus loin l’usage de RDF en le complétant d’un langage de requête permettant par exemple une manipulation ensembliste des réseaux sémantiques : IntersectionOf permet de mélanger deux ontologies… mais aussi UnionOf, ComplementOf…

En ce qui concerne la norme ISO-11179, elle est plus ancienne que RDF et OWL. Elle spécifie les méta-données qui doivent être rattachées à une donnée pour la décrire (nom, définition, origine, date de mise à jour, propriétaire…) mais propose aussi son propre Classification Schemes dont l’étude de proximité et d’agencement avec ceux de RDF/OWL et d’ebXML sort du cadre de cette note de synthèse (voir ‘Global Ontology’ sur la figure suivante) mais nécessite un chantier à part entière.

Actuellement, on assiste à des travaux de convergence et/ou d’interfaçage entre toutes ces approches qui contribuent à l’objectif de la gestion d’ontologie. Par exemple l’implémentation XML de l’ISO-11179 est un sujet important.

Registry

L’ensemble des modèles et schémas XML produits fait l’objet d’une exposition dans un référentiel accessible par des populations d’acteurs variés et pas exclusivement informaticien.

Ainsi l’usage d’un AGL de conception, bien qu’il remplisse les fonctions d’un référentiel, ne peut pas se substituer à un outil d’exposition plus fonctionnel. C’est à ce niveau que le concept et les outils de Registry (ou Registry XML) interviennent.
La Registry accueille les éléments suivants :

• L’ontologie dans un format d’importation conforme avec les standards RDF, OWL et ISO11179.
• Les schémas XML (.xsd) qui correspondent aux différentes vues des Catégories. Le concept de Catégorie est un élément de l’ontologie.
• Pour chaque donnée XML la description conforme au standard ISO11179 (sur la figure ci-contre : ‘XML Data points description’).
• Les descriptifs des Web services, c'est-à-dire les fichiers XML et les Schémas de données associés (soit directement ceux générés par le toolkit SOAP soit les schémas déjà référencés par les vues des Catégories : ce point n’est pas détaillé dans cette note de synthèse).
• Les modèles UML ou certains d’entre eux que l’on souhaite mettre à disposition de certaines populations d’acteur.
• D’autres informations multimédias comme les documentations bureautiques par exemple que l’on souhaite publier.

La Registry offre une interface utilisateur pour formuler des requêtes d’interrogation qui suit les Classification Schemes de l’Ontologie. Chaque acteur dispose de droits de consultation et de mise à jour adaptés. On peut gérer des acteurs internes à l’organisation et extérieurs (filiales, partenaires, clients, fournisseurs…).

Compte tenu de la diversité des informations stockées, il faut que l’outil Registry soit multi-standards, ce qui reste encore un point faible du marché actuel bien que certaines implémentations commencent à s’engouffrer dans ce domaine : voir par exemple http://www.blueoxide.com/ (septembre 2004). Plus précisément, l’interface d’accès doit permettre de traiter les ontologies (RDF, OWL…), les meta-données ISO11179, ebXML registry pour le stockage des Schéma XML, UDDI pour les Web services.

Autres points à prendre en compte

Gestion des namespaces

Il faut décider de la façon dont les propriétés du namespace sont rattachées au modèle UML. Une solution consiste à créer un package UML pour chaque namespace et d’utiliser les propriétés du package (ou du stéréotype <Category>) pour renseigner celles du namespace : nom, elementFormDefault, attributeFormDefault…Dans ce cas, il n’est pas possible d’avoir plusieurs schémas qui disposent du même namespaces (1 Schéma XML par package).

Il faut aussi définir des règles pour la construction des Schémas XML sans namespace (ie. un namespace avec un label spécifique pour le repérer) qui sont par ailleurs inclus (ou importé, ou redéfinis) par d’autres schémas ayant eux-mêmes un namespace déclaré : c’est le mécanisme des schémas « caméléons ». Le schéma de départ (le caméléon) peut ainsi être réutilisé dans d’autres schémas avec le nom de la namespace du schéma qui l’utilise (voir exemple sur la figure ci-contre).

Profile XML (UML)

On trouve plusieurs profiles XML disponibles sur le marché sans pour autant qu’il existe de standardisation connue à ce jour (Septembre 2004). Par exemple, il faut faire attention à ce que les Schémas XML générés restent compatibles avec une exploitation ultérieure par JAXB ou bien admettre la modification du modèle logique de données avant la génération JAXB.

A ce titre, il conviendrait de réfléchir à un profile XML – JAXB (UML).

De nombreuses autres questions pour le passage de la modélisation d’UML vers XML Schéma se pose comme par exemple la représentation des contraintes OCL (Object Constraints Language) qui sont utilisées pour l’expression des pré-conditions et post-conditions sur les opérations des services métiers. Certaines approches consistent à générer du Schematron (règles déclarées en XML qui s’appuient sur Xpath) ou des Aspects Java (voir aussi la meilleure pratique sur la validation automatique des contrats de services).

Règles de réutilisation des schémas

Les règles de réutilisation par <include>, <import> et <redefine> doivent être précisées à la fois au niveau de l’organisation des données entre les catégories et au niveau des services métiers.

Le profile UML permet de représenter les types de dépendance entre les packages (donc entre les schémas XML) via un stéréotype qui indique soit l’action d’include, d’import ou de redefine XML.

Règles d’organisation du WSDL

Nous avons déjà traité ce sujet dans la meilleure pratique sur le mapping WSDL vers UDDI selon la TC OASIS. On rappelle qu’il faut découper le WSDL en trois fichiers : message + portType, Binding, Service.

Gestion de versions et cycle de vie

Nous avons déjà traité ce sujet dans une autre meilleure pratique avec notamment l’usage d’un datestamps sur la targetnamespace de la Catégorie.

Toutes les règles restent valident dans le contexte d’utilisation d’une registry comme présentée dans cette note : il convient donc de se reporter aux autres meilleures pratiques sur la gestion des versions et du cycle de vie des Web services (Tmodel dans UDDI).