Artigo Clube Delphi 69 - UDDI

Esse artigo faz parte da revista Clube Delphi edição 69. Clique aqui para ler todos os artigos desta edição

UDDI

Parte IV - Analisando o cenário em funcionamento

No artigo anterior estudamos a inclusão de informações em um registro UDDI, usando para isso os serviços UDDI do Windows Server 2003. Depois de entendido esse processo na prática, podemos partir agora para a conclusão da implementação de nosso cenário prático, estudando a UDDI SOAP API e codificando os elementos restantes. Vamos lá!

A UDDI SOAP API

Como já foi comentado ao longo desta série, todo serviço UDDI é obrigado a disponibilizar uma interface SOAP padrão para acesso programático, são as chamadas UDDI Inquiry API e UDDI Publish API. Neste artigo estaremos utilizando apenas a API de pesquisa, visto que a publicação já fizemos na parte III da série, usando a interface web disponibilizada pelo Windows Server 2003 para esse propósito.

A UDDI Inquiry API é relativamente simples, sendo composta de algumas poucas mensagens cujas descrições resumidas podem ser encontradas a seguir:

·find_binding: Usada para localizar vinculações específicas dentro de serviço (businessService) registrado, seu retorno é uma mensagem bindingDetail;

·find_business: Usada para localizar informações sobre provedores, seu retorno é uma mensagem businessList;

·find_relatedBusinesses: Usada para localizar informações sobre provedores (businessEntity) que são relacionados a uma unidade de negócio específica cuja chave é fornecida, seu retorno é uma mensagem relatedBusinessesList;

·find_service: Usada para localizar serviços específicos de um dado provedor (businessEntity) já registrado. Seu retorno é uma mensagem serviceList;

·find_tModel: Usada para localizar informações sobre estruturas tModel, ou seja, especificações abstratas de serviços de interesse da comunidade. Seu retorno é uma estrutura tModelList;

·get_bindingDetail: Usada para obter detalhes completos sobre vinculações (bindingTemplate) de um dado conjunto de serviços requisitados. Seu retorno é uma mensagem bindingDetail;

·get_businessDetail: Usada para obter informações completas sobre provedores (businessEntity), seu retorno é uma mensagem businessDetail;

·get_businessDetailExt: Usada para obter informações estendidas sobre provedores (businessEntity), seu retorno é uma mensagem businessDetailExt;

·get_serviceDetail: Usada para obter detalhes completos sobre um dado conjunto de serviços registrados, seu retorno é uma mensagem serviceDetail;

·get_tModelDetail: Usada para obter detalhes completos sobre um dado conjunto de tModels registrados, seu retorno é uma mensagem tModelDetail.

Maiores detalhes sobre a especificação da UDDI SOAP API podem ser obtidos em www.uddi.org. Bom, para começarmos a desenvolver o restante de nosso cenário precisaremos decidir como faremos esse acesso ao servidor UDDI. Obviamente codificar manualmente os envelopes SOAP e enviá-los, assim como realizar o processo inverso para o recebimento da resposta, é uma opção, vejamos como exemplo a formatação da mensagem find_tModel:

">  [maxRows="nn"] generic="2.0"

  xmlns="urn:uddi-org:api_v2" >

  [<findQualifiers/>]

  [ []…]

  []

  []

Mesmo sabendo que essa é uma opção e que todas as mensagens da referida API são igualmente simples, podemos concluir com facilidade que essa não é a opção mais produtiva. O melhor caminho é buscarmos um framework que já faça esse trabalho repetitivo e de mais baixo nível para nós, de tal forma que possamos nos preocupar apenas com as regras de negócios envolvidas na lógica que queremos empregar.

Obtendo o Microsoft UDDI .NET SDK 2.0 Beta 1

" [...] continue lendo...