PUC Projeto Final de Programação Mecanismo para Criação e Gerenciamento de Grupos no Middleware de Comunicação do ContextNet Rafael Oliveira Vasconcelos Professor Orientador: Markus Endler Professor Coordenador: Arndt von Staa Departamento de Informática PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO RUA MARQUÊS DE SÃO VICENTE, 225 - CEP 22453-900 RIO DE JANEIRO - BRASIL
28
Embed
Projeto Final de Programação - inf.puc-rio.brrvasconcelos/Projeto Final/Documentação... · O objetivo geral deste projeto final de programação foi alterar a modo como os grupos
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
PUC
Projeto Final de Programação
Mecanismo para Criação e Gerenciamento de Grupos no Middleware de Comunicação do
ContextNet
Rafael Oliveira Vasconcelos
Professor Orientador:
Markus Endler
Professor Coordenador:
Arndt von Staa
Departamento de Informática
PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO
O trabalho proposto faz parte do projeto ContextNet [1] desenvolvido no LAC (Laboratory for Advanced Collaboration). Este projeto tem como objetivo desenvolver serviços de distribuição de informações de contexto e de raciocínio autônomo para colaboração pervasiva em sistemas móveis de larga escala com suporte a monitoramento, comunicação e coordenação das atividades dos nós móveis em tempo real. O ContextNet tem como foco principal o desenvolvimento de tecnologias de middleware para distribuição escalável das informações de contexto entre centenas de milhares de nós produtores e consumidores de conteúdo, como também técnicas de raciocínio inerentemente distribuídas e capazes de detectar situações compostas de contexto – resultado do agrupamento de situações primárias – que sejam relevantes para as aplicações. Como exemplo, é possível citar padrões de movimentação entre os nós e detecção da área de cobertura de equipes de resgate.
Dentre as diversas camadas do ContextNet, este trabalho desenvolveu um novo mecanismo de criação e gerenciamento de grupos para o núcleo da camada de distribuição de dados SDDL [2] [3] [4] [5]. Esta camada conecta nós estacionários DDS [6] em uma rede cabeada (denominado de núcleo – core – do SDDL) a nós móveis usando conexão sem fio. Dentro do core SDDL a comunicação entre os nós é realizada através do padrão DDS e cada nó tem uma função específica (são exemplos definição de grupos, monitoramento e controle dos nós móveis, agregação de dados e gerência de mensagens não entregues aos nós móveis). A Error! Reference source not found. ilustra a arquitetura do SDDL aplicada no projeto de rastreamento de veículos InfoPAE Móvel desenvolvido em parceria com o laboratório Tecgraf.
A camada SDDL utiliza como implementação do padrão DDS o middleware
CoreDX DDS [7].
Figura 1. Arquitetura do SDDL
2
O objetivo geral deste projeto final de programação foi alterar a modo como os grupos eram criados e gerenciados para flexibilizar a utilização da camada SDDL.
Os objetivos do novo modelo foram:
Permitir a criação de grupos baseado em informações de contexto produzidas pelos nós móveis
Permitir a criação de grupos explícitos, ou seja, grupos criados arbitrariamente pelo administrador do sistema.
Para atender os objetivos citados, foram considerados os seguintes requisitos:
Possibilitar que a lógica da definição dos grupos pudesse ser facilmente alterada;
Possibilitar a inserção agentes definidores de grupos (GroupDefiner) com lógicas diferentes na arquitetura do SDDL, ou seja, permitir que houvesse GroupDefiners com implementações diferentes para a definição dos grupos;
Criar uma solução de baixo custo computacional.
Para permitir que a lógica da definição dos grupos pudesse ser facilmente alterada, a lógica da definição dos grupos é implementada como um módulo (Group Selection Module) que o GroupDefiner utiliza, desta forma o GroupDefiner fica genérico e permite que o desenvolvedor implemente um módulo contendo apenas a lógica de como os nós móveis devem ser agrupados.
Cada módulo de seleção de grupo possui um identificador único que é utilizado como chave composta do grupo, o que possibilita que outro módulo funcione na arquitetura SDDL sem o perigo de conflitos de identificadores.
Por fim, é mostrado em [5] que o modelo atual dos grupos é mais performático que o modelo anterior e que a nova solução apresenta baixo custo computacional. Os experimentos realizados mostram que em menos de 20 milissegundos após o recebimento do dado de contexto produzido pelo nó móvel, a infraestrutura do SDDL é capaz de atualizar os grupos que o nó móvel pertence.
A alteração da criação e gerenciamento dos grupos impactou em três outros serviços do SDDL além do GroupDefiner: (i) Gateway, (ii) Mobile Temporary Disconnection Service (MTD) e (iii) Points of Attachment-Manager (PoA-Manager). Um novo GroupDefiner foi projetado e implementado, enquanto os demais serviços foram adaptados para trabalharem com o novo modelo de grupos. Nas próximas seções são apresentados os projetos de cada um destes serviços.
3
Figura 2. Casos de uso da camada SDDL
A Figura 2 mostra os casos de uso da camada SDDL aplicada ao InfoPAE Móvel. Atualmente toda a interação do usuário móvel com o sistema ou supervisor é generalizada para o envio/recebimento de mensagens.
Figura 3. Organização dos dados trafegados no núcleo do SDDL
A Figura 3 mostra a organização dos tópicos que são trafegados dentro do núcleo do SDDL. A Figura 4 mostra os dados que são trocados entre os nós móveis e a arquitetura.
4
Figura 4. Organização dos dados trocados entre o nó móvel e o núcleo do SDDL
2. GroupDefiner
Este trabalho de Projeto Final de Programação desenvolveu um GroupDefiner totalmente novo, o que possibilitou a criação de pequenos módulos internos, melhor documentação e legibilidade do código.
A Figura 5 mostra uma visão de alto nível do GroupDefiner e suas interações com o núcleo do SDDL. O GroupDefiner se comunica apenas com o Gateway, que é quem recebe e repassa as informações de contexto produzidas pelos nós móveis.
5
Figura 5. Arquitetura de alto nível do GroupDefiner
A Figura 6 exibe a arquitetura interna do GroupDefiner. Ele possui dois módulos distintos, o Group Selection Module e o Group Membership G-Diff Message. O Group Selection Module é contém toda a lógica utilizada na definição dos grupos. É ele quem efetivamente processa as informações. Este módulo é implementado pelo desenvolvedor da aplicação, conhecedor da lógica de negócio, e deve ser passado no momento da inicialização.
Já o Group Membership G-Diff Message é responsável analisar a diferença sofrida nos grupos que o nó móvel pertence e gerar a G-Diff message. Resumidamente, esta mensagem contém os grupos que foram adicionados ou removidos do nó móvel. Caso não haja mudança, não é produzida a mensagem.
O GroupDefiner fica então responsável apenas por receber as mensagens de contexto e enviar a mensagem G-Diff para o núcleo do SDDL. O GroupDefiner conta ainda com um módulo chamado InfoPAE DDS Manager, que é responsável por gerenciar o uso do CoreDX DDS, o que facilita o seu uso por parte aplicação.
Figura 6. Arquitetura interna do GroupDefiner
Os diagramas de classe do GroupDefiner são mostrados na Figura 7.
6
Figura 7. Diagramas de classe do GroupDefiner
A organização dos dados manipulados pelo GroupDefiner são exibidos na Figura 8.
7
Figura 8. Organização dos dados usados pelo GroupDefiner
3. PoA-Manager
O PoA-Manager (Points of Attachment-Manager) é responsável por balancear a carga dos Gateways. Ele faz a análise da carga de cada Gateway e caso haja um desbalanceamento, manda uma mensagem (PoA-Object) para um conjunto de nós móveis informando que eles devem se conectar a outro Gateway (handover mandatório). É também o PoA-Manager encarregado de informar aos nós móveis quais são os Gateways disponíveis na arquitetura.
Este trabalho apenas adaptou o PoA-Manager para trabalhar com o novo modelo de grupos. Optou-se por ser o menos intrusivo possível no código. Por este motivo, não houve muito esforço na engenharia do PoA-Manager, entretanto toda a documentação foi realizada neste projeto final.
A Figura 9 mostra uma visão de alto nível do PoA-Manager e suas interações com o núcleo do SDDL. Ele se comunica apenas com o Gateway, que é quem recebe e repassa as informações de contexto produzidas pelos nós móveis e as mensagens para os nós móveis contendo o PoA-Object.
8
Figura 9. Arquitetura de alto nível do PoA-Manager
A Figura 10 exibe os módulos do PoA-Manager. Além do InfoPAE DDS Manager, comum a todos os nós do núcleo SDDL, o PoA-Manager possui o Load Report Analyzer e Planning Executor.
O Load Report Analyzer é o módulo responsável por analisar a carga de todos os Gateways e definir quantos nós móveis devem ficar conectados em cada Gateway. Já o Planning Executor é encarregado de escolher quais nós móveis sofrerão um handover mandatório, qual o novo Gateway de cada um deles e de criar as mensagens contendo PoA-Object.
Figura 10. Arquitetura interna do PoA-Manager
Os diagramas de classe do PoA-Manager são mostrados em Figura 11.
9
Figura 11. Diagramas de classe do PoA-Manager
A organização dos dados manipulados pelo PoA-Manager é exibida na Figura 12.
Figura 12. Organização dos dados usados pelo PoA-Manager
10
4. Gateway
Responsável por manter a conexão dos veículos com o domínio DDS, um gateway pode receber e manter múltiplas conexões MR-UDP. Ele é responsável por conectar os nós móveis ao núcleo do SDDL. O Gateway é capaz de enviar mensagens através de unicast, groupcast ou broadcast. Por utilizar o protocolo MR-UDP para a comunicação com os nó móveis e também fazer parte do domínio DDS (núcleo do SDDL), o Gateway é considerado um tipo de broker. Este serviço é quem faz a comunicação do núcleo com o mundo exterior.
Foram alteradas as formas de armazenamento, gerenciamento e comunicação de grupos no Gateway, renomeados métodos e variáveis e realizada toda a documentação do código.
Figura 13. Arquitetura de alto nível do Gateway
A Figura 13 mostra uma visão de alto nível do Gateway e suas interações com o núcleo do SDDL. Ele se comunica com todos os outros e é considerado o elemento mais complexo do SDDL.
A Figura 14 ilustra a arquitetura interna do Gateway. Ele possui 4 módulos distintos: (i) Load Monitor, (ii) Pong Manager, (iii) MR-UDP e (iv) InfoPAE DDS Manager. O primeiro módulo é responsável por monitorar a carga do Gateway e periodicamente fazer o envio da sua carga para o PoA-Manager. O segundo módulo é responsável por gerenciar as respostas de um pacote do tipo Ping. Quando, por exemplo, é enviado um pacote Ping para todos os nós móveis, o Gateway espera a resposta de todos os nós móveis a ele conectados para enviar um único pacote Pong (resposta de um pacote Ping) ao domínio. Isto aumenta o desempenho geral da arquitetura e facilita o desenvolvimento das aplicações, pois estas já recebem o dado sumarizado do Gateway. O MR-UDP é responsável por gerenciar o protocolo utilizado para a comunicação com os nós móveis. O ultimo módulo, InfoPAE DDS Manager, já foi explicado nas seções anteriores.
11
Figura 14. Arquitetura interna do Gateway
Figura 15. Organização dos dados usados pelo Gateway
Os dados manipulados pelo Gateway são mostrados em Figura 15. Os diagramas de classe do Gateway são exibidos na Figura 16.
12
Figura 16. Diagramas de classe do Gateway
5. MTD Service
O Mobile Temporary Disconnection Service (MTD Service) é o serviço responsável armazenar as mensagens que por algum motive não puderam ser enviadas para os nós móveis. Em uma situação onde o nó móvel perde sua conexão e após uma hora volta a se comunicar com algum Gateway, todas as mensagens que deveriam ser entregues a este nó móvel serão enviadas no momento da reconexão. Quando o Gateway não consegue fazer o envio de alguma mensagem, ele avisa ao domínio qual foi a
13
mensagem, deste modo o MTD Service armazena estas mensagens. Após uma conexão do nó móvel, o Gateway também notifica o domínio sobre este evento, o qual é recebido pelo MTD Service. O MTD é o serviço mais simples da camada SDDL.
Não foi objetivo deste projeto aplicar uma reengenharia no MTD Service, o esforço foi empregado para fazer as alterações necessárias e sua devida documentação.
A Figura 17 mostra uma visão de alto nível do MTD Service e suas interações com o Gateway, único elemento que o MTD Service tem comunicação.
Figura 17. Arquitetura de alto nível do MTD Service
Figura 18. Arquitetura interna do MTD Service
Por ser o elemento mais simples, o MTD não possui módulos além do InfoPAE DDS Manager, como exibido na Figura 18. Os diagramas de classe do MTD Service são exibidos na Figura 19.
14
Figura 19. Diagramas de classe do MTD Service
A organização dos dados manipulados pelo MTD Service é exibida na Figura 20.
15
Figura 20. Organização dos dados usados pelo MTD Service
6. Roteiro de Testes
Por ser uma implementação totalmente nova do GroupDefiner, este foi o elemento mais testado por este projeto final. Foram realizados testes de caixa branca, preta, testes unitários e automatizados. Por ser uma arquitetura distribuída de comunicação, houve uma maior dificuldade na criação de testes unitários e automatizados. Outro fator que dificultou a realização dos testes foi a natureza paralela e assíncrona do GroupDefiner. Alguns eventos são disparados assincronamente e processados paralelamente, o que algumas vezes inviabiliza a realização de um teste unitário automatizado.
Atualmente a nova implementação já está sendo utilizada e não há o conhecimento de bugs. Os resultados de desempenho foram publicados em [5] e submetidos para o “26th International Symposium on Distributed Computing (DISC)”. Outros testes de desempenho foram realizados em [3] e submetidos para a “ACM/IFIP/USENIX 13th International Conference on Middleware”, entretanto não foram específicos para os serviços mencionados por este projeto final.
Foram realizados testes unitários automatizados nos seguintes métodos do módulo Group Membership G-Diff Message: GetGroupCollection, AddAllGroups e GetGDiffMessage. Também foi realizado um teste automatizado que produzia informações de contexto e verificava a corretude da resposta (mensagem G-Diff criado), quando aplicado. A Figura 21 contém os logs produzidos pelos testes automatizados.
16
Figura 21. Log gerado pelos testes automatizados do GroupDefiner
O MTD Service foi testado com técnicas de caixa branca e preta, além de testes automatizados. Por ser um serviço simples, poucos foram os casos de testes realizados. O teste automatizado consistiu em simular o aviso perda de mensagens e de conexão dos nós móveis a fim de garantir que todas as mensagens foram entregues aos devidos nós. O log dos testes é mostrando na Figura 22.
Figura 22. Log gerado pelos testes automatizados do MTD Service
O PoA-Manager, por ser um serviço de balanceamento de carga, raramente produz algum dado. Na maior parte do tempo este serviço fica recebendo os dados sobre a carga dos Gateways e quando ele detecta um desbalanceamento, pode enviar PoA Objects para os nós móveis. Não há como saber de antemão quais serão os nós móveis escolhidos para sofrerem handover e nem como saber qual será seu novo Gateway. Outro fator que dificultou a realização de testes automatizados é que mesmo que haja um desbalanceamento na arquitetura do SDDL, o PoA-Manager pode decidir não enviar as mensagens de handover, pois o intervalo entre as ações foi considerada curta ou o desbalanceamento não atingiu um limite mínimo. Por tais motivos, foram realizados apenas testes de caixa branca e preta. Em ambos os testes, foram levantados alguns Gateways e simuladores de nós móveis para que fossem realizados os testes. Por vezes o uso de processador dos Gateways era artificialmente aumentando com o uso de programas externos que utilizassem parte dos recursos da máquina.
A atual arquitetura do Gateway inviabilizou a execução de testes unitários e automatizados. Grande parte dos métodos do Gateway é privada e não há retorno, os métodos públicos são utilizados apenas para a notificação de eventos por parte dos listeners, como por exemplo, o recebimento de um dado enviado por um nó móvel. Estes métodos também não possuem retorno. Optou-se então por realizar apenas testes de caixa branca e preta. Nos testes de caixa preta e branca foram utilizados simuladores dos nós móveis e dispositivos reais para verificar o fluxo de execução no Gateway, seu estado, possíveis erros gerados e saída de dados.
17
Com exceção do GroupDefiner, que foi implementado por completo, todos os testes realizados tiveram como foco verificar a existência de erros nas partes que sofreram alteração.
Por fim, foram realizados também testes de integração e de sistema. Todos os serviços estão operando normalmente nos experimentos realizados dentro do LAC. Vale destacar que já foram realizadas duas demonstrações, uma realizada pela equipe do LAC e outra pela equipe do InfoPAE Móvel do Tecgraf, com a versão atual do SDDL.
7. Acompanhamento de Execução
Para conclusão deste trabalho final de programação, foram realizadas as seguintes tarefas:
1. Definir a estrutura do grupo, alterar e compilar a IDL;
2. Implementar um novo GroupDefiner para trabalhar com a nova estrutura de
grupo e informar as operações de lista (G-Diff Message) ao Gateway;
3. Testar a implementação do GroupDefiner;
4. Alterar a implementação do Gateway para trabalhar com operações sobre listas
(G-Diff Message) e a nova estrutura de grupo;
5. Realizar teste do GroupDefiner e Gateway;
6. Alterar a implementação do MTD Service para funcionar com a nova estrutura
de grupo;
7. Realizar teste do GroupDefiner, Gateway e MTD Service;
8. Alterar a implementação do PoA-Manager para funcionar com a nova estrutura
de grupo;
9. Realizar teste do GroupDefiner, Gateway, MTD Service e PoA-Manager;
10. Realizar teste de sistema;
11. Fazer testes de desempenho entre a versão antiga e nova do SDDL;
12. Preparar documentação;
As tarefas 1, 3, 5, 6 e 7 foram classificadas com dificuldade 1 em uma escala que vai de 1 até 3. As tarefas 2, 9, 10, 11 e 12 foram classificados com dificuldade 2. As outras tarefas, 4 e 8, foram classificadas com nível de dificuldade 3.
O cronograma das tarefas é mostrado em Tabela 1.
18
Tabela 1. Cronograma de tarefas
Mês Abril Maio Junho
Tarefa/Semana 1 2 3 4 1 2 3 4 1 2 3 4
1
2
3
4
5
6
7
8
9
10
11
12
8. Comentários de Controle de Versão
A seguir são mostrados todos os comentários de versões que foram realizados no GitHub, ferramenta de controle de versão utilizada pelo LAC. O histórico dos commits está organizado em ordem decrescente, ou seja, do mais recente para o mais antigo.
Jun 23, 2012
1. Traducao do Javadoc do MTD Service …
Alguns comentarios estavam em portugues. Todos foram traduzidos para ingles.
1f0d131535Browse code
rafaelov authored 6 days ago
Jun 19, 2012
1. Traducao do Javadoc do GroupDefinerV2 …
Toda a documentacao do projeto do GroupDefinerV2 foi feita em portugues pensando no
Projeto Final, entretanto para seguir o padrao da linguagem adotada na programacao e
das demais documentacoes do projeto, o Javadoc do GroupDefiner foi traduzido
4. Criacao do topico GroupAdvertisementTopic que sera utilizado pelo Gro… …
…upDefiner v2 para anuncio da lista de operacoes sobre os grupos do veiculo que o
Gateway deve executar
ef3b965705Browse code
rafaelov authored 2 months ago
5. Criacao e configuracao do projeto do novo GroupDefiner do ContextNet …
Foi criado o projeto do GroupDefiner v2 bem como realizada as configurações basicas
do projeto (e.g. importacao de JARs e dependencias de projetos)
28999928e7Browse code
rafaelov authored 2 months ago
Bibliografia
[1] M. Endler et al., “ContextNet: Context Reasoning and Sharing Middleware for Large-scale Pervasive Collaboration and Social Networking,” in Proceedings of the Workshop on Posters and Demos Track - PDT ’11, 2011, pp. 1-2.
[2] L. David, R. Vasconcelos, L. Alves, R. André, G. Baptista, and M. Endler, “A Communication Middleware for Scalable Real-time Mobile Collaboration,” in IEEE 21st International WETICE, Track on Adaptive and Reconfigurable Service-oriented and component-based Applications and Architectures (AROSA), 2012.
[3] M. Endler, R. O. Vasconcelos, L. David, R. André, and L. Alves, “A DDS-based middleware for scalable tracking and communication of wireless-connected mobile nodes in a WAN.” Monografias em Ciência da Computação - MCC 06/2012, Dep. de Informática, PUC-Rio, ISSN 0103-9741, Rio de Janeiro, 2012.
[4] L. David, R. Vasconcelos, L. Alves, R. André, and G. Baptista, “A Large-scale Communication Middleware for Fleet Tracking and Management,” in Salão de Ferramentas, Brazilian Symposium on Computer Networks and Distributed Systems (SBRC 2012), 2012.
[5] R. O. Vasconcelos, L. David, L. Alves, R. André, and M. Endler, “Real-time Group Management and Communication for Large-scale Pervasive Applications.” Monografias em Ciência da Computação - MCC 05/2012, Dep. de Informática, PUC-Rio, ISSN 0103-9741, Rio de Janeiro, 2012.
[6] OMG, “Data Distribution Service for Real-time Systems.” 2007. [7] T. O. C. Inc, “CoreDX DDS Data Distribution Service Middleware Twin Oaks