L'implémentation de l'API d'interrogation UDDI dans 4D - Partie 1
Date de publication : juin 2003
Par
Julien FEASSON (4D Inc.)
Cette note technique est la première d'une série de deux, ayant pour objectif la réalisation d'un client UDDI
mettant à l'oeuvre les fonctionnalités de client de service Web natives dans 4D 2003.
UDDI (Universal Description, Discovery and Integration) est un protocole fondé sur SOAP. Cette note
technique suppose donc que le lecteur est déjà familier avec SOAP, les services Web et XML. Le processus
d'utilisation du client de service Web et des nouvelles commandes d'analyse XML de 4D sera détaillé.
I. Introduction
II. Survol rapide d'UDDI
III. Présentation d'UDDI
IV. Survol technique
V. Quatre types d'information
VI. Les API de programmation
VII. Fondé sur SOAP
VIII. Les API d'interrogation
IX. Le modèle d'invocation UDDI
X. Faire face à un échec lors de l'appel d'un service Web
I. Introduction
Cette note technique est la première d'une série de deux, ayant pour objectif la réalisation d'un client UDDI
mettant à l'oeuvre les fonctionnalités de client de service Web natives dans 4D 2003.
UDDI (Universal Description, Discovery and Integration) est un protocole fondé sur SOAP. Cette note
technique suppose donc que le lecteur est déjà familier avec SOAP, les services Web et XML. Le processus
d'utilisation du client de service Web et des nouvelles commandes d'analyse XML de 4D sera détaillé.
Un client UDDI peut s'utiliser de deux façons, en invoquant un service Web :
· de recherche, effectuant une requête auprès d'un serveur UDDI ;
· d'enregistrement, en vue de publier un service Web sur un serveur UDDI.
Cette première note technique s'attachera à l'aspect requête tandis que la seconde détaillera la publication d'un
service Web.
La base de démo est loin d'inclure toutes les fonctionnalités d'un client UDDI, mais elle représente un très bon
point de départ de l' implémentation d'un client UDDI.
La base de démo accompagnant cette note ne propose pas de fonction de publication, la seconde base sera
fournie avec une prochaine note technique et inclura les deux aspects de recherche et publication.
II. Survol rapide d'UDDI
Une page HTML peut se retrouver perdue dans l'anonymat de billions d'autres pages sur le Web. Quelques
pionniers du Web des années 80 émirent l'idée de créer des annuaires, de manière à procurer aux autres
utilisateurs du Web un moyen simplifié de trouver rapidement n'importe quel page sur n'importe quel sujet.
Avec l'avènement des services Web, quelques sites Web (comme xmethods.net) ont commencé à fournir un
service d'enregistrement. Dans une approche analogue à celle de Yahoo, les fournisseurs de services Web
doivent enregistrer leurs services de façon à les publier pour les rendre accessibles au public.
UDDI propose le même genre d'outil de recherche mais bâti sur le protocole SOAP. Il devient ainsi possible de
requêter la base de données UDDI depuis n'importe quel langage supportant le protocole SOAP et d'intégrer
dans la même application, les services Web et les fonctions de recherche au lieu de devoir passer par un
navigateur.
Fourni avec 4D 2003, le client SOAP permet aux utilisateurs d'effectuer des requêtes sur un tel type de serveur.
Il devient ainsi possible de trouver et utiliser un service Web, disponible sur internet si les requêtes sont
envoyées vers un serveur UDDI sur le Web ou sur n'importe quel réseau interne pourvu que celui-ci héberge un
serveur UDDI centralisant tous les services Web disponibles en interne.
La définition d'UDDI a d'abord été l'affaire d'un comité constitué par les rédacteurs des spécifications SOAP.
Les spécifications UDDI sont maintenant entre les mains d'OASIS, une association essayant de regrouper
toutes les spécifications de protocoles liés à XML avant de les soumettre au W3C (se référer à www.oasisopen.
org).
UDDI en est aujourd'hui à la troisième version de ses spécifications et quelques organisations proposent déjà des serveurs auxquels vous pouvez envoyer des requêtes (XMethods, Microsoft, IBM). Sur le site Web de
l'O ASIS, vous trouverez le WSDL "générique" qui n'est cependant pas un WSDL valide de service UDDI. Un
WSD L DOIT (d'après les spécifications) comporter un élément "service" qui a pour fonction d'agréger une série
de ports reliés (correspondant à une collection de points finaux du réseau). Comme le WSDL fourni sur OASIS
est défini comme "générique", il ne comprend pas d'élément service car il n'est lié à aucun serveur spécifique. En
con séquence vous ne pouvez pas analyser le WSDL UDDI générique à l'aide de l'assistant de service Web de
4D ou de n'importe quel analyseur de WSDL. En revanche, ce WSDL est très utile car il spécifie un cadre
déc hange de données entre les clients et les serveurs UDDI. Il liste les méthodes qui devraient être proposées
par un serveur UDDI accompagnées pour chacune d'entre elles de ses paramètres et valeurs de retour.
Dans cette note technique, nous allons nous cantonner aux API d'interrogation qui permettent à un client UDDI
de rechercher des services Web sur des serveurs UDDI. Le WSDL attaché à ce service d'interrogation se trouve
ici :
III. Présentation d'UDDI
UDDI est un protocole s'appuyant sur SOAP, les couches peuvent se représenter ainsi :
· UDDI
· SOAP
· XML
· Protocole de transport Internet (HTTP, TCP/IP)
La spécification UDDI décrit un nuage conceptuel (centralisation logique d'un ensemble de noeuds physiques
d'opérateurs) de services Web et une interface de programmation qui définit un canevas relativement simple
permettant de décrire tout type de service Web. La spécification comprend plusieurs documents reliés et un
schéma XML qui définit un protocole de programmation fondé sur SOAP pour enregistrer et découvrir les
services Web.
IV. Survol technique
Les spécifications UDDI consistent en un schéma XML pour les messages SOAP et une spécification des API
UDDI. L'ensemble procure un modèle d'information de base et un cadre d'interaction offrant la capacité de
publier et retrouver de l'information sur un large spectre de services Web.
V. Quatre types d'information
Le coeur du modèle d'information utilisé par les registres UDDI est défini par un schéma XML. Le choix
d'XML se justifie par sa neutralité vis-à-vis des plateformes et sa capacité à décrire de manière naturelle les
relations hiérarchiques. Le standard émergent XML Schéma a été choisi pour son support de types de données
complexes et sa capacité à décrire facilement des modèles d'information.
Le schéma XML UDDI définit 4 type d'information de base représentant les données nécessaires à un technicien désireux d'utiliser les services Web d'un partenaire :
· Information métier (business information)
· Information service (service information)
· Information de liaison (binding information)
· Information sur les spécifications des services.
 Diagramme UML de relations entre les structures
Information métier : l'élément businessEntity
Ce modèle sert à stocker toutes les informations sur une entreprise qui publie des informations, sur ses contacts
et le services proposés. Elle stocke également une clé unique, identifiant l'entité commerciale : UUID (Universal
Unique Identifier). Correspond aux pages blanches de l'annuaire.
Information service : l'élément businessService
Ces informations consistent en la description métier des services Web; deux structures sont définies :
businessService et bindingTemplate. Une structure businessEntity peut contenir plusieurs structures
businessService.
La structure businessService est un conteneur descriptif utilisé pour regrouper des séries de services Web reliés
par le processus métier ou la catégorie de services. On pourrait citer comme exemples de processus métiers
pouvant se décliner en service Web : les services achats, les services d'expédition et d'autres processus métier de
haut-niveau. Correspond aux pages jaunes de l'annuaire.
Information de liaison : l'élément bindingTemplate
Les détails techniques requis pour interroger physiquement un service sont décrits dans des structures
bindingTemplate. Ces structures sont également appelées pages vertes. Elles gèrent la liste des structures
tModels que nous retrouverons dans la suite de cette note.
Pointeurs de spécifications et empreintes techniques (technical fingerprints)
Le bindingTemplate ne se révèle pas toujours suffisant pour simplement savoir où contacter un service Web
particulier, il décrit généralement le service en donnant son URL et une référence vers un élément tModel. Cette
structure comprend des informations propres à l'utilisation du service Web, comprenant son nom, l'identité de l'organisation qui publie et des pointeurs URL vers la description physique (formats de données, protocoles de
transport), habituellement sous forme de WSDL.
VI. Les API de programmation
Les spécifications de UDDI comprennent la description d'interfaces de service Web permettant un accès par
programmation à l'information contenue dans le registre UDDI. Cette API se divise en deux parties logiques :
les API d'interrogation (sur lesquelles nous allons nous focaliser dans la suite de cette note technique);
les API de publication (qui seront abordées dans la seconde note).
Les API d'interrogation se découpent elles-mêmes en deux sous-parties :
· une première utilisée pour construire des programmes qui interrogent et parcourent l'annuaire UDDI;
· une seconde utile dans l'éventualité où l'interrogation du service échoue.
La suite de cette note se restreindra sur la première de ces deux sous-parties : rechercher et naviguer dans
l'information proposée par les registres UDDI.
VII. Fondé sur SOAP
SOAP (Simple Object Access Protocol) est une recommandation du W3C décrivant une utilisation d'XML audessus
d'HTTP afin de disposer de mécanismes d'échanges de données et d'appels de procédures distantes.
Tous les appels aux API définis par les spécifications UDDI se comportent de manière synchrone avec les
registres des sites des opérateurs composant le nuage de service distribué UDDI .
VIII. Les API d'interrogation
Les API d'interrogation consistent en deux types d'appels qui permettent d'abord à un programme de trouver
rapidement les métiers, services Web et spécifications correspondant à sa recherche, puis de rentrer dans le
détail en se basant sur l'information générale procurée par les appels initiaux.
Les commandes API find_xx sont destinées aux recherches générales fondées sur de nombreux critères. Les
appels directs get_xx API offrent un accès à de l'information détaillée sur un enregistrement particulier.
IX. Le modèle d'invocation UDDI
Chaque service Web référencé est représenté par une structure bindingTemplate. L'invocation d'un service Web
s'effectue généralement sur la base d'informations fournies par une structure bindingTemplate mise au préalable
en cache. Le scénario d'utilisation d'UDDI àfin de rédiger un programme d'appel d'un service Web spécifique se
présente alors de la manière suivante :
Le développeur utilise l'annuaire professionnel UDDI pour retrouver l'information enregistrée sur l'entreprise
ou sur le partenaire qui déclare le service Web : information businessEntity.
Le développeur rentre au choix plus en détail dans une structure businessService ou demande une structure
complète businessEntity, puis sélectionne un bindingTemplate particulier.
En se basant sur le bindingTemplate, le développeur obtient de l'information sur les spécifications du service
Web au travers des structures tModel référencées par une clé unique contenu dans l'attribut tModelKey. Dans
le cas de 4D, une fois connu le lien vers le WSDL, le recours à l'assistant de web service permet de "découvrir"
le service Web.
En général, les appels au service distant fonctionneront correctement, les cas particuliers d'échecs et les moyens
d'y faire face sont explicités ci-dessous.
X. Faire face à un échec lors de l'appel d'un service Web
L'un des principaux bénéfices à maintenir de l'information sur les services Web dans un annuaire UDDI
distribué réside dans l'aspect "self service" fourni aux techniciens. Les entreprises utilisant les services Web
dans des opérations commerciales avec leurs partenaires doivent être capables de détecter et de gérer les problèmes de communication ou les autres causes d'échec. L'un des principaux soucis consiste dans la capacité
de prédire, détecter, ou réparer les échecs dans les systèmes d'un partenaire distant. De simples situations
d'interruptions temporaires provoquées par de la maintenance ou des sauvegardes nocturnes peuvent freiner la
décision de migrer vers les services Web. D'un autre côté, si vous êtes l'entreprise qui fournit les connexions
directes aux services Web, la remise en route après une panne et la capacité de basculer totalement sur un
système de sauvegarde sont des préoccupations primordiales. Je n'aborderai pas cet aspect dans cette note
technique quoi que cela puisse représenter le sujet d'une autre note si plusieurs développeurs sont intéressés…
__________________________________________________
Copyright © 1985-2008 4D SA - Tous droits réservés
Tous les efforts ont été faits pour que le contenu de cette note technique présente le maximum de fiabilité possible.
Néanmoins, les différents éléments composant cette note technique, et le cas échéant, le code, sont fournis sans garantie d'aucune sorte.
L'auteur et 4D S.A. déclinent donc toute responsabilité quant à l'utilisation qui pourrait être faite de ces éléments, tant à l'égard de leurs
utilisateurs que des tiers.
Les informations contenues dans ce document peuvent faire l'objet de modifications sans préavis et ne sauraient en aucune manière engager
4D SA. La fourniture du logiciel décrit dans ce document est régie par un octroi de licence dont les termes sont précisés par ailleurs dans la
licence électronique figurant sur le support du Logiciel et de la Documentation afférente. Le logiciel et sa documentation ne peuvent être
utilisés, copiés ou reproduits sur quelque support que ce soit et de quelque manière que ce soit, que conformément aux termes de cette
licence.
Aucune partie de ce document ne peut être reproduite ou recopiée de quelque manière que ce soit, électronique ou mécanique, y compris par
photocopie, enregistrement, archivage ou tout autre procédé de stockage, de traitement et de récupération d'informations, pour d'autres buts
que l'usage personnel de l'acheteur, et ce exclusivement aux conditions contractuelles, sans la permission explicite de 4D SA.
4D, 4D Calc, 4D Draw, 4D Write, 4D Insider, 4ème Dimension ®, 4D Server, 4D Compiler ainsi que les logos 4e Dimension, sont des marques
enregistrées de 4D SA.
Windows,Windows NT,Win 32s et Microsoft sont des marques enregistrées de Microsoft Corporation.
Apple, Macintosh, Power Macintosh, LaserWriter, ImageWriter, QuickTime sont des marques enregistrées ou des noms commerciaux de Apple Computer,Inc.
Mac2Win Software Copyright © 1990-2002 est un produit de Altura Software,Inc.
4D Write contient des éléments de "MacLink Plus file translation", un produit de DataViz, Inc,55 Corporate drive,Trumbull,CT,USA.
XTND Copyright 1992-2002 © 4D SA. Tous droits réservés.
XTND Technology Copyright 1989-2002 © Claris Corporation.. Tous droits réservés ACROBAT © Copyright 1987-2002, Secret
Commercial Adobe Systems Inc.Tous droits réservés. ACROBAT est une marque enregistrée d'Adobe Systems Inc.
Tous les autres noms de produits ou appellations sont des marques déposées ou des noms commerciaux appartenant à leurs propriétaires
respectifs.
__________________________________________________
 
Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur.
La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
|
