Universal Description Discovery and Integration
Universal Description Discovery and Integration, connu aussi sous l'acronyme UDDI, est un annuaire de services fondé sur XML et plus particulièrement destiné aux services Web.
UDDI a été conçu pour une utilisation conjointe avec le ebXML pour le commerce électronique.
Un annuaire UDDI permet de localiser sur le réseau le service Web recherché. C'est un élément clé dans les spécifications de Services Web WS-*, car il permet l'accès aux répertoires des utilisateurs potentiels de services web.
UDDI est une spécification mise au point par l'OASIS.
Historique
modifierLe projet UDDI a commencé en octobre 2000 par une collaboration entre Microsoft, Ariba (en)[1], et IBM. D'autres entreprises s'y sont jointes comme Sun Microsystems, Oracle, HP ou encore SAP.
Une version 2 a été mise au point en 2002.
La version 3 a été mise au point en 2003, et a été adoptée par quelques entreprises en 2005[2].
En 2022 cette technologie est quasi obsolète, pratiquement seul le projet Apache jUDDI persiste.
Utilisation d'UDDI pour le commerce électronique
modifierUDDI : un annuaire de services web pour ebXML
modifierUDDI a vocation d'être employé dans le commerce électronique comme un annuaire pour la découverte des services web WS-*, en étant couplé avec le registre ebXML avec lequel il est étroitement imbriqué[3]. De cette façon, UDDI permet de construire des registres de services web.
En pratique, UDDI permet de stocker à la fois des informations techniques et des informations sur les processus d'affaires telles que l'adresse pour accéder aux services Web, mais également des informations beaucoup plus contextuelles, telles que le nom de la personne qui s'occupe de leur gestion, la description sommaire de leurs fonctionnalités ou encore le nom et la branche d'activité de l'entreprise dont ils dépendent.
Place d'UDDI dans le commerce électronique
modifierLe commerce électronique comporte trois phases principales[4] :
- le transport : assuré grâce au protocole SOAP,
- la découverte des services Web : c'est là qu'intervient UDDI,
- la description des services Web : assurée grâce à WSDL (fondé sur XML).
Consultation de l'annuaire
modifierL'annuaire UDDI est consultable de différentes manières :
- Les pages blanches comprennent la liste des entreprises ainsi que des informations associées à ces dernières. Nous y retrouvons donc des informations comme le nom de l'entreprise, ses coordonnées, la description de l'entreprise mais également l'ensemble de ses identifiants.
- Les pages jaunes recensent les services Web de chacune des entreprises sous le standard WSDL.
- Les pages vertes fournissent des informations techniques précises sur les services fournis. Ces informations concernent les descriptions de services et d'information de liaison ou encore les processus métiers associés.
Grâce à cette triple lecture, l'ensemble des informations utiles sont accessibles.
Utilisation d'UDDI pour trouver un registre/répertoire ebXML
modifierEn mai 2001, IBM et Sun ont signé un document intitulé "Using UDDI to find ebXML Registry/Repository"[5]. Ce document présente une étude de cas qui montre comment utiliser le registre "business" UDDI pour rechercher un registre ebXML, et définit une série d'étapes qui doivent être suivies pour définir et enregistrer un registre ebXML dans un registre UDDI.
Il y a la possibilité d'une interopérabilité opérationnelle entre UDDI et un registre ebXML en termes de découverte. Différents documents ont été écrits sur ce sujet.
Dans l'architecture ebXML, UDDI peut interagir en utilisant CORBA.
UDDI comme registre pour les composants ebXML
modifierEn 2003, le comité technique UDDI a produit une note intitulée "UDDI as the registry for ebXML components" (UDDI comme registre pour les composants ebXML). Cette note technique fournit des lignes directrices pour l'utilisation des registres UDDI dans le framework ebXML des services B2B, et pour permettre la découverte automatique de composants du framework ebXML (Collaboration Protocol Profiles, Collaboration Protocol Agreements, Business Process Schema Specifications, etc.) en utilisant UDDI.
Cette interopérabilité démultiplie les forces complémentaires de chaque registre de manière effective.
Architecture fonctionnelle
modifierAvertissement :
Cette section est placée à titre d'information exclusivement, et n'est pas destinée à une utilisation pour la programmation[6].
Représentation des informations
modifierPour que les services Web aient du sens, on a besoin de fournir des informations qui dépassent les spécifications techniques des services. Le cœur du registre UDDI est constitué par la représentation des données et des métadonnées sur les services Web[7].
Schémas UDDI
modifierUDDI utilise le langage XML Schema pour décrire ses structures de données[8]. En version 3.0.1 de UDDI, il existe 9 schémas XML :
- UDDI API Schema
- UDDI Custody Schema
- UDDI Subscription Schema
- UDDI Subscription listener Schema
- UDDI Replication Schema
- UDDI Value Set Validation Schema
- UDDI Value Set Catching
- UDDI Policy
- UDDI Policy Instance Parameters
Structures de données UDDI
modifierQuatre types principaux de structures de données
modifierLes informations qui permettent d'établir un enregistrement UDDI consistent en quatre types principaux de structures de données XML. Cette répartition simple par type d'information aide à la localisation et à la compréhension rapide des différentes informations qui constituent un enregistrement.
Ces quatre types constituent l'ensemble des informations fournies par le cadre de description de service UDDI. Chacune de ces structures XML contient un certain nombre de champs qui servent à décrire une affaire ou une technologie.
Détails :
- Structure de données de référence, V2.03, , participation IBM, HP, Fujitsu, Sun, Microsoft, SAP, Oracle Corporation.
- UDDI structure de données du registre, version 3.0.1, , participation IBM, Microsoft, France Telecom, SAP, Oracle Corporation.
Entité métier
modifierTerme anglais : businessEntity
Détails (v3.0.1) :
BusinessEntity est une structure de donnée de haut niveau qui décrit une entreprise ou une autre entité pour laquelle une information est enregistrée. Elle est employée pour représenter les entreprises ("businesses") et les fournisseurs dans UDDI. Elle contient de l'information descriptive sur l'entreprise ou le fournisseur et sur les services qu'il propose.
Documentation complémentaire :
- discoveryURL : URL de "découverte",
- name : autres noms de la businessEntity,
- description : descriptions dans de multiples langues de la businessEntity (xml:lang),
- contact : information sur les contacts,
- adresse : adresse postale du contact, avec la langue (xml:lang), et ligne d'adresse,
- businessServices,
- identifierBag : information de classification.
- categoryBag : informations sur les normes par exemple,
etc
Les descriptions de service et l'information technique sont exprimés dans une businessEntity par les structures businessService et bindingTemplate qui lui appartiennent. Même si le nom de l'entité XML contient le mot “business”, la structure peut très bien être employée pour modéliser plus qu'un simple “business”.
Service métier
modifierTerme anglais : businessService
Détails (v3.0.1) :
BusinessService permet de décrire un ensemble logique de services web, qui peut contenir un ou plusieurs bindingTemplates. Au niveau service, aucune information technique n'est encore fournie sur ces services ; en revanche, cette structure offre la possibilité d'assembler un ensemble de services sous une rubrique commune.
Chaque businessService est le fils logique d'une seule businessEntity. Chaque businessService contient de l'information descriptive – noms, descriptions et information de classification - qui soulignent l'objectif des services web individuels que l'on trouve à l'intérieur. Par exemple, une structure businessService pourrait contenir un ensemble de services web de commandes d'achat (soumission, confirmation et notification) qui sont fournies par un métier.
bindingTemplate
modifierDétails (v3.0.1) :
- Représentation de l'information technique des services web avec bindingTemplate
- Description de la structure de bindingTemplate
Information requise pour invoquer des services spécifiques qui peuvent contenir des liens avec un ou plusieurs protocoles, comme HTTP or SMTP.
tModel
modifierDétails (v3.0.1) :
- Représentation des modèles techniques avec tModels
- Description de la structure des modèles techniques
- tModel sur le site UDDI
tModel (technical model ou modèle technique) correspond à l'“empreinte digitale” technique pour un service donné qui peut aussi fonctionner comme espace de noms (namespace) pour identifier d'autres entités, incluant d'autres tModels.
L'utilisation des tModels est essentielle dans la manière avec laquelle UDDI représente les données et les métadonnées.
Le tModel peut comporter les informations suivantes :
- Définition des protocoles (HTTP, SMTP),
- Ensemble de valeurs : systèmes d'identificateurs, espaces de noms, ...
- Groupes de catégorisations,
- Formats d'adresses postales,
- Find qualifiers utilisés pour modifier le comportement des API UDDI find_xx,
- Attributs de type d'utilisation, qui spécifient le type de ressource auquel on fait référence dans une URI.
Pour bien comprendre la relation entre un BindingTemplate et un tModel, il faut savoir qu’un BusinessService peut supporter plusieurs types de business protocols ou de spécifications (XML vocabularies, EDI standards, RosettaNet Partner Interface Processes, …). Le BindingTemplate peut faire référence à chacun de ces protocoles ou spécifications via un tModel spécifique.
Autres (publisherAssertion,...)
modifierpublisherAssertion : Description, dans la vue d'une businessEntity, de la relation qu'une businessEntity entretient avec une autre businessEntity.
subscription : Description d'une requête dans la durée pour garder la trace des changements des entités déscrites par la souscription.
Architecture technique
modifierOrientations techniques
modifierTechniquement, UDDI se place dans le cadre d'architectures orientées services (Service Oriented Architecture).
Il repose sur un ensemble de technologies compatibles avec le langage de balisage XML :
- le protocole de transport SOAP (HTTP),
- le langage de description de format de document XML Schema,
- et le langage de description de service web WSDL.
Sommaire : UDDI Services and API Sets
Nœuds UDDI
modifierLes nœuds UDDI sont des services qui supportent les spécifications UDDI et appartiennent à un registre UDDI.
Registre UDDI
modifierLes registres UDDI sont des ensembles d'un ou plusieurs nœuds.
Emploi au niveau des gouvernements
modifierUDDI est employé dans le cadre des initiatives XML du gouvernement fédéral des États-Unis.
En septembre 2003, UDDI restait à l'état "à suivre" dans le cadre commun d'interopérabilité de l'Union européenne[9].
Implémentations
modifierAvertissement : Cette section est placée à titre d'information exclusivement, et n'est pas destinée à une utilisation pour la programmation.
Clients UDDI
modifier- uddi4j : UDDI pour Java
- UDDI.NET SDK : UDDI pour Microsoft .NET
- uddi4r : UDDI pour Ruby
- uddi4py : UDDI pour Python
- UDDI::Lite : UDDI pour Perl
Serveurs UDDI
modifierNotes et références
modifier- « News and Press », sur ariba.com (consulté le ).
- « Cover Pages : OASIS Consortium Members Approve UDDI Version 3 as an OASIS Standard. », sur coverpages.org (consulté le ).
- Voir UDDI and ebXML Registry: A Co-Existence Paradigm
- guide informatique - fiche soap
- http://www.ebxml.org/specs/rrUDDI.pdf [PDF]
- Base UDDI architecture V3.0.1
- Détails sur la représentation des informations, v3.0.1
- Schémas UDDI version 3.0.1
- cf Cadre commun d'interopérabilité - les architectures applicatives, page 4 « Copie archivée » (version du sur Internet Archive)
Voir aussi
modifierLiens externes
modifier- (fr) Découverte et sélection des services Web pour une application Mélusine (2004)
- (en) Site officiel
- (en) UDDI and ebXML Registry : A Co-Existence Paradigm sur le site webservices.org
- (en) Spécifications d'UDDI sur le site de l'OASIS
- (en) Serveur d'annuaire de l'organisation Apache sous licence libre