Registro UDDI

Obter informações sobre Web Services nem sempre é uma tarefa trivial. Especialmente quando se trata de uma arquitetura distribuída em que os Web Services estão localizados em um domínio e as informações sobre esses Web Services foram armazenados em um local diferente. Alguns trabalhos na literatura abordam a necessidade de um registro de serviço mais confiável e, ao mesmo tempo de forma consistente, de modo que a busca de determinado serviço seja realizada em menor tempo. Em (Pilioura et al., 2004), os autores apostam na Web semântica para tentar endereçar

Web Services de forma apropriada, por meio de repositórios UDDIs confiáveis, e da proposição

de uma infra-estrutura para publicação e descoberta de Web Services. As promessas vão desde a publicação e descoberta de serviços baseada na sintaxe e semântica, o uso de QoS, o uso de uma infra-estrutura escalável que organize registros com base em domínios e permita que usuários acessem múltiplos registros sob uma única visão, juntamente com a descoberta de serviços por usuários finais e desenvolvedores. Os autores sinalizam para os pontos negativos da especificação UDDI, tais como:

• Descrição deficiente do serviço;

• Descrição deficiente para atender as necessidades do solicitante do serviço; • Filtragem adicional feita de modo manual;

• Falta de uma interface amigável com o usuário final;

• Problemas de escalabilidade devido à centralização do UDDI;

• Informações armazenadas no UDDI são semanticamente diferentes. Não há um padrão es- pecífico. A infra-estrutura deveria acomodar diferentes mecanismos da publicação e de- scoberta;

• A distribuição física não é transparente ao usuário.

O funcionamento da arquitetura proposta não é apresentado. As demonstrações da mesma são feitas teoricamente utilizando ontologias. Soma-se a isso a ausência total de aspectos de avaliação de desempenho. Informações armazenadas no UDDI são semanticamente diferentes. Não há um padrão específico. A infra-estrutura deve acomodar diferentes mecanismos de publicação e descoberta. A distribuição física deve ser transparente para o cliente (visualizar como uma coleção de serviços sem saber de onde vem). Embora o artigo demonstre o funcionamento por meio de ontologias, não há nenhuma discussão sobre a forma como esta arquitetura funciona na prática, nem algum impacto sobre a avaliação de desempenho.

Em (Banerjee et al., 2005) é discutido o problema de escalabilidade no gerenciamento de grandes quantidades de dados de diferentes fontes. Os autores propõem o desenvolvimento de

CAPÍTULO 3. DESEMPENHO EM SOA E QOS EM WEB SERVICES 41 uma arquitetura para a descoberta de Web Services. As limitações do UDDI levam a pensar na proposta de um registro UDDI distribuído. Os autores não relatam como foi avaliada a eficácia do esquema proposto e também quais técnicas serão utilizadas para essa finalidade. Estes pontos estão abertos e não são discutidos no artigo. O registro UDDI precisa fornecer alto throughput, tempo de resposta baixo, alta disponibilidade e acesso aos dados consistentes. Uma maneira de satisfazer essas necessidades é utilizando replicação, como demonstrado no trabalho apresentado em (Sun et al., 2004).

Muitos pesquisadores investigam mecanismos para melhorar o acesso à interface UDDI para a pesquisa de Web Services. Poucos estudos, no entanto, se preocupam com o impacto do UDDI no desempenho da invocação de um Web Service, como caracterizado em (Saez et al., 2004). A questão de como invocar um Web Service com base em informações contidas no registro UDDI é considerada em (Yu e Lin, 2004). Eles mencionam que, em um ambiente real é difícil invocar dinamicamente Web Services que têm a mesma funcionalidade entre muitos existentes em um grande banco de dados de informações. Os autores propõem um framework que estende o registro

UDDIe analisa a aplicabilidade e as características deste framework, mas não se preocupa com as

questões gerais de desempenho. Em (Kumar et al., 2005) a proposta é uma abordagem generalizada para construir um registro UDDI baseado em QoS, cujo objetivo é tornar a busca de informações mais eficiente.

Em (Liu et al., 2005a) é proposto um registro UDDI orientado a domínio. Nesta proposta, um banco de dados de informação centralizada e externo é usado para armazenar os serviços não- funcionais e suas relações. O trabalho discutido em (Blake et al., 2007) propõe um método para avaliar os modos de operação em um ambiente de computação orientada a serviço. Os autores avaliaram o desempenho de algumas implementações do UDDI e incorporam os resultados de desempenho em um software de simulação. Usando esse software, foram avaliados dois modos de operação que suportam o uso do UDDI a fim de permitir a confiabilidade em um cenário de processos de negócio.

Em (Peterkin et al., 2007) é apresentado um sistema para controlar o acesso ao UDDI. A idéia é limitar a busca de informações por meio de um controle de acesso que garanta um de- sempenho adequado. Nenhuma avaliação de desempenho é discutida. Em (Liu et al., 2007b), os autores caracterizam como grafos de Web Services podem ser suportados pelo registro UDDI, acrescentando-lhe uma estrutura de dados auxiliar. Embora a conclusão do artigo mencione algu- mas experiências, nenhuma delas está associada à avaliação de desempenho. A falta de recursos adicionais que possam estar presentes no UDDI também é estudada na literatura.

O trabalho discutido em (ShaikhAli et al., 2003) propõe a implementação de um registro UDDI com algumas extensões, denominado UDDIe. Dentre as deficiências identificadas no UDDI padrão destaca-se que as páginas são baseadas em alguns atributos e não apresentam um mecanismo de atualização do Web Service armazenado. Assim, a busca de um determinado serviço é restrita aos atributos listados, podendo haver serviços que não estão mais disponíveis e com sua especifi- cação desatualizada. As soluções propostas pela implementação de UDDI estão além das páginas

42 3.4. ÍNDICES DE CARGA E DE DESEMPENHO