Os experimentos do NetLab WebLab são desenvolvidos independentes dos projetos de gerência de serviços. Isso evita que o site para o acesso aos experimentos de um WebLab “saia do ar” a cada novo processo de disponibilização e/ou manutenção de experimentos, reduz a dependência entre os projetos e o “espalhamento” de código, e simplifica o processo de distribuição de experimentos entre diferentes WebLabs. Essa solução foi alcançada com a alteração do software de gerência de uso dos experimentos do projeto GigaBOTWL.
Os clientes dos serviços de interação foram agrupados nos projetos dos experimentos. Como a co- municação utiliza Web Services, cada Web Service possui um projeto separado dos demais. De forma semelhante, cada experimento é agrupado em um único projeto, separado do projeto de gerência de uso dos experimentos. Os projetos são disponibilizados no servidor separadamente e a criação de novos experimentos é realizada com a composição de Web Services: o projeto do experimento apenas informa quais métodos e parâmetros do Web Service deseja utilizar. Caso o projeto do Web Service
Fig. 4.3: Infraestrutura do WebLab GigaBOT [6].
ainda não tenha sido implementado, o experimento ainda conseguirá ser executado, mas sem executar a ação do Web Service.
Um cliente de serviço de interação em um experimento solicita a execução de uma ou mais ações. A comunicação é estabelecida seguindo um modelo composto por três blocos principais, como ilus- trado na Fig. 4.5: bloco cliente, bloco de comunicação e bloco servidor. O bloco cliente cria o cliente da ação e utiliza uma ou mais interfaces para acessar um ou mais blocos de comunicação. O bloco
de comunicação apenas encaminha para o host destino as mensagens que recebe do host de origem.
Esse bloco desempenha o papel de servidor da requisição cliente e de cliente de uma solicitação para o bloco servidor. Para isso, o bloco de comunicação implementa uma ou mais interfaces para acessar diretamente as funções do bloco servidor e cada bloco de comunicação é específico para um bloco
servidor. O bloco servidor é responsável por processar a requisição e devolver o resultado para o bloco de comunicação associado a ele que, por sua vez, encaminha o resultado para o bloco cliente.
A arquitetura de um experimento depende de quais funcionalidades estão implementadas com a composição de serviços, como ilustrado na Fig. 4.6. Para iniciar um experimento é necessário que todos os recursos cadastrados sejam previamente inicializados o que se dá com o auxílio de uma fábrica de software instanciada em cada host. Na inicialização do experimento, o cliente da fábrica comunica-se com o Web Service FabricaRMI para que este encaminhe a requisição de criação de instâncias dos objetos que executam a função remota no recurso do laboratório. Depois disso, o cliente do serviço de interação pode interagir com o recurso através do Web Service específico associado ao objeto instanciado pela fábrica.
O protocolo SOAP é utilizado quando os componentes da arquitetura encontram-se em domínios diferentes porque esse protocolo simplifica as políticas de segurança para realizar a comunicação en- tre firewalls, proxies, gateways e demais intermediários de domínios distintos. O protocolo RMI é utilizado para a interação entre os componentes que estão no mesmo domínio para otimizar o de- sempenho da comunicação na rede interna do laboratório. Mas esse desempenho na comunicação também é otimizado com a redução das funções do Web Service que possui apenas métodos para encaminhar as informações entre a origem e o destino.
Serviços de Acesso AccessService
Base de dados Serviço de Interação
NetLabWL Serviço de Interação 1Cliente do
Serviço de Interação 1Cliente do
Objeto Servidor 2 Host remoto 1 Objeto Servidor 1 Host remoto 2 Web Service do Serviço de Interação 2 Interação 1 Web Service do Serviço de Experimento 1 <SOAP> Host Servidor <SOAP> Experimento 2 Cliente do Serviço de Interação 2 <SOAP> <HTTPS> <RMI> <RMI>
Fig. 4.4: Arquitetura Parcial dos Projetos AccessService e NetLabWL.
Bloco Cliente ComunicaçãoBloco de Bloco Servidor
Fig. 4.5: Modelo de Blocos para a Realização de Ações em Experimentos.
4.5.1 Composição de serviços em experimentos
A arquitetura da Fig. 4.6 é utilizada em diversos experimentos do NetLab WebLab: experimentos
DiffServ, configuração de NIC (Network Interface Card), tratamento de rotas, teste de conexão entre hosts, submissão de fluxos simulados e captura de dados de vídeo. Isso demonstra a praticidade
de se seguir a arquitetura para disponibilizar quaisquer tipos de experimentos. Cada Web Service está associado a um único objeto servidor que, por sua vez, pode estar associado a um ou mais objetos servidores os quais são responsáveis pela implementação das requisições do aplicativo do experimento e, por isso, podem interagir com outros objetos servidores [72].
A composição de serviços é definida nessa dissertação como um conjunto de serviços utilizados por um experimento, e é realizada como mostra a Fig. 4.7. Para isso, o aplicativo do experimento precisa possuir interfaces para acesso aos outros Web Services do laboratório. No entanto, o aplicativo e o Web Service do experimento não possuem a lógica para a realização das configurações: essa lógica é implementada apenas pelo objeto servidor instanciado no host do laboratório.
O acesso aos aplicativos fora do domínio do WebLab é realizado independente do sistema ope- racional graças à tecnologia JWS (Java Web Start) [73] [74] e não são necessários tratamentos alter- nativos das informações transmitidas porque o formato das mensagens segue o padrão SOAP. Dentro do domínio, a performance dos experimentos é otimizada porque os Web Services possuem apenas as referências para os hosts do WebLab e para os respectivos métodos nesses hosts que executam a ação
<SOAP> <RMI> da do Web Service Objeto Servidor FabricaRMI
Web Service <RMI>
Objeto Servidor <SOAP> Cliente da da FabricaRMI Cliente do Serviço de Interação
Fig. 4.6: Arquitetura dos Experimentos no NetLabWL.
Objeto Servidor Recurso 2 Objeto Servidor Recurso N Objeto Servidor Recurso 1 Objeto Servidor Recurso N Objeto Servidor Recurso 1 Aplicativo JWS <SOAP> <SOAP> <SOAP> Recurso N Web Service Web Service Recurso 2 Web Service Recurso 1 Web Server Domínio do usuário <RMI> <RMI> <RMI> Host1 Host2 Objeto Servidor Recurso 2
Fig. 4.7: Composição de Serviços no NetLab WebLab.
solicitada pelo usuário. Os Web Services fazem então o acesso direto aos métodos dos objetos servi- dores Java com o uso de RMI. Esses objetos realizam as alterações necessárias nos hosts, interagem entre si se necessário e devolvem o resultado para o Web Service que, por sua vez, apenas encaminha a resposta para o aplicativo JWS do usuário.