Broker

As informações de qualidade de serviço são de fundamental importância para que os compo- nentes participantes da WSARCH possam se comunicar. Em geral, as informações propagadas

66 4.5. IMPLEMENTAÇÃO são dos provedores de serviços para o Broker, do UDDI para o Broker e do cliente para o Broker de serviços. A Figura 4.5 descreve as três interfaces presentes no Broker, cada uma das quais armazenando informações de QoS vindas de outros componentes da arquitetura.

Figura 4.5: Broker e Interfaces

Os provedores de serviços propagam as informações a partir dos dados coletados pelo sistema de gerenciamento que utiliza o Ganglia, como mostra a Figura 4.6.

Essas informações são atualizadas periodicamente a medida que o estado do provedor de serviços sofre modificações (CPU, memória, disco, etc). A cada nova medida programada no protótipo implementado para 2 segundos no provedor de serviços, uma requisição contendo as in- formações é enviada ao UDDI Server que as armazena numa estrutura de dados em que constam a URL do provedor, se ele está ativo/inativo, e quais as métricas, ou associação de métricas que foram coletadas. Essas informações são utilizadas pelo Broker da WSARCH para a escolha dos serviços candidatos ao atendimento da solicitação do cliente do serviço. A Figura 4.6 mostra ainda a interação do UDDI Server, Broker e clientes com o LogServer. O LogServer armazena métricas referentes ao tempo de resposta, variação do índice de carga do provedor de serviços, tempo de sobrecarga da arquitetura, dentre outros.

CAPÍTULO 4. A ARQUITETURA WSARCH 67

Ordem dos Estágios: 1 a 7 1 3 5 2 6 4 7 mysql-client_insert_data (data) Legenda

Atualização de info de QoS (2s) Log-Interações

Broker - UDDI Log Info QoS (1s) Broker - Provedor Cliente - Broker WSARCH Connecting Applications LOG Server UDDI Server GMOND MESTRE Ganglia UDDI P1 GMOND ESCRAVO Serviços P2Serviços GMOND ESCRAVO PnServiços GMOND ESCRAVO Broker Ganglia Broker calcQoS mysql-client_insert_data (data) Clientes Iptables

Figura 4.6: WSARCH - Informações de QoS Algoritmos Implementados

O Broker da arquitetura WSARCH funciona como um agente roteador/escalonador de men- sagens SOAP recebidas de Web Services clientes. Todas as requisições são analisadas antes de serem encaminhadas para os respectivos provedores de serviços que podem atender tais requi- sições. Os critérios de roteamento/escalonamento de mensagens são baseados em algoritmos implementados no Broker, os quais possuem características distintas tais como: selecionar com base no conteúdo da mensagem SOAP, com base em alguma informação do cabeçalho, com base em classes de aplicações, etc. No protótipo inicial do Broker, dois algoritmos são implementa- dos: o primeiro é o Algoritmo de Classificação que apenas seleciona os provedores de serviços com base em um índice de desempenho (este é composto de um índice de CPU junta- mente com um índice de memória do provedor de serviços). O cálculo deste índice de desem- penho é feito por meio de uma adaptação do algoritmo proposto por (Branco, 2004). A técnica proposta por (Branco, 2004) utiliza Distância Euclidiana para calcular o índice desempenho que varia de 0 a 1. No caso da arquitetura WSARCH, o cálculo do índice é utilizado para classificar os clientes nas classes Gold, Silver e Bronze. Os clientes da classe Gold serão atendidos quando o índice de desempenho estiver mais próximo de 0 (zero). Para os clientes da classe Bronze o índice de desempenho deve ficar próximo de 1 (um) sinalizando para o pior recurso a ser escol- hido. O índice de desempenho mais próximo da média é escolhido para a classificação dos clientes da classe Silver. Um problema do algoritmo de classificação é que mantidas as mesmas pro-

68 4.5. IMPLEMENTAÇÃO porções de chegada de requisições para clientes Gold e Bronze, o processamento das requisições dos clientes da classe Gold pode sofrer interferências como será discutido no capítulo de validação da arquitetura WSARCH. O segundo algoritmo, denominado Algoritmo de Reserva de

Recursosé uma variante do primeiro, cujo objetivo é reservar uma quantidade de recursos para

as classes de clientes. Entende-se como classe cliente: Gold, Silver, Bronze e para a classe de serviço destaca-se: CPU-Bound, Memory-Bound, etc. Assim, os clientes terão suas requisições processadas de acordo com a quantidade de provedores disponíveis para cada classe de cliente. Ou seja, os clientes da classe Gold terão mais provedores disponíveis que os clientes da classe

Silver e estes por sua vez mais provedores disponíveis que os clientes da classe Bronze. Dentre

os provedores alocados para tal classe, escolhe-se o melhor provedor de acordo com o índide de desempenho. Vale ressaltar que os dois algoritmos propostos neste trabalho visam a validação e o funcionamento da arquitetura WSARCH. No entanto, a estrutura de software do Broker viabiliza a construção de novos algoritmos de roteamento/escalonamento de mensagens mais eficazes, os quais serão abordados em trabalhos futuros.

4.5.4 Registro UDDI

O registro UDDI possui a finalidade de armazenar informações funcionais sobre os Web Ser-

vicesimplantados em um provedor de serviços. Além dessa finalidade, para os propósitos deste

trabalho de doutorado, o registro UDDI foi alterado para também contemplar informações de QoS dos provedores de serviços. Nesse sentido, no momento em que o Broker recebe uma requisição do cliente, deve consultar o registro UDDI e verificar os provedores de serviços disponíveis (iden- tificado por suas URLs) e também a qualidade de serviço por eles oferecidas. O atributo de QoS utilizado para a validação foi o índice de desempenho, porém outros atributos tais como: taxa de ocupação de CPU, tempo de resposta, satisfação do cliente, etc., possam ser utilizados. Em re- sumo, o UDDI deve possuir uma tabela em que constam as informações apresentadas na Tabela 4.2.

Tabela 4.2: Informações de QoS armazenadas no registro UDDI

URL do Provedor Métrica

http://192.168.2.20:8080/services/ Índice de Desempenho http://192.168.2.21:8080/services/ Índice de Desempenho

. .

. .

. .

A métrica listada na Tabela 4.2 é apenas uma métrica específica, o que não impede de se uti- lizar uma combinação entre outras métricas para a construção de um novo índice. Isso é possível, uma vez que o Ganglia fornece diversas informações sobre o estado do provedor de Web Services, facilitando assim a escolha da utilização da métrica. É importante mencionar que a extensão do

CAPÍTULO 4. A ARQUITETURA WSARCH 69

UDDI para armazenar informações não-funcionais não foi uma tarefa trivial. Foi necessário al-

terar parte da estrutura de dados e de armazenamento do UDDI para que as informações dinâmicas provenientes dos provedores pudessem ser utilizadas pelo Broker da WSARCH. Para os propósi- tos da arquitetura foi utilizada a primeira versão considerando a especificação 2.0 do UDDI. A versão mais recente da especificação do UDDI diferente daquela utilizada na WSARCH (JUDDI da Apache Software Foundation), permite que o acesso aos dados seja feito de forma menos dis- pendiosa uma vez que ela utiliza Hibernate para garantir persistência de dados. A nova versão do

jUDDI deve ser implantada nas próximas fases de desenvolvimento da arquitetura WSARCH, o

que deve incluir ajustes e otimizações no código.