UDDI - Guide rapide

UDDI est une norme basée sur XML pour la description, la publication et la recherche de services Web.

  • UDDI signifie Universal Description, Discovery, and Integration.

  • UDDI est une spécification pour un registre distribué de services Web.

  • UDDI est un framework ouvert et indépendant de la plateforme.

  • UDDI peut communiquer via SOAP, CORBA, Java RMI Protocol.

  • UDDI utilise le langage WSDL (Web Service Definition Language) pour décrire les interfaces vers les services Web.

  • UDDI est considéré avec SOAP et WSDL comme l'une des trois normes fondamentales des services Web.

  • UDDI est une initiative industrielle ouverte, permettant aux entreprises de se découvrir et de définir comment elles interagissent sur Internet.

UDDI a deux sections -

  • Registre de toutes les métadonnées du service Web, y compris un pointeur vers la description WSDL d'un service.

  • Un ensemble de définitions de type de port WSDL pour manipuler et rechercher ce registre.

Histoire de l'UDDI

  • UDDI 1.0 a été initialement annoncé par Microsoft, IBM et Ariba en septembre 2000.

  • Depuis l'annonce initiale, l'initiative UDDI s'est développée pour inclure plus de 300 entreprises, dont Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP et Sun.

  • En mai 2001, Microsoft et IBM ont lancé les premiers sites d'opérateurs UDDI et mis le registre UDDI en ligne.

  • En juin 2001, UDDI a annoncé la version 2.0.

  • Au moment de la rédaction de ce didacticiel, les sites Microsoft et IBM avaient implémenté la spécification 1.0 et prévoyaient un support 2.0 dans un proche avenir.

  • Actuellement, l'UDDI est parrainé par OASIS.

Processus d'interface partenaire

Les processus d'interface partenaire (PIP) sont des interfaces XML qui permettent à deux partenaires commerciaux d'échanger des données. Des dizaines de PIP existent déjà. Certains d'entre eux sont répertoriés ici -

  • PIP2A2 - Permet à un partenaire de demander à un autre des informations sur le produit.

  • PIP3A2 - Permet à un partenaire d'interroger le prix et la disponibilité de produits spécifiques.

  • PIP3A4 - Permet à un partenaire de soumettre un bon de commande électronique et de recevoir un accusé de réception de la commande.

  • PIP3A3 - Permet à un partenaire de transférer le contenu d'un panier électronique.

  • PIP3B4 - Permet à un partenaire d'interroger le statut d'un envoi spécifique.

Registres UDDI privés

Au lieu d'utiliser le réseau public fédéré de registres UDDI disponibles sur Internet, les entreprises ou les groupes industriels peuvent choisir de mettre en œuvre leurs propres registres UDDI privés.

Ces services exclusifs sont conçus dans le seul but de permettre aux membres de la société ou du groupe industriel de partager et de faire de la publicité entre eux.

Indépendamment du fait que le registre UDDI fasse partie du réseau fédéré mondial ou d'un registre privé et géré, la seule chose qui les lie tous est une API de services Web commune pour la publication et la localisation des entreprises et des services annoncés dans le registre UDDI.

Une entreprise ou une entreprise peut enregistrer trois types d'informations dans un registre UDDI. Ces informations sont contenues dans trois éléments de l'UDDI.

Ces trois éléments sont -

  • Pages blanches,
  • Pages jaunes, et
  • Pages vertes.

Pages blanches

Les pages blanches contiennent -

  • Informations de base sur l'entreprise et ses activités.

  • Coordonnées de base, y compris le nom de l'entreprise, l'adresse, le numéro de téléphone, etc.

  • A Identifiants uniques pour les numéros d'identification fiscale des sociétés. Ces informations permettent aux autres de découvrir votre service Web en fonction de l'identification de votre entreprise.

Pages Jaunes

  • Les pages jaunes contiennent plus de détails sur l'entreprise. Ils comprennent des descriptions du type de capacités électroniques que l'entreprise peut offrir à quiconque souhaite faire affaire avec elle.

  • Les pages jaunes utilisent des schémas de catégorisation industrielle communément acceptés, des codes industriels, des codes produit, des codes d'identification d'entreprise, etc. pour permettre aux entreprises de rechercher plus facilement dans les listes et de trouver exactement ce qu'elles veulent.

Pages vertes

Les pages vertes contiennent des informations techniques sur un service Web. Une page verte permet à quelqu'un de se lier à un service Web une fois qu'il a été trouvé. Il comprend -

  • Les différentes interfaces
  • Les emplacements des URL
  • Informations de découverte et données similaires requises pour rechercher et exécuter le service Web.

NOTE- UDDI ne se limite pas à la description de services Web basés sur SOAP. Au contraire, UDDI peut être utilisé pour décrire n'importe quel service, depuis une seule page Web ou une seule adresse e-mail jusqu'aux services SOAP, CORBA et Java RMI.

L'architecture technique UDDI se compose de trois parties -

Modèle de données UDDI

Le modèle de données UDDI est un schéma XML permettant de décrire les entreprises et les services Web. Le modèle de données est décrit en détail dans le chapitre "Modèle de données UDDI".

Spécification de l'API UDDI

Il s'agit d'une spécification d'API pour la recherche et la publication de données UDDI.

Services cloud UDDI

Ce sont des sites d'opérateurs qui fournissent des implémentations de la spécification UDDI et synchronisent toutes les données sur une base planifiée.

UDDI Business Registry (UBR), également connu sous le nom de cloud public, est un système conceptuellement unique construit à partir de plusieurs nœuds dont les données sont synchronisées via la réplication.

Les services cloud actuels fournissent un répertoire logiquement centralisé, mais physiquement distribué. Cela signifie que les données soumises à un nœud racine seront automatiquement répliquées sur tous les autres nœuds racine. Actuellement, la réplication des données a lieu toutes les 24 heures.

Les services cloud UDDI sont actuellement fournis par Microsoft et IBM. Ariba avait initialement prévu de proposer un opérateur également, mais a depuis renoncé à cet engagement. D'autres opérateurs d'autres sociétés, dont Hewlett-Packard, sont prévus dans un proche avenir.

Il est également possible de mettre en place des registres UDDI privés. Par exemple, une grande entreprise peut créer son propre registre UDDI privé pour enregistrer tous les services Web internes. Comme ces registres ne sont pas automatiquement synchronisés avec les nœuds UDDI racine, ils ne sont pas considérés comme faisant partie du cloud UDDI.

UDDI inclut un schéma XML qui décrit les structures de données suivantes -

  • businessEntity
  • businessService
  • bindingTemplate
  • tModel
  • publisherAssertion

Structure de données businessEntity

La structure de l'entité commerciale représente le fournisseur de services Web. Dans le registre UDDI, cette structure contient des informations sur l'entreprise elle-même, y compris des informations de contact, des catégories d'industries, des identifiants d'entreprise et une liste des services fournis.

Voici un exemple d'entrée de registre UDDI d'une entreprise fictive -

<businessEntity businessKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"
   operator = "http://www.ibm.com" authorizedName = "John Doe">
   <name>Acme Company</name>
   <description>
      We create cool Web services
   </description>
	
   <contacts>	
      <contact useType = "general info">
         <description>General Information</description>
         <personName>John Doe</personName>
         <phone>(123) 123-1234</phone>
         <email>[email protected]</email>
      </contact>		
   </contacts>
	
   <businessServices>
      ...
   </businessServices>
   <identifierBag>	
      <keyedReference tModelKey = "UUID:8609C81E-EE1F-4D5A-B202-3EB13AD01823" 
         name = "D-U-N-S" value = "123456789" />
   </identifierBag>
	
   <categoryBag>	
      <keyedReference tModelKey = "UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2" 
         name = "NAICS" value = "111336" />			
   </categoryBag>		
</businessEntity>

Structure de données businessService

La structure du service métier représente un service Web individuel fourni par l'entité commerciale. Sa description comprend des informations sur la manière de se lier au service Web, le type de service Web dont il s'agit et les catégories taxonomiques auxquelles il appartient.

Voici un exemple de structure de service métier pour le service Web Hello World.

<businessService serviceKey = "uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
   businessKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40">
   <name>Hello World Web Service</name>
   <description>A friendly Web service</description>
   <bindingTemplates>
      ...
   </bindingTemplates>
   <categoryBag />
</businessService>

Notez l'utilisation des identificateurs universellement uniques (UUID) dans les attributs businessKey et serviceKey . Chaque entité commerciale et service commercial est identifié de manière unique dans tous les registres UDDI via l'UUID attribué par le registre lors de la première saisie des informations.

Structure de données bindingTemplate

Les modèles de liaison sont les descriptions techniques des services Web représentés par la structure des services métier. Un service métier unique peut avoir plusieurs modèles de liaison. Le modèle de liaison représente l'implémentation réelle du service Web.

Voici un exemple de modèle de liaison pour Hello World.

<bindingTemplate serviceKey = "uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
   bindingKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40">
   <description>Hello World SOAP Binding</description>
   <accessPoint URLType = "http">http://localhost:8080</accessPoint>
   
   <tModelInstanceDetails>
      <tModelInstanceInfo tModelKey = "uuid:EB1B645F-CF2F-491f-811A-4868705F5904">
         <instanceDetails>
            <overviewDoc>
               <description>
                  references the description of the WSDL service definition
               </description>
               
               <overviewURL>
                  http://localhost/helloworld.wsdl
               </overviewURL>
            </overviewDoc>
         </instanceDetails>
      </tModelInstanceInfo>
   </tModelInstanceDetails>
</bindingTemplate>

Comme un service d'entreprise peut avoir plusieurs modèles de liaison, le service peut spécifier différentes implémentations du même service, chacune liée à un ensemble différent de protocoles ou à une adresse réseau différente.

Structure des données du tModel

Le tModel est le dernier type de données de base, mais potentiellement le plus difficile à saisir. tModel est synonyme de modèle technique.

Le tModel est une manière de décrire les différentes structures d'entreprise, de service et de modèle stockées dans le registre UDDI. Tout concept abstrait peut être enregistré dans l'UDDI en tant que tModel. Par exemple, si vous définissez un nouveau type de port WSDL, vous pouvez définir un tModel qui représente ce type de port dans l'UDDI. Ensuite, vous pouvez spécifier qu'un service métier donné implémente ce type de port en associant le tModel à l'un des modèles de liaison de ce service métier.

Voici un exemple de tModel représentant le type de port Hello World Interface.

<tModel tModelKey = "uuid:xyz987..." operator = "http://www.ibm.com" 
   authorizedName = "John Doe">
   <name>HelloWorldInterface Port Type</name>
   <description>
      An interface for a friendly Web service
   </description>
	
   <overviewDoc>
      <overviewURL>
         http://localhost/helloworld.wsdl
      </overviewURL>
   </overviewDoc>
</tModel>

publisherAssertion Data Structure

Il s'agit d'une structure de relation mettant en association deux ou plusieurs structures d'entité commerciale selon un type de relation spécifique, comme une filiale ou un service.

La structure publisherAssertion se compose des trois éléments: fromKey (le premier businessKey), toKey (le deuxième businessKey) et keyedReference.

Le keyedReference désigne le type de relation affirmé en termes d'une paire keyName keyValue dans un tModel, référencé de manière unique par un tModelKey.

<element name = "publisherAssertion" type = "uddi:publisherAssertion" />
<complexType name = "publisherAssertion">
   <sequence>
      <element ref = "uddi:fromKey" />
      <element ref = "uddi:toKey" />
      <element ref = "uddi:keyedReference" />
   </sequence>
</complexType>

Un registre ne sert à rien sans un moyen d'y accéder. La version 2.0 de la norme UDDI spécifie deux interfaces permettant aux consommateurs de services et aux fournisseurs de services d'interagir avec le registre.

Les consommateurs de services utilisent Inquiry Interface pour trouver un service et les fournisseurs de services utilisent Publisher Interface pour lister un service.

Les définitions de schéma XML UDDI constituent le cœur de l'interface UDDI. Ceux-ci définissent les types de données UDDI fondamentaux à travers lesquels toutes les informations circulent.

L'interface de l'éditeur

L'interface éditeur définit seize opérations pour un fournisseur de services gérant ses entrées dans le registre UDDI -

  • get_authToken- Récupère un jeton d'autorisation. Toutes les opérations de l'interface de l'éditeur nécessitent la soumission d'un jeton d'autorisation valide avec la demande.

  • discard_authToken- Indique au registre UDDI de ne plus accepter un jeton d'autorisation donné. Cette étape équivaut à se déconnecter du système.

  • save_business - Crée ou met à jour les informations d'une entité commerciale contenues dans le registre UDDI.

  • save_service - Crée ou met à jour des informations sur les services Web fournis par une entité commerciale.

  • save_binding - Crée ou met à jour les informations techniques sur la mise en œuvre d'un service Web.

  • save_tModel - Crée ou met à jour l'enregistrement des concepts abstraits gérés par le registre UDDI.

  • delete_business - Supprime complètement les entités commerciales données du registre UDDI.

  • delete_service - Supprime complètement les services Web donnés du registre UDDI.

  • delete_binding - Supprime les détails techniques des services Web donnés du registre UDDI.

  • delete_tModel - Supprime les tModels spécifiés du registre UDDI.

  • get_registeredInfo - Renvoie un résumé de tout ce que le registre UDDI suit actuellement pour l'utilisateur, y compris toutes les entreprises, tous les services et tous les tModels.

  • set_publisherAssertions - Gère toutes les affirmations de relation suivies associées à un compte d'éditeur individuel.

  • add_publisherAssertions - Provoque l'ajout d'une ou plusieurs assertions publisherAssertions à la collection d'assertions d'un éditeur individuel.

  • delete_publisherAssertions - Provoque la suppression d'un ou plusieurs éléments publisherAssertion de la collection d'assertions d'un éditeur.

  • get_assertionStatusReport - Fournit un support administratif pour déterminer l'état des affirmations d'éditeur actuelles et en suspens qui impliquent l'une des inscriptions d'entreprise gérées par le compte d'éditeur individuel.

  • get_publisherAssertions - Obtient l'ensemble complet d'assertions d'éditeur associé à un compte d'éditeur individuel.

L'interface d'enquête

L'interface de recherche définit dix opérations pour rechercher dans le registre UDDI et récupérer des détails sur des enregistrements spécifiques -

  • find_binding - Renvoie une liste de services Web qui correspondent à un ensemble particulier de critères basés sur les informations techniques de liaison.

  • find_business - Renvoie une liste d'entités commerciales qui correspondent à un ensemble particulier de critères.

  • find_ltservice - Renvoie une liste de services Web qui correspondent à un ensemble particulier de critères.

  • find_tModel - Renvoie une liste de tModels qui correspondent à un ensemble particulier de critères.

  • get_bindingDetail - Renvoie les informations d'enregistrement complètes pour un modèle de liaison de service Web particulier.

  • get_businessDetail - Renvoie les informations d'enregistrement d'une entité commerciale, y compris tous les services fournis par cette entité.

  • get_businessDetailExt - Renvoie les informations d'enregistrement complètes pour une entité commerciale.

  • get_serviceDetail - Renvoie les informations d'enregistrement complètes pour un service Web.

  • get_tModelDetail - Renvoie les informations d'enregistrement complètes pour un tModel.

  • find_relatedBusinesses - Découvre les entreprises qui ont été liées via le modèle uddi-org: relations.

Prenons l'exemple d'une entreprise que XYZ souhaite enregistrer ses coordonnées, sa description de service et ses informations d'accès au service en ligne avec UDDI. Les étapes suivantes sont nécessaires -

  • Choisissez un opérateur avec lequel travailler. Chaque opérateur a des termes et conditions différents pour autoriser l'accès à sa réplique du registre.

  • Créez ou obtenez un client UDDI, tel que ceux fournis par les opérateurs.

  • Obtenez un jeton d'authentification auprès de l'opérateur.

  • Enregistrez des informations sur l'entreprise. Incluez autant d'informations que cela peut être utile à ceux qui recherchent des correspondances.

  • Libérez le jeton d'authentification.

  • Utilisez les API d'enquête pour tester la récupération des informations, y compris les informations de modèle de liaison, afin de vous assurer que quelqu'un qui les obtient peut les utiliser avec succès pour interagir avec votre service.

  • Remplissez les informations du tModel au cas où quelqu'un voudrait rechercher un service donné et trouver votre entreprise en tant que fournisseur de services.

  • Mettez à jour les informations si nécessaire pour refléter les informations de contact professionnelles changeantes et les nouveaux détails du service, en obtenant et en libérant un nouveau jeton d'authentification de l'opérateur à chaque fois. Chaque fois que vous avez besoin de mettre à jour ou de modifier les données que vous avez enregistrées, vous devez revenir à l'opérateur avec lequel vous avez saisi les données.

Les exemples suivants montreront comment la société XYZ enregistrerait ses informations et comment un distributeur intéressé par la gamme de produits XYZ pourrait trouver des informations sur la manière de contacter la société et de passer une commande, en utilisant les services Web XYZ.com.

Création du registre

Après avoir obtenu un jeton d'authentification de l'un des opérateurs Microsoft, par exemple, les développeurs XYZ.com décident des informations à publier dans le registre et utilisent l'un des outils UDDI fournis par Microsoft. Si nécessaire, les développeurs peuvent également écrire un programme Java, C # ou VB.NET pour générer les messages SOAP appropriés. Voici un exemple.

POST /save_business HTTP/1.1
Host: www.XYZ.com
Content-Type: text/xml; charset = "utf-8"
Content-Length: nnnn
SOAPAction: "save_business"

<?xml version = "1.0" encoding = "UTF-8" ?>
<Envelope xmlns = "http://schemas/xmlsoap.org/soap/envelope/">
   <Body>
      <save_business generic = "2.0" xmlns = "urn:uddi-org:api_v2">
         <businessKey = "">
         </businessKey>
         
         <name>
            XYZ, Pvt Ltd.
         </name>
         
         <description>
            Company is involved in giving Stat-of-the-art....
         </description>
         
         <identifierBag> ... </identifierBag>
         ...
      </save_business>
   </Body>
</Envelope>

Cet exemple illustre un message SOAP demandant d'enregistrer une entité commerciale UDDI pour la société XYZ. L'élément clé est vide, car l'opérateur génère automatiquement la clé UUID pour la structure de données. La plupart des champs sont omis dans le but de montrer un exemple simple.

La société XYZ peut toujours exécuter une autre opération save_business pour ajouter les informations de base requises pour créer une entité commerciale.

Récupérer des informations

Une fois que la société XYZ a mis à jour son entrée UDDI avec les informations pertinentes, les entreprises qui souhaitent devenir distributeurs XYZ peuvent rechercher des informations de contact dans le registre UDDI et obtenir les descriptions de services et les points d'accès pour les deux services Web que XYZ.com publie en ligne. saisie des commandes: commandes en gros de pré-saison et commandes de réapprovisionnement en saison.

Cet exemple illustre un exemple de demande SOAP pour obtenir des informations commerciales détaillées sur la société XYZ. Une fois que vous connaissez l'UUID, ou la clé, pour l'entreprise spécifique qui a été enregistrée, vous pouvez l'utiliser dans l'API get_businessDetail pour renvoyer des informations spécifiques sur cette entreprise.

POST /get_businessDetail HTTP/1.1
Host: www.XYZ.com
Content-Type: text/xml; charset = "utf-8"
Content-Length: nnnn
SOAPAction: "get_businessDetail"

<?xml version = "1.0" encoding = "UTF-8" ?>
<Envelope xmlns = "http://schemas/xmlsoap.org/soap/envelope/">
   <Body>
      <get_businessDetail generic = "2.0" xmlns = "urn:uddi-org:api_v2">
         <businessKey = "C90D731D-772HSH-4130-9DE3-5303371170C2">
         </businessKey>
      </get_businessDetail>
   </Body>
</Envelope>

Le modèle de données UDDI définit une structure générique pour stocker des informations sur une entreprise et les services Web qu'elle publie. Le modèle de données UDDI est complètement extensible et comprend plusieurs structures de séquence d'informations répétées.

Cependant, WSDL est utilisé pour décrire l'interface d'un service Web. WSDL est assez simple à utiliser avec UDDI.

  • WSDL est représenté dans UDDI à l'aide d'une combinaison d'informations businessService, bindingTemplate et tModel .

  • Comme pour tout service enregistré dans UDDI, les informations génériques sur le service sont stockées dans la structure de données businessService , et les informations spécifiques sur la manière et le lieu d'accès au service sont stockées dans une ou plusieurs structures bindingTemplate associées . Chaque structure bindingTemplate comprend un élément qui contient l'adresse réseau du service et auquel est associée une ou plusieurs structures tModel qui décrivent et identifient de manière unique le service.

  • Lorsque UDDI est utilisé pour stocker des informations WSDL ou des pointeurs vers des fichiers WSDL, le tModel doit être désigné par convention sous le nom de type wsdlSpec , ce qui signifie que l' élément overviewDoc est clairement identifié comme pointant vers une définition d'interface de service WSDL.

  • Pour UDDI, le contenu WSDL est divisé en deux éléments principaux: le fichier d'interface et le fichier d'implémentation.

Le service Web du système de réservation Hertz fournit un exemple concret de la façon dont UDDI et WSDL fonctionnent ensemble. Voici le <tModel> pour ce service Web -

<tModel authorizedName = "..." operator = "..." tModelKey = "...">
   <name>HertzReserveService</name>
   <description xml:lang = "en">
      WSDL description of the Hertz reservation service interface
   </description>
	
   <overviewDoc>
      <description xml:lang = "en">
         WSDL source document.
      </description>
      <overviewURL>
         http://mach3.ebphost.net/wsdl/hertz_reserve.wsdl
      </overviewURL>
   </overviewDoc>
   
   <categoryBag>
      <keyedReference tModelKey = "uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"
         keyName = "uddi-org:types" keyValue = "wsdlSpec"/>
   </categoryBag>	
</tModel>

Les points clés sont -

  • L'élément overviewURL donne l'URL vers laquelle se trouve le fichier WSDL de définition d'interface de service. Cela permet aux humains et aux outils compatibles UDDI / WSDL de localiser la définition de l'interface de service.

  • Le but de l'élément keyedReference dans le categoryBag est de s'assurer que ce tModel est catégorisé comme un document de spécification WSDL.

Un certain nombre d'implémentations UDDI sont actuellement disponibles. Ces implémentations facilitent la recherche ou la publication de données UDDI, sans s'embourber dans les complexités de l'API UDDI. Voici un bref synopsis des principales implémentations UDDI disponibles.

Implémentations Java

Il existe deux implémentations UDDI pour Java.

  • UDDI4J (UDDI pour Java) - UDDI4J a été créé à l'origine par IBM. En janvier 2001, IBM a remis le code à son propre site open source. UDDI4J est une bibliothèque de classes Java qui fournit une API pour interagir avec un UDDI.

  • jUDDI - jUDDI est une implémentation Java open source d'un registre UDDI et une boîte à outils pour accéder aux services UDDI.

Implémentation Perl

  • UDDI::Lite - Il fournit un client UDDI de base pour l'enquête et la publication.

Implémentation Ruby

  • UDDI4r - Il fournit un client UDDI de base pour l'enquête et la publication.

Implémentation Python

  • UDDI4Py - UDDI4Py est un package Python qui permet l'envoi de requêtes et le traitement des réponses à partir des API UDDI version 2.

Le projet UDDI définit également un ensemble de définitions de schéma XML qui décrivent les formats de données utilisés par les différentes API de spécification. Ces documents sont tous disponibles pour téléchargement sur www.uddi.org . La version actuelle de tous les groupes de spécifications est la version 2.0.

Les spécifications comprennent ce qui suit -

  • Réplication UDDI,
  • Opérateurs UDDI,
  • API du programmeur UDDI, et
  • Structures de données UDDI

Réplication UDDI

Ce document décrit les processus et interfaces de réplication de données auxquels un opérateur de registre doit se conformer pour réaliser la réplication de données entre les sites. Cette spécification n'est pas l'API d'un programmeur; il définit le mécanisme de réplication utilisé entre les nœuds UBR.

Opérateurs UDDI

Ce document décrit le comportement et les paramètres opérationnels requis par les opérateurs de nœuds UDDI. Cette spécification définit les exigences de gestion des données auxquelles les opérateurs doivent adhérer.

API du programmeur UDDI

Cette spécification définit un ensemble de fonctions que tous les registres UDDI prennent en charge pour se renseigner sur les services hébergés dans un registre et pour publier des informations sur une entreprise ou un service dans un registre. Cette spécification définit une série de messages SOAP contenant des documents XML auxquels un registre UDDI accepte, analyse et répond. Cette spécification, avec le schéma API XML UDDI et la spécification de structure de données UDDI, constitue une interface de programmation complète pour un registre UDDI.

Structures de données UDDI

Cette spécification couvre les spécificités des structures XML contenues dans les messages SOAP définis par l'API du programmeur UDDI. Cette spécification définit cinq structures de données de base et leurs relations les unes avec les autres.

Le schéma de l'API XML UDDI n'est pas contenu dans une spécification; il est plutôt stocké sous la forme d'un document de schéma XML qui définit la structure et les types de données des structures de données UDDI.

UDDI et ses éléments dans ce tutoriel et ont également vu l'architecture complète et le modèle de données de UDDI.

Nous avons découvert les deux interfaces UDDI: l'interface de l'éditeur et l'interface d'interrogation. Nous avons également appris à s'inscrire et à rechercher des services Web avec UDDI.

Et après?

L'étape suivante consiste à découvrir SOAP, WSDL et les services Web.

SAVON

SOAP est un protocole basé sur XML simple qui permet aux applications d'échanger des informations via HTTP.

Si vous souhaitez en savoir plus sur SOAP, veuillez visiter notre tutoriel SOAP .

WSDL

WSDL est le format standard pour décrire un service Web au format XML.

WSDL fait partie intégrante de l'UDDI.

Si vous souhaitez en savoir plus sur WSDL, veuillez visiter notre tutoriel WSDL .

Services Web

Les services Web peuvent convertir vos applications en applications Web.

Si vous souhaitez en savoir plus sur les services Web, veuillez consulter notre didacticiel sur les services Web .

Voici la référence complète des API UDDI Inquiry et des API UDDI Publishing.

Les API d'enquête UDDI

Nom de l'API La description V1.0 V2.0
find_binding Recherche les liaisons de modèle associées à un service spécifié. Oui Oui
find_business Recherche une entreprise qui correspond aux critères spécifiés. Oui Oui
find_relatedBusinesses Découvre les activités liées via le modèle uddi-org: relations. Oui
find_service Recherche le service associé à une entreprise spécifiée. Oui Oui
find_tModel Recherche les enregistrements du tModel qui correspondent aux critères spécifiés. Oui Oui
get_bindingDetail Récupère le bindingTemplate complet pour chaque bindingKey spécifié. Oui Oui
get_businessDetail Récupère le businessEntity complet pour chaque businessKey spécifié. Oui Oui
get_businessDetailExt Récupère le businessEntity étendu pour chaque businessKey spécifié. Oui Oui
get_serviceDetail Récupère l'enregistrement businessService pour chaque serviceKey spécifié. Oui Oui
get_tModelDetail Récupère l'enregistrement du tModel pour chaque tModelKey spécifié. Oui Oui

Les API de publication UDDI

Nom de l'API La description V1.0 V2.0
get_authToken Récupère un jeton d'autorisation. Toutes les opérations de l'interface de l'éditeur nécessitent la soumission d'un jeton d'autorisation valide avec la demande. Oui Oui
discard_authToken Indique au registre UDDI de ne plus accepter un jeton d'autorisation donné. Cette étape équivaut à se déconnecter du système. Oui Oui
save_business Crée ou met à jour les informations d'une entité commerciale contenues dans le registre UDDI. Oui Oui
save_service Crée ou met à jour des informations sur les services Web fournis par une entité commerciale. Oui Oui
save_binding Crée ou met à jour les informations techniques sur l'implémentation d'un service Web. Oui Oui
save_tModel Crée ou met à jour l'enregistrement des concepts abstraits gérés par le registre UDDI. Oui Oui
delete_business Supprime complètement les entités commerciales données du registre UDDI. Oui Oui
delete_service Supprime complètement les services Web donnés du registre UDDI. Oui Oui
delete_binding Supprime les détails techniques du service Web donné du registre UDDI. Oui Oui
delete_tModel Supprime les tModels spécifiés du registre UDDI. Oui Oui
get_registeredInfo Renvoie un résumé de tout ce que le registre UDDI garde actuellement pour l'utilisateur, y compris toutes les entreprises, tous les services et tous les tModels. Oui Oui
set_publisherAssertions Gère toutes les affirmations de relation suivies associées à un compte d'éditeur individuel. Oui
add_publisherAssertions Provoque l'ajout d'une ou plusieurs assertions publisherAssertions à la collection d'assertions d'un éditeur individuel. Oui
delete_publisherAssertions Provoque la suppression d'un ou de plusieurs éléments publisherAssertion de la collection d'assertions d'un éditeur. Oui
get_assertionStatusReport Fournit un support administratif pour déterminer l'état des affirmations d'éditeur en cours et en suspens qui impliquent l'une des inscriptions d'entreprise gérées par le compte d'éditeur individuel. Oui
get_publisherAssertions Obtient l'ensemble complet d'assertions d'éditeur associé à un compte d'éditeur individuel. Oui

Référence du code d'erreur

Une référence complète des codes d'erreur renvoyés par les API UDDI est donnée -

Codes d'erreur