Universal Description, Discovery and Integration (UDDI)
Rafael Andrade
Mestrado em Ciências da Computação, 2002
Laboratório de Integração de Hardware e Software (LISHA)
Universidade Federal de Santa Catarina (UFSC), Brasil, 88040-900.
Fone (0XX48) 331-9498 R. 223, Fax (0XX48) 331-9770.
[email protected]
Resumo
Este trabalho apresenta uma visão geral do protocolo UDDI, (Universal
Description, Discovery and Integration), utilizado na comunicação de aplicações
distribuídas baseadas na Internet, e como as aplicações podem fazer uso de suas
funcionalidades. Registros baseados em UDDI ajudarão empresas a tirarem
vantagem dos serviços Web. Empresas terão um pensamento para descrever serviços
e processos negociáveis em um mundo global, abrindo o ambiente da internet para
expandir esse avanço. Uma barreira para participação rápida em uma economia de
internet global será expandida para qualquer negócio em qualquer lugar. Empresas
serão capazes de organizar suas pastas de serviços em um ambiente controlado.
Introdução
Atualmente
a
web
é
utilizada
principalmente para o acesso interativo a
documentos e aplicações. Na maioria dos casos,
este acesso é feito através de web browsers, por
usuários humanos. No entanto, acredita-se que a
partir do momento em que houver uma forte
integração entre diferentes aplicações na Internet, o
uso da web poderá ser maximizado.
Quando pensamos em computadores
móveis, cuja capacidade de processamento,
armazenamento e transmissão de dados é limitada,
esta necessidade de integração é ainda maior. Por
exemplo, tendo acesso a diferentes aplicações
distribuídas na web, computadores móveis
poderiam solicitar uma série de serviços que
executam na rede fixa, recebendo o resultado de
seu processamento. Como exemplos podem ser
citados serviços de impressão de arquivos,
armazenamento de documentos e conversão de
formatos.
No entanto, para que uma boa relação
custo-benefício seja alcançada, é necessário que
esta integração entre aplicações seja efetuada de
forma padronizada. Desta forma uma vez
desenvolvida a integração de uma aplicação, ela
estará pronta para ser acessada por qualquer outra,
através de um padrão único. Sendo assim o
desenvolvimento específico e artesanal de
integração de pares de aplicações é evitado,
gerando uma grande economia de gastos no
processo de integração como um todo.
Um Web Service pode ser definido como
uma aplicação de software ou um dispositivo de
hardware que pode ser acessado ou utilizado
através da web. Cada Web Service implementa
uma ou mais interfaces de serviço descritas através
de linguagens específicas. Estas interfaces
descrevem o conjunto de operações às quais o
serviço dá suporte, contendo toda a informação
necessária para interação com ele, incluindo o
formato das mensagens trocadas, o protocolo de
transporte utilizado e sua localização. Esta
interface esconde os detalhes de implementação do
serviço,
permitindo
sua
utilização
independentemente da plataforma de hardware ou
software na qual ele é implementado ou da
linguagem na qual ele é escrito.
Arquitetura Conceitual de Web
Services
A arquitetura padrão da tecnologia de Web
Services pode ser descrita em diversas camadas.
Para as diferentes operações de publicação,
descoberta e invocação de serviços são necessárias
diversas camadas que compõem a denominada
“Pilha de Web Services”, ilustrada na figura 1. As
camadas superiores são construídas utilizando
funcionalidades disponibilizadas pelas camadas
inferiores. As colunas no lado direito da figura
ilustram requisitos necessários em cada um dos
níveis da pilha, enquanto o texto da esquerda
representa as tecnologias e padrões que são
utilizados na implementação de em cada uma das
camadas.[2]
Para que Web Services possam ser
invocados por um cliente remoto, eles devem ser
acessíveis através da rede. Desta forma, na base da
pilha está a camada de rede. Na maioria das vezes
é interessante que os serviços sejam acessados
através da Internet, sendo então necessária a
utilização de protocolos amplamente difundidos na
grande rede. Devido a sua onipresença o protocolo
HTTP é o principal protocolo no nível de rede
utilizado na implementação de Web Services. No
entanto, outros protocolos também podem ser
utilizados como, por exemplo, SMTP ou FTP. Em
caso de implementação de Web Services em redes
locais, serviços confiáveis de trocas de mensagens
como, por exemplo, IBM MQSeries também
podem ser utilizados.
A segunda camada é a de troca de
mensagens baseadas em XML. O protocolo SOAP
é o escolhido para esta camada devido
principalmente ao seu mecanismo padronizado de
envelope de mensagens centradas em documentos
ou chamada remota de procedimentos (RPC).
Além disso, o protocolo possui uma maneira
padronizada de codificação, isto é, de
transformação de tipos de dados específicos a
diferentes linguagens de programação aos dados
necessários para a mensagem.
A próxima camada da pilha é a de
descrição de serviços. Nesta camada o padrão
utilizado é o chamado WSDL. Este padrão é
necessário para que se possa interoperar Web
Services. WSDL define a interface de comunicação
com o serviço assim como a dinâmica de interação
com este.
Uma arquitetura composta por estas três
primeiras camadas é o mínimo necessário para
possibilitar a utilização de qualquer Web Service.
Enquanto estas camadas apresentam as tecnologias
de interoperabilidade entre serviços, as duas
próximas camadas, de publicação e de descoberta
de serviços, podem ser implementadas através de
uma gama variada de soluções.
Qualquer ação que torna um documento
WSDL disponível para um cliente, em qualquer
estágio do ciclo de vida deste, é qualificada como a
publicação de um serviço. O exemplo mais simples
e estático de implementação desta camada é o
envio de um documento WSDL diretamente ao
cliente. Esta forma de publicação, chamada de
publicação direta, pode simplesmente utilizar o email como veículo de comunicação. O mecanismo
de publicação direta é bastante útil para aplicações
que são ligadas estaticamente a serviços. De
maneira alternativa, o provedor do serviço pode
publicar o documento WSDL em um broker que
poderá ser acessado posteriormente por clientes.
Neste broker, a principal tecnologia utilizada é o
UDDI, que pode ser visto como o padrão para
registrar, descrever e localizar Web Services
utilizando uma base de registro compartilhada
entre os diferentes clientes.
Figura 1 Pilha de protocolos da arquitetura
de Web Services
Uma vez que serviços não podem ser
descobertos sem terem sido publicados, a camada
de descoberta de serviços depende da camada de
publicação. Assim como acontece para a
publicação, um grande número de abordagens pode
ser utilizado nesta camada. Qualquer mecanismo
que permite que o cliente tenha acesso a descrição
do Web Service e a torna disponível para a
aplicação desejada em tempo de execução, pode
ser qualificado como um mecanismo de descoberta
de serviços. O exemplo mais simples e estático de
descoberta é aquele no qual o cliente recupera o
documento WSDL a partir de um arquivo local. No
entanto, um Web Service pode ser descoberto em
tempo de projeto ou de execução, através da busca
em uma base de registro comum ou broker.
A criação e gerência desta base de registro
e descoberta, compartilhada entre os diversos
clientes, são alguns dos pontos críticos do projeto
de Web Services. Isto se deve à necessidade de
acesso a esta base por diferentes clientes com
capacidades de hardware e software diferentes.
Desta forma, o protocolo UDDI vem sendo
utilizado como tecnologia para a implementação
desta base, principalmente por ser baseado em
padrões abertos e ubíquos. O protocolo UDDI será
apresentado com maiores detalhes na próxima
seção.
A implementação de um Web Service pode
ser encarada como a de um componente de
software. Desta forma, é natural construir novos
serviços compondo serviços pré-existentes.
Composições de serviços podem desempenhar
diferentes papéis. Dentro de um provedor de
serviços, diferentes Web Services podem colaborar
de forma a apresentar uma interface única para o
público. Da mesma forma, diferentes serviços de
diferentes provedores podem colaborar de forma a
oferecer serviços mais completos ou implementar
tarefas de integração. De forma alternativa um
gerenciador de workflow pode ser utilizado
chamando cada Web Service que participa de um
processo específico. A camada mais alta da pilha,
denominada camada de fluxo entre serviços, é a
responsável por esta tarefa, descrevendo como
comunicações entre serviços, colaboração e fluxo
de dados são implementadas. A tecnologia
emergente para a especificação e implementação
desta camada está baseada na linguagem WSFL
(Web Services Flow Language). Neste trabalho
esta linguagem não será discutida com maiores
detalhes, uma vez que esta é, dentre todas as
tecnologias utilizadas na implementação de Web
Services, a menos estabelecida e validada.
Para que Web Services possam ser utilizados
em aplicações reais e escaláveis alguns requisitos
de infra-estrutura devem ser oferecidos por cada
uma das camadas da pilha. Dentre estes podemos
citar segurança, gerenciamento e qualidade de
serviço. As soluções adotadas em cada uma das
camadas podem seguir abordagens diferentes, e
atualmente não existem padrões específicos que
possam ser utilizados para que estes requisitos
sejam alcançados. Acredita-se que, com o passar
do tempo e conseqüente maturidade da tecnologia
de Web Services, venham a surgir novos padrões
para a implementação destes requisitos.
Universal Description, Discovery and
Integration (UDDI)
A especificação do padrão Universal
Description, Discovery and Integration (UDDI)
define uma maneira de publicar e descobrir
informações relativas a Web Services. Trata-se de
uma proposta de um diretório universal de registro
de Web Services, onde seriam encontradas
informações sobre as empresas fornecedoras de
serviços. A primeira vista o processo
de
descoberta de Web Services pode parecer simples.
Na verdade, uma vez que se sabe qual o provedor
de serviços que oferece um conjunto de operações
agrupadas em serviços, o que mais é preciso
descobrir? No entanto, quando é necessário
descobrir quais provedores oferecem os serviços
desejados, a capacidade de descobrir as respostas
torna-se muito mais complicada.
Com a intenção de resolver este problema,
UDDI usa uma abordagem baseada em uma base
de registros distribuídos de provedores de serviços
e suas descrições de serviços, implementada
utilizando
um
formato
XML
comum.
Conceitualmente, a informação que faz parte da
base de registro UDDI consiste de três
componentes:
•
Páginas brancas: contêm o endereço,
pessoas de contato e outros identificadores
relativos a um provedor de serviço;
•
Páginas amarelas: incluem categorizações
industriais baseadas em taxonomias
padrão;
•
Páginas verdes: contêm informações
específicas sobre serviços disponibilizados
pelo provedor.
Na maioria dos casos programas e
desenvolvedores usam a base de registros UDDI
para localizar informações sobre serviços. No caso
específico de programadores a utilização está
focada na preparação de sistemas compatíveis com
Web Services anunciados ou para descrever seus
próprios serviços que serão utilizados por
terceiros.[1]
A especificação do UDDI descreve uma
nuvem conceitual de Web Services e uma interface
programável que define um framework simples
para a descrição de qualquer tipo de serviço. Esta
especificação consiste em um esquema XML para
a estrutura de dados e um outro que contém uma
API que define um protocolo para registro e
descoberta de serviços.
O esquema XML que representa os dados em
um documento UDDI possui quatro tipos de dados
principais, conforme ilustrado na figura 2:
Figura 2 Informação no esquema XML do UDDI
•
businessEntity:
contém
informações
relativas à entidade que publica
informações sobre uma família de
serviços;
•
businessService: contém informações
descritivas sobre um serviço particular;
•
bindingTemplate: contém informações
técnicas sobre um serviço e especificações
relativa s a sua construção;
•
tModel:
contém
descrições
a
especificações
para
serviços
ou
taxonomias. Na verdade, tModels são
utilizados como interfaces que são
implementadas por bindingTemplates.
Um outro tipo de elemento que também faz
parte do esquema UDDI é o Publisher Assertion
que possui informações relativas a relacionamento
entre duas entidades provedoras de serviços.
Estes tipos de dados fazem parte das
requisições e chamadas definidas na UDDI API
Schema. Esta API define aproximadamente 25
requisições e 15 respostas formatadas em XML
utilizadas na descoberta e publicação de serviços
em bases de registro UDDI. Exemplos de
requisições podem ser find_service, find_tModel,
save_service ou save_business.
Discussão e Conclusões
A tecnologia de Web Services surgiu há
poucos anos e vem se firmando como o padrão da
indústria para a interoperabilidade de serviços
distribuídos. No entanto, ainda existe pouca
pesquisa no meio acadêmico relacionada a esta
tecnologia. O principal fator para a forte aceitação
de Web Services pela indústria é o fato dele ser
baseado em protocolos abertos que utilizam
tecnologias amplamente estabelecidas na Internet,
como HTTP e XML.
A interoperabilidade de Web Services é
realizada em alto nível permitindo que clientes e
serviços sejam fracamente acoplados, separando
claramente a interface da implementação. A
utilização de Web Services em clientes móveis
torna-se especialmente interessante uma vez que
grande parte dos serviços necessários a eles pode
ser localizada na rede fixa. Os clientes podem
então fazer buscas dinâmicas por serviços
utilizando bases de registro UDDI, conectar-se a
eles e em seguida fazer solicitações utilizando o
protocolo SOAP. Apesar destas vantagens e de
muitas promessas da indústria relativas a Web
Services específicos para acesso de computadores
móveis, atualmente não existem muitos serviços
deste tipo implementados.[4]
Referências
[1] D. Ehnebuske, C. Riegen and D. Rogers
(editors), “UDDI Version 2.0 Data Structure
Specification,”
(http://www.uddi.org/pubs/DataStructureV2.00-Open-20010608.pdf)
[2] H. Kreger, Web Services Conceptual
Architecture, May 2001, (http://www4.ibm.com/software/solutions/webservices/pdf/
WSCA.pdf)
[3] UDDI Version 2.0 Operator’s Specification
http://www.uddi.org/pubs/OperatorsV2.00-Open-20010608.pdf
[4] www.w3c.org