DATA2XML

DATA2XMLDATA2XML

PROBLEMATIQUE INITIALE :

Les SI actuels sont généralement composés de services et applications largement hétérogènes.

Les SI couvrent un champ de services et un domaine fonctionnel de plus en plus vaste.

La variété et l'hétérogénéité des différents composants du SI entrainent la complexité de l'administration et souvent la dispersion de l'information.

1

DATA2XMLDATA2XML


Les demandes des utilisateurs face à cette hétérogénéité vont vers plus de simplicité (SSO, BV, etc).

Les demandes des utilisateurs vont vers de la consolidation d'informations issues des divers composants du SI.

Les demandes des utilisateurs vont vers de la valorisation de l'information par rapport aux services ou actes de gestion (pilotage, statistiques).

2

DATA2XMLDATA2XML


Les demandes des informaticiens vont vers plus d'ouverture des systèmes ou plateforme.

Les demandes des informaticiens vont une simplification de l'administration (bases de comptes, etc)

Les demandes des informaticiens vont vers la communication entre eux des composants des SI.

3

DATA2XMLDATA2XML


LES SI SONT CONFRONTES A DES NECESSITES DE COHESION ET D'INTEROPERABILITE DE LEURS COMPOSANTS.

Projets structurants : ENT, LDAP, Portails ou SI intégrés type LR

Préconisations : S3IT, SDET, etc usage des technologies ouvertes : JAVA, XML, LDAP, WebServices, ...

4

DATA2XMLDATA2XMLDATA2XMLDATA2XML

CONSTAT N° 1 :

L'information est au coeur du problème :

pas une problématique de services, mais de récupération, de circulation, d'intégration, de communication et de synchronisation des données entre composants hétérogènes du SI.

D'où les standards ouverts : XML, Java, LDAP, WebServices...

5


CONSTAT N° 2 :

L'information est dispersée dans le SI.

Créer des canaux de récupération, de communication et de synchronisation des données entre les composants du SI induit le risque de dispersion des services (« moulinettes, cron, etc ») supportant ces canaux.

6


CONSTAT N° 3 :

La compétence est aussi dispersée :

L'informaticien ou le fonctionnel expert sur une « source » de données n'est généralement pas l'expert dans les technologies préconisées.

Et vice-versa ...

7


CONSTAT N° 4 :

Les composants du SI ne sont pas conçus en tant que tel pour communiquer entre eux :

applis de gestion métier autonome type AMUE : fermées (rien de prévu sur l'extérieur)applis de gestion métier intégrée type LR : intégrées entre elles, ouvertes mais pas communicant (pas d'API, pas de WS,...)services (mail, authentification, samba, etc) : interface à programmer soit même vers les autres services ou applis.

8


DATA2XML essaie donc de répondre a minima à ces constations.

Conçu pour un usage par un expert d'une ou plusieurs « sources de données » sans connaissance de Java, XML, ou programmation de WS.

Conçu pour centraliser et stocker des méthodes de récupérations de données (requêtes) afin d'éviter la dispersion du code appelé.

Conçu en Java, comme un WebService générique, fournisseur de données au format XML.

9


DATA2XML est un WebService.

Grosso modo :

un WS est un service sur une machine distante, accessible essentiellement pour des applications (service entre applications) par un protocole reprenant généralement quelques principes identiques :

- encodage XML- transport http, le plus souvent- organisation requêtes/réponses : RPC (xml-rpc, SOAP)

10


DATA2XML est aussi une application Web.

Elle s'adresse aux informaticiens compétents sur des stocks de données (bases ORACLE, MySQL, fichiers csv, fichiers texte, etc) et maîtrisant le langage d'interrogation associé (SQL, shell, etc), mais non expert dans la mise en oeuvre d'un WebService ou les technologies inhérentes : XML, programmation Objet, etc.

Elle fournit une interface web de construction d'un document de données accessible par un WebService.

11


Terminologie DATA2XML :

source de données: c'est un stock de données accessible via un moteur quelconque. Exemple : une base Oracle, une base MySQL, un annuaire LDAP, un fichier csv, un fichier texte, etc.

connecteur: le canal et les droits associés qui permettent d'interroger la source de données par une ou plusieurs commandes écrites dans un langage connu du moteur et de récupérer le résultat de cette interrogation. Exemple : JDBC, LDAP, ssh, etc.

12


Terminologie DATA2XML (suite) :

requête: commande ou liste de commandes écrites dans un langage et soumises à la source de données via un connecteur. Exemple : requête SQL.

Paramètre: variable incluse dans la ligne de commande d'une requête et dont la valeur est affectée avant de soumettre la requête à la source de donnée. Exemple : clause WHERE d'une requête SQL, select nom from individu where age >= &&age .

13


Terminologie DATA2XML (suite) :

transaction: ensemble de requêtes sur un connecteur donné. La notion de commit n'a de sens que pour une interrogation d'un SGBDR, si on le décide.

Fournisseur de données: ensemble de transactions et par extension le document contenant les résultats de l'exécution de l'ensemble de ses transactions. Exemple : Liste des agents partant à la retraite d'ici 5 ans.

14


Terminologie DATA2XML (fin) :

Développeur: l'informaticien utilisateur de DATAXML, connaissant bien sa source de donnée et compétent pour écrire des requêtes sur celle-ci.

Consommateur, client ou utilisateur: l'application ou l'utilisateur final qui exploitera les données produites par un fournisseur et reçues du WebService sous forme d'un flux XML. Exemple : formulaire web pour un internaute du service du personnel.

15


Fonctionnement :

Un développeur écrit un fournisseur de données sur ses sources de données via les connecteurs.

Le fournisseur de données est publié et devient accessible au travers du WebService.

Le fournisseur est stocké à un endroit unique et est ré-utilisable ou modifiable par d'autres développeurs.

16


17

Fournisseur 2

Fournisseur n

1 SEUL WEBSERVICE

Fournisseur 1

Source de données

Source de données

Source de données

Source de données

Sérialisation

XML

Principe général


Résultat renvoyé :

Document XML : nom du fournisseur de donnéestransaction 1 sur un connecteur

requête 1liste de commandes

requête 2liste de commandes

...requête n

liste de commandestransaction 2 sur un connecteur

requête 1requête 2...requête n

...transaction n

18


Exemple :

Dans un même document de pilotage : suivi des contractuels

Paragraphe 1 (sur Harpège) nombre de contractuels employés à l'instant trépartition du nombre par tranche d'ancienneté (<1 an, de 1 à 3 ans, de 3 à 5, plus de 5 ans)répartition du nombre en tranches indiciaires et en catégories A,B, C, Drépartition du pourcentage entre contrat et vacation

Paragraphe 2 (sur Papaye)répartition des salaires en tranches indiciaires avec min et max par trancheécart-type de salaires par tranche indiciaire et par catégorie

Paragraphe 3 (sur Nabuco)masse salariale sur budget UR consommée à l'instant tmasse salariale sur conventions consommée à l'instant tpourcentage de la masse salariale sur budget global par UB

19


Usages

Initialement, tout besoin simple d'interopérabilité applicative orientée données (moulinettes)

20


Usages

Mais aussi :

● complément comme fournisseur d'éditions pour toute application de gestion métier limité en natif par un nombre déterminé et souvent insuffisant d'éditions spécifiques (à une XSLT près),

● alimentation immédiate d'un outil de reporting XML (type ireporting) sans dispersion des fournisseurs de données sur les postes clients,

21


Usages

ou encore :

● publier des informations issues directement des bases du SI sur un site web (cf client orienté « éditeur Lenya » et pluggé Cocoon sur notre site),

● générer des fichiers XML eux-même fournisseurs de données pour DATA2XML (possibilité requêtage multibase croisé),

22


Usages

ou enfin :

● charger des objets métiers J2EE, voire recharger des bases de données, alimenter un annuaire LDAP, etc

● en résumé, fournir simplement en données n'importe quel consommateur du WebService... Les besoins ne manquent pas !

23


Les améliorations attendues

L'authentification des développeurs et la gestion des droits sur les objets de l'application (connecteurs, fournisseurs) dans l'interface de conception,

Le transport et la gestion d'une authentification en provenance du consommateur,

Un espace de rangement multi-dimensionnel des fournisseurs sérialisés,

24


Les améliorations attendues

La prise en charge de connecteurs vers d'autres types de sources de données que les SGDB, en particulier :

● vers session shell unix (grep, cut, awk, ed, etc),

● vers fichier XML (XST),

● vers annuaire LDAP,

● vers un fournisseur de données déjà sérialisé (appel dynamique et résultat vu comme source de données !)

25

Documents

DATA2XML