Smart Proxies para Invocação de Serviços Web Replicados

Smart Proxies para Invocação de Serviços Web Replicados José Geraldo Ribeiro Júnior (CEFET-MG / PUC Minas) Orientador: Prof. Marco Túlio Valente (PUC Minas) Fevereiro 2007

Apresentação Motivação Proposta Trabalhos relacionados Sistema SmartWS Experimentos Contribuições Conclusão Trabalhos Futuros 2/64

Motivação Potencial de Serviços Web para tornar realidade, idéias e princípios propostos em Computação Orientada por Serviços (SOC) Características do ambiente Flutuações de largura de banda Alto número de falhas Elevadas latências Desafios na busca de QoS na Internet Desempenho Disponibilidade 3/64

Replicação Vantagem Incrementa o desempenho e a disponibilidade de aplicações distribuídas Dificuldades Localização da réplica Diferenças entre réplicas 4/64

Solução - Middleware Vantagem Apoio ao desenvolvimento de clientes de serviços Web evitando o entrelaçamento entre o código funcional e não-funcional Considerar Características do cliente Latência de rede Carga de processamento nos servidores Dificuldade Atuais plataformas de middleware não disponibilizam suporte a replicação 5/64

Proposta Uso de Smart Proxies Extensão que inclui a especificação e geração de proxies especiais, destinados a encapsular as tarefas relacionadas com a seleção da melhor réplica de um serviço Extensão proposta - SmartWS Recursos definição de interfaces abstratas definição de políticas de seleção definição de adaptadores de interface definição de sessões de uso definição de protocolo de invocação de métodos 6/64

Trabalhos relacionados Políticas para seleção transparente de serviços Web replicados (implementadas por clientes) Framework RWS Implementa cinco políticas para seleção de servidores Web replicados: Aleatória (Randômica), Paralela, HTTPing, Melhor Última e Melhor Mediana Apresenta uma avaliação empírica das políticas implementadas, utilizando serviços Web reais espalhados em três continentes 7/64

Análise crítica - RWS Deixa a cargo da aplicação cliente a definição da política de seleção de réplica Não apresenta diretrizes claras e objetivas sobre os ambientes de rede adequados a cada uma das políticas propostas Não considera o fato dos servidores Web possuírem picos distintos de processamento e tráfego de rede de acordo com os fuso horários O cenário utilizado apresentava poucas falhas e por isso ignorou-se o tratamento de falhas Conseqüência: não foi possível detectar o problema de adaptação da política via Melhor Mediana 8/64

Contribuições em relação a RWS Proposta da política PBM (Parallel Best Median) para seleção de servidores Diretrizes claras e objetivas sobre os ambientes de rede adequados a cada uma das políticas de seleção de réplicas propostas Suporte a adaptadores de interfaces Suporte ao estabelecimento de sessões de uso de um servidor Suporte a protocolos de invocação de métodos Geração automática dos smart proxies, a partir de uma linguagem de especificação de alto nível 9/64

SmartWS Políticas de seleção de réplicas Seleção Estática Seleção Aleatória Seleção Paralela Seleção via Melhor Mediana Seleção PBM (Parallel Best Median) 10/64

Política de seleção - Estática Funcionamento Programador define, estaticamente, a ordem em que as réplicas serão invocadas (em caso de falhas) A política falha quando todas as réplicas falham Aplicação Tempos de resposta previamente conhecidos Prioridade de acesso a determinada réplica Sintaxe de uso em SmartWS policy service1 > service2 >... > servicen 11/64

Política de seleção - Aleatória Funcionamento Escolhe-se aleatoriamente a réplica que será invocada pelo cliente A política falha quando todas as réplicas falham Aplicação Servidores com características e tempos de resposta semelhantes Sintaxe de uso em SmartWS policy service1? service2?...? servicen 12/64

Política de seleção - Paralela Funcionamento Invoca-se concorrentemente todas as réplicas conhecidas de um serviço Web A política falha quando todas as réplicas falham Aplicação Tempos de resposta desconhecidos É permitido invocar todas as réplicas simultaneamente Desvantagem: overhead gerado Sintaxe de uso em SmartWS policy service1 service2... servicen 13/64

Política de seleção Melhor Mediana Funcionamento O serviço invocado é aquele que possui a menor mediana dentre as k últimas invocações A política falha quando todas as réplicas falham Aplicação Tempos de resposta desconhecidos Pequena variação nos tempos de resposta Poucas falhas Sintaxe de uso em SmartWS policy bestmedian(service1, service2,..., servicen) 14/64

Problemas detectados Política não se adapta a grandes variações no tempo de resposta e falhas Conseqüência: invocação de um serviço que se recuperou (após uma seqüência ruim de invocações) depende da piora de todos os outros Uso de buffer grande Conseqüência: tamanho do buffer está diretamente relacionado ao tempo necessário para adaptação 15/64

Exemplo de uso - Buffer com 13 posições Política utilizada - via Melhor Mediana. Mediana dos servidores: A = 400ms, B = 500ms, C = 650ms, D = 580ms Servidor A Posição do Situação 1 9 invocações Buffer (ms) depois (ms) Mediana 1 400 400 400 2 300 300 350 3 350 350 350 4 340 340 345 5 390 390 350 6 400 400 370 7 380 380 380 8 340 340 365 9 370 370 370 10-10000 375 11-10000 380 12-10000 385 13-10000 390 14-10000 395 15-10000 400 16-10000 400 17-10000 400 18-10000 5200 19 - - - 20 - - - 16/64

Princípios básicos para definição da política PBM (Parallel Best Median) Resolver o problema do overhead gerado pela política Paralela Proposta: definir um limite superior para o paralelismo, baseado nas características da rede Utilizar outros recursos além da escolha da melhor mediana (cenário que apresente alterações bruscas nos tempos de resposta ou falhas) Proposta: é imprescindível, independentemente do critério para seleção da réplica, renovar os tempos de todos os servidores periodicamente, para obter um novo panorama do cenário 17/64

Política de seleção PBM (Parallel Best Median) Combina aspectos positivos das políticas de seleção Paralela e via Melhor Mediana A cada ciclo com n invocações, as t primeiras invocações funcionam de forma idêntica à política Paralela Objetivo Atualizar o tempo de resposta de todos os servidores no início de cada ciclo Permitir que servidores voltem a ser selecionados Obs.: t deve ser igual ao b, onde b é o tamanho do buffer 2 18/64

Política de seleção PBM (Parallel Best Median) Nas próximas invocações do ciclo, invoca-se de forma concorrente: o serviço com a menor mediana m os serviços cujas medianas são menores ou iguais a m*k (limitados a um máximo de p servidores (k > 0, p r)) k - grau de paralelismo, p - limite superior para este paralelismo e r - total de réplicas Aplicação Tempos de resposta desconhecidos Variação nos tempos de resposta Falhas 19/64

Política de seleção PBM (Parallel Best Median) A política falha quando todas as réplicas falham Sintaxe de uso em SmartWS policy pbm(1.2, 2, 10, 3, service1, service2,.., servicen) Obs.: respectivamente: k, p, n, t 20/64

Composição de políticas Exemplo 1 policy (service1 service2 service3) > service4 Exemplo 2 policy pbm(1.2, 2, 10, 3, service1, service2, service3) > (service4 service5) 21/64

Adaptadores de interface Possíveis diferenças entre interfaces Nome dos métodos Número, tipo e ordem dos parâmetros de entrada SmartWS se vale dos conceitos de interfaces abstratas e adaptadores de interfaces Objetivo: compatibilizar a interface abstrata de um cliente com as interfaces concretas das réplicas que este cliente consulta Um objeto adaptador deve implementar a interface abstrata e possuir uma referência para o serviço que está sendo adaptado 22/64

Sessão de uso As operações opstart e opend delimitam uma sessão Desabilitam e habilitam o emprego de uma política de seleção de réplicas Aplicação Operação altera o estado de uma réplica e exige que as operações seguintes sejam processadas sobre o estado alterado Exemplo - Sistema de comércio eletrônico: operações como pesquisaproduto, login e logout 23/64

Protocolo de Invocação Define um protocolo com seqüências válidas de mensagens enviadas aos servidores remotos por meio de um AFD Cada transição representa uma chamada ao método da interface abstrata (se o estado atual não possui uma transição correspondente ao método, a referida chamada é inválida) 24/64

Estudo de caso Método Invocado pesqproduto pesqproduto additemcarrinho login additemcarrinho listacarrinho efetuacompra logout pesqproduto pesqproduto Servidor 1 3-2 2 2 2 2 3 4 Estado q0 q0 Msg Erro q1 q1 q1 q1 q0 q0 q0 25/64

Timeout Tempo máximo no qual o cliente está disposto a esperar por uma resposta das réplicas Tempo considerado a partir da invocação até o momento em que a aplicação cliente recebe a resposta Timeout em sessões de uso No caso de perda da conexão durante uma sessão de uso é possível definir: número de tentativas para restabelecer a sessão intervalo entre cada tentativa 26/64

Interface de Programação SmartWS Arquitetura Geração Funcionamento Linguagem de especificação 27/64

Arquitetura do Sistema 28/64

Processo de geração de SmartWS 29/64

Funcionamento de SmartWS (política PBM) 30/64

Linguagem de especificação (sintaxe) interface name= EchoInt webservice alias= service1 uri= http://200.154.100.23/echo.asmx?wsdl adapter= terra1 webservice alias= service2 uri= http://200.154.100.232/echo.asmx?wsdl adapter= terra2 webservice... buffer size= 5 refresh= 20 timeout= 20000 policy pbm(1.2, 2, 10, 3, service1, service2,..., servicen ) end 31/64

Linguagem de especificação (sintaxe)... buffer... session begin= login finish= logout retry= 5 interval= 3000 protocol methods= pesqproduto, login, logout, additemcarrinho, remitemcarrinho, efetuacompra, limpacarrinho, listacarrinho states= q0, q1 transitions= q0, pesqproduto, q0; q0, login, q1; q1, additemcarrinho remitemcarrinho..., q1; q1, logout, q0; timeout = 20000 policy... end 32/64

Exemplo de implementação de uma aplicação cliente de SmartWS public class cliente { public static void main(string[] args){ //Instancia o objeto do tipo PROXY convtemp teste = PROXY.getInstance(); for(int x=1; x<=100; x++) { try { teste.ctof(100); } catch (WSFailureInvocation e) {... } catch (ProtocolFailure e) {... } catch (Exception e) {... } } } } 33/64

Resultados Experimentais Cenário 1 4 experimentos curtos 100 invocações (cada política) 3 servidores utilizados em cada experimento Políticas utilizadas: Estática, Aleatória, Paralela, via Melhor Mediana e PBM Serviço utilizado conversão de temperatura Cenário 2 3 experimentos de longa duração Cada experimento 4 dias (segunda a quinta-feira) 24h por dia 6 servidores utilizados Políticas utilizadas: Aleatória, Paralela, via Melhor Mediana e 2 variações da política PBM Serviço utilizado Echo (mensagens de 8 KB, 4 KB e 1 KB) 34/64

Resultados Experimentais Experimento 1 (Cenário 1) Foram utilizados 3 servidores (WebserviceX, DeveloperDays, local) 35/64

Resultados Experimentais Experimento 2 (Cenário 1) Foram utilizados 3 servidores locais (iniciados sem nenhuma carga extra de processamento) 36/64

Resultados Experimentais Experimento 2 (Cenário 1) Distribuição de cargas 37/64

Resultados Experimentais Experimento 3 (Cenário 1) Foram utilizados 3 servidores remotos (WebserviceX, DeveloperDays, CEFET-MG) O tempo de resposta dos servidores variava de forma considerável Servidores apresentavam sempre uma baixa taxa de falhas 38/64

Resultados Experimentais 39/64

Resultados Experimentais Experimento 4 (Cenário 1) Foram utilizados 3 servidores (WebserviceX, DeveloperDays, local (indisponível nas primeiras 50 invocações)) 40/64

Resultados Experimentais Serviços utilizados nos Experimentos 5, 6 e 7 (Cenário 2) WS 1 - http://200.176.0.129/echo.asmx?wsdl (Terra) WS 2 - http://200.154.100.232/echo.asmx?wsdl (Terra) WS 3 - http://201.87.225.6/echo.asmx?wsdl (Empresa de BH) WS 4 - http://200.214.173.151/mpvrisk/echo.asmx?wsdl (Empresa de BH) WS 5 - http://200.131.41.132:8180/axis/echo.jws?wsdl (CEFET - MG) WS 6 - http://143.106.7.180/axis/echo.jws?wsdl (Unicamp) 42/64

Resultados Experimentais Configurações da política PBM nos Experimentos 5, 6 e 7 (Cenário 2) Argumentos n t k p PBM 16 3 1,2 1 PBM2 16 3 1,2 2 43/64

Resultados Experimentais Semana 1ª 2ª 3ª Registro de falhas durante os Experimentos do Cenário 2 Mensagens 8 KB 4 KB 1 KB Experimento 5 6 7 Número de Invocações 30075 26010 38510 Timeouts 424 (1,4%) 887 (3,4%) 1382 (3,6%) Outras falhas 66 (0,2%) 41 (0,2%) 29 (0,1%) Obs.: Outras falhas - falhas na rede local, no acesso à Internet ou nos servidores consultados 44/64

Resultados Experimentais Experimento 5 (Cenário 2) Experimentos com 8 KB 45/64

Resultados Experimentais Somatório dos tempos de invocação - Mensagens de 8 KB 57/64

Contribuições Proposta de uma nova política de seleção chamada PBM (Parallel Best Median) Implementação de um protótipo em Java do sistema SmartWS Utiliza o conceito de smart proxies Suporta as principais políticas de seleção de servidores replicados, incluindo a política proposta PBM Adaptação de interfaces remotas Estabelecimento de sessões de uso Definição de protocolos de invocação Smart proxies são gerados automaticamente a partir de uma linguagem de especificação de alto nível Validação do protótipo proposto, por meio de experimentos Definição de diretrizes que permitem a um programador de clientes de serviços Web optar pela política mais adequada a sua aplicação 60/64

Conclusão Diretrizes para escolha de políticas de seleção de réplicas Política Estática Aleatória Mediana Ambiente Computacional Recomendada quando se tem servidores com tempos de resposta conhecidos a priori, estáveis e diferentes entre si (Experimento 1) Recomendada quando se tem servidores com tempos de resposta conhecidos a priori, estáveis e semelhantes entre si (Experimento 2) Recomendada quando se tem servidores desconhecidos a priori, mas que apresentam pequenas variações nos tempos de resposta. Não recomendada para ambientes instáveis, como a Internet (Experimentos 3, 5, 6 e 7) 61/64

Conclusão Política Paralela PBM Ambiente Computacional Recomendada quando se tem servidores com tempos de resposta desconhecidos ou que variam ao longo do tempo, que falham com freqüência considerável e em situações onde é permitido invocar todas as réplicas simultaneamente. Recomendado somente quando se utiliza um tamanho de mensagem que gere um overhead suportado pela rede (Experimentos 6 e 7) Recomendada quando se tem servidores com tempos de resposta desconhecidos ou que variam ao longo do tempo, que falham com freqüência considerável e onde o tamanho da mensagem não é previamente conhecido. Recomendada para ambientes como a Internet (Experimentos 4, 5, 6 e 7) 62/64

Trabalhos Futuros Permitir que as configurações da política PBM sejam definidas em tempo de execução Definir, por exemplo, um tamanho de ciclo maior ou menor, como mais ou menos invocações em paralelo Desenvolver um mecanismo para monitoramento e análise dos dados históricos, com o objetivo de prever mudanças de comportamento no ambiente Sugestão - utilizar técnicas de Inteligência Artificial como, por exemplo, Redes Neurais Fazer um estudo para definir o limite suportado com mensagens de tamanho x em uma rede com largura de banda y, acessando em paralelo z servidores Web 63/64

Trabalhos Futuros Permitir, em tempo de execução, uma combinação das políticas suportadas por SmartWS, ou mesmo alteração entre elas Definir em SmartWS a utilização de buffers diferentes para cada método, ou classes de métodos, de um servidor 64/64

Smart Proxies para Invocação de Serviços Web Replicados José Geraldo Ribeiro Júnior (CEFET-MG / PUC Minas) Orientador: Prof. Marco Túlio Valente (PUC Minas) Fevereiro 2007