Finalização de Experimentos

O processo de finalização ocorre em uma das seguintes situações:

• término da aplicação JWS pelo usuário: quando o usuário finaliza remotamente a sua aplicação; • término da aplicação por meio do objeto servidor de Sessão no host servidor do laboratório: o término de um experimento também é controlado pelo laboratório com o uso de aplicações que interagem com o objeto servidor de Sessão;

• término do tempo reservado para uso do experimento: o objeto servidor de Sessão dispara o evento de finalização do experimento;

• inatividade ou exceção da experimentação: o objeto servidor de Sessão atualiza periodicamente informações sobre o tempo restante para uso de cada experimento ativo. Nesse envio, caso ocorra um timeout da confirmação da recepção, o objeto servidor de Sessão dispara o processo de finalização do experimento.

O processo de finalização solicitado pela aplicação JWS envia uma mensagem de término para o

Web Service WSSessao que encaminha a requisição para o Objeto Servidor de Sessão no host servidor

do laboratório. As demais situações são iniciadas nesse objeto. A primeira tarefa dele é realizar a operação de persistência ao armazenar na base de dados as informações de término.

Logo após o Objeto Servidor de Retaguarda é contactado para solicitar a cada um dos objetos de

retaguarda a reinicialização dos valores atribuídos aos hosts, com base nas informações armazenadas

na base de dados. Cada um desses objetos sabe como reinicializar seus respectivos objetos remotos. Feito isso, o serviço de retaguarda finaliza cada um dos objetos instanciados no host servidor.

O próximo passo é solicitar a finalização dos objetos servidores dos hosts. Para isso, o Objeto

Servidor de Sessão precisa de uma interface para informar ao WSFabricaRMI os objetos servidores de atividades que precisam ser finalizados nos hosts do laboratório.

4.9 Considerações Finais

A arquitetura do NetLab WebLab orienta a implementação de experimentos modulares com su- porte a DiffServ utilizando a base da infraestrutura do projeto GigaBOT. O próximo capítulo descreve a implementação dessa arquitetura e a validação da proposta intra-domínio.

Capítulo 5

Implementação e Resultados

Este capítulo apresenta a implementação da arquitetura DiffServ no NetLab WebLab e apresenta experimentos de geração de fluxos reais e simulados no domínio do laboratório. Os aplicativos Web de Gerência Administrativa e de Uso do NetLab WebLab são fundamentais para garantir a instanci- ação adequada de recursos físicos e lógicos para os experimentos. A implementação da arquitetura de software do WebLab possui um fraco acoplamento com a arquitetura física do laboratório e isso permite que aplicativos mais elaborados como um Bandwidth Broker para experimentos DiffServ seja implementado sem alterar a estrutura física do domínio. A implementação do BB com suporte a monitoramento e readaptação de fluxos também será descrita nesse capítulo.

As características inerentes do ambiente DiffServ permitem estudar o comportamento de diferen- tes tipos de fluxos e avaliar os resultados nos diferentes cenários oferecidos. O WebLab prioriza o desempenho da comunicação ao utilizar RMI entre os elementos da rede interna e ao simplificar os mecanismos de encaminhamento de pacotes SOAP; promove escalabilidade ao reduzir o acoplamento entre a arquitetura física e a arquitetura de software; promove a segurança no acesso às informações com o uso de serviços de acesso e utiliza arquiteturas independentes do sistema operacional.

5.1 Disponibilização de Experimentos no NetLab WebLab

Os experimentos do NetLab WebLab são disponibilizados como aplicações Web no host servidor do laboratório. Eles estão fracamente acoplados à infraestrutura de hardware porque são formados de acordo com o modelo de blocos que distribui os elementos de requisição, comunicação e interação direta com os dispositivos gerenciáveis. Apenas o último bloco interage diretamente com o host gerenciável e isso permite a manutenção distribuída dos componentes de cada bloco. Os experimentos também estão fracamente acoplados à infraestrutura dos aplicativos Web de Gerência Administrativa e de Uso do WebLab porque são desenvolvidos independentes deles.

Um experimento é formado por um conjunto de recursos físicos e lógicos. Os recursos físicos são formados pelos hosts e seus respectivos sub-recursos, como interfaces de rede, por exemplo. Os recursos lógicos são os aplicativos incluídos no bloco servidor que atuam diretamente nos hosts do laboratório. O modelo distribuído permite a criação de diversos recursos lógicos independentes do experimento. Dessa forma, um ou mais experimentos podem ser formados pela composição de diversos recursos lógicos. Da mesma forma, um experimento pode ser disponibilizado com diversos recursos físicos.

O usuário tem acesso a um experimento através do site da aplicação Web de gerência de uso do experimentos, como ilustrado na Fig. 4.2. Apenas são vistos os experimentos disponibilizados para o WebLab. Essa disponibilização ocorre no site da aplicação Web de gerência administrativa, como ilustrado na Fig. 4.2. Um experimento precisa ser cadastrado antes de ser disponibilizado para um ou

mais WebLabs. Quando o usuário clica no link do experimento, no site do laboratório, é iniciado o processo de download da aplicação com o uso da tecnologia Java Web Start [74]. O usuário deve ter uma plataforma Java Runtime Environment (JRE) [78], versão 1.2.2 ou mais recente instalada em seu

host para acessar o experimento.

O aplicativo Web do laboratório verifica as credenciais do usuário e a disponibilidade de uso do experimento baseada no prévio agendamento. A identificação do experimento é coletada a partir do

link do experimento cadastrado e as credenciais do usuário são coletadas com um serviço de acesso.

Caso as verificações retornem uma condição válida, o servlet ServletExp faz a coleta na base de dados de todos os recursos associados ao experimento. Depois, esses recursos são separados em dois grupos: recursos físicos e lógicos. Para cada recurso físico são instanciados os recursos lógicos do experimento. O critério de uso ou não desses elementos irá depender de como o experimento será utilizado. O ServletExp apenas garante que eles serão ativados pelas fábricas de objetos antes do aplicativo JWS ser iniciado remotamente. O servlet continua o seu processamento e prepara os objetos servidores de Retaguarda de acordo com a necessidade do experimento. Esses serviços irão iniciar os objetos instanciados pela fábrica ou ficarão à disposição para quaisquer outras necessidades de interação do aplicativo JWS com o servidor (por exemplo, consulta à base de dados do WebLab). Caso ocorra algum problema ou exceção em qualquer uma dessas etapas, o aplicativo não é iniciado. Para permitir o início do download o ServletExp encaminha para o arquivo iniciarExperimento.jsp do respectivo projeto do experimento apenas o nome do experimento, o usuário e os hosts, como mostrado no trecho a seguir:

String URL = "http://" + enderecoIPServidor + ":" + porta + "/" + nomeExperimento + "/iniciarExperimento.jsp?" +

"usuario=" + IDUsuario + "&hosts=";

O arquivo iniciarExperimento.jsp é um arquivo JSP do tipo JNLP (Java Network Launching Pro-

tocol) que recebe os argumentos do servlet e inicia a aplicação JWS.