UDDI - Guia Rápido

UDDI é um padrão baseado em XML para descrever, publicar e localizar serviços da web.

  • UDDI significa Universal Description, Discovery, and Integration.

  • UDDI é uma especificação para um registro distribuído de serviços da web.

  • UDDI é uma estrutura aberta e independente de plataforma.

  • UDDI pode se comunicar via SOAP, CORBA, protocolo Java RMI.

  • UDDI usa Web Service Definition Language (WSDL) para descrever interfaces para serviços da web.

  • UDDI é visto com SOAP e WSDL como um dos três padrões básicos de serviços da web.

  • UDDI é uma iniciativa aberta do setor, permitindo que as empresas se descubram e definam como elas interagem na Internet.

UDDI tem duas seções -

  • Um registro de todos os metadados do serviço da web, incluindo um ponteiro para a descrição WSDL de um serviço.

  • Um conjunto de definições de tipo de porta WSDL para manipular e pesquisar esse registro.

História da UDDI

  • O UDDI 1.0 foi originalmente anunciado pela Microsoft, IBM e Ariba em setembro de 2000.

  • Desde o anúncio inicial, a iniciativa UDDI cresceu para incluir mais de 300 empresas, incluindo Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP e Sun.

  • Em maio de 2001, a Microsoft e a IBM lançaram os primeiros sites de operadoras UDDI e ativaram o registro UDDI.

  • Em junho de 2001, a UDDI anunciou a versão 2.0.

  • No momento em que este tutorial foi escrito, os sites da Microsoft e da IBM haviam implementado a especificação 1.0 e planejavam o suporte 2.0 em um futuro próximo.

  • Atualmente a UDDI é patrocinada pela OASIS.

Processos de interface de parceiro

Partner Interface Processes (PIPs) são interfaces baseadas em XML que permitem que dois parceiros comerciais troquem dados. Já existem dezenas de PIPs. Alguns deles estão listados aqui -

  • PIP2A2 - Permite que um parceiro consulte outro para obter informações sobre o produto.

  • PIP3A2 - Permite que um parceiro consulte o preço e a disponibilidade de produtos específicos.

  • PIP3A4 - Permite que um parceiro envie um pedido de compra eletrônico e receba a confirmação do pedido.

  • PIP3A3 - Permite que um parceiro transfira o conteúdo de um carrinho de compras eletrônico.

  • PIP3B4 - Permite que um parceiro consulte o status de uma remessa específica.

Registros UDDI privados

Como alternativa ao uso da rede pública federada de registros UDDI disponíveis na Internet, as empresas ou grupos da indústria podem optar por implementar seus próprios registros UDDI privados.

Esses serviços exclusivos são projetados com o único propósito de permitir que os membros da empresa ou do grupo da indústria compartilhem e anunciem serviços entre si.

Independentemente de o registro UDDI ser parte da rede federada global ou um registro de propriedade e operação privada, a única coisa que os une é uma API de serviços da web comum para publicar e localizar empresas e serviços anunciados no registro UDDI.

Uma empresa ou empresa pode registrar três tipos de informações em um registro UDDI. Essas informações estão contidas em três elementos do UDDI.

Esses três elementos são -

  • White Pages,
  • Páginas Amarelas e
  • Páginas verdes.

White Pages

As páginas brancas contêm -

  • Informações básicas sobre a empresa e seus negócios.

  • Informações básicas de contato, incluindo nome comercial, endereço, número de telefone de contato, etc.

  • A Identificadores exclusivos para os IDs fiscais da empresa. Essas informações permitem que outras pessoas descubram seu serviço da web com base em sua identificação comercial.

Paginas amarelas

  • As páginas amarelas contêm mais detalhes sobre a empresa. Eles incluem descrições do tipo de recursos eletrônicos que a empresa pode oferecer a qualquer pessoa que queira fazer negócios com ela.

  • As páginas amarelas usam esquemas de categorização industrial comumente aceitos, códigos de indústria, códigos de produtos, códigos de identificação de empresas e similares para tornar mais fácil para as empresas pesquisarem nas listas e encontrarem exatamente o que desejam.

Páginas Verdes

As páginas verdes contêm informações técnicas sobre um serviço da web. Uma página verde permite que alguém se conecte a um serviço da Web depois que ele for encontrado. Inclui -

  • As várias interfaces
  • Os locais de URL
  • Informações de descoberta e dados semelhantes necessários para localizar e executar o serviço da web.

NOTE- UDDI não se restringe a descrever serviços da web baseados em SOAP. Em vez disso, o UDDI pode ser usado para descrever qualquer serviço, desde uma única página da Web ou endereço de e-mail até os serviços SOAP, CORBA e Java RMI.

A arquitetura técnica UDDI consiste em três partes -

Modelo de Dados UDDI

O modelo de dados UDDI é um esquema XML para descrever negócios e serviços da web. O modelo de dados é descrito em detalhes no capítulo "Modelo de Dados UDDI".

Especificação da API UDDI

É uma especificação de API para pesquisar e publicar dados UDDI.

Serviços de nuvem UDDI

Esses são sites de operadoras que fornecem implementações da especificação UDDI e sincronizam todos os dados em uma base programada.

O UDDI Business Registry (UBR), também conhecido como Nuvem Pública, é um sistema conceitualmente único construído a partir de vários nós, tendo seus dados sincronizados por meio de replicação.

Os serviços de nuvem atuais fornecem um diretório logicamente centralizado, mas fisicamente distribuído. Isso significa que os dados enviados a um nó raiz serão automaticamente replicados em todos os outros nós raiz. Atualmente, a replicação de dados ocorre a cada 24 horas.

Os serviços de nuvem UDDI são fornecidos atualmente pela Microsoft e IBM. A Ariba planejou originalmente oferecer uma operadora também, mas desde então desistiu do compromisso. Operadores adicionais de outras empresas, incluindo Hewlett-Packard, estão planejados para um futuro próximo.

Também é possível configurar registros UDDI privados. Por exemplo, uma grande empresa pode configurar seu próprio registro UDDI privado para registrar todos os serviços da web internos. Como esses registros não são sincronizados automaticamente com os nós UDDI raiz, eles não são considerados como parte da nuvem UDDI.

UDDI inclui um esquema XML que descreve as seguintes estruturas de dados -

  • businessEntity
  • businessService
  • bindingTemplate
  • tModel
  • publisherAssertion

Estrutura de dados businessEntity

A estrutura da entidade comercial representa o provedor de serviços da web. No registro UDDI, essa estrutura contém informações sobre a própria empresa, incluindo informações de contato, categorias de setor, identificadores de negócios e uma lista de serviços fornecidos.

Aqui está um exemplo de entrada de registro UDDI de uma empresa fictícia -

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

Estrutura de dados businessService

A estrutura do serviço comercial representa um serviço web individual fornecido pela entidade comercial. Sua descrição inclui informações sobre como vincular-se ao serviço da web, que tipo de serviço da web ele é e a quais categorias taxonômicas ele pertence.

Aqui está um exemplo de uma estrutura de serviço de negócios para o serviço da 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 o uso dos identificadores exclusivos universais (UUIDs) nos atributos businessKey e serviceKey . Cada entidade comercial e serviço comercial é identificado exclusivamente em todos os registros UDDI por meio do UUID atribuído pelo registro quando as informações são inseridas pela primeira vez.

Estrutura de dados bindingTemplate

Os modelos de ligação são as descrições técnicas dos serviços da web representados pela estrutura de serviço de negócios. Um único serviço de negócios pode ter vários modelos de ligação. O modelo de ligação representa a implementação real do serviço da web.

Aqui está um exemplo de um modelo de ligação 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 um serviço de negócios pode ter vários modelos de ligação, o serviço pode especificar diferentes implementações do mesmo serviço, cada uma ligada a um conjunto diferente de protocolos ou um endereço de rede diferente.

Estrutura de dados tModel

tModel é o último tipo de dados principal, mas potencialmente o mais difícil de entender. tModel significa modelo técnico.

tModel é uma maneira de descrever os vários negócios, serviços e estruturas de modelo armazenadas no registro UDDI. Qualquer conceito abstrato pode ser registrado no UDDI como um tModel. Por exemplo, se você definir um novo tipo de porta WSDL, poderá definir um tModel que representa esse tipo de porta dentro do UDDI. Em seguida, você pode especificar que um determinado serviço de negócios implemente esse tipo de porta associando o tModel a um dos modelos de ligação desse serviço de negócios.

Aqui está um exemplo de um tModel que representa o tipo de porta 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>

Estrutura de dados publisherAssertion

É uma estrutura de relacionamento que associa duas ou mais estruturas businessEntity de acordo com um tipo específico de relacionamento, como filial ou departamento.

A estrutura publisherAssertion consiste em três elementos: fromKey (a primeira businessKey), toKey (a segunda businessKey) e keyedReference.

O keyedReference designa o tipo de relacionamento declarado em termos de um par keyName keyValue dentro de um tModel, referenciado exclusivamente por um 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>

Um registro é inútil sem alguma forma de acessá-lo. O padrão UDDI versão 2.0 especifica duas interfaces para consumidores e provedores de serviços interagirem com o registro.

Consumidores de serviço usam Inquiry Interface para encontrar um serviço e os provedores de serviço usam Publisher Interface para listar um serviço.

O núcleo da interface UDDI são as definições do Esquema XML UDDI. Eles definem os tipos de dados UDDI fundamentais através dos quais todas as informações fluem.

A interface do editor

A Interface do Editor define dezesseis operações para um provedor de serviços gerenciando suas entradas no registro UDDI -

  • get_authToken- Recupera um token de autorização. Todas as operações da interface do Publisher requerem que um token de autorização válido seja enviado com a solicitação.

  • discard_authToken- Diz ao registro UDDI para não aceitar mais um determinado token de autorização. Esta etapa é equivalente a efetuar logout do sistema.

  • save_business - Cria ou atualiza as informações de uma entidade comercial contidas no registro UDDI.

  • save_service - Cria ou atualiza informações sobre os serviços da web que uma entidade comercial fornece.

  • save_binding - Cria ou atualiza as informações técnicas sobre a implementação de um serviço da web.

  • save_tModel - Cria ou atualiza o registro de conceitos abstratos gerenciados pelo registro UDDI.

  • delete_business - Remove as entidades comerciais fornecidas do registro UDDI completamente.

  • delete_service - Remove os serviços da web fornecidos do registro UDDI completamente.

  • delete_binding - Remove os detalhes técnicos de serviços da Web fornecidos do registro UDDI.

  • delete_tModel - Remove os tModels especificados do registro UDDI.

  • get_registeredInfo - Retorna um resumo de tudo o que o registro UDDI está rastreando para o usuário, incluindo todas as empresas, todos os serviços e todos os tModels.

  • set_publisherAssertions - Gerencia todas as afirmações de relacionamento rastreadas associadas a uma conta de editor individual.

  • add_publisherAssertions - Faz com que um ou mais publisherAssertions sejam adicionados à coleção de asserções de um publicador individual.

  • delete_publisherAssertions - Faz com que um ou mais elementos publisherAssertion sejam removidos da coleção de asserções de um editor.

  • get_assertionStatusReport - Fornece suporte administrativo para determinar o status das afirmações atuais e pendentes do editor que envolvem qualquer um dos registros comerciais gerenciados pela conta do editor individual.

  • get_publisherAssertions - Obtém o conjunto completo de afirmações do editor que está associado a uma conta individual do editor.

A interface de inquérito

A interface de consulta define dez operações para pesquisar o registro UDDI e recuperar detalhes sobre registros específicos -

  • find_binding - Retorna uma lista de serviços da web que correspondem a um determinado conjunto de critérios com base nas informações técnicas de vinculação.

  • find_business - Retorna uma lista de entidades comerciais que correspondem a um determinado conjunto de critérios.

  • find_ltservice - Retorna uma lista de serviços da web que correspondem a um determinado conjunto de critérios.

  • find_tModel - Retorna uma lista de tModels que correspondem a um determinado conjunto de critérios.

  • get_bindingDetail - Retorna as informações de registro completas para um modelo de ligação de serviço da web específico.

  • get_businessDetail - Retorna as informações de registro de uma entidade comercial, incluindo todos os serviços que a entidade fornece.

  • get_businessDetailExt - Retorna as informações de registro completas de uma entidade comercial.

  • get_serviceDetail - Retorna as informações de registro completas para um serviço da web.

  • get_tModelDetail - Retorna as informações de registro completas para um tModel.

  • find_relatedBusinesses - Descobre negócios que foram relacionados por meio do uddi-org: modelo de relacionamentos.

Considere que uma empresa XYZ deseja registrar suas informações de contato, descrição do serviço e informações de acesso ao serviço online com UDDI. As etapas a seguir são necessárias -

  • Escolha um operador com o qual trabalhar. Cada operadora tem diferentes termos e condições para autorizar o acesso à sua réplica do registro.

  • Crie ou obtenha um cliente UDDI, como os fornecidos pelos operadores.

  • Obtenha um token de autenticação do operador.

  • Cadastre informações sobre o negócio. Inclua todas as informações que possam ser úteis para aqueles que procuram correspondências.

  • Libere o token de autenticação.

  • Use as APIs de consulta para testar a recuperação das informações, incluindo informações do modelo de ligação, para garantir que alguém que as obtiver possa usá-las com êxito para interagir com seu serviço.

  • Preencha as informações do tModel caso alguém queira pesquisar um determinado serviço e encontrar sua empresa como uma das prestadoras de serviço.

  • Atualize as informações conforme necessário para refletir as mudanças nas informações de contato comercial e novos detalhes do serviço, obtendo e liberando um novo token de autenticação da operadora a cada vez. Sempre que você precisar atualizar ou modificar os dados que você registrou, você deve voltar para a operadora com a qual você inseriu os dados.

Os exemplos a seguir mostram como a Empresa XYZ registraria suas informações e como um distribuidor interessado em levar a linha de produtos da XYZ pode encontrar informações sobre como entrar em contato com a empresa e fazer um pedido, usando os serviços da Web XYZ.com.

Criando Registro

Depois de obter um token de autenticação de uma das operadoras da Microsoft, por exemplo, os desenvolvedores do XYZ.com decidem quais informações publicar no registro e usam uma das ferramentas UDDI fornecidas pela Microsoft. Se necessário, os desenvolvedores também podem escrever um programa Java, C # ou VB.NET para gerar as mensagens SOAP apropriadas. Aqui está um exemplo.

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 exemplo ilustra uma mensagem SOAP solicitando o registro de uma entidade comercial UDDI para a Empresa XYZ. O elemento chave está em branco, porque o operador gera automaticamente a chave UUID para a estrutura de dados. A maioria dos campos é omitida para mostrar um exemplo simples.

A empresa XYZ sempre pode executar outra operação save_business para adicionar às informações básicas necessárias para criar uma entidade comercial.

Recuperando Informações

Depois que a Empresa XYZ atualizou sua entrada UDDI com as informações relevantes, as empresas que desejam se tornar distribuidores XYZ podem pesquisar informações de contato no registro UDDI e obter as descrições de serviço e os pontos de acesso para os dois serviços da Web que XYZ.com publica para online entrada de pedido: pedidos em massa pré-temporada e pedidos de reabastecimento na temporada.

Este exemplo ilustra uma amostra de solicitação SOAP para obter informações de detalhes de negócios sobre a Empresa XYZ. Depois de saber o UUID, ou chave, para o negócio específico que foi registrado, você pode usá-lo na API get_businessDetail para retornar informações específicas sobre esse negócio.

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>

O modelo de dados UDDI define uma estrutura genérica para armazenar informações sobre um negócio e os serviços da web que ele publica. O modelo de dados UDDI é completamente extensível, incluindo várias estruturas de sequência de informações repetidas.

No entanto, WSDL é usado para descrever a interface de um serviço da web. WSDL é bastante simples de usar com UDDI.

  • WSDL é representado em UDDI usando uma combinação de informações businessService, bindingTemplate e tModel .

  • Como acontece com qualquer serviço registrado no UDDI, as informações genéricas sobre o serviço são armazenadas na estrutura de dados businessService e as informações específicas sobre como e onde o serviço é acessado são armazenadas em uma ou mais estruturas bindingTemplate associadas . Cada estrutura bindingTemplate inclui um elemento que contém o endereço de rede do serviço e tem associado a ele uma ou mais estruturas tModel que descrevem e identificam exclusivamente o serviço.

  • Quando UDDI é usado para armazenar informações WSDL, ou ponteiros para arquivos WSDL, o tModel deve ser referido por convenção como tipo wsdlSpec , o que significa que o elemento overviewDoc é claramente identificado como apontando para uma definição de interface de serviço WSDL.

  • Para UDDI, o conteúdo WSDL é dividido em dois elementos principais, o arquivo de interface e o arquivo de implementação.

O serviço da web do sistema de reservas Hertz fornece um exemplo concreto de como UDDI e WSDL funcionam juntos. Aqui está o <tModel> para este serviço da 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>

Os pontos principais são -

  • O elemento overviewURL fornece a URL onde o arquivo WSDL de definição de interface de serviço pode ser encontrado. Isso permite que humanos e ferramentas com reconhecimento de UDDI / WSDL localizem a definição da interface de serviço.

  • O objetivo do elemento keyedReference em categoryBag é garantir que este tModel seja categorizado como um documento de especificação WSDL.

Várias implementações de UDDI estão disponíveis atualmente. Essas implementações tornam mais fácil pesquisar ou publicar dados UDDI, sem ficar atolado nas complexidades da API UDDI. Aqui está uma breve sinopse das principais implementações UDDI disponíveis.

Implementações Java

Existem duas implementações UDDI para Java.

  • UDDI4J (UDDI para Java) - UDDI4J foi originalmente criado pela IBM. Em janeiro de 2001, a IBM entregou o código para seu próprio site de código aberto. UDDI4J é uma biblioteca de classes Java que fornece uma API para interagir com um UDDI.

  • jUDDI - jUDDI é uma implementação Java de código aberto de um registro UDDI e um kit de ferramentas para acessar serviços UDDI.

Implementação Perl

  • UDDI::Lite - Fornece um cliente UDDI básico para consulta e publicação.

Implementação Ruby

  • UDDI4r - Fornece um cliente UDDI básico para consulta e publicação.

Implementação Python

  • UDDI4Py - UDDI4Py é um pacote Python que permite o envio de solicitações e processamento de respostas das APIs UDDI Versão 2.

O projeto UDDI também define um conjunto de definições de Esquema XML que descreve os formatos de dados usados ​​pelas várias APIs de especificação. Todos esses documentos estão disponíveis para download em www.uddi.org . A versão atual de todos os grupos de especificações é a Versão 2.0.

As especificações incluem o seguinte -

  • Replicação UDDI,
  • Operadores UDDI,
  • API do programador UDDI e
  • Estruturas de dados UDDI

Replicação UDDI

Este documento descreve os processos e interfaces de replicação de dados aos quais um operador de registro deve estar em conformidade para obter a replicação de dados entre sites. Esta especificação não é uma API do programador; ele define o mecanismo de replicação usado entre os nós UBR.

Operadores UDDI

Este documento descreve o comportamento e os parâmetros operacionais exigidos pelos operadores de nó UDDI. Esta especificação define os requisitos de gerenciamento de dados aos quais os operadores devem aderir.

API do programador UDDI

Esta especificação define um conjunto de funções que todos os registros UDDI suportam para indagar sobre serviços hospedados em um registro e para publicar informações sobre um negócio ou serviço para um registro. Esta especificação define uma série de mensagens SOAP contendo documentos XML que um registro UDDI aceita, analisa e responde. Esta especificação, junto com o esquema UDDI XML API e a especificação UDDI Data Structure, constitui uma interface de programação completa para um registro UDDI.

Estruturas de dados UDDI

Esta especificação cobre as especificidades das estruturas XML contidas nas mensagens SOAP definidas pela API do programador UDDI. Esta especificação define cinco estruturas de dados principais e seus relacionamentos entre si.

O esquema UDDI XML API não está contido em uma especificação; em vez disso, é armazenado como um documento de esquema XML que define a estrutura e os tipos de dados das estruturas de dados UDDI.

UDDI e seus elementos neste tutorial e também vimos a arquitetura completa e o modelo de dados de UDDI.

Aprendemos sobre as duas interfaces UDDI: Publisher's Interface e Inquiry Interface. Também aprendemos como registrar e pesquisar serviços da web com UDDI.

Qual é o próximo?

A próxima etapa é aprender sobre SOAP, WSDL e Web Services.

SABONETE

SOAP é um protocolo simples baseado em XML que permite que os aplicativos troquem informações sobre HTTP.

Se você quiser saber mais sobre o SOAP, visite nosso tutorial SOAP .

WSDL

WSDL é o formato padrão para descrever um serviço da web em formato XML.

WSDL é parte integrante do UDDI.

Se você quiser saber mais sobre WSDL, visite nosso Tutorial WSDL .

Serviços web

Os serviços da web podem converter seus aplicativos em aplicativos da web.

Se quiser saber mais sobre os serviços da Web, visite nosso tutorial de Serviços da Web .

Aqui está a referência completa das APIs de consulta UDDI e das APIs de publicação UDDI.

As APIs UDDI Inquiry

Nome API Descrição V1.0 V2.0
find_binding Procura ligações de modelos associadas a um serviço especificado. Y Y
find_business Pesquisa empresas que correspondam aos critérios especificados. Y Y
find_relatedBusinesses Descobre negócios que foram relacionados por meio do modelo uddi-org: relacionamentos. Y
find_service Pesquisa por serviço associado a um negócio específico. Y Y
find_tModel Procura por registros tModel que correspondam aos critérios especificados. Y Y
get_bindingDetail Recupera o bindingTemplate completo para cada bindingKey especificado. Y Y
get_businessDetail Recupera o businessEntity completo para cada businessKey especificado. Y Y
get_businessDetailExt Recupera o businessEntity estendido para cada businessKey especificado. Y Y
get_serviceDetail Recupera o registro businessService para cada serviceKey especificado. Y Y
get_tModelDetail Recupera o registro tModel para cada tModelKey especificado. Y Y

As APIs de publicação UDDI

Nome API Descrição V1.0 V2.0
get_authToken Recupera um token de autorização. Todas as operações da interface do Publisher requerem que um token de autorização válido seja enviado com a solicitação. Y Y
discard_authToken Diz ao registro UDDI para não aceitar mais um determinado token de autorização. Esta etapa é equivalente a efetuar logout do sistema. Y Y
save_business Cria ou atualiza as informações de uma entidade comercial contidas no registro UDDI. Y Y
save_service Cria ou atualiza informações sobre os serviços da web que uma entidade comercial fornece. Y Y
save_binding Cria ou atualiza as informações técnicas sobre a implementação de um serviço da web. Y Y
save_tModel Cria ou atualiza o registro de conceitos abstratos gerenciados pelo registro UDDI. Y Y
delete_business Remove as entidades comerciais fornecidas do registro UDDI completamente. Y Y
delete_service Remove os serviços da web fornecidos do registro UDDI completamente. Y Y
delete_binding Remove os detalhes técnicos do serviço da web fornecidos do registro UDDI. Y Y
delete_tModel Remove os tModels especificados do registro UDDI. Y Y
get_registeredInfo Retorna um resumo de tudo o que o registro UDDI está rastreando para o usuário, incluindo todas as empresas, todos os serviços e todos os tModels. Y Y
set_publisherAssertions Gerencia todas as afirmações de relacionamento rastreadas associadas a uma conta individual do editor. Y
add_publisherAssertions Faz com que um ou mais publisherAssertions sejam adicionados à coleção de asserções de um publicador individual. Y
delete_publisherAssertions Faz com que um ou mais elementos publisherAssertion sejam removidos da coleção de asserções de um editor. Y
get_assertionStatusReport Fornece suporte administrativo para determinar o status das afirmações de editoras atuais e pendentes que envolvem qualquer um dos registros comerciais gerenciados pela conta de editor individual. Y
get_publisherAssertions Obtém o conjunto completo de asserções do editor que está associado a uma conta individual do editor. Y

Referência de código de erro

Uma referência completa dos códigos de erro retornados pelas APIs UDDI é fornecida -

Códigos de Erro