UDDI - Guía rápida

UDDI es un estándar basado en XML para describir, publicar y encontrar servicios web.

  • UDDI significa Universal Description, Discovery, and Integration.

  • UDDI es una especificación para un registro distribuido de servicios web.

  • UDDI es un marco abierto, independiente de la plataforma.

  • UDDI puede comunicarse a través de SOAP, CORBA, Java RMI Protocol.

  • UDDI utiliza el lenguaje de definición de servicios web (WSDL) para describir las interfaces de los servicios web.

  • UDDI se considera con SOAP y WSDL como uno de los tres estándares fundamentales de los servicios web.

  • UDDI es una iniciativa industrial abierta que permite a las empresas conocerse entre sí y definir cómo interactúan a través de Internet.

UDDI tiene dos secciones:

  • Un registro de todos los metadatos del servicio web, incluido un puntero a la descripción WSDL de un servicio.

  • Un conjunto de definiciones de tipo de puerto WSDL para manipular y buscar ese registro.

Historia de UDDI

  • UDDI 1.0 fue anunciado originalmente por Microsoft, IBM y Ariba en septiembre de 2000.

  • Desde el anuncio inicial, la iniciativa UDDI ha crecido para incluir a más de 300 empresas, incluidas Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP y Sun.

  • En mayo de 2001, Microsoft e IBM lanzaron los primeros sitios de operadores UDDI y activaron el registro UDDI.

  • En junio de 2001, UDDI anunció la versión 2.0.

  • En el momento de redactar este tutorial, los sitios de Microsoft e IBM habían implementado la especificación 1.0 y estaban planeando el soporte 2.0 en un futuro próximo.

  • Actualmente UDDI está patrocinado por OASIS.

Procesos de interfaz de socios

Los procesos de interfaz de socio (PIP) son interfaces basadas en XML que permiten a dos socios comerciales intercambiar datos. Ya existen decenas de PIP. Algunos de ellos se enumeran aquí:

  • PIP2A2 - Permite a un socio consultar a otro para obtener información del producto.

  • PIP3A2 - Permite a un socio consultar el precio y la disponibilidad de productos específicos.

  • PIP3A4 - Permite a un socio enviar una orden de compra electrónica y recibir acuse de recibo de la orden.

  • PIP3A3 - Permite a un socio transferir el contenido de un carrito de compras electrónico.

  • PIP3B4 - Permite a un socio consultar el estado de un envío específico.

Registros privados UDDI

Como alternativa al uso de la red pública federada de registros UDDI disponible en Internet, las empresas o grupos industriales pueden optar por implementar sus propios registros UDDI privados.

Estos servicios exclusivos están diseñados con el único propósito de permitir a los miembros de la empresa o del grupo industrial compartir y publicitar servicios entre ellos.

Independientemente de si el registro UDDI es parte de la red federada global o un registro operado y de propiedad privada, lo único que los une a todos es una API de servicios web común para publicar y localizar empresas y servicios anunciados dentro del registro UDDI.

Una empresa o empresa puede registrar tres tipos de información en un registro UDDI. Esta información está contenida en tres elementos de UDDI.

Estos tres elementos son:

  • Páginas blancas,
  • Páginas Amarillas y
  • Páginas verdes.

Páginas blancas

Las páginas blancas contienen:

  • Información básica sobre la empresa y su negocio.

  • Información de contacto básica que incluye nombre comercial, dirección, número de teléfono de contacto, etc.

  • A Identificadores únicos para los números de identificación fiscal de la empresa. Esta información permite a otros descubrir su servicio web basándose en su identificación comercial.

Páginas Amarillas

  • Las páginas amarillas contienen más detalles sobre la empresa. Incluyen descripciones del tipo de capacidades electrónicas que la empresa puede ofrecer a cualquiera que quiera hacer negocios con ella.

  • Las páginas amarillas utilizan esquemas de categorización industrial comúnmente aceptados, códigos de industria, códigos de producto, códigos de identificación comercial y similares para facilitar a las empresas la búsqueda en los listados y encontrar exactamente lo que buscan.

Páginas verdes

Las páginas verdes contienen información técnica sobre un servicio web. Una página verde permite que alguien se vincule a un servicio web después de que se encuentre. Incluye -

  • Las diversas interfaces
  • Las ubicaciones de URL
  • Información de descubrimiento y datos similares necesarios para encontrar y ejecutar el servicio web.

NOTE- UDDI no se limita a describir servicios web basados ​​en SOAP. Más bien, UDDI se puede utilizar para describir cualquier servicio, desde una sola página web o dirección de correo electrónico hasta los servicios SOAP, CORBA y Java RMI.

La arquitectura técnica UDDI consta de tres partes:

Modelo de datos UDDI

El modelo de datos UDDI es un esquema XML para describir empresas y servicios web. El modelo de datos se describe en detalle en el capítulo "Modelo de datos UDDI".

Especificación de API UDDI

Es una especificación de API para buscar y publicar datos UDDI.

Servicios en la nube UDDI

Estos son sitios de operadores que proporcionan implementaciones de la especificación UDDI y sincronizan todos los datos de forma programada.

El Registro de Empresas UDDI (UBR), también conocido como Public Cloud, es un sistema conceptualmente único construido a partir de múltiples nodos que tienen sus datos sincronizados a través de la replicación.

Los servicios en la nube actuales proporcionan un directorio lógicamente centralizado, pero físicamente distribuido. Significa que los datos enviados a un nodo raíz se replicarán automáticamente en todos los demás nodos raíz. Actualmente, la replicación de datos ocurre cada 24 horas.

Los servicios en la nube UDDI los proporcionan actualmente Microsoft e IBM. Ariba había planeado originalmente ofrecer un operador también, pero desde entonces se ha alejado del compromiso. Se planean operadores adicionales de otras compañías, incluida Hewlett-Packard, para un futuro próximo.

También es posible configurar registros UDDI privados. Por ejemplo, una gran empresa puede configurar su propio registro UDDI privado para registrar todos los servicios web internos. Como estos registros no se sincronizan automáticamente con los nodos raíz UDDI, no se consideran parte de la nube UDDI.

UDDI incluye un esquema XML que describe las siguientes estructuras de datos:

  • businessEntity
  • businessService
  • bindingTemplate
  • tModel
  • publisherAssertion

BusinessEntity Estructura de datos

La estructura de la entidad comercial representa al proveedor de servicios web. Dentro del registro UDDI, esta estructura contiene información sobre la propia empresa, incluida la información de contacto, las categorías de la industria, los identificadores comerciales y una lista de los servicios prestados.

A continuación se muestra un ejemplo de la entrada de registro UDDI de una empresa ficticia:

<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>

estructura de datos del servicio empresarial

La estructura de servicios comerciales representa un servicio web individual proporcionado por la entidad comercial. Su descripción incluye información sobre cómo vincularse al servicio web, qué tipo de servicio web es y a qué categorías taxonómicas pertenece.

A continuación, se muestra un ejemplo de una estructura de servicio empresarial para el servicio 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>

Observe el uso de identificadores únicos universales (UUID) en los atributos businessKey y serviceKey . Cada entidad comercial y servicio comercial se identifica de manera única en todos los registros UDDI a través del UUID asignado por el registro cuando se ingresa la información por primera vez.

bindingTemplate Estructura de datos

Las plantillas de enlace son las descripciones técnicas de los servicios web representados por la estructura de servicios empresariales. Un solo servicio comercial puede tener varias plantillas de enlace. La plantilla de enlace representa la implementación real del servicio web.

A continuación, se muestra un ejemplo de una plantilla de enlace para 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>

Como un servicio comercial puede tener múltiples plantillas de enlace, el servicio puede especificar diferentes implementaciones del mismo servicio, cada una vinculada a un conjunto diferente de protocolos o una dirección de red diferente.

Estructura de datos tModel

tModel es el último tipo de datos principales, pero potencialmente el más difícil de comprender. tModel significa modelo técnico.

tModel es una forma de describir las diversas estructuras comerciales, de servicios y de plantillas almacenadas en el registro UDDI. Cualquier concepto abstracto puede registrarse dentro de la UDDI como un tModel. Por ejemplo, si define un nuevo tipo de puerto WSDL, puede definir un tModel que represente ese tipo de puerto dentro del UDDI. Luego, puede especificar que un servicio comercial determinado implemente ese tipo de puerto asociando el tModel con una de las plantillas de enlace de ese servicio comercial.

A continuación, se muestra un ejemplo de un tModel que representa el tipo de puerto de la interfaz Hello World.

<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 Estructura de datos

Es una estructura de relación que pone en asociación dos o más estructuras de entidad empresarial de acuerdo con un tipo específico de relación, como subsidiaria o departamento.

La estructura publisherAssertion consta de tres elementos: fromKey (la primera clave empresarial), toKey (la segunda clave empresarial) y keyedReference.

KeyedReference designa el tipo de relación afirmada en términos de un par keyName keyValue dentro de un tModel, al que se hace referencia de forma única por 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 registro no sirve de nada sin alguna forma de acceder a él. La versión 2.0 del estándar UDDI especifica dos interfaces para que los consumidores y proveedores de servicios interactúen con el registro.

Los consumidores de servicios utilizan Inquiry Interface para encontrar un servicio y los proveedores de servicios utilizan Publisher Interface para listar un servicio.

El núcleo de la interfaz UDDI son las definiciones del esquema XML UDDI. Estos definen los tipos de datos UDDI fundamentales a través de los cuales fluye toda la información.

La interfaz del editor

La interfaz del editor define dieciséis operaciones para un proveedor de servicios que administra sus entradas en el registro UDDI:

  • get_authToken- Recupera un token de autorización. Todas las operaciones de la interfaz del editor requieren que se envíe un token de autorización válido con la solicitud.

  • discard_authToken- Le dice al registro UDDI que ya no acepte un token de autorización determinado. Este paso equivale a cerrar la sesión del sistema.

  • save_business - Crea o actualiza la información de una entidad empresarial contenida en el registro UDDI.

  • save_service - Crea o actualiza información sobre los servicios web que brinda una entidad comercial.

  • save_binding - Crea o actualiza la información técnica sobre la implementación de un servicio web.

  • save_tModel - Crea o actualiza el registro de conceptos abstractos gestionados por el registro UDDI.

  • delete_business - Elimina por completo las entidades comerciales dadas del registro UDDI.

  • delete_service - Elimina completamente los servicios web dados del registro UDDI.

  • delete_binding - Elimina los detalles técnicos de los servicios web dados del registro UDDI.

  • delete_tModel - Elimina los tModels especificados del registro UDDI.

  • get_registeredInfo - Devuelve un resumen de todo lo que el registro UDDI está realizando actualmente para el usuario, incluidas todas las empresas, todos los servicios y todos los tModels.

  • set_publisherAssertions - Gestiona todas las afirmaciones de relaciones rastreadas asociadas con una cuenta de editor individual.

  • add_publisherAssertions - Hace que se agreguen una o más aserciones de editor a la colección de aserciones de un editor individual.

  • delete_publisherAssertions - Hace que uno o más elementos publisherAssertion se eliminen de la colección de aserciones de un editor.

  • get_assertionStatusReport - Proporciona apoyo administrativo para determinar el estado de las afirmaciones de editor actuales y pendientes que involucran cualquiera de los registros comerciales administrados por la cuenta de editor individual.

  • get_publisherAssertions - Obtiene el conjunto completo de afirmaciones del editor asociado con una cuenta de editor individual.

La interfaz de consulta

La interfaz de consulta define diez operaciones para buscar en el registro UDDI y recuperar detalles sobre registros específicos:

  • find_binding - Devuelve una lista de servicios web que coinciden con un conjunto particular de criterios basados ​​en la información técnica vinculante.

  • find_business - Devuelve una lista de entidades comerciales que coinciden con un conjunto particular de criterios.

  • find_ltservice - Devuelve una lista de servicios web que coinciden con un conjunto particular de criterios.

  • find_tModel - Devuelve una lista de tModels que coinciden con un conjunto particular de criterios.

  • get_bindingDetail - Devuelve la información de registro completa para una plantilla de enlace de servicio web en particular.

  • get_businessDetail - Devuelve la información de registro de una entidad comercial, incluidos todos los servicios que brinda la entidad.

  • get_businessDetailExt - Devuelve la información de registro completa para una entidad comercial.

  • get_serviceDetail - Devuelve la información de registro completa para un servicio web.

  • get_tModelDetail - Devuelve la información de registro completa para un tModel.

  • find_relatedBusinesses - Descubre negocios que se han relacionado a través del modelo uddi-org: relaciones.

Considere una empresa que XYZ desea registrar su información de contacto, descripción del servicio e información de acceso al servicio en línea con UDDI. Los siguientes pasos son necesarios:

  • Elija un operador con el que trabajar. Cada operador tiene diferentes términos y condiciones para autorizar el acceso a su réplica del registro.

  • Construya u obtenga un cliente UDDI, como los proporcionados por los operadores.

  • Obtenga un token de autenticación del operador.

  • Registrar información sobre el negocio. Incluya toda la información que pueda ser útil para quienes busquen coincidencias.

  • Libera el token de autenticación.

  • Utilice las API de consulta para probar la recuperación de la información, incluida la información de la plantilla vinculante, para asegurarse de que alguien que la obtenga pueda utilizarla correctamente para interactuar con su servicio.

  • Complete la información de tModel en caso de que alguien quiera buscar un servicio determinado y encontrar su empresa como uno de los proveedores de servicios.

  • Actualice la información según sea necesario para reflejar la información de contacto comercial cambiante y los nuevos detalles del servicio, obteniendo y liberando un nuevo token de autenticación del operador cada vez. Siempre que necesite actualizar o modificar los datos que ha registrado, debe volver al operador con el que ha introducido los datos.

Los siguientes ejemplos mostrarán cómo la empresa XYZ registraría su información y cómo un distribuidor interesado en llevar la línea de productos de XYZ podría encontrar información sobre cómo ponerse en contacto con la empresa y realizar un pedido utilizando los servicios web XYZ.com.

Crear registro

Después de obtener un token de autenticación de uno de los operadores de Microsoft, por ejemplo, los desarrolladores de XYZ.com deciden qué información publicar en el registro y utilizan una de las herramientas UDDI proporcionadas por Microsoft. Si es necesario, los desarrolladores también pueden escribir un programa Java, C # o VB.NET para generar los mensajes SOAP apropiados. Aquí hay un ejemplo.

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>

Este ejemplo ilustra un mensaje SOAP que solicita registrar una entidad comercial UDDI para la empresa XYZ. El elemento clave está en blanco, porque el operador genera automáticamente la clave UUID para la estructura de datos. La mayoría de los campos se omiten para mostrar un ejemplo sencillo.

La empresa XYZ siempre puede ejecutar otra operación save_business para agregar a la información básica necesaria para crear una entidad comercial.

Recuperación de información

Después de que XYZ Company haya actualizado su entrada UDDI con la información relevante, las empresas que quieran convertirse en distribuidores XYZ pueden buscar información de contacto en el registro UDDI y obtener las descripciones de los servicios y los puntos de acceso para los dos servicios web que XYZ.com publica en línea. entrada de pedidos: pedidos al por mayor de pretemporada y pedidos de reabastecimiento durante la temporada.

Este ejemplo ilustra una solicitud SOAP de muestra para obtener información detallada sobre la empresa XYZ Company. Una vez que conozca el UUID, o clave, para la empresa específica que se ha registrado, puede usarlo en la API get_businessDetail para devolver información específica sobre esa empresa.

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>

El modelo de datos UDDI define una estructura genérica para almacenar información sobre una empresa y los servicios web que publica. El modelo de datos UDDI es completamente extensible e incluye varias estructuras de secuencia de información repetidas.

Sin embargo, WSDL se utiliza para describir la interfaz de un servicio web. WSDL es bastante sencillo de usar con UDDI.

  • WSDL se representa en UDDI mediante una combinación de información businessService, bindingTemplate y tModel .

  • Al igual que con cualquier servicio registrado en UDDI, la información genérica sobre el servicio se almacena en la estructura de datos businessService , y la información específica sobre cómo y dónde se accede al servicio se almacena en una o más estructuras de bindingTemplate asociadas . Cada estructura bindingTemplate incluye un elemento que contiene la dirección de red del servicio y tiene asociada una o más estructuras tModel que describen e identifican de forma única el servicio.

  • Cuando se utiliza UDDI para almacenar información WSDL, o punteros a archivos WSDL, el tModel debe denominarse por convención tipo wsdlSpec , lo que significa que el elemento overviewDoc se identifica claramente como apuntando a una definición de interfaz de servicio WSDL.

  • Para UDDI, el contenido WSDL se divide en dos elementos principales: el archivo de interfaz y el archivo de implementación.

El servicio web del sistema de reservas de Hertz proporciona un ejemplo concreto de cómo UDDI y WSDL funcionan juntos. Aquí está el <tModel> para este servicio 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>

Los puntos clave son:

  • El elemento OverviewURL proporciona la URL donde se puede encontrar el archivo WSDL de definición de la interfaz de servicio. Esto permite que los humanos y las herramientas conscientes de UDDI / WSDL localicen la definición de la interfaz de servicio.

  • El propósito del elemento keyedReference en categoryBag es asegurarse de que este tModel esté categorizado como un documento de especificación WSDL.

Actualmente hay disponibles varias implementaciones de UDDI. Estas implementaciones facilitan la búsqueda o la publicación de datos UDDI, sin atascarse en las complejidades de la API UDDI. Aquí hay una breve sinopsis de las principales implementaciones de UDDI disponibles.

Implementaciones de Java

Hay dos implementaciones de UDDI para Java.

  • UDDI4J (UDDI para Java) : UDDI4J fue creado originalmente por IBM. En enero de 2001, IBM entregó el código a su propio sitio de código abierto. UDDI4J es una biblioteca de clases de Java que proporciona una API para interactuar con un UDDI.

  • jUDDI - jUDDI es una implementación Java de código abierto de un registro UDDI y un juego de herramientas para acceder a los servicios UDDI.

Implementación de Perl

  • UDDI::Lite - Proporciona un cliente UDDI básico para consulta y publicación.

Implementación de Ruby

  • UDDI4r - Proporciona un cliente UDDI básico para consulta y publicación.

Implementación de Python

  • UDDI4Py : UDDI4Py es un paquete de Python que permite el envío de solicitudes y el procesamiento de respuestas de las API de la versión 2 de UDDI.

El proyecto UDDI también define un conjunto de definiciones de esquemas XML que describen los formatos de datos utilizados por las distintas API de especificación. Todos estos documentos están disponibles para su descarga en www.uddi.org . La versión actual de todos los grupos de especificaciones es la versión 2.0.

Las especificaciones incluyen lo siguiente:

  • Replicación UDDI,
  • Operadores UDDI,
  • API del programador UDDI y
  • Estructuras de datos UDDI

Replicación UDDI

Este documento describe los procesos de replicación de datos y las interfaces a las que debe ajustarse un operador de registro para lograr la replicación de datos entre sitios. Esta especificación no es una API de programador; define el mecanismo de replicación utilizado entre los nodos UBR.

Operadores UDDI

Este documento describe el comportamiento y los parámetros operativos requeridos por los operadores de nodo UDDI. Esta especificación define los requisitos de gestión de datos que deben cumplir los operadores.

API del programador UDDI

Esta especificación define un conjunto de funciones que todos los registros UDDI admiten para consultar sobre servicios alojados en un registro y para publicar información sobre una empresa o un servicio en un registro. Esta especificación define una serie de mensajes SOAP que contienen documentos XML que un registro UDDI acepta, analiza y responde. Esta especificación, junto con el esquema de API XML UDDI y la especificación de estructura de datos UDDI, constituyen una interfaz de programación completa para un registro UDDI.

Estructuras de datos UDDI

Esta especificación cubre los aspectos específicos de las estructuras XML contenidas en los mensajes SOAP definidos por la API del programador UDDI. Esta especificación define cinco estructuras de datos centrales y sus relaciones entre sí.

El esquema de la API XML UDDI no está incluido en una especificación; más bien, se almacena como un documento de esquema XML que define la estructura y los tipos de datos de las estructuras de datos UDDI.

UDDI y sus elementos en este tutorial y también he visto la arquitectura completa y el modelo de datos de UDDI.

Hemos aprendido sobre las dos interfaces UDDI: la interfaz del editor y la interfaz de consulta. También hemos aprendido a registrarnos y buscar servicios web con UDDI.

¿Que sigue?

El siguiente paso es aprender sobre SOAP, WSDL y Web Services.

JABÓN

SOAP es un protocolo simple basado en XML que permite a las aplicaciones intercambiar información a través de HTTP.

Si desea obtener más información sobre SOAP, visite nuestro tutorial SOAP .

WSDL

WSDL es el formato estándar para describir un servicio web en formato XML.

WSDL es una parte integral de UDDI.

Si desea obtener más información sobre WSDL, visite nuestro Tutorial de WSDL .

Servicios web

Los servicios web pueden convertir sus aplicaciones en aplicaciones web.

Si desea obtener más información sobre los servicios web, visite nuestro tutorial de servicios web .

Aquí está la referencia completa de las API de consulta UDDI y las API de publicación UDDI.

Las API de consulta de UDDI

Nombre de API Descripción V1.0 V2.0
find_binding Busca enlaces de plantilla asociados con un servicio específico. Y Y
find_business Busca empresas que coincidan con los criterios especificados. Y Y
find_relatedBusinesses Descubre negocios que se han relacionado a través del modelo de relaciones uddi-org. Y
find_service Busca servicios asociados con una empresa específica. Y Y
find_tModel Busca registros de tModel que coincidan con los criterios especificados. Y Y
get_bindingDetail Recupera el bindingTemplate completo para cada bindingKey especificado. Y Y
get_businessDetail Recupera la businessEntity completa para cada businessKey especificada. Y Y
get_businessDetailExt Recupera la businessEntity ampliada para cada businessKey especificada. Y Y
get_serviceDetail Recupera el registro businessService para cada serviceKey especificado. Y Y
get_tModelDetail Recupera el registro tModel para cada tModelKey especificado. Y Y

Las API de publicación UDDI

Nombre de API Descripción V1.0 V2.0
get_authToken Recupera un token de autorización. Todas las operaciones de la interfaz del editor requieren que se envíe un token de autorización válido con la solicitud. Y Y
discard_authToken Le dice al registro UDDI que ya no acepte un token de autorización determinado. Este paso equivale a cerrar la sesión del sistema. Y Y
save_business Crea o actualiza la información de una entidad comercial contenida en el registro UDDI. Y Y
save_service Crea o actualiza información sobre los servicios web que proporciona una entidad comercial. Y Y
save_binding Crea o actualiza la información técnica sobre la implementación de un servicio web. Y Y
save_tModel Crea o actualiza el registro de conceptos abstractos gestionados por el registro UDDI. Y Y
delete_business Elimina completamente las entidades comerciales dadas del registro UDDI. Y Y
delete_service Elimina completamente los servicios web dados del registro UDDI. Y Y
delete_binding Elimina los detalles técnicos del servicio web proporcionado del registro UDDI. Y Y
delete_tModel Elimina los tModels especificados del registro UDDI. Y Y
get_registeredInfo Devuelve un resumen de todo lo que el registro UDDI está realizando actualmente para el usuario, incluidas todas las empresas, todos los servicios y todos los tModels. Y Y
set_publisherAssertions Gestiona todas las afirmaciones de relaciones rastreadas asociadas con una cuenta de editor individual. Y
add_publisherAssertions Hace que se agreguen una o más PublisherAssertions a la colección de aserciones de un editor individual. Y
delete_publisherAssertions Hace que uno o más elementos publisherAssertion se eliminen de la colección de aserciones de un editor. Y
get_assertionStatusReport Proporciona apoyo administrativo para determinar el estado de las afirmaciones de editor actuales y pendientes que involucran cualquiera de los registros comerciales administrados por la cuenta de editor individual. Y
get_publisherAssertions Obtiene el conjunto completo de afirmaciones del editor asociado con una cuenta de editor individual. Y

Referencia de código de error

Una referencia completa de los códigos de error devueltos por las API de UDDI es la siguiente:

Códigos de error