PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO
TRAFFIC INSPECTOR:
MONITORAMENTO DO FLUXO DE MENSAGENS
NO MIDDLEWARE SDDL
Matheus Felipe Ferreira Maciel
PROJETO FINAL DE GRADUAÇÃO
CENTRO TÉCNICO CIENTÍFICO - CTC
DEPARTAMENTO DE INFORMÁTICA
Curso de Graduação em Engenharia da Computação
Rio de Janeiro, junho de 2012
Matheus Felipe Ferreira Maciel
Traffic Inspector:
Monitoramento do fluxo de mensagens
no middleware SDDL
Relatório de Projeto Final, apresentado como requisito
parcial para a obtenção do titulo de Engenheiro de
Computação.
Orientador: Markus Endler
Rio de Janeiro
Junho de 2012.
Agradecimentos
À minha família, por acreditarem no meu potencial e me darem todo suporte
emocional necessário para que eu conseguisse viver a uma distância tão grande.
Mesmo quando meu futuro acadêmico e profissional pareceu incerto, vocês me
deram força para continuar tentando.
À minha namorada, que me mostrou como é necessário controlar meu
temperamento e manter o controle mesmo em situações onde todas as saídas são
complexas.
Aos meus companheiros do curso Student to Business, que me mostraram que não
existem limites para o que podemos atingir desde que não desistamos de tentar.
Nunca conheci indivíduos tão aplicados e determinados a ascender como pessoas e
profissionais em toda minha vida.
Ao meu orientador, Markus Endler, por ter me dado a oportunidade de executar o
projeto quando nada parecia certo sobre meu futuro acadêmico. Tenho muito
respeito pelo seu trabalho e agradeço pelo conhecimento adquirido durante a
execução do projeto.
À equipe do LAC, que me apresentou um novo universo relativo a desenvolvimento
de software e novas ferramentas da computação que eu nunca tive contato até a
execução desse projeto.
Resumo
Maciel, Matheus. Markus Endler. Monitoramento do fluxo de mensagens no
middleware SDDL. Rio de Janeiro, 2012. 33 p. Relatório Final de Projeto Final
II – Departamento de Informática. Pontifícia Universidade Católica do Rio de
Janeiro.
A proposta desse trabalho é o desenvolvimento de um sistema de
monitoramento de mensagens trocadas durante uma comunicação DDS. Esse
sistema tem como objetivo auxiliar o desenvolvimento da arquitetura ContextNet,
mais precisamente da camada SDDL.
Palavras-chave
DDS, ContextNet, SDDL, Traffic, Inspector.
Abstract
Maciel, Matheus., Markus Endler. Monitoramento do fluxo de mensagens no
middleware SDDL. Rio de Janeiro, 2012. 33 p. Relatório Final de Projeto Final
II – Departamento de Informática. Pontifícia Universidade Católica do Rio de
Janeiro.
The purpose of this project is the development of a system capable of
monitoring message exchanging in a DDS based communication environment.
This system has the final objective of helping further development of the
ContextNet architecture, more precisely the SDDL layer.
Keywords
DDS, ContextNet, SDDL, Traffic, Inspector.
Sumário
1. Introdução ............................................................................................................. 1
1.1. Objetivos do projeto........................................................................................ 1
1.2. Contextualização do problema..................................................................... 1
2. Estado da Arte...................................................................................................... 3
3. Proposta................................................................................................................. 5
4. Plano de Ação ...................................................................................................... 7
5. Middleware DDS................................................................................................... 8
5.1. O que é DDS ...................................................................................................... 8
5.2. Funcionamento do DDS ................................................................................. 8
6. SDDL ..................................................................................................................... 11
6.1. O que é o SDDL .............................................................................................. 11
6.2. Componentes do SDDL ................................................................................ 11
6.2.1. RUDP .............................................................................................................. 12
6.3. Exemplos de uso do SDDL.......................................................................... 13
7. Traffic Inspector................................................................................................. 15
7.1. MVC.................................................................................................................... 15
7.2. Tópicos DDS e estruturas de dados ......................................................... 16
7.2.1. TruckInformationTopic.............................................................................. 16
7.2.1. TruckGroupInfoTopic ................................................................................ 17
7.2.3. LoadReportTopic ........................................................................................ 17
7.3. Interface ............................................................................................................ 18
7.3.1. Truck Traking Information........................................................................ 18
7.3.2. Group Information ...................................................................................... 22
7.3.3. Gateway Load Information ....................................................................... 24
7.3.4. Custom Data Filtering................................................................................ 26
7.4. Comunicação .................................................................................................. 28
7.4.1. Recebimento/Processamento ................................................................. 28
7.5. Base de Dados................................................................................................ 29
7.5.1. Escrita no banco de dados ...................................................................... 29
7.5.2. Leitura do banco de dados ...................................................................... 30
7.6. Atualização do Traffic Inspector................................................................ 31
8. Considerações Finais.............................................................................. 32
9. Referências Bibliográficas...................................................................... 33
Lista de Figuras
Figura 1 – Camadas do ContextNet.................................................................... 2
Figura 2 – Esquemático da comunicação DDS............................................... 9
Figura 3 – Componentes do SDDL.................................................................... 11
Figura 4 – Arquitetura de uma aplicação para monitoramento de
veículos.................................................................................................................... 14
Figura 5 – Aba Truck Tracking Information do Traffic Inspector............. 19
Figura 6 – Aba Truck Tracking Information após a identificação de
mensagens.............................................................................................................. 22
Figura 7 – Aba Group Information.................................................................... 23
Figura 8 – Aba Gateway Load Information..................................................... 25
Figura 9 – Aba Custom Data Filtering.............................................................. 27
1. Introdução
1.1. Objetivos do projeto
Desenvolver um programa de aplicação capaz de monitorar o tráfego de
dados em um sistema distribuído baseado no middleware SDDL [1] que utiliza o
padrão Data Distribution Service (DDS), da OMG. As principais funcionalidades do
programa, denominado Traffic Inspector, incluem: monitorar o fluxo de mensagens
nos tópicos DDS pertinentes, apresentar os dados obtidas no monitoramento e
possibilitar registro dos mesmos em um banco de dados a fim de permitir a sua
análise após o monitoramento.
1.2. Contextualização do problema
A coordenação e comunicação em aplicações distribuídas com muitos
usuários móveis, em áreas como transporte, segurança, logística e outros, requer o
monitoramento de milhares de dispositivos e capacidade de comunicação entre
estes, de preferência em tempo real.
O desenvolvimento de tais aplicações distribuídas móveis nunca foi uma
tarefa fácil, tendo em vista a quantidade de fatores desafiadores, tais como: a
mobilidade dos usuários e seus dispositivos, a limitação de recursos dos
dispositivos, a instabilidade das conexões sem fio, a variação intrínseca no numero
de participantes, etc. Uma das questões mais complexas em relação a esse tipo de
desenvolvimento é a comunicação entre os nós da aplicação móvel. Os nós podem
possuir sistemas operacionais diferentes, utilizar protocolos de comunicação
diversos ou estarem em redes nas quais a qualidade e a confiabilidade da conexão
não são garantidas e variam rapidamente. Todos esses aspectos costumam ser
fatores de risco no desenvolvimento dessas aplicações e sempre são características
prioritárias para uma aplicação distribuída móvel.
Motivado por esse desafio, iniciou-se no LAC da PUC-Rio, o desenvolvimento
do ContextNet, um projeto que tem como desenvolver protocolos, serviços e
ferramentas que auxiliem o desenvolvimento e gerenciamento de aplicações
distribuídas para colaboração e coordenação móvel, com ciência de contexto
individual e coletiva. Para tal, define uma arquitetura em várias camadas e serviços
(vide Figura 1). A camada sobre a qual esse projeto atua é a camada Scalable Data
Distribution Layer (SDDL), que trata da distribuição de dados de contexto (p.ex. a
1
localização) dos dispositivos móveis e da comunicação eficiente com os dispositivos
móveis, em larga escala [1].
Figura 1: Camadas do ContextNet
Um aspecto importante do desenvolvimento de qualquer aplicação baseada
no middleware SDDL é a necessidade de monitorar e visualizar o fluxo de dados
trafegados entre os nós do seu núcleo (que utilizam a tecnologia DDS), a sua
distribuição de carga e o seu desempenho. Nesse caso específico, era desejada
uma ferramenta que permitisse a visualização das mensagens que trafegavam
durante as comunicações, como forma de depurar, testar e avaliar desenvolvimento
realizado. A partir dessa necessidade, o Traffic Inspector foi desenvolvido.
2
2. Estado da Arte
Quando tratamos do monitoramento e detecção de problemas de redes,
existem diversos programas disponíveis no mercado. Muitos desses programas se
destinam à verificação de banda utilizada por estações e dispositivos de rede ou
verificação de pacotes UDP ou TCP, conhecidos como packet sniffers. Ferramentas
como o FlowScan analisam os dados exportados por um roteador baseado em IP
[7]. Essa ferramenta se destina especificamente para fluxos de pacotes de rede
Internet, não sendo aplicável ao caso do SDDL, onde os objetos de interesse são
mensagens DDS. Outra ferramenta que poderia ser útil durante os testes realizados
pelos desenvolvedores do SDDL é o Lilith Lights, que tem como objetivos
apresentar a comunicação entre clusters e a utilização de CPU dos mesmos. Essa
aplicação auxilia a depuração de código executado em diversas máquinas,
apontando gargalos em algoritmos [8].
As ferramentas apresentadas acima não são capazes de resolver o problema
principal apresentado aos desenvolvedores do SDDL: a visualização das
mensagens DDS transmitidas entre os nós que fazem parte da rede núcleo do
SDDL. Mesmo que um packet sniffer fosse capaz de identificar os pacotes de rede
sendo trocados durante uma comunicação, os desenvolvedores teriam grandes
dificuldades para identificar as mensagens DDS correspondentes e descobrir o que
ocorre de fato durante o processo de troca de mensagens DDS entre os nós do
SDDL. Como não encontramos ferramentas de domínio público destinadas à
verificação dos dados transmitidos por aplicações que utilizam o padrão DDS para
efetuar suas comunicações, se fez necessário desenvolver uma nova aplicação
para resolver o problema.
Para que um programa represente o estado da arte nesse assunto, é
necessário que ele resolva os problemas relacionados aos testes do SDDL. O
primeiro problema vital é a visualização do grande fluxo de dados que transitam na
rede, originados tanto dos nós móveis (informações de contexto), como dos nós da
rede núcleo SDDL, como por exemplo, as mensagens trocadas entre PoAManagers, Gateways e GroupDefiners. Essa visualização deve ser realizada em
tempo real e deve ser organizada de tal maneira que o usuário encontre a
informação desejada com a devida facilidade.
3
Outro problema vital é a avaliação dos dados obtidos durante um teste do
SDDL. Uma aplicação ideal deve ser capaz de armazenar os dados obtidos de
forma segura e confiável, deixando essas informações disponíveis para consultas
posteriores.
Uma vez que esses requisitos sejam alcançados, uma aplicação terá atingido
o nível ideal para monitorar as atividades relacionadas ao desenvolvimento do
SDDL, podendo vir a ter valor nos trabalhos futuros relacionados à arquitetura
ContextNet..
4
3. Proposta
Para solucionar o problema de monitoramento e visualização do trafego de
dados no middleware SDDL, um software com interface gráfica para usuários deve
ser desenvolvido. Dessa forma, o usuário pode interagir com as informações em
tempo real conforme elas são publicadas pelos nós móveis que estejam conectados
a rede. A abordagem convencional para a dificuldade de inspeção de um grande
volume de mensagens/dados gerados continuamente é a utilização de filtros sobre
os tópicos DDS, de acordo com parâmetros bem definidos ou mesmo filtros
personalizados pelo usuário. Vale notar que, como se trata de uma ferramenta de
monitoramento, ela somente mostra o tráfego a partir do momento da sua entrada
na mesma, sendo que o tráfego de mensagens/dados ocorridos antes disso não são
capturados/visualizados. Para melhorar a utilidade do programa, a ele foi adicionada
uma função de armazenamento persistente das informações que trafegaram
durante a sua execução, para facilitar a análise posterior dos dados. Para que esse
programa seja utilizável na prática, os seguintes requisitos tiveram que ser
satisfeitos:
• O Traffic Inspector deve possuir uma interface gráfica coesa e
concisa, para que os desenvolvedores possam testar o SDDL sem que haja
confusão sobre os dados que trafegam na rede;
• Possuir uma forma de persistência para que os desenvolvedores
possam posteriormente verificar os resultados dos testes de carga para
corrigir problemas;
• Aplicar filtros seletivos sobre os dados, facilitando a visualização dos
dados/mensagens
que
são
relevantes
para
a
tarefa
específica
do
desenvolvedor/testador;
• Aplicar filtros especificados pelo desenvolvedor em tempo real, para
que os usuários do programa sejam capazes de adicionar parâmetros a
filtragem que não estão previstos nos filtros padrões da aplicação.
Como dito na seção anterior, não existem softwares de domínio púbico para
monitoramento em sistemas baseados no padrão DDS. Com o cumprimento dos
requisitos listados acima, um software capaz de realizar tal inspeção de tráfego e
auxiliar os desenvolvedores será desenvolvido. A partir desse ponto, é possível
caminhar mais ainda em direção a uma solução geral que possa atender outras
5
aplicações que o SDDL possa vir a ter no futuro. Ou seja, o Traffic Inspector poderia
ser ampliado para inspecionar qualquer ferramenta que utilizar o middleware SDDL
com as devidas modificações no código fonte.
O programa oferece uma interface gráfica para a verificação do tráfego de
nós móveis, atividades de grupos e carga dos servidores bem como a persistência
de dados no banco de dados e a filtragem em tempo real dos mesmos.
6
4. Plano de Ação
Para realizar um projeto como o Traffic Inspector, se fez necessário um estudo
de diversas áreas do curso de engenharia de computação. Para desenvolver um
programa que possuísse uma interface gráfica, existem algumas opções de
linguagens de programação. Devido ao ambiente de trabalho e o conhecimento da
equipe envolvida no SDDL, a linguagem Java foi escolhida para a tarefa. Esse
requisito dificultou o desenvolvimento do projeto devido ao meu conhecimento
reduzido sobre o assunto, embora não tenha impedido que a tarefa fosse realizada
com sucesso. Os componentes Swing de Java foram utilizados para desenvolver a
interface gráfica de forma a permitir que o software opere em diversos sistemas
operacionais que tem suporte para essa linguagem.
Em se tratando de conexão e comunicação de redes, o DDS teve que ser
estudado, já que se trata do padrão utilizado pela camada SDDL da arquitetura
ContextNet. Anterior a esse projeto, eu não possuía qualquer conhecimento sobre
middlewares para computação distribuída e sobre esse padrão DDS, em particular.
Completar os objetivos de fazer a persistência dos dados monitorados exigiu
conhecimento sobre bancos de dados obtidos anteriormente em matérias da
graduação que me forneceram a base para dominar desde queries SQL até como
integrar um banco de dados a uma aplicação Java.
O resultado final do projeto foi um sistema Java capaz de monitorar o
funcionamento da camada SDDL na qual ele está inserido. Esse sistema agrega
boa parte do conhecimento obtido durante todo o curso e ferramentas de diversos
assuntos que se integram cada vez mais no cenário atual de desenvolvimento de
aplicações comerciais.
Para executar esse projeto foram, portanto, necessários estudos e
aprofundamento em diferentes áreas de conhecimento da Computação. O
cronograma de execução das tarefas para a realização dele se encontra abaixo:
Atividade / Mês
Estudo SDDL / DDS
Estudo Java / SQL
Modelagem do Traffic Inspector
Montagem da interface do Traffic Inspector
Desenvolvimento do Traffic Inspector
Abril
Maio
X
X
Junho
X
X
X
X
X
X
X
7
5. Middleware DDS
5.1. O que é DDS?
A comunicação de dados costuma ser um problema complexo e caro no ciclo
de desenvolvimento de aplicações distribuídas. Isso levou a comunidade de
computação a desenvolver padrões de middleware tais como o CORBA, o COM,
Web Services, etc. Um desses padrões de middleware de comunicação é conhecido
como DDS (Data Distribution Service), conhecido padrão middleware de
comunicações que foi concebido e é mantido pelo OMG (Object Management
Group). Através da simplificação da API de comunicação entre computadores, o
desenvolvimento de aplicações distribuídas se torna mais simples e menos
propenso a erros, alem de facilitar a interoperabilidade dos componentes
distribuídos,
possivelmente
desenvolvidos
em
linguagens
de
programação
diferentes e executando plataformas distintas.
Ou seja, os middlewares de comunicações foram desenvolvidos para servir
como uma camada que atua entre o sistema operacional e os softwares de
aplicação e que torna a comunicação entre computadores mais simples e mais
eficiente. Tais ferramentas foram desenvolvidas com o objetivo de facilitar o
desenvolvimento de aplicações, assim como a manutenção e o entendimento de
como dados são servidos e recebidos por serviços que as utilizem. Middlewares
desse tipo são utilizados em diversos nichos de mercado que variam de dispositivos
móveis até grandes aplicações empresariais de bancos de dados: Os middlewares
atuam nesses ambientes de forma a tornar os requisitos de qualidade alcançáveis e
facilitar a comunicação entre essas diferentes aplicações. Com o crescimento da
necessidade de integração de aplicações outrora independentes ao contexto de
uma organização ou serviço tornam os middlewares cada vez mais válidos no
desenvolvimento de novas tecnologias [4].
5.2. Funcionamento do DDS
O DDS trabalha como uma camada entre a aplicação e o sistema operacional,
tendo como dever transferir mensagens entre publishers (Publicadores) e
subscribers (Assinantes). Quando ambos os lados de uma comunicação utilizam
8
DDS, é possível transferir mensagens entre eles sendo que o DDS controla os
casos em que informações são perdidas, simplificando código e economizando
tempo para os desenvolvedores. A escolha do DDS se deu devido a garantia de
consistência na transferência de dados entre diferentes plataformas e sistemas
operacionais, além de posse de políticas de QoS (Quality of Service) que definem a
janela de tempo que uma mensagem é armazenada e como ela deve ser
apresentada para os subscribers.
Um modelo DDS de comunicação tem alguns elementos básicos que o
compõe. Esses elementos tornam a comunicação possível em um ambiente do tipo
Publisher/Subscriber. Dentre esses elementos básicos, o tópico tem papel
importante. Esse elemento contém dados de um tipo de mensagem trocada nesse
ambiente, bem como informações sobre sua disponibilidade e distribuição. Os
publishers e subscribers mencionados anteriormente também são elementos
básicos da comunicação que, por agruparem DataWriters/DataReaders, são
efetivamente capazes de controlar o fluxo de informações na comunicação. Os
DataWriters/DataReaders são entidades que escrevem ou recebem mensagens de
um tipo de dado utilizado na comunicação, sempre se referindo a um único tópico.
Os DataWriters são as entidades responsáveis pela escrita e os DataReaders são
responsáveis pela leitura.
Figura 2: Esquemático da comunicação DDS
Em relação ao fluxo de dados, a comunicação ocorre quando a seção que
publica informações (publishers) escreve um dado utilizando um DataWriter. Em
seguida, esse dado é publicado pelo publisher, tendo como objetivo todos os
9
subscribers associados ao tópico em questão. A comunicação é finalizada quando
cada subscriber entrega a mensagem ao DataReader. Vale notar que o sistema
identifica se um tópico é válido verificando se os tipos de dados, o nome e as
políticas de QoS são iguais: Somente se essas características são condizentes
ocorre a comunicação correta entre os dois (vide Figura 2).
O DDS e os tópicos utilizados são relevantes para o desenvolvimento do
Traffic Inspector, por serem a base da comunicação utilizada no SDDL. O SDDL
utiliza uma grande quantidade de tópicos que se referem a informações como
localização de um nó móvel, grupos (de nós) definidos durante a execução das
comunicações, carga de processamento atual dos servidores e outros tópicos
genéricos utilizados no nível do protocolo de aplicação, como mensagens de texto
simples. Cada um desses tópicos necessita de um DataReader correspondente essencialmente, um stub gerado pelo DDS encapsulando os detalhes da
comunicação através do protocolo Real-Time Publish-Subscribe (RTPS) subjacente
ao DDS - para que o Traffic Inspector possa ser o receptor dos dados transmitidos
“em cada tópico”.
10
6. SDDL
6.1. O que é o SDDL?
O SDDL é uma das camadas básicas da arquitetura do ContextNet, que tem
como objetivo conectar nós estacionários de uma rede física com todos o nós
móveis envolvidos na comunicação. Essa camada tem uma importância
fundamental no funcionamento dessa arquitetura e está ligada diretamente ao
funcionamento do Traffic Inspector.
6.2. Componentes do SDDL
Para o funcionamento do SDDL, é necessário que alguns componentes
estejam presentes. Tais elementos podem ser observados na Figura 3, abaixo:
Figura 3: Componentes do SDDL
Dentre os nós SDDL necessários para uma comunicação DDS, o GW
(Gateway) e o PoA-Manager tem papéis muito importantes e serão descritos a
seguir.
O Gateway é o componente ao qual nós móveis de uma aplicação que
utilizam essa arquitetura se conectam. Dessa forma, esse componente precisa se
comunicar com a rede principal e com os elementos móveis, sugerindo a
necessidade de protocolos de comunicação diferentes para processar mensagens.
11
A tarefa do gateway é definida por traduzir mensagens do protocolo de
comunicação móvel para o DDS e vice-versa.
Ainda relativo aos elementos que compõe essa camada, o PoA-Manager
tem algumas tarefas bem definidas. Uma delas é a distribuição de listas contendo
os gateways disponíveis periodicamente e a outra é requisitar trocas de pontos de
conexão ou gateways. Para saber como efetuar essas trocas, o PoA-Manager se
inscreve no tópico onde todos os gateways informam sua carga de veículos
conectados e dados de processamento. Dessa forma, o PoA-Manager é capaz de
selecionar a melhor opção para um caso de reconexão baseado em grupos e carga.
Devido à natureza do problema, que envolve localização de nós móveis e a
necessidade de verificação de informações de contexto como a localização do nó,
existe a necessidade de um nó DDS no domínio. Esse nó é conhecido como
GroupDefiner. Esse nó é responsável por designar grupos para todos os nós moveis
que se encontram conectados a rede. Dessa forma, é possível enviar mensagens a
grupos que pertençam a algum grupo especificado. Uma forma de classificar os nós
móveis como pertencentes a um dado grupo é utilizando sua localização geográfica.
O componente Monitor tem como função apresentar os dados da
comunicação pelo SDDL de uma forma gráfica. Esse componente é importante para
mostras públicas sobre o SDDL, mas não tem as funcionalidades exigidas para se
tornar a ferramenta que auxiliará os desenvolvedores em testes da ferramenta,
notavelmente em testes onde milhares de nós móveis se conectam a rede e
informações sobre grupos específicos são necessárias.
Como mencionado anteriormente, é preciso empregar protocolos de
comunicação. A utilização do DDS foi escolhida para a rede principal do ContextNet
e o protocolo RUDP (Reliable UDP) foi escolhido para realizar a comunicação entre
os nós móveis da rede e a rede principal. O protocolo DDS foi apresentado
anteriormente e o protocolo RUDP será discutido a seguir.
6.2.1. RUDP
O protocolo RUDP é a base de comunicações entre os nós móveis da rede e
a rede principal da arquitetura ContextNet. Ela implementa funcionalidades do tipo
TCP utilizando UDP, tendo recebido as adaptações necessárias para lidar com
conexões intermitentes, Firewall/NAT transversal e capacidade de lidar com
12
mudanças de IP e interfaces de rede. Todas as mensagens enviadas precisam de
reconhecimento e caso esse recebimento não seja obtido, a transmissão é efetuada
diversas vezes até que a conexão seja considerada perdida. Todas essas
adaptações foram realizadas devido ao nível de indisponibilidade de acesso a
internet por muitas redes móveis. Quando se trata de um celular em movimento,
podem ocorrer mudanças na intensidade do sinal disponível e a conexão com a
rede pode ser perdida. Ainda nesse cenário, pode ocorrer uma situação em que o
dispositivo móvel se reconecta a rede e é designado a um novo servidor. Uma
situação similar ocorre quando um servidor requisita uma mudança de servidor para
o dispositivo móvel. Essas situações caracterizam um HO (Hang over). Para lidar
com situações de HO, o serviço MTD (Mobile Temporary Disconnection) é utilizado,
mas como não se trata de uma ferramenta relevante para o Traffic Inspector, não
será discutida aqui.
6.3. Exemplos de uso do SDDL
Para resolver o problema de controle de frota de uma empresa de óleo e gás,
o SDDL foi implantado. Utilizando essa aplicação, é possível rastrear caminhões
pertencentes à frota em tempo real para aperfeiçoar suas trajetórias, notificar
possíveis problemas em uma dada região e monitorar as ações do piloto. Para
realizar essa tarefa, a companhia utiliza aparelhos celulares que possuem diferentes
serviços de acesso a internet como 2G ou 3G. Dessa forma, durante uma viagem é
possível a ocorrência de perda de sinal e troca de IPs. Na imagem abaixo podemos
verificar a arquitetura da aplicação utilizada no exemplo [1]:
13
Figura 4: Arquitetura de uma aplicação para monitoramento de veículos
Tendo em vista o SDDL como middleware de comunicação utilizado nessa
aplicação, o nós móveis são os veículos pertencentes à companhia.
Cada veículo conectado a um servidor disponibiliza sua localização a cada 30
segundos. Devido à disponibilidade dessas informações de localização para outros
membros da rede que incluem todos os nós móveis, é possível notificar veículos de
situações anormais baseados em sua localização.
Outro exemplo para a aplicação do SDDL pode ser a organização de veículos
de polícia, para realizar notificações em tempo real sobre necessidade de auxilio em
uma dada região, além de quantos oficiais ou poder de fogo são necessários para
completar uma dada tarefa. Além disso, é possível disponibilizar um canal de
comunicação rápido com a polícia para notificar sobre acontecimentos perigosos em
uma dada área, acelerando o serviço da polícia no local. No cenário apresentado,
uma aplicação colaborativa baseada em localização pode ser mais eficiente que
ferramentas convencionais por diversas razões: comunicações por rádio podem ser
interceptadas e não informam a posição precisa de veículos alocados em uma dada
missão, o sistema pode informar somente os veículos que podem dar assistência a
situação e os cidadãos têm mais facilidade em informar um ocorrido em uma região
do que ligando para a emergência [5].
14
7. Traffic Inspector
7.1. Model-View-Controller (MVC)
Em cenários de desenvolvimento de grandes projetos, uma discussão
constante é a metodologia a ser utilizada para manter o desenvolvimento conciso e
fácil de manter. Essa discussão é ainda maior quando a rotatividade de
desenvolvedores envolvidos no projeto é muito grande ou quando a possibilidade de
entrada de novos membros na equipe de desenvolvimento é comum [2].
Para solucionar o problema relacionado à organização de uma aplicação e
sua manutenção, a utilização da arquitetura Model-View-Controller (MVC) é
bastante comum no mercado. Esse padrão de projeto descreve problemas
recorrentes no desenvolvimento de software na qual a solução pode não ser a
mesma em todos os casos. Para utilizar o modelo MVC de desenvolvimento,
precisamos entender a tríade que compõe esse padrão. Essa tríade é composta
pela camada de modelo, visão e controle. Essas camadas são criadas para formar a
aplicação final, dividindo responsabilidades e funcionalidades entre elas. A
arquitetura MVC divide uma aplicação em três áreas de responsabilidade, sendo
elas:
Modelo: Essa área contém os objetos do domínio ou estruturas de dados
utilizadas por toda a aplicação, representando o estado atual da aplicação.
Notoriamente, a camada de modelo não tem qualquer informação sobre as outras
camadas;
Visão: Essa área verifica o estado da aplicação e informa o usuário sobre
esse estado, sendo a interface do programa em boa parte dos casos. Essa camada
interage com o modelo, recebendo os dados da mesma;
Controle: Essa área liga as operações realizadas pelo usuário ao modelo e a
visão, modificando o estado da aplicação conforme necessário. No caso de Java, o
controle e a visão se encontram conectados, funcionando através de delegates.
Sabendo que software precisa interagir com pessoas ou mesmo outros
softwares, é razoável pensar que as interfaces de comunicação mudam com o
tempo, mesmo que algumas vezes a lógica do controle e os dados do modelo não
mudem. Em alguns casos, ocorre o contrário, a interface e controle permanecem
praticamente inalterados, e apenas o modelo é ligeiramente modificado.
15
Em ambos os casos, migrar um software ou mesmo atualizá-lo pode ser um
grande problema caso essas responsabilidades não estejam claramente definidas.
Desde os anos 70, MVC é um design pattern muito conhecido na indústria de
desenvolvimento de software e existem muitos frameworks no mercado que
auxiliam processo de criação de aplicações utilizando o paradigma. No Traffic
Inspector, os conceitos de MVC foram aplicados embora nenhum framework tenha
sido utilizado para auxiliar a tarefa.
Como dito acima, a visão conhece o modelo e interage com ele. Dessa
forma, quando um botão é pressionado ou algum valor é modificado e precisa ser
mostrado, a visão envia e recebe os dados necessários da camada de modelo.
Dessa forma, é necessário que o controle informe ao modelo a necessidade de
atualização de dados ou o fornecimento deles. Dessa forma, o controle se torna a
ponte que atua entre as outras duas camadas, formando uma conexão indireta
entre a camada de modelo e a camada de visão.
Utilizar essa arquitetura ou design pattern facilita a separação de
responsabilidades da aplicação, facilitando a detecção de erros e mantendo o
código bem definido. Dessa forma, a manutenção do código se torna uma tarefa
mais simples e intuitiva.
7.2. Tópicos DDS e estruturas de dados
Devido à natureza da aplicação desenvolvida, foi necessária a definição de
diversas estruturas de dados que tem papel fundamental no funcionamento do
Traffic Inspector. Para falar sobre as estruturas de dados efetivamente utilizadas no
programa, é necessário conhecer os tópicos DDS que estão envolvidos na
comunicação e a função de cada um deles no sistema.
7.2.1. TruckInformationTopic
Esse tópico contém informações relativas a um nó móvel (e.g. um caminhão)
que periodicamente envia dados sobre sua localização corrente para os demais nós
do núcleo SDDL. Informações contidas nesse tópico incluem sua posição
geográfica, a identificação do gateway ao qual o nó móvel se encontra conectado e
o grupo ao qual ele pertence. Para representar essas mensagens no Traffic
16
Inspector, foi designado um modelo conhecido como TruckModel. Esse modelo
contém todas as informações existentes nas mensagens desse tipo e existem duas
listas desse modelo no projeto. Uma das listas controla quais são os nós móveis
que enviaram mensagens desde a inicialização do programa até seu fechamento e
a outra contém todas as mensagens enviadas. A primeira lista existe para controlar
elementos da interface relativos aos filtros disponíveis para o usuário e a segunda
para fornecer os dados que podem ser visualizados na janela principal do Traffic
Inspector.
7.2.2. TruckGroupInfoTopic
Esse tópico contém informações relativas aos grupos existentes (de nós
móveis) definidos pelos GroupDefiners dentro do núcleo SDDL. O tópico verifica a
troca de informações quando algum nó móvel tem seu grupo definido ou então
quando ocorre alguma mudança de grupo de um nó. Dados encontrados nesse
tópico incluem a identificação do nó móvel em questão e o conjunto de grupos aos
quais ele pertence e as mudanças de pertinência de um ou mais grupos. Essas
mensagens são representadas pelo modelo GroupModel no Traffic Inspector. No
modelo todos os dados contidos no tópico são representados e existe uma lista que
utiliza esse modelo para armazenar as mensagens recebidas durante a execução
do programa. Com a utilização dessa lista, é possível manter a interface atualizada
com as informações referentes a grupos, preenchendo os elementos de filtragem.
7.2.3. LoadReportTopic
Nesse tópico são divulgadas informações sobre a carga de trabalho e os
recursos utilizados em cada gateway. Esse tópico é lido pelo PoA-Manager para
conhecer a carga atual de cada gateway e eventualmente realizar a distribuição de
conexões de nós móveis para os gateways. O uso desse tópico tem, portanto,
grande impacto no desempenho geral da comunicação na rede. Entre as
informações mais importantes nesse tópico podemos citar a quantidade de veículos
conectados a um determinado gateway e a memória utilizada em um gateway. As
mensagens desse tópico são representadas no Traffic Inspector pelo modelo
GatewayModel. Para armazenar as informações durante a execução do programa
17
existem duas listas que utilizam esse modelo. O conteúdo dessas listas tem a
mesma funcionalidade das listas mencionadas anteriormente.
7.3. Interface
Ao iniciar o programa, a tela principal é apresentada. A interface gráfica do
Traffic Inspector oferece abas que relacionam os tópicos discutidos acima e cada
visão da tela principal, e também contém controles responsáveis pela filtragem e
amostragem dos dados da comunicação realizada durante a execução do programa
pelo SDDL. A discussão sobre cada aba do programa é feita a seguir.
7.3.1. Truck Traking Information
Para permitir que o usuário tenha controle sobre a carga de comunicação
causada pela execução do Traffic Inspector, a interface oferece a possibilidade de o
usuário conectar ou desconectar o programa do tópico TruckInformationTopic. Essa
opção é dada devido a cenários onde existem muitos nós móveis conectados aos
gateways, e o fluxo e volume de mensagens é maior do que o sistema
operacional/protocolos, um hipervisor (no caso de uso de máquina virtual), o JVM
ou o DDS conseguem suportar para uma determinada máquina hospedeira.
Nessa aba é possível também filtrar as informações relativas ao tópico
TruckInformationTopic. Para tanto, são oferecidos controles que utilizam parâmetros
definidos pelo usuário para a filtragem como o índice de um nós identificados ou um
grupo específico. Quando o programa é inicializado e não existem comunicações
correntes, essa aba é apresentada como na (Figura 5)
Nesse caso, nenhum dos elementos da interface relacionados à filtragem de
dados é preenchido com informações, tendo em vista que não existem informações
sobre nós móveis armazenados na aplicação.
18
Figura 5: Aba Truck Tracking Information do Traffic Inspector
Uma vez que o programa inicia a identificação de mensagens no tópico
TruckInformationTopic, os controles são preenchidos com informações relativas aos
nós móveis conectados a um gateway e gerando dados de localização. Dessa
forma, o usuário não se engana ao escolher uma opção de filtragem. Caso não haja
um grupo de um dado número, esse número não será apresentado na interface.
Esse conceito se aplica a todos os controles de filtragem e mantém a interface
concisa com os dados inspecionados até o momento.
Como opções de filtragem para esse tópico, o usuário tem quatro opções. A
primeira delas é a filtragem por nó móvel. Esse filtro é necessário devido ao grande
número de nós móveis que podem existir ao mesmo tempo em um cenário e serve
como uma ferramenta para verificar se todos os nós móveis presentes nesse
cenário estão enviando mensagens como deveriam. Esse filtro não é expressivo em
relação à identificação do nó móvel, já que esses são identificados por informações
mais complexas. Assim, esse filtro é preenchido conforme os nós móveis enviam
mensagens. Isso impede a comparação de dados entre duas plataformas que
19
executem o Traffic Inspector por esse parâmetro, já que a numeração dos nós
móveis está ligada a ordem de chegada das mensagens enviadas pelo mesmo.
O segundo filtro apresentado nessa aba diz respeito aos grupos já
mencionados no TruckInformationTopic. Dessa forma, cada vez que uma
mensagem é identificada, o grupo ao qual o nó móvel pertence é verificado e caso
seja novo no contexto de execução do programa, é adicionado à lista para
referência futura. Dessa forma, caso um nó móvel pertença a um grupo e mude
desse grupo durante a execução, suas mensagens antigas estarão armazenadas no
grupo anterior e as novas mensagens serão visualizadas no novo grupo. A filtragem
por grupos permite que o usuário identifique nós móveis de acordo com o número
designado pelo GroupDefiner. Essa funcionalidade é importante tendo em vista que
os grupos são designados dinamicamente.
A terceira opção de filtragem é relativa ao gateway. Com esse filtro, é possível
identificar quais nós móveis enviaram mensagens pela rede por um dado gateway.
Sempre que uma mensagem no tópico TruckTrackingInformation é enviada, o
programa inspeciona a mensagem, tal como é feito no caso acima. Caso o gateway
ao qual a mensagem se refere não tenha sido identificado até o momento, ele é
adicionado à lista de gateways disponíveis como parâmetros de filtragem. Da
mesma forma realizada pela filtragem por grupos, a filtragem por gateway mantém
as mensagens antigas como pertencentes ao gateway antigo, sem traduzi-las para
um novo gateway em caso de HO. Essa característica é importante para que não
haja discordância entre os dados quando uma verificação dos dados armazenados
for realizada.
A quarta opção de filtragem trata da filtragem customizada. Essa opção foi
incluída para facilitar a visualização dos dados de acordo com parâmetros definidos
pelo usuário. Existe cenários nos quais é necessário filtrar informações de dois
grupos simultaneamente ou mesmo filtrar mensagens por um dado gateway e grupo
ao mesmo tempo. Nesses cenários a utilização dos filtros básicos não é suficiente
para realizar essas atividades. A filtragem customizada desse caso se aplica
somente
ao
TruckInformationTopic
e
as
principais
características
dessa
funcionalidade serão discutidas mais adiante.
Cada
vez
que
um
nó
móvel
divulga
uma
mensagem
no
tópico
TruckInformationTopic sem que o programa tenha capturado alguma mensagem
anterior pelo mesmo nó móvel, é escrita uma notificação na região de texto abaixo
20
da tabela de amostragem de dados. Essa região de texto foi criada para evitar o uso
excessivo de janelas de alerta para o usuário. Tal decisão foi tomada já que o
programa pode trabalhar com milhares de veículos e gerar uma janela de alerta
para cada novo nó móvel que enviar uma mensagem seria completamente inviável.
Dessa forma a interface se mantém simples e dinâmica, além da área de texto ser
uma forma fácil de manter um registro de todas as notificações realizadas durante a
execução do programa.
Essa aba apresenta uma tabela para amostrar os dados de forma clara e
organizada. Devido ao grande volume de dados gerados pela comunicação dos nós
móveis na rede, uma área de texto é inviável já que a separação de cada
mensagem por campo de informação se torna instável. Tendo em vista que os
valores apresentados como a latitude ou longitude, se tentarmos formatar a
mensagem ou truncar os valores para apresentá-los ao usuário, geramos
inconsistências de informação. Dessa forma, a tabela se mostrou o melhor controle
para realizar a visualização dos dados (Figura 6).
Ainda nessa aba, temos dois botões. O primeiro botão apresenta uma janela
de alerta que contém as informações do nó móvel selecionado na caixa localizada
acima dele. Esse botão existe para identificar o nó móvel selecionado pelo seu
identificador e não pelo indicador na caixa. Dessa forma, quando comparamos a
execução de dois ou mais programas ao mesmo tempo, é possível identificar o nó
móvel por dados do tópico. O segundo botão existe para desativar todos os filtros.
Essa funcionalidade é importante para identificar o funcionamento da rede e
verificar o recebimento de mensagens quando não existe necessidade de filtragem.
21
Figura 6: Aba Truck Tracking Information após identificação de mensagens
7.3.2. Group Information
Similar ao Truck Tracking Information, para permitir que o usuário tenha
controle sobre a carga de comunicação gerada devido ao Traffic Inspector, a
interface oferece a possibilidade do conectar ou desconectar o programa do tópico
TruckGroupInfoTopic. Essa opção se encontra disponível para o usuário mesmo
que esse tópico tenha um fluxo de informações tendenciosamente menor do que o
TruckInformationTopic, já que em um cenário onde os nós móveis mudem de
grupos constantemente pode sobrecarregar os componentes que trabalham para o
funcionamento do SDDL.
Nessa
aba
é
possível
filtrar
as
informações
relativas
ao
tópico
TruckGroupInfoTopic. São oferecidos controles que utilizam parâmetros para a
realização de uma filtragem de dados. Quando o programa é inicializado, todos os
componentes da interface que oferecem as funcionalidades relacionadas à filtragem
se encontram vazios. A janela resultante é apresentada na figura 7.
22
Figura 7: Aba Group Information
Tão logo o subscriber do Traffic Inspector inicializa o reconhecimento de
mensagens do tópico TruckGroupInfoTopic, essas mensagens oferecem os dados
necessários para preencher os elementos que disponibilizam a filtragem para o
usuário. Como somente informações já trafegadas são armazenadas, não é dada a
possibilidade de seleção de grupos que nunca tenham sido mencionados nas
mensagens até o momento. Esse controle permite que o usuário não cometa erros
em relação à existência ou não de um grupo ao tentar filtrar os dados.
Devido à quantidade reduzida de parâmetros para realizar uma pesquisa
nesse tópico, apenas dois filtros são oferecidos para o usuário. O primeiro filtro se
refere ao grupo que se deseja inspecionar. Dessa forma, sempre que o
GroupDefiner definir um grupo para um dado nó móvel, uma mensagem será
enviada no TruckGroupInfoTopic e será possível identificar os grupos ao quais o
dado nó móvel pertence no momento. Esses grupos são então armazenados na
aplicação e utilizados para preencher a caixa que contém os grupos possíveis. Com
a utilização desse filtro é possível verificar todas as definições e mudanças de
23
grupos realizadas no decorrer da execução do programa, sendo possível identificar
inconsistências. Um cenário onde um nó móvel muda de grupo faz com que o filtro
da primeira aba não identifique o nó móvel como participante do grupo anterior nas
mensagens futuras. Uma forma de confirmar que essa alteração está estritamente
ligada a mudança de grupos é verificar se houve alguma mudança de grupos nessa
aba relativa ao novo grupo do nó móvel.
Filtragem customizada também é uma forma de filtragem oferecida nessa
seção do programa. Utilizando esse filtro é possível identificar as mudanças de
grupos relativas a um nó móvel específico ou um mesmo um gateway.
Essa aba apresenta uma tabela para amostrar os dados de forma clara e
organizada. Nessa tabela o usuário pode verificar os dados relativos à filtragem
realizada pelo usuário.
Os botões existentes nessa tela têm funcionalidades similares aos
apresentados na aba anterior. O botão localizado abaixo da caixa que contém a
numeração dos grupos identificados apresenta uma janela de alerta que contém do
grupo selecionado. O segundo botão existe para desativar todos os filtros
selecionados anteriormente.
Quando algum novo grupo é identificado, é gerada uma mensagem de
notificação para todas as abas. Essa mensagem é diferente daquela gerada pela
primeira aba em caso de identificação de um novo grupo pelo tópico
TruckInformationTopic. Assim, mesmo que haja um novo grupo na primeira aba, a
mudança só irá se refletir nessa aba caso ocorra alguma mensagem no
TruckGroupInfoTopic. Essa característica é adotada para manter a diferenciação
dos dados de acordo com cada tópico, evitando assim que uma desconexão em
outros tópicos comprometa a execução das funcionalidades relacionada com esse
tópico. Para exemplificar, em um cenário onde um novo grupo foi identificado na
aba de Truck Tracking Information, se a informação for atualizada na aba Group
Information podemos ter dois grupos iguais ou mesmo um erro de execução devido
à inclusão imprópria de um valor no controle relativo a segunda aba.
7.3.3. Gateway Load Information
Similar ao Truck Tracking Information, para permitir que o usuário tenha
controle sobre a carga de comunicação gerada devido ao Traffic Inspector, a
24
interface oferece a possibilidade do conectar ou desconectar o programa do tópico
LoadReportTopic. Mesmo que uma rede não tenha uma quantidade considerável de
gateways em situações rotineiras, existe a possibilidade de uma rede conter muitos
desses elementos, aumentando a fluxo de dados. Tendo em vista essa
possibilidade, essa opção é dada ao usuário.
Nessa aba visualizar as informações do tópico LoadReportTopic. Como nas
outras abas, o usuário pode tratar os dados obtidos pelo Traffic Inspector. Essa aba
se comporta de forma similar as outras abas já apresentadas, ou seja, as opções de
filtragem de dados estão vazias logo após a inicialização do programa. A figura 8
apresenta a aba em questão.
Figura 8: Aba Gateway Load Information
Os gateways conectados ao tópico LoadReportTopic e escrevem mensagens
que são detectadas pelo programa. Assim que uma mensagem é identificada, o
conteúdo da mensagem é utilizado para popular os elementos que permitem a
filtragem de dados pelo usuário.
25
Como opções de filtragem para esse tópico, o usuário tem duas opções. A
primeira delas é a filtragem por gateway. Similar a aba de Truck Tracking
Information, nessa aba os gateways são identificados por números que não
representam sua identificação real no contexto da rede. Dessa forma, comparar
diretamente as informações obtidas durante a execução de dois ou mais Traffic
Inspector não é a forma correta de comparar os dados já que a organização dos
dados ocorre de acordo com a ordem de chegada das mensagens relativas ao
tópico.
Para oferecer mais flexibilidade para o usuário, a opção de filtragem
customizada também é oferecida nessa aba. Utilizando esse filtro é possível
identificar gateways que contenham quantidades específicas de nós móveis
conectados ou mesmo que estejam com uma dada porcentagem de memória livre.
Essa aba também apresenta uma tabela para a amostragem de dados. Os
dois botões têm uma funcionalidade similar à primeira aba devido à similaridade dos
dois tópicos. O primeiro botão mostra os dados do gateway selecionado na caixa
localizada acima dele. O segundo botão existe para desativar todos os filtros, como
realizado na primeira aba.
7.3.4. Custom Data Filtering
Essa aba se difere das outras abas disponíveis no programa. Em todas as
abas existem opções para filtragem customizada e essa funcionalidade é definida
nessa seção do programa.
26
Figura 9: Aba Custom Data Filtering
Para utilizar um filtro customizado, é necessário definir a expressão do filtro a
ser utilizada. Existe um campo de texto onde o usuário pode escrever essa
expressão e um botão para que o filtro seja salvo pelo programa. Essas expressões
têm uma estrutura similar ao comando SQL WHERE, sendo que os parâmetros para
a filtragem podem conter elementos como equals, and e or. Uma expressão
exemplo seria “x<%0”: Nessa expressão, queremos informações no tópico nas
quais a variável x receba um valor menor que a primeira variável definida na
expressão (%0). É necessário que o usuário atribua o filtro a uma das abas do
programa, selecionando uma das opções apresentadas na janela após a gravação
da expressão, para que não ocorram inconsistências nas buscas e nas informações
mostradas. Outro aspecto importante a ser mencionado é que qualquer filtro que
tenha a sua sintaxe incorreta não irá notificar o usuário. Uma vez que esse filtro está
salvo, é possível selecionar o filtro como uma opção na caixa de opções nas abas
de filtragem customizadas discutidas anteriormente.
27
As expressões já escritas anteriormente são armazenadas e apresentadas na
área de texto na parte inferior da tela. O usuário pode selecionar um filtro de sua
escolha e editá-lo ou apagá-lo.
Algumas considerações são importantes em relação a um filtro customizado.
As expressões seguem os predicados e regras definidas em [6] e quando um filtro
customizado é criado, todas as informações relativas a momentos anteriores a
criação dele não são mostradas, ou seja, o filtro só é aplicado aos dados
monitorados a partir do instante de sua criação. Ou seja, caso um usuário decida
filtrar as informações sobre o TruckInformationTopic e nesse filtro seja utilizado um
grupo como parâmetro, mensagens anteriores que contenham esse grupo como
característica não serão exibidas na tabela da aba em questão.
7.4. Comunicação
Para entendermos como o Traffic Inspector funciona, é necessário entender
como o SDDL se comunica e quais são os tópicos envolvidos na comunicação. Para
o Traffic Inspector, escolhemos os tópicos que eram diretamente relacionados ao
desenvolvimento do exemplo utilizado acima sobre SDDL.
7.4.1. Recebimento/Processamento
Como o objetivo principal do Traffic Inspector é inspecionar as atividades nos
tópicos selecionados, para que o programa funcione corretamente ele precisa se
conectar a todos esses tópicos. Uma vez conectado, ele aguarda que algum desses
tópicos tenha atividade. Quando os tópicos são encontrados na rede, a linha de
comando mostra uma mensagem indicando esse reconhecimento. Como o Traffic
Inspector se direciona aos desenvolvedores do ContextNet, é importante que esses
avisos sejam efetuados.
Quando uma mensagem é identificada em um desses tópicos, o Traffic
Inspector executa sua rotina para verificar o que deve ser feito com a mensagem.
Sendo três os tópicos disponíveis para tratamento, a aplicação tem uma forma
específica de lidar com cada um deles. No caso do TruckInformationTopic, a rotina
tenta identificar novos nós móveis, grupos ou gateways. Essa atividade tem como
objetivo manter a interface atualizada de acordo com a chegada de novas
28
mensagens. Em caso de TruckGroupInfoTopic, a rotina tenta identificar novos
grupos e no caso de LoadReportTopic, novos gateways. Esse tipo de atividade
adiciona overhead sobre o programa, pois são necessárias diversas verificações em
listas para a verificação dessas informações. Dado a natureza da verificação em
tempo real, essas rotinas mantiveram sua característica de atualização ao receber
novos dados, mas em ambientes onde testes não precisam dessa rapidez, tais
atualizações poderiam ser efetuadas em outros momentos, como quando o usuário
seleciona um parâmetro para um filtro.
7.5. Base de Dados
O Traffic Inspector mantém os dados das mensagens obtidas durante a sua
execução em memória. Ou seja, quando o programa é finalizado, as informações
obtidas e guardadas em memória durante aquela execução são perdidas. Como o
programa tem um aspecto muito importante relacionado a testes e verificação de
funcionamento, é necessário que essas informações sejam armazenadas em um
local para consultas posteriores. Para tanto, um banco de dados foi utilizado para
realizar a persistência dessas informações para uso posterior. Esse cenário é
comum tendo em vista que testes nem sempre ocorrem no mesmo dia e podem
estar sujeitos a imprevistos que forçam a sua parada. Como banco de dados foram
escolhidos o MS Access em primeira instância e o MySQL ao final do projeto. Essa
mudança se deu devido a quantidade de plataforma utilizadas no contexto do SDDL
e a compatibilidade do MySQL com tais plataformas.
7.5.1. Escrita no banco de dados
Para realizar a escrita no banco de dados, foi necessário entender do
problema em questão. Um teste de carga utilizando o Traffic Inspector foi realizado.
Esse teste consistia de 4000 nós móveis e dois gateways. Nesse teste, o programa
escrevia no banco de dados sempre que havia alguma nova mensagem relativa a
alguns dos tópicos. Essa postura funcionou durante esse teste, mas não há
confirmação se ela irá funcionar em casos de teste maiores. Para resolver essa
questão em testes mais extremos, é necessário limitar a interação do Traffic
Inspector com o banco de dados. Uma forma razoável de realizar essa tarefa é
29
selecionar intervalos de tempo bem definidos, nos quais o programa escreve as
informações que possui em suas estruturas de dados no banco de dados. Outra
atitude, para evitar a perda de dados, é escrever as informações do Traffic Inspector
no banco de dados quando o usuário tenta finalizar a aplicação. Essas foram as
formas adotadas para manter os dados armazenados no banco sem atrapalhar o
funcionamento do Traffic Inspector em cenário de teste muito carregados.
7.5.2. Leitura do banco de dados
Uma vez que os dados obtidos durante a execução do Traffic Inspector se
encontram armazenadas no banco de dados, é necessário realizar consultas nesse
banco de dados para obter tais informações. Para tanto, é necessário ter
conhecimento sobre SQL. O Traffic Inspector não fornece maneiras de consultar o
banco de dados diretamente, ficando a cargo dos desenvolvedores do SDDL
realizar as consultas manualmente no banco de dados caso seja necessário
comparar dados ou mesmo consultar os dados obtidos em uma execução anterior
do programa.
7.6. Adaptação do Traffic Inspector
Devido ao status de protótipo, o middleware SDDL pode sofrer futuras
mudanças relacionadas aos tópicos DDS envolvidos na comunicação. Nesse caso,
é necessário atualizar o Traffic Inspector para refletir essas mudanças. Para realizar
a tarefa de atualização, é necessário modificar os dados contidos no modelo do
tópico referido. Depois disso, é preciso atualizar a camada de controle para que a
tabela de visualização de dados reflita exatamente as modificações feitas no
modelo. Em seguida, a interface precisa ser adaptada, em particular a tabela que
exibe os dados: por exemplo, quando ocorre uma adição de novos campos no
tópico, novas colunas precisam ser adicionadas à tabela. Também é necessário que
os comandos SQL utilizados para armazenar as informações no banco de dados
sejam atualizados, bem como o banco de dados em si nos casos de adições de
novos campos aos tópicos. Devido à estruturação do Traffic Inspector em camadas
baseadas no MVC, a atualização da aplicação se torna uma tarefa relativamente
simples para os desenvolvedores do SDDL.
30
8. Considerações Finais
Para visualizar os dados referentes à comunicação do SDDL, foi necessário o
desenvolvimento de uma aplicação. Não havia qualquer aplicação no mercado que
possuísse
as
características
necessárias
para
facilitar
os
trabalhos
de
desenvolvimento do SDDL quando o assunto é a visualização das mensagens que
trafegam na rede. Dessa oportunidade nasceu esse projeto e desse projeto uma
aplicação Java foi criada.
As funcionalidades da aplicação criada tentam se aproximar o máximo
possível dos requisitos exigidos pela equipe. Testes foram realizados no ambiente
do laboratório e mostraram resultados promissores relacionados ao funcionamento
do Traffic Inspector. Depois dessa fase, os principais envolvidos com o
desenvolvimento do SDDL estarão sobre o controle da ferramenta e sua
confiabilidade será um aspecto que deverá ser julgado pela equipe durante o
processo de desenvolvimento das atividades do laboratório.
Os trabalhos realizados pela equipe na atualização e desenvolvimento do
SDDL farão que atualizações no Traffic Inspector sejam realizadas para
acompanhar essa evolução. Durante o desenvolvimento, foram tomadas atitudes
para tornar essas atualizações uma tarefa possível para a equipe.
31
9. Referencias Bibliográficas
[1] L. David, R, Vasconcelos, L. Alves, R. Andre, G. Baptista, M. Endler, A
Communication Middleware Supporting Large scale Real-time Mobile Collaboration,
IEEE 21st International WETICE, Track on Adaptive and Reconfigurable Serviceoriented and component-based Applications and Architectures (AROSA), Toulouse,
June 2012 (to appear)
[2] McConnell, Steve. Code Complete 2nd Edition. Redmond, Washington, USA,
2004, 914p.
[3] Data Distribution Service for Real-time Systems. Jan. 2007. Disponível em:
http://www.omg.org/cgi-bin/doc?formal/07-01-01. Acesso em: 11 jun. 2012.
[4] Learn About Middleware: Take the Middleware Tour. Disponível em:
http://www.twinoakscomputing.com/coredx/middleware_tour. Acesso em: 11 jun.
2012.
[5] M. Endler, G. Baptista, L.D. Silva, R. Vasconcelos, M. Malcher, V. Pantoja, V.
Pinheiro, ContextNet: Context Reasoning and Sharing Middleware for Large-scale
Pervasive
Collaboration
and
Social
Networking,
Laboratory
for
Advanced
Collaboration, Department of Informatics, PUC-Rio, Brazil, 2011.
[6] CoreDX Data Distribution Service: Content FilteredTopic Class Reference.
Disponível
em:
http://www.twinoakscomputing.com/documents/coredx_refman_java_html/classcom_
1_1toc_1_1coredx_1_1DDS_1_1ContentFilteredTopic.html. Acesso em: 11 jun.
2012.
[7] FlowScan – Network Traffic Flow Visualization and Reporting Tool. Disponível em
http://www.caida.org/tools/utilities/flowscan/. Acesso em 11 jun. 2012.
32