curso de engenharia de computação estudo e...
TRANSCRIPT
Curso de Engenharia de Computação
ESTUDO E IMPLEMENTAÇÃO DE SISTEMA DE
MONITORAMENTO E SEGURANÇA PELA WEB EM JAVA
Kelin Carla da Silva
Campinas – São Paulo – Brasil
Dezembro de 2008
Curso de Engenharia de Computação
ESTUDO E IMPLEMENTAÇÃO DE SISTEMA DE
MONITORAMENTO E SEGURANÇA PELA WEB EM JAVA
Kelin Carla da Silva
Monografia apresentada à disciplina de Trabalho de Conclusão do Curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Prof. M. Sc. Rodrigo Chavez Monteiro do Prado, como exigência parcial para conclusão do curso de graduação. Orientador : Prof. M. Sc. Rodrigo Chavez Monteiro do Prado.
Campinas – São Paulo – Brasil
Dezembro de 2008
Estudo e implementação de sistema de monitoramento e segurança pela web em Java
Kelin Carla da Silva
Monografia defendida e aprovada em 12 de Dezembro de 2008 pela
Banca Examinadora assim constituída:
Prof. M.Sc. Rodrigo Chavez Monteiro do Prado (Orien tador)
USF – Universidade São Francisco – Campinas – SP.
Prof. Dr. Carlos Eduardo Câmara (Membro interno)
USF – Universidade São Francisco – Campinas – SP.
Prof. M.Sc. Sidney Pio de Campos (Membro interno)
USF – Universidade São Francisco – Campinas – SP.
Dedico este trabalho aos meus pais, Márcia e
Cido e à minha madrinha Clinárcia, por terem sido
meus constantes incentivadores no decorrer dos
anos de faculdade e de vida, e por terem
acreditado em mim mesmo quando tudo parecia
estar perdido.
v
Agradecimentos
A Deus em primeiro lugar, por me dar saúde e discernimento, sem sua
presença em todos os momentos de minha vida não teria alcançado esta tão grande
esperada vitória.
Aos meus pais, por me dedicarem tanto amor de forma incondicional e me
tornarem uma pessoa de fé, princípios e ideais.
Ao meu irmão por ser acima de tudo meu amigo e me dar a certeza de que
sempre sou capaz.
A minha madrinha em especial, por ser minha segunda mãe, e me incentivar
e me proporcionar tantos momentos de alegria.
Ao meu tio Vislei por estar sempre pronto a me ajudar, tendo sempre as
palavras certas em qualquer momento.
Aos meus tios, avós e primos por estarem sempre presentes de alguma forma
em minha vida, dando-me força e coragem para lutar e vencer os obstáculos da
vida.
Ao meu namorado por estar sempre ao meu lado e fazer com que sua
presença seja essencial em todos os momentos.
A todos os meus amigos pela amizade sincera e por compartilharem
momentos maravilhosos, em especial a minha amiga Rubia que esteve presente em
minha vida nestes quatro anos de universidade, sem você tudo seria mais difícil.
Aos professores desta instituição pela amizade e dedicação. Ao meu
orientador Prof. Rodrigo Chavez Monteiro do Prado pelo apoio, incentivo e
disponibilidade, tornando-se uma das pessoas diretamente responsáveis por este
ideal alcançado.
vi
“O sucesso nasce do querer, da determinação e
persistência em se chegar a um objetivo. Mesmo
não atingindo o alvo, quem busca e vence
obstáculos, no mínimo fará coisas admiráveis".
José de Alencar
vii
SUMÁRIO
SUMÁRIO ................................................................................................................ VII
LISTA DE SIGLAS.................................... ................................................................ IX
LISTA DE FIGURAS................................... .............................................................. XI
RESUMO................................................................................................................. XIII
ABSTRACT........................................... .................................................................. XIII
1 INTRODUÇÃO.....................................................................................................1
1.1 CONTEXTUALIZAÇÃO ..................................................................................................1
1.2 OBJETIVOS...................................................................................................................2
1.2.1 Objetivos gerais..................................................................................................2
1.2.2 Objetivos específicos ..........................................................................................2
1.3 ESTRUTURA DO TEXTO................................................................................................3
2 FUNDAMENTAÇÃO TEÓRICA.............................. .............................................4
2.1 JAVA MEDIA FRAMEWORK..........................................................................................4
2.2 JAVA MAIL ...................................................................................................................8
2.3 APPLETS......................................................................................................................9
2.3.1 Definição ............................................................................................................9
2.3.2 Estados de uma applet........................................................................................9
2.3.3 Restrições das applets ......................................................................................11
2.3.4 Assinatura de applets .......................................................................................12
2.4 REAL TIME TRANSPORT PROTOCOL...........................................................................12
2.5 JAVA SERVER PAGES.................................................................................................14
2.6 THREAD.....................................................................................................................15
2.6.1 Estados de uma thread .....................................................................................15
2.6.2 Multithreading..................................................................................................16
3 DESENVOLVIMENTO DO SISTEMA......................... .......................................17
3.1 OBJETIVOS DO SISTEMA ............................................................................................17
viii
3.2 PROJETO....................................................................................................................18
3.2.1 Módulo Servidor ...............................................................................................19
3.2.2 Módulo Cliente .................................................................................................41
3.3 DETALHES DE IMPLEMENTAÇÃO ...................................................................44
3.4 TESTES....................................................................................................................45
4 CONCLUSÃO .......................................... ..........................................................47
4.1 CONTRIBUIÇÕES........................................................................................................47
4.2 TRABALHOS FUTUROS...............................................................................................48
ix
Lista de Siglas
AIFF Audio Interchange File Format
API Application Programming Interface
ASP Active Server Pages
AVI Microsoft Áudio/Vídeo Interleave
GUI Graphical User Interface
HTML Hyper Text Markup Language
IDE Integrated Development Environment
IETF Internet Engineering Task Force
IMAP Internet Message Access Protocol
IP Internet Protocol
J2SE Java Standard Edition
JAR Java Archive
JDBC Java Database Connectivity
JDK Java Development Kit
JMF Java Media Framework
JPEG Joint Photographic Experts Group
JPG Joint Photographic Group
JSP Java Server Pages
JVM Java Virtual Machine
LAN Local Area Network
MIDI Musical Instruments Digital Interface
MOV Formato criado pela Apple para o QuickTime
MP3 MPEG Audio Layer 3
MPEG Motion Picture Experts Group
MPG Motion Picture Group
PHP Personal Home Page
POP3 Post Office Protocol
RTCP Real Time Control Protocol
RTP Real Time Transport Protocol
SMS Short Message Service
x
SMTP Simple Mail Transfer Protocol
SWF Small Web File
UDP User Datagram Protocol
USB Universal Serial Bus
VCR Video Cassete Recorder
WAN Wide Area Network
WAV Windows Audio Video
WTP Web Tools Plataform
xi
Lista de Figuras
FIGURA 2.1 - CAMADAS DE ABSTRAÇÃO DA API JMF ................................................................4
FIGURA 2.2 - MODELO DO OBJETO PLAYER .................................................................................5
FIGURA 2.3 - ESTADOS DE UM OBJETO PLAYER............................................................................6
FIGURA 2.4 - MODELO DO OBJETO PROCESSOR............................................................................7
FIGURA 2.5 - ESTADOS DE UM OBJETO PROCESSOR......................................................................7
FIGURA 2.6 - ARQUITETURA JMF................................................................................................8
FIGURA 2.7 - IMPLEMENTAÇÃO DE UMA APPLET.......................................................................11
FIGURA 2.8 - TRECHO DE CÓDIGO HTML INVOCANDO UMA APPLET.........................................11
FIGURA 2.9 - CABEÇALHO DO PROTOCOLO RTP........................................................................13
FIGURA 2.10 - PROCESSO DE REQUISIÇÃO A PÁGINAS JSP.........................................................15
FIGURA 2.11 – CICLO DE VIDA DE UMA THREAD........................................................................16
FIGURA 3.1 – COMUNICAÇÃO DE DADOS DO SISTEMA PROPOSTO..............................................19
FIGURA 3.2 - DEPENDÊNCIAS DO MÓDULO SERVIDOR ..............................................................20
FIGURA 3.3 - MODELO DO SERVIDOR........................................................................................21
FIGURAS 3.4 - TELA DE VISUALIZAÇÃO DOS FRAMES CAPTURADOS...........................................22
FIGURA 3.5 - TELA DE CONFIGURAÇÕES DO SISTEMA................................................................22
FIGURA 3.6 – DIAGRAMA DE CLASSES PARA A TRANSMISSÃO DE VÍDEO....................................23
FIGURA 3.7 – FLUXOGRAMA PARA DETECÇÃO DE MOVIMENTO.................................................24
FIGURA 3.8 - MÉTODO PARA GERAÇÃO DE IMAGENS.................................................................25
FIGURA 3.9 - CLASSE PARA ENVIO DE SMS ATRAVÉS DE E-MAIL ..............................................28
FIGURA 3.10 - FLUXOGRAMA DO PROCESSO DE INSERÇÃO........................................................30
FIGURA 3.11 - FLUXOGRAMA DO PROCESSO DE ATUALIZAÇÃO.................................................32
FIGURA 3.12 - FLUXOGRAMA DO PROCESSO DE EXCLUSÃO.......................................................33
FIGURA 3.13 - MODELO DE DADOS DO CADASTRO DE USUÁRIOS...............................................34
FIGURA 3.14 - DIAGRAMA DE CLASSES.....................................................................................35
FIGURA 3.15 - TELA DE LOGIN...................................................................................................36
FIGURA 3.16 - TELA DE FALHA DE LOGIN ..................................................................................37
FIGURA 3.17 - TELA DE VISUALIZAÇÃO DOS FRAMES (TELA PRINCIPAL) ...................................38
FIGURA 3.18 - TELA DE CADASTRO/LISTAGEM DE USUÁRIOS.....................................................39
FIGURA 3.19 - TELA DE LISTAGEM DE IMAGENS........................................................................40
xii
FIGURA 3.20 - AUMENTO DA IMAGEM SELECIONADA................................................................41
FIGURA 3.21 - IMPLEMENTAÇÃO PARA O RECEBIMENTO DOS FRAMES.......................................42
FIGURA 3.22 - CLASSE RTPPLAYER QUE ESTENDE APPLET.......................................................43
FIGURA 3.23 - INVOCAÇÃO DA APPLET......................................................................................43
xiii
Resumo
Este trabalho de monografia propõe um sistema de monitoramento e
segurança utilizando webcam comum conectada a computadores convencionais ou
notebooks. O sistema desenvolvido em Java, utiliza a API Java Media Framework
que permite a captura de frames da webcam e sua transmissão pela rede através do
uso do protocolo RTP.
O sistema ainda possui outras funcionalidades interessantes como permitir
que usuários remotos visualizem estes frames através de um browser, fazer a
detecção de movimentos da mídia capturada e guardar imagens geradas por estas
detecções para visualizações posteriores. Além de notificar via mensagem SMS os
eventos de detecção.
PALAVRAS-CHAVE : Monitoramento, Segurança, Java Media Framework, Real
Time Transport Protocol, Detecção de movimentos.
Abstract
This work of monograph proposes a monitoring and security system using
common webcam connected to conventional computers or notebooks. The system
developed in Java uses the Java Media Framework API that allows the capture of
frames of the Webcam and their transmission over the network through the use of the
RTP protocol.
The system also has other interesting features as allow remote users to view
these frames through a browser, making the detection of movement of media and
store captured images generated by these detections for later views. In addition to
alarm via SMS message the events of detection.
KEY WORDS: Monitoring, Security, Java Media Framework, Real Time Transport
Protocol, Motion detection.
1
1 INTRODUÇÃO
1.1 Contextualização
Há muito tempo vêm sendo desenvolvidas tecnologias e novas soluções
que possuem a finalidade de prover segurança, seja para contemplar áreas
comerciais, residenciais e até mesmo públicas. As próprias prefeituras vêm
utilizando câmeras espalhadas por todo o perímetro de ruas e avenidas, para
que seja possível monitorar qualquer tipo de ação que comprometa a
segurança da população.
Várias pessoas gostariam de possuir um sistema de segurança em sua
própria residência ou comércio. Diante disso, pode-se perguntar, se a grande
maioria da população possui meios de adquirir um sistema de segurança cujo
custo é demasiadamente alto. É claro que não, a maioria não possui meios de
adquirir tais sistemas, pois envolve a compra de equipamentos caros.
Pensando nisso, analisou-se então o que resta a esta grande fatia da
população. Há alguns softwares ou tecnologias disponíveis na Internet, que
realizam o trabalho de monitoramento por webcam, alguns que apenas
monitoram e outros que além de monitorar, também possuem detecção de
movimento e gravam imagens para visualizações posteriores.
Como exemplo de tecnologia, pode-se citar o sistema WebMonitor1, que
atua somente como um monitor, onde não há possibilidade de gravação de
vídeo ou imagem, detecção de movimentos, configurações, etc.
Outro exemplo, é o sistema CamShot2, que utiliza webcam comum para
detectar movimentos, captura imagens e as envia pela Internet (página
específica ou e-mail), possuindo dois modos de captura: periódica e com
detecção de movimentos. Este software não possibilita a visualização de
frames em tempo real pela Web.
.
1 http://www.compressweb.com/ 2 http://www.evinco.com.hk
2
1.2 Objetivos
1.2.1 Objetivos gerais
O objetivo deste trabalho se deu pela necessidade de uma aplicação
de monitoramento local, utilizando uma webcam posicionada num lugar
estratégico, onde poderiam ser visualizados e também captados movimentos
e gravados em disco rígido para visualizações posteriores, ou seja,
disponibilizaria ao usuário todo controle do ambiente no qual foi instalada a
webcam.
Mais tarde, com o amadurecimento da idéia, foi pensado que seria
bem mais vantajoso que esta aplicação fosse desenvolvida em ambiente
Web, para que fosse possível a visualização de frames em tempo real de
forma remota.
1.2.2 Objetivos específicos
Como objetivos específicos deste trabalho pode-se citar os seguintes:
• Captura e transmissão de frames pela rede;
• Detectar movimentos observando-se os frames;
• Notificação de detecção por SMS;
• Gerar e gravar imagens pela detecção dos movimentos;
• Solução em plataforma web para permitir:
- Autenticação de usuários;
- Visualização de frames em tempo real;
- Visualização de imagens gravadas;
- Cadastro de usuários.
3
1.3 Estrutura do Texto
No capítulo 2 é apresentado o embasamento teórico no qual este
trabalho se fundamenta. Na seção 2.1 é abordada a API JMF, responsável por
tornar possível a implementação de aplicações multimídia em Java e na seção
2.4 é abordado o protocolo RTP, que é normalmente utilizado para transmissão
de dados multimídia pela rede.
No capítulo 3 são detalhados os objetivos do sistema, sua modelagem e
implementação. É neste capítulo também que são descritos os problemas
encontrados e os testes realizados.
No capítulo 4 é realizada a conclusão do trabalho e citadas suas
contribuições, além de apresentar melhorias para trabalhos futuros.
4
2 FUNDAMENTAÇÃO TEÓRICA
2.1 Java Media Framework
Devido ao enorme crescimento de conteúdo multimídia na Internet e em aplicações Desktop, a Sun Microsystems, a Intel e a Silicon Graphics decidiram trabalhar juntas para produzir uma Interface de Programação de Aplicativos (API) para multimídia, conhecida como a Java Media Framework (JMF) [1], dando assim suporte a áudio e vídeo em aplicações Java, sejam estes aplicativos desktop ou applets. A API JMF é uma dentre as várias APIs para multimídia em Java. Esta seção se baseia na guia fornecida pela Sun Microsystems [2].
O uso da API JMF torna possível o desenvolvimento de aplicativos que reproduzem, editam e capturam mídia baseada em tempo, e ainda garante a independência de plataforma. A figura 2.1 mostra as camadas que abstraem as peculiaridades da plataforma.
A versão atual da API é a JMF 2.1.1, desenvolvida pela Sun e IBM, dando suporte aos formatos padrões de mídia, como por exemplo: Audio Video Interleave (.avi), Small Web File (.swf), MPEG Áudio Layer 3 (.mp3), Musical Instrument Digital Interface (MIDI; .mid), Motion Picture Experts Group (.mpeg), QuickTime (.mov), Windows Audio Video (.wav) e Audio Interchange File Format (.aiff).
Figura 2.1 - Camadas de abstração da API JMF [2]
Como reprodutores de mídia para computadores dependem muito da
plataforma nativa, a API JMF provê uma abstração que torna possível desenvolver aplicativos que se utilizam de multimídia sem ter o conhecimento de qual plataforma o aplicativo vai funcionar.
As principais classes e interfaces da API JMF são:
� CaptureDevice � MediaLocator � DataSource
5
� Player � Processor � DataSink � Manager � Format
CaptureDevice Representa o hardware que será capturado, como por exemplo uma
webcam ou um microfone. MediaLocator
É a origem da mídia a ser reproduzida ou editada, pode ser o caminho
de um arquivo existente num diretório qualquer, um endereço da internet que contém alguma mídia ou até mesmo a representação do hardware capturado pelo objeto CaptureDevice.
DataSource
É o conteúdo de mídia propriamente dito, pode ser áudio ou vídeo,
como também áudio e vídeo ao mesmo tempo. Seu conteúdo é enviado ao objeto Player ou ao objeto Processor para ser renderizado.
Player
É o objeto que recebe a mídia do DataSource e renderiza para o cliente
visualizar. A figura 2.2 mostra o modelo do objeto Player.
Figura 2.2 - Modelo do objeto Player [2]
O Player possui estados como os de um aparelho de DVD: parar,
iniciar, avançar e retroceder. Além destes estados que são visíveis ao usuário, há também estados invisíveis e que são necessários para a efetiva reprodução do conteúdo de mídia: Unrealized , Realizing , Realized , Prefetching , Prefetched e Started . A mídia é reproduzida somente se o evento de Prefetched ocorrer.
A figura 2.3 mostra os estados de um objeto Player, ilustrando também que a mídia somente é reproduzida quando passa do estado Stopped (conjunto de estados) para Started .
6
Unrealized : é o estado no momento em que o Player é instanciado;
Realizing : é o estado no momento em que se chama o método realize() da classe Player. Neste estado o Player determina os recursos necessários para reproduzir a mídia;
Realized : é o estado no momento em que o Player já tem conhecimento dos recursos necessários para se reproduzir a mídia;
Prefetching : é o estado no momento em que se chama o método prefetch() da classe Player. Neste estado o Player se prepara e faz o carregamento da mídia a ser reproduzida;
Prefetched : é o estado que indica que o carregamento da mídia foi concluído e esta está pronta para ser reproduzida;
Started : é o estado no momento em que se chama o método start(), ou seja, estado em que a mídia está sendo reproduzida.
Figura 2.3 - Estados de um objeto Player [2]
Processor
Estende a classe Player e portanto é um tipo de player que também
renderiza a mídia contida no DataSource e possui todos os controles do Player. O que o diferencia do objeto Player é que ele tem o controle de qual processamento é feito no stream de entrada e ainda pode além de renderizar o DataSource, ter como saída uma mídia que é enviada para outro Processor ou Player e assim por diante. A figura 2.4 mostra o modelo do objeto Processor.
7
Figura 2.4 - Modelo do objeto Processor [2]
O Processor possui mais dois estados, além dos seis mencionados na
seção 2.1.4:
Configuring : é o estado no momento em que se chama o método configure() da classe Processor , onde o objeto Processor conecta ao DataSource, realiza a demultiplexação da mídia e recebe informações do seu formato;
Configured : é o estado no momento em que as operações do
estado Configuring são finalizadas. A figura 2.5 mostra os estados de um objeto Processor.
Figura 2.5 - Estados de um objeto Processor [2]
DataSink
Interface que lê o conteúdo do DataSource e renderiza a mídia para um
destino, como por exemplo na forma de um arquivo.
8
Manager É o objeto responsável por intermediar dois objetos diferentes como,
por exemplo, criar um Player ou um Processor a partir de um DataSource. Format
Representa o formato da mídia, subclasses são audioformat e
videoformat. Não fornece parâmetros específicos de codificação.
Arquitetura JMF A arquitetura JMF pode ser comparada ao processo decorrido desde a
filmagem por uma câmera Video Cassete Recorder (VCR) até a saída em vídeo e/ou áudio, conforme mostra a figura 2.6.
Figura 2.6 - Arquitetura JMF [2]
2.2 JavaMail
É uma API para aplicativos Java que possibilita o envio, recebimento e
manipulação de e-mails sem a necessidade de conhecer detalhes dos
protocolos utilizados, ou seja, o desenvolvedor só tem a preocupação com os
detalhes de alto nível, como por exemplo, e-mail do remetente, e-mail do
destinatário, assunto e corpo do e-mail, e deixa para a API detalhes da
transmissão [3].
A Sun oferece gratuitamente a distribuição desta API, com
implementação dos protocolos: Post Office Protocol (POP3), Simple Mail
Transfer Protocol (SMTP) e Internet Message Access Protocol (IMAP). Esta
distribuição é adquirida separadamente do Java Standard Edition (J2SE).
9
2.3 Applets
2.3.1 Definição
É um tipo de aplicação Java que pode ser embutida em documentos
Hiper Text Markup Language (HTML), ou seja, executada pelo browser.
A applet é inserida numa página HTML como se fosse uma imagem,
podendo assim estar fixada em qualquer parte da tela.
Praticamente qualquer aplicação destinada a web pode ser feita por
meio de applets, porém, elas possuem algumas restrições, as quais serão
mencionadas na seção 2.3.2, além de poder ter baixo desempenho diante de
sua eventual complexidade, a qual pode ocasionar lentidão de seu
carregamento, pois para isso se faz necessária sua transferência para a
máquina cliente.
Para que seja possível seu carregamento é necessária a instalação do
Java Plug-in na máquina cliente [4].
2.3.2 Estados de uma applet
A applet possui um ciclo de vida composto por métodos que são
invocados de acordo com alguns eventos disparados pelas ações dos
usuários [4]. O ciclo de vida de uma applet é dividido em seis estágios
distintos:
Instanciação: Ocorre no momento em que uma classe que estende a
applet é criada: public class AppletExemplo extends Applet;
Inicialização: é o método invocado após a criação da applet, utilizado
para iniciar a execução da mesma, como por exemplo para a criação da
Graphical User Interface (GUI). Pode ser comparado ao construtor de
uma classe convencional. Este método é invocado somente uma vez no
carregamento da applet. O nome do método responsável por esta
inicialização é: init();
10
Início: é o método invocado toda a vez em que a applet se torna visível
no browser, como por exemplo, quando a janela do browser é
minimizada a applet se torna oculta e quando a janela é maximizada, se
torna visível. O nome do método invocado por este evento é: start();
Parada: é o método invocado toda vez em que a applet se torna invisível
ou oculta, ou seja, é quando a janela do browser é minimizada. O nome
do método invocado por este evento é: stop();
Atualização: é o método invocado toda vez em que a applet precisa ser
atualizada na tela (janela redimensionada, minimizada, maximizada,
etc.). O nome do método invocado por estes eventos é: paint();
Finalização: é o método invocado toda vez que a applet é descarregada,
quando por exemplo a janela do browser é fechada. Isto ocorre para que
todos os recursos de memória utilizados durante sua execução sejam
liberados. O nome do método invocado por este evento é: destroy().
Apesar da existência destes seis estágios (métodos), a utilização é
opcional e depende exclusivamente da necessidade da aplicação. Na figura
2.8 é mostrado um exemplo de uma classe que estende applet com os seis
métodos implementados.
Outra característica da applet é a necessidade de elaboração de um
trecho de código usando tags (etiquetas) HTML contendo uma invocação da
classe (Applet), conforme mostra a figura 2.9.
11
Figura 2.7 - Implementação de uma applet
Figura 2.8 - Trecho de código HTML invocando uma applet
2.3.3 Restrições das applets
As applets podem executar algumas tarefas sem qualquer tipo de
restrição, como: exibir imagens, vídeos, executar sons, processar o
acionamento do teclado, do mouse e se comunicar com o computador
(servidor remoto) de onde foram carregadas.
Pelo motivo das applets rodarem localmente, há uma forma de se
evitar que estas atuem como vírus, acessando informações sigilosas,
alterando ou apagando dados; que seria expor restrições ao seu
funcionamento.
As applets operam num modelo chamado: caixa de areia (sandbox), o
que impossibilita que elas saiam do raio de atuação permitido [4].
Para que algumas ou todas as restrições de uma applet sejam
retiradas, se faz necessária a criação de um arquivo de política (policy file), o
que estiver neste arquivo de política será permitido, isto somente após a
12
aceitação do usuário em executar esta applet, diante de uma assinatura
pública. Este assunto é tratado na próxima seção.
2.3.4 Assinatura de applets
A assinatura de applet é necessária para que se tenha certeza de que
a applet se origina de uma fonte confiável, funciona como um certificado de
confiabilidade.
Há duas formas de se declarar que uma determinada applet é
confiável, uma é conseguida através de uma declaração (não gratuita) de
uma entidade idônea, como por exemplo, a empresa brasileira Certisign,
denominada também como Autoridade de Certificação e outra forma é o
próprio desenvolvedor assinar a applet, seriam os certificados auto-assinados
(self-signed), que por sua vez são gratuitos [5].
O processo de assinatura só pode ser realizado em arquivos
compactados Java Archive (JAR), nos quais são empacotadas todas as
classes necessárias para a execução da applet.
A Sun disponibiliza todas as ferramentas necessárias para a assinatura
de Applets: Jar Creation Tool, Key and Certificate Management Tool (Keytool)
e JAR Signer and Verification Tool (Jarsigner).
2.4 Real Time Transport Protocol
O protocolo RTP é definido pela recomendação RFC 3550 da Internet
Engineering Task Force (IETF), é o principal protocolo utilizado para o
transporte fim-a-fim de pacotes contendo mídia em tempo real, como voz e
vídeo interativos. A grande parte de aplicações distribuídas que realizam
transmissão de dados em tempo real, como por exemplo, as vídeo-
conferências, utilizam RTP [6].
Este protocolo não reserva recursos, nem garante qualidade de serviço,
porém ele encarrega outros protocolos de outras camadas para realizar estes
13
serviços, que se utilizam do seu número de seqüência para tentar fazer a
remontagem de pacotes na ordem correta
Normalmente este protocolo trabalha em cima do protocolo User
Datagram Protocol (UDP) que não garante a entrega dos pacotes no destino,
porém esta perda é admissível quando falamos de dados multimídia.
É importante salientar que transmissões RTP são realizadas por
sessões RTP, ou seja, cada sessão formada por um par: porta/endereço
Internet Protocol (IP), se encarrega de transmitir um tipo de mídia. Se houver
mais de um tipo de mídia, como por exemplo numa vídeo conferência, são
criadas duas sessões com portas distintas, uma para cada tipo de mídia, que
neste caso é uma para o áudio e outra para o vídeo.
O protocolo RTP trabalha tanto transmitindo dados em Multicast (de um
para muitos) como em Unicast (de um para um).
A figura 2.10 mostra as informações contidas no cabeçalho do protocolo
RTP.
Figura 2.9 - Cabeçalho do protocolo RTP [2]
Juntamente com o RTP, existe o protocolo de controle, Real Time
Control Protocol (RTCP) que tem como objetivo prover uma resposta sobre a
qualidade dos dados distribuídos. O RTCP é baseado na transmissão periódica
de pacotes de controle para todos os participantes da sessão. O protocolo
sobre o qual o RTP trabalha deve prover multiplexação de pacotes de dados e
controle. No caso do UDP, isso é possível fazendo-se uso de portas diferentes
para os pacotes de controle e de dados. Esse protocolo faz parte do papel do
RTP como protocolo de transporte e trata do fluxo de dados e do controle de
14
congestionamento. Esse protocolo pode ser útil para algoritmos de codificação
adaptativos que aumentam a taxa de compressão de acordo com o aumento
do congestionamento da rede [7].
2.5 Java Server Pages
JSP é uma tecnologia de extensão da tecnologia Servlet, orientada a
criar páginas web dinâmicas em linguagem Java. Com esta tecnologia é
possível criar aplicações web que se executam em servidores multiplataforma,
já que Java em sua essência é uma linguagem multiplataforma [8].
As páginas JSP são compostas por códigos HTML e tags especiais para
programar scripts de servidor em sintaxe Java, portanto podendo ser escritas
em qualquer editor de texto, assim como na criação de páginas Personal Home
Pages (PHP) e Active Server Pages (ASP).
Assim que o cliente solicita (somente na primeira vez) via browser uma
página .jsp, o servidor realiza a tradução desta página para um servlet [9],
implementado em um arquivo de Byte Codes de Java (.class) e logo em
seguida é enviada ao cliente uma página traduzida, ou seja, em HTML.
A figura 2.11 mostra o processo de requisição, tradução e resposta de
páginas JSP.
15
Figura 2.10 - Processo de requisição a páginas JSP
2.6 Thread
É uma unidade básica de utilização de CPU. As threads são definidas
como processo de pouco peso e operam de forma semelhante a processos
quanto seu estado.
Uma thread pode criar threads filhas e apenas uma thread é executada
por vez em ordem de prioridade.
Um exemplo de thread é o método principal (main()) de aplicações em
Java, esta thread é executada assim que o programa é iniciado [10].
2.6.1 Estados de uma thread
Uma thread pode, a qualquer momento, encontrar-se em um dos vários
estados existentes [1]. Pode-se dizer que quando ela acaba de ser criada está
no estado de nascimento e permanece neste estado até que se chame o
16
método start da thread, passando-se para o estado pronta, e após algumas
verificações de prioridade passa-se para o estado em execução .
A figura 2.12 demonstra todos os estados possíveis de uma thread.
Figura 2.11 – Ciclo de vida de uma thread [1]
2.6.2 Multithreading
É a execução de várias threads num mesmo processo de forma
simultânea. Neste trabalho monográfico utilizou-se multithreading para que
fosse possível a transmissão dos frames e disparo de e-mails
simultaneamente.
Em Java, as primitivas de simultaneidade de processos estão
disponíveis ao desenvolvedor sem a necessidade de bibliotecas adicionais [1].
17
3 DESENVOLVIMENTO DO SISTEMA
3.1 Objetivos do Sistema
O sistema de monitoramento e segurança proposto possui os seguintes
objetivos:
� Capturar frames de webcam comum e transmiti-los para a rede;
� Fazer a detecção automática de movimentos dos frames capturados;
� Gerar imagens Joint Photographic Group (JPG) e gravá-las em disco
rígido quando houver detecção de movimento;
� Enviar mensagem Short Message Service (SMS) para um celular
específico, após um número determinado de detecções;
� Possibilitar que usuários remotos visualizem os frames em tempo real;
� Possibilitar que usuários remotos visualizem as imagens gravadas;
� Possuir Interface simples e amigável, que permita ao usuário (local):
- Iniciar e finalizar a captura de dispositivo de vídeo (webcam)
e a transmissão dos frames capturados para a rede via
protocolo RTP;
- Iniciar e finalizar através de botão, a detecção de
movimentos;
- Realizar a configuração de parâmetros específicos do
sistema, como nível de sensibilidade da detecção,
quantidade de frames por detecção e espelhamento da
imagem;
- Iniciar e finalizar através de botão a amostragem de regiões
que estão sendo detectadas nos frames.
� Possuir interface web, que permita ao usuário (remoto):
- Logar no sistema;
- Visualizar os frames em tempo real;
- Visualizar as imagens gravadas por detecção;
- Filtrar estas imagens por data;
- Aumentar (zoom) a imagem para melhor visualização;
- Visualizar listagem de todos os usuários cadastrados;
18
- Cadastrar novos usuários do sistema, bem como excluir ou
alterar dados de qualquer usuário.
3.2 Projeto
Esta seção define os módulos existentes do projeto e trata de toda a
modelagem dos componentes dos módulos.
Definição dos módulos
O sistema se divide em dois módulos distintos: o módulo servidor e o
módulo cliente. O módulo servidor é responsável pela captura e
disponibilização dos frames aos clientes, detecção de movimentos, geração e
gravação de imagens em disco rígido e notificação de eventos à clientes
específicos. Por outro lado, o módulo cliente disponibiliza aos usuários através
de um browser, a visualização dos frames em tempo real e a interface para os
serviços de visualização das imagens gravadas, cadastro, alteração e exclusão
de usuários.
Vale ressaltar que o módulo servidor também realiza a autenticação do
usuário, ou seja, somente usuários remotos pré-cadastrados têm acesso ao
sistema.
A arquitetura física da comunicação de dados do sistema proposto é
mostrada na figura 3.1.
19
Figura 3.1 – Comunicação de dados do sistema proposto
Os módulos servidor e cliente são descritos nas sessões 3.2.1 e 3.2.2
respectivamente.
3.2.1 Módulo Servidor
Os objetivos do módulo servidor são listados abaixo:
- Obter frames de webcam comum;
- Transmitir frames para a rede WAN / LAN;
- Detectar possíveis movimentos;
- Autenticar usuários remotos;
- Permitir que usuários remotos visualizem as imagens gravadas por
detecção;
- Notificar clientes via SMS diante de movimentos detectados;
- Disponibilizar interface amigável e simples para que o usuário local
possa alterar as configurações específicas do sistema.
20
Para prover todas estas funcionalidades, o módulo servidor necessita
dos serviços oferecidos individualmente por outros servidores: servidor de
banco de dados, servidor SMTP e servidor HTTP. Esta dependência é
demonstrada na figura 3.2.
Figura 3.2 - Dependências do Módulo Servidor
O Módulo Servidor é composto por sub-módulos que se agregam, mas
que exercem funções distintas entre si, são eles:
• Captura;
• Transmissão;
• Detecção;
• Envio de SMS;
• Geração e gravação de imagens;
• Cadastro de usuários;
• Autenticação de usuários;
• Interface com o cliente remoto;
• Interface com o cliente local.
21
No projeto do sistema, estes sub-módulos foram agrupados em
pacotes, de acordo com a dependência existente entre eles. A figura 3.3
demonstra mais claramente como se dá este agrupamento.
Figura 3.3 - Modelo do servidor
Nos próximos itens desta seção, é tratada a modelagem de cada
pacote individualmente.
A – Pacote Principal
Interface com o cliente local
A interface com o cliente local é composta por duas telas, uma
contendo a visualização dos frames capturados e outra contendo os controles
de configuração do sistema, conforme mostra as figuras 3.4 e 3.5.
22
Figuras 3.4 - Tela de visualização dos frames capturados
Figura 3.5 - Tela de configurações do sistema
Captura
O mecanismo de captura da webcam utiliza a classe Capture , esta é
instanciada logo que se inicia a interface mencionada acima.
23
Transmissão
A transmissão dos frames capturados também é iniciada no momento
em que a classe Capture é instanciada, porém é criada uma cópia desta
captura, através da instanciação da classe Clone .
Após a criação deste clone, é instanciada a classe VideoTransmit ,
disponibilizada no site oficial da Sun Microsystems como exemplo de
aplicações que transmitem vídeo via RTP. A função dessa classe é
disponibilizar o vídeo do dispositivo de captura para o cliente que esteja
conectado ao sistema.
Essa classe recebe o objeto DataSource do dispositivo de captura e
cria um objeto DataSink que disponibiliza o vídeo para o endereço IP do
cliente conectado.
A compressão utilizada é a Joint Photographic Experts Group (JPEG)
devido ela ser amplamente suportada em todas as plataformas e por possuir
a menor carga de dados a serem transmitidos em RTP.
A figura 3.6 mostra o diagrama de classes da transmissão de vídeo.
Figura 3.6 – Diagrama de classes para a transmissão de vídeo
24
Detecção
O processo de detecção de movimentos entre frames se dá por um
conjunto de classes, que realizam o processamento das imagens e verificam
se houve movimento ou não. Este processo se baseia no pacote Vision do
projeto open source Lejos 2.1.0 [11].
O método utilizado é o de diferença de pixels. Este método se inicia
com a aquisição de um frame denominado padrão de comparação, a cada
novo frame verifica-se a quantidade de pixels diferentes entre o frame padrão
e o novo frame, ou seja, é feita a subtração de uma imagem para a outra, e
assim é gerada uma terceira imagem. Se o resultado desta subtração for
maior do que o nível fixado, ocorre a detecção do movimento.
O fluxograma da figura 3.7 mostra de forma simplificada a seqüência
do processo de detecção.
Figura 3.7 – Fluxograma para detecção de movimento
25
Geração de imagens
A geração de imagens e posterior gravação em disco rígido acontece
logo que se constata uma diferença significativa entre duas imagens,
conforme foi mostrado no fluxograma da figura 3.7.
A Sun disponibiliza dentro do pacote de APIs do Java Standard Edition
(J2SE) as classes BufferedImage e JPEGImageEncoder , responsáveis
pela geração de imagens.
A figura 3.8 mostra o método responsável pela geração de imagens,
utilizando as classes mencionadas acima, observe que o caminho no qual a
imagem será gravada é enviado como parâmetro (String fn).
Figura 3.8 - Método para geração de imagens
Envio de SMS
O envio de SMS também ocorre logo que se constata a diferença
significativa de imagens, porém, somente após um intervalo definido de
26
detecções, para que não sejam enviadas inúmeras mensagens num curto
prazo de tempo.
Como o SMS é um tipo de mensagem própria de telefones móveis,
seria necessário o estudo do envio destas mensagens através de web-
services proprietários, ou seja, web-services das operadoras de celulares. Isto
levantaria um grande problema, já que o consumo destes web-services não é
gratuito.
Para contornar este problema, definiu-se que somente serão aceitos
números de celulares da operadora Claro, já que esta aceita o envio de SMS
em forma de e-mail e sem custo algum.
A Sun Microsystems disponibiliza a API JavaMail, a qual foi
mencionada na seção 2.2 para tornar possível o envio de e-mails.
A figura 3.9 mostra a classe utilizada para o envio de SMS através de
e-mails.
Fazendo uma breve análise da classe SendMail , implementada neste
projeto, pode-se notar algumas linhas importantes para o seu funcionamento:
Linha 18 – a classe SendMail estende Thread , ou seja, a cada
instanciação desta classe é criada uma nova thread;
Linha 20 – é declarada uma variável contendo o IP do servidor SMTP
responsável pelo envio de e-mails;
Linha 31 – é criada a classe SMTPAuthenticator que estende a
classe Authenticator , a classe SMTPAuthenticator possui um
método que retorna os dados de autenticação, no caso do servidor
SMTP exigir autenticação;
Linha 39 – é criado o método EnviarEmailPara , recebendo os
parâmetros necessários para o envio de e-mail: endereço de e-mail de
destino, assunto do e-mail e corpo da mensagem;
Linha 46 a 55 – são definidos os parâmetros do servidor SMTP, como
porta, endereço IP do servidor, etc;
Linha 86 – onde são enviadas as informações para o servidor SMTP e
este por sua vez, enviar o e-mail;
27
Linha 88 – método run() da classe Thread sobrescrito, este método é
chamado quando a thread é iniciada.
Neste projeto o servidor SMTP utilizado é o SMTPServer3, por ser livre
e simples de usar.
A classe SendMail herda da classe Thread para tornar possível o
envio de SMS (através de e-mail) ao mesmo tempo em que os frames são
transmitidos, ou seja, para possibilitar tarefas simultâneas, conforme foi
mencionado na seção 2.6.
3 http://www.emailarms.com/downloads/1st_smtp.html
28
public class SendMail extends Thread { private String host = "10.1.0.131"; /* endereço do servido r smtp */ String para; String assunto; String mensagem; public SendMail(String para, String assunto, String mensa gem) { this.para = para; this.assunto = assunto; this.mensagem = mensagem; } public class SMTPAuthenticator extends Authenticator { @Override public PasswordAuthentication getPasswordAuthentication() { String username = ""; String password = ""; return new PasswordAuthentication(username, password); } } public void EnviarEmailPara() throws Exception { String from = "RemoteEye"; String fileAttachment = ""; Properties mailProps = System. getProperties(); mailProps.put("mail.smtp.host", this.host); Authenticator auth = new SMTPAuthenticator(); Session session = Session. getDefaultInstance(mailProps, auth); mailProps.put("mail.smtp.auth", "true"); mailProps.put("mail.debug", "true"); mailProps.put("mail.smtp.debug", "true"); mailProps.put("mail.mime.charset", "ISO-885 9-1"); mailProps.put("mail.smtp.port", "25"); MailcapCommandMap mc = (MailcapCommandMap)C ommandMap.getDefaultCommandMap(); mc.addMailcap("text/html;; x-java-content-h andler=com.sun.mail.handlers.text_html"); mc.addMailcap("text/xml;; x-java-content-ha ndler=com.sun.mail.handlers.text_xml"); mc.addMailcap("text/plain;; x-java-content- handler=com.sun.mail.handlers.text_plain"); mc.addMailcap("multipart/*;; x-java-content -handler=com.sun.mail.handlers.multipart_mixed"); mc.addMailcap("message/rfc822;; x-java-cont ent-handler=com.sun.mail.handlers.message_rfc822"); CommandMap. setDefaultCommandMap(mc); // Definir mensagem MimeMessage message = new MimeMessage(session); message.setFrom( new InternetAddress(from)); message.addRecipient(Message.RecipientType. TO, new InternetAddress(para)); message.setSubject(assunto); // Criar parte da mensagem MimeBodyPart messageBodyPart = new MimeBodyPart(); // Texto da mensagem messageBodyPart.setText(mensagem); Multipart multipart = new MimeMultipart(); multipart.addBodyPart(messageBodyPart); // Enviar parte da mensagem message.setContent(multipart); message.setContent(mensagem.toString(), "te xt/html"); // Enviar toda a mensagemSend the message Transport. send( message ); } public void run() { try { this.EnviarEmailPara(); } catch(Exception e) { e.getMessage(); } } }
Figura 3.9 - Classe para envio de SMS através de e-mail
29
B – Pacote de acesso e persistência ao banco de dad os
Escolha do banco de dados
Para persistir os dados de cadastro de usuários se faz necessária a
utilização de um servidor de banco de dados. Definiu-se para este projeto o
banco de dados MySQL Server 5.1 disponível para download no site oficial da
MySql4 [15], por ser independente de plataforma, leve e o mesmo tempo
robusto.
Acesso ao banco de dados
Para acessar a base de dados MySQL em Java, é exigido um driver
chamado MySQL Connector, disponível para download no site oficial da
MySql5. Porém, para que a conexão ao banco de dados seja possível, além
deste driver, também é necessária a API Java Database Connectivity (JDBC),
disponível para download no site oficial da Sun Microsystems 6.
Os dois em conjunto fornecem meios de conexão ao banco de dados
MySQL, além de permitir consultas e persistência de dados (inserir, excluir e
atualizar).
Neste projeto foi criada uma classe que possui uma única função, a de
realizar a conexão junto ao banco, ou seja, nenhuma outra classe precisa
conhecer as informações de acesso ao banco (senha, usuário, etc), estas
informações são encapsuladas na classe de conexão chamada Conexao .
4 http://dev.mysql.com/downloads/mysql/5.0.html 5 http://dev.mysql.com/downloads/connector 6 http://java.sun.com/products/jdbc/download.html
30
Cadastro de usuários
Todas as operações de cadastro do usuário são realizadas por uma
classe chamada Usuario . Assim como foi mencionado anteriormente, esta
classe não realiza a conexão com o banco, ela requisita a classe Conexao e,
de posse da conexão, realiza as operações de inserção, atualização e
exclusão, além de consultas.
As figuras 3.10, 3.11 e 3.12 demonstram o processo realizado para
cada operação de cadastro.
Figura 3.10 - Fluxograma do processo de inserção
31
O fluxograma da figura 3.10 ilustra o processo realizado para inserir um
novo usuário. Pode-se descrevê-lo da seguinte forma: após a entrada dos
dados, é verificado se todos os campos obrigatórios foram preenchidos e se o
login digitado já está cadastrado no banco, passadas estas verificações, os
dados são inseridos no banco.
32
Figura 3.11 - Fluxograma do processo de atualização
33
O fluxograma da figura 3.11 ilustra o processo realizado para atualizar
dados de um usuário já existente. Pode-se descrevê-lo da seguinte forma:
Depois de selecionado o usuário na listagem e alterados os dados
necessários, é verificado se todos os dados obrigatórios foram preenchidos,
passada esta verificação, os dados são atualizados no banco.
Figura 3.12 - Fluxograma do processo de exclusão
O fluxograma da figura 3.12 ilustra o processo realizado para excluir
um usuário já existente. Pode-se descrevê-lo da seguinte forma: depois de
selecionado o usuário na listagem é feita a exclusão no banco.
34
Listagem de usuários
A classe responsável pela listagem de usuários é a Usr_lista , esta
não possui nenhuma operação de persistência, ou seja, somente realiza
consultas. Ela também não é responsável pela conexão com o banco de
dados.
Autenticação de usuários
Da mesma forma que a classe usuário e Usr_lista não são
responsáveis pela conexão com o banco, a classe responsável pela
autenticação de usuários (quando este se loga no sistema) chamada
Autenticacao , também não é responsável pela conexão com o banco e a
requisita para a classe Conexao, e somente depois realiza a consulta na
tabela de usuários para verificar se os dados de login informados realmente
existem. Esta classe também não realiza operações de persistência.
As figuras 3.13 e 3.14 mostram respectivamente o modelo de dados do
cadastro de usuários e o diagrama das classes mencionadas neste item.
Figura 3.13 - Modelo de dados do cadastro de usuários
35
Figura 3.14 - Diagrama de classes
C – Interface com o cliente remoto
Para disponibilizar interface com o cliente remoto através da web,
foram criadas páginas JSP, esta tecnologia foi abordada na seção 2.5.
Tela de login
Como foi mencionado no início da seção 3.2, somente os usuários
cadastrados possuem acesso ao sistema e para isso foi criada uma página de
login, contendo campos de usuário e senha para serem preenchidos. A figura
3.15 mostra a tela de login do sistema.
36
Figura 3.15 - Tela de login
Se os dados informados não existirem no cadastro de usuários, o
cliente é redirecionado à tela de falha de login, conforme mostra a figura 3.16,
caso contrário é redirecionado à tela principal do sistema, esta é mencionada
no próximo item.
37
Figura 3.16 - Tela de falha de login
Tela de visualização dos frames (principal)
Somente os usuários cadastrados possuem acesso a esta tela, através
dela o usuário pode visualizar o vídeo em tempo real, além de possuir links
que abrem outras telas do sistema: tela de cadastro/listagem de usuários e
tela de listagem de imagens.
O link responsável por abrir a tela de cadastro/listagem de usuários
somente é visível a usuários logados que possuem o perfil administrativo
(ADMIN), ou seja, se o usuário logado possuir perfil comum (COMMON), este
nem mesmo verá o link responsável por abrir esta tela.
É nesta página também que o usuário pode sair do sistema, através do
link "Logoff", conforme mostra a figura 3.17.
38
Figura 3.17 - Tela de visualização dos frames (tela principal)
Tela de cadastro/listagem de usuários
Da mesma forma que a tela de cadastro, somente os usuários
cadastrados possuem acesso, porém, como é mencionado acima, o usuário
logado deve possuir o perfil administrativo (ADMIN) para poder visualizá-la.
Esta tela possui as seguintes funções:
• Listar os usuários cadastrados;
• Inserir novo usuário;
• Atualizar dados de um usuário;
• Excluir um usuário.
A figura 3.18 mostra todo o conteúdo da tela de cadastro/listagem de
usuários.
39
Figura 3.18 - Tela de cadastro/listagem de usuários
Tela de listagem de imagens
Esta tela também só pode ser visualizada por usuários cadastrados,
porém tanto pelo perfil ADMIN como também pelo COMMON. Ela é
responsável por permitir a visualização das imagens geradas e gravadas no
servidor, pelo evento de detecção de movimento.
O usuário tem a possibilidade de filtrar por data as imagens a serem
visualizadas, porém deve ficar claro que a filtragem é somente por uma data
específica, ou seja, não foi definido para este projeto o filtro das imagens por
um intervalo de datas, conforme mostra a figura 3.19.
É possível também aplicar aumento (zoom) de cada imagem clicando
sobre ela, conforme mostra a figura 3.20.
40
Figura 3.19 - Tela de listagem de imagens
41
Figura 3.20 - Aumento da imagem selecionada
3.2.2 Módulo Cliente
Os dois únicos objetivos do módulo cliente são: receber via protocolo
RTP os frames em tempo real enviados pelo módulo servidor e fornecer
meios para a visualização destes frames através do browser, ou seja, pela
página principal do sistema, conforme foi mencionado na seção 3.2.1 item
“Tela de visualização dos frames (tela principal)”.
Recebendo frames do módulo servidor
A classe responsável pelo recebimento dos frames em tempo real
enviados pelo módulo servidor é a RtpPlayer , e através de poucas linhas de
implementação este recebimento é possível, conforme mostra a figura 3.21.
42
Figura 3.21 - Implementação para o recebimento dos frames
Pode-se observar brevemente na figura 3.21 alguns detalhes
importantes:
Linha 10 – é criada uma variável do tipo String recebendo o endereço e
porta de origem dos frames, observe que é utilizado: “rtp://”, isto se faz
para receber os dados originados deste endereço, via comunicação
RTP.
Linha 12 – é criado um objeto do tipo MediaLocator, o qual foi
mencionado na seção 2.1.1, passando como parâmetro o endereço
contido na variável url. Dando-se assim o recebimento dos frames.
Permitindo visualização dos frames pelo browser
Para permitir que estes frames recebidos sejam visualizados via
browser, se faz necessária a utilização de applets, este assunto foi abordado
na seção 2.3.
O trecho de código mostrado na figura 3.22 pertence a classe
RtpPlayer, que por sua vez estende a classe Applet .
43
Figura 3.22 - Classe RtpPlayer que estende Applet
Observa-se na classe apresentada na figura 3.22 que são utilizados os
métodos responsáveis por responder aos principais eventos de uma applet,
conforme foi mencionado na seção 2.3: init, start, stop e destroy.
Para que esta applet seja executada no browser é necessário invocá-la
dentro do código HTML, a figura 3.23 mostra a implementação deste código.
Figura 3.23 - Invocação da applet
44
3.3 DETALHES DE IMPLEMENTAÇÃO
Requisitos de hardware
• Dois computadores, desktop ou notebook com entrada Universal
Serial Bus (USB) em pelo menos um deles;
• Conexão com a Internet (banda larga);
• Uma webcam comum.
Requisitos de software
Cliente:
• Java Virtual Machine (JVM);
• Java Plug-in;
• API JMF 2.1.1;
• Navegador de Internet (Internet Explorer / Firefox).
Servidor:
• JRE 1.6.0_07;
• API JMF 2.1.1;
• Apache Tomcat 5.5;
• Servidor MySql 5.0;
• API JavaMail 1.4;
• Servidor 1st SMTPServer.
O sistema foi desenvolvido na linguagem Java, utilizando-se o Java
Development Kit (JDK) 1.6.0_07, juntamente com o Ambiente de
Desenvolvimento Integrado (IDE - Integrated Development. Environment)
Eclipse Europa 3.3.1 e o plug-in Web Tools Plataform (WTP) em plataforma
Windows XP SP3.
45
Problemas encontrados
Houve dificuldade na implementação do envio de frames via RTP para a
Internet, ou seja, da forma que foi implementado, os frames são transmitidos
somente para clientes da mesma rede.
Isto se deu pela impossibilidade de definição de um endereço IP de
destino que atendesse aos clientes da Internet, ou seja, o endereço IP de
transmissão de dados entre o servidor e o cliente que requisita os frames pela
Internet.
3.4 TESTES
Foram realizados testes funcionais e de integração entre o servidor (PC
Pentium IV, 3GHz, 2GB de memória RAM, 256 MB de memória de vídeo, com
conexão banda larga de 2MB) e cliente (Notebook Pentium Dual Core, 1.6GHz,
1GB de memória RAM, com conexão banda larga de 2MB).
No servidor foi conectada uma webcam comum e iniciada a aplicação, ou
seja, iniciou-se a captura dos frames e transmissão para a rede.
Em seguida foi pressionado o botão “Iniciar detecção” e ajustado por
várias vezes os níveis de sensibilidade e proporção da detecção. Percebeu-se
que conforme o nível diminuía, eram detectados menos movimentos e por
conseqüência eram geradas e gravadas quantidades menores de imagens.
Quanto ao envio de SMS, constatou-se que o processo foi realizado com
sucesso, segundos após a detecção (a cada 10 detecções) a mensagem foi
recebida no aparelho móvel. Porém, pode ocorrer atraso no envio já que a
mensagem é enviada à operadora e esta por sua vez pode estar com seu
serviço de entrega indisponível.
Logo após, no cliente abriu-se o browser e digitou-se o endereço:
http://IP_servidor:porta_servidor_apache/remote_eye. Assim abrindo-se a
página de login do sistema, conforme foi mostrada na figura 3.15 da seção 3.2.1.
Para um primeiro teste digitou-se os dados de login incorretamente,
sendo a página redirecionada para a tela de login inválido, conforme mostrou a
figura 3.16 da seção 3.2.1.
46
Após este teste, entrou-se com dados válidos de login, sendo a página
redirecionada para a tela principal do sistema e lá se iniciou o recebimento e
visualização dos frames em tempo real, conforme mostrou a imagem 3.17 da
seção 3.2.1.
Outro teste realizado foi o de cadastro de usuários. Pressionou-se o link
“Cadastro” da tela principal, abrindo-se uma nova janela do browser contendo a
tela de cadastro de usuários, juntamente com a listagem dos usuários já
cadastrados, conforme mostrou a figura 3.18 da seção 3.2.1. Nesta tela houve
três itens a serem testados: inserir novo usuário, atualizar dados de usuário
cadastrado e excluir usuário.
Na inserção de novo usuário, tentou-se a inserção digitando-se um login
existente e clicou-se no botão “Adicionar novo usuário”, o cadastro não foi
efetuado já que o login era existente. Alterando-se o login, o cadastro foi
efetuado com sucesso e a listagem de usuários foi atualizada automaticamente.
Na atualização de usuário, foi selecionado um usuário na listagem e em
seguida alterou-se algum dado, clicou-se no botão “Salvar usuário”, a
atualização foi efetuada com sucesso e a listagem de usuários foi atualizada
automaticamente.
Vale ressaltar que tanto na inserção como na atualização existe uma
verificação antecipada dos campos preenchidos, ou seja, os campos: login,
senha e perfil são obrigatórios.
No teste de exclusão, foi selecionado um usuário na listagem e em
seguida clicou-se no botão “Excluir usuário”, a exclusão foi efetuada com
sucesso e a listagem de usuários foi atualizada automaticamente.
O próximo teste realizado foi o de visualização das imagens gravadas em
disco pela detecção de movimento. Para isto, clicou-se no link “Imagens” da tela
principal do sistema, abrindo-se uma nova janela contendo um combo para a
seleção da data desejada.
Selecionando-se uma data, a listagem de imagens é construída da tela,
havendo após o carregamento da página a possibilidade de se clicar em
qualquer uma das imagens e visualizá-la em tamanho maior, conforme foram
mostradas nas imagens 3.19 e 3.20 da seção 3.2.1. Alterando-se a data, a
página foi recarregada e a listagem de imagens atualizada.
47
Realizou-se também o teste de logoff (sair) do sistema, clicando-se no link
“Logoff”, feito isto, a página é redirecionada a tela inicial de login, efetuando
internamente a limpeza das sessões do browser, para se provar que realmente
houve esta limpeza, tentou-se manualmente entrar em todas as telas
mencionadas acima, estas ações não foram possíveis, ou seja, o processo de
limpeza das sessões foi efetuado com sucesso.
4 CONCLUSÃO
Neste trabalho de conclusão de curso foi implementado um sistema de
monitoramento e segurança na linguagem Java. O sistema captura frames de uma
webcam comum e transmite estes frames em tempo real para clientes remotos via
protocolo RTP através dos métodos da API JMF.
O sistema possui também outras funcionalidades, as quais foram descritas nos
capítulos anteriores.
Antes iniciar a implementação do sistema, foi necessário o estudo da API JMF,
a qual foi abordada nas seção 2.1.
Os testes descritos na seção 3.4 mostraram que a utilização da API JMF junto
a aplicações Java que possuem o objetivo de capturar e transmitir mídia em tempo
real pela rede realmente funcionam.
Observou-se que devido ao conteúdo dos pacotes transmitidos sob a rede ser
vídeo, houve atrasos visíveis quando utilizada conexão com tamanho pequeno de
banda (conexão por linha discada).
O resultado final comprovou que todas as funcionalidades do sistema foram
atendidas com sucesso.
4.1 Contribuições
Este trabalho contribuiu para:
- demonstrar que é possível um sistema de monitoramento e
segurança com baixo investimento em equipamentos;
- permitir que clientes sejam notificados diante de eventos de
detecção na área de foco da webcam;
48
- permitir que usuários remotos visualizem a partir de qualquer
computador conectado a banda larga, o que está ocorrendo em
tempo real na área focada pela webcam e imagens gravadas pelo
evento de detecção.
4.2 Trabalhos futuros
O sistema implementado possui todas as funcionalidades básicas para
que o propósito inicial deste trabalho monográfico fosse atendido, porém, há
algumas funcionalidades e melhorias que poderão ser implementadas
futuramente, das quais podem ser citadas:
- Capturar, transmitir e receber frames em tempo real de mais de uma
webcam simultaneamente;
- Permitir a configuração das notificações por detecção de movimento,
como por exemplo, optar por notificação ou não e ainda poder selecionar
quais dispositivos móveis receberão os alarmes;
- Possibilitar a inicialização do servidor e configuração dos parâmetros do
sistema remotamente;
- Disponibilizar outros filtros para visualização das imagens gravadas;
- Exibir notificações no servidor para cada cliente conectado e
desconectado remotamente do sistema;
- Permitir selecionar a região dos frames na qual se deseja detectar os
movimentos.
49
REFERÊNCIAS BIBLIOGRÁFICAS
[1] Deitel, M. Harvey; Deitel, J. Paul. Java, como programar. 4.ed.. Tradução: Carlos Arthur Lang
Lisboa. Porto Alegre: Bookman, 2002. [2] Java Media Framework API Guide. Disponível on-line em http://java.sun.com/javase/technologies/desktop/media/jmf/2.1.1/guide/index.html. Acesso em Dezembro, 2008.
[3] JavaMail API Design Specification. Disponível on-line em http://java.sun.com/products/javamail/JavaMail-1.4.pdf. Acesso em Dezembro, 2008.
[4] Furgeri, Sérgio. Java 2: Ensino didático: Desenvolvendo e implementando aplicações. São Paulo: Érica, 2002.
[5] Assinatura de applets. Disponível on-line em http://www.das.ufsc.br/jacoweb/restrito/documentos/assinatura/index.htm. Acesso em Dezembro, 2008.
[6] RFC 3550 – RTP: A Transport Protocol for Real-Time Applications. Disponível on-line em http://tools.ietf.org/html/rfc3550. Acesso em Dezembro, 2008.
[7] RTP Real Time Protocol. Disponível on-line em http://www.gta.ufrj.br/grad/01_2/vidconf/rtp.html. Acesso em Dezembro, 2008.
[8] Kurniawan, Budi. Java para a Web com Servlets, JSP e EJB. Rio de Janeiro: Ciência Moderna, 2002.
[9] Introdução a Containers Web: A primeira aplicação web com Servlets. Disponível on-line em http://www.ucb.br/prg/professores/giovanni/disciplinas/2004-1/talp/material/jacques/html/servlets/intro.htm. Acesso em Dezembro, 2008.
[10] Uma visão geral sobre Threads. Disponível em http://www.revista.grupointegrado.br/campodigital/include/getdoc.php?id=135&article=42&mode=pdf. Acesso em Dezembro, 2008.
[11] Projeto Lejos. Disponível on-line em http://sourceforge.net/project/showfiles.php?group_id=9339. Acesso em Dezembro, 2008.