Gestão de interfaces gráficas com agentes JADE

Gestão de componentes gráficas com agentes
JADE
Xarevision SA
2009 / 2010
1060445 César Ricardo da Silva Teixeira

Gestão de componentes gráficas com agentes
JADE
Xarevision SA
2009 / 2010
1060445 César Ricardo da Silva Teixeira
Licenciatura em Engenharia Informática
Setembro de 2010
Orientador ISEP: Doutora Maria João Viamonte
Supervisor Externo: Engenheiro Sílvio Macedo

À minha família, aos meus amigos e à minha namorada,

Agradecimentos
Aos meus orientadores, Doutora Maria João Viamonte e Engenheiro Sílvio Macedo por
me terem acompanhado e aconselhado durante todo o estágio.
Ao Instituto Superior de Engenharia do Porto e aos seus docentes por me terem passado
todo o conhecimento adquirido.
À Xarevision SA por me ter dado a oportunidade de estagiar e concluir a minha
licenciatura.
Aos meus pais e irmão por estarem sempre ao meu lado e por me apoiarem quando foi
preciso.
Aos meus amigos, Ricardo Marques, Pedro Neves, Telmo Costa, Bruno Freitas, Filipe
Magalhães, Paulo Esteves, Pedro Esteves, Ricardo Esteves, Bruno Saraiva, Pedro Ferreira,
Ricardo Canastro, José Pais, Henrique Ribeiro, Tiago Costa, Mário Celso, por todos os
momentos que passamos juntos.
À minha namorada pelo apoio que me deu e pelos momentos que passámos juntos.

Nota de confidencialidade
A informação contida neste documento é considerada privilegiada e
confidencial. A posição da Xarevision sobre o uso da informação contida neste
documento é que a mesma só deve ser utilizada pelos docentes responsáveis pelo
estágio com o objectivo de validar o seu conteúdo para a sua análise e avaliação do
aluno. Nenhuma parte deste documento poderá ser reproduzida total ou parcialmente
por qualquer meio para informação de terceiros, sem a prévia autorização da
Xarevision. Partes ou a totalidade deste documento podem conter informações
técnicas sujeitas ou em processo de serem patenteadas ou protegidas por outras
formas de protecção da propriedade industrial e intelectual que consubstanciam, pelo
que os leitores deste documento se comprometem a assegurar a manutenção destas
condições de confidencialidade na consulta e armazenamento, presente e futuro, desta
informação.

Sistema de Gestão de Interfaces Gráficas
César Teixeira vi
Resumo
O trabalho desenvolvido insere-se num contexto de “Corporate Tv” e “Digital
Signage Networks”.
O sistema, baseado em agentes JADE, tem como componente principal um
agente controlador de ambientes gráficos presentes em terminais distribuídos
geograficamente onde são apresentados conteúdos multimédia.
Ao longo do estágio foram abordadas diversas tecnologias e muitas delas foram
aplicadas no sistema desenvolvido, como por exemplo: agentes JADE, Servidor Web
Multi-Threaded, Polling, Javascript OO, Adobe Flash, Castor Framework e SAJAX.
O desenvolvimento de um agente na plataforma JADE, responsável pela gestão
dos conteúdos a apresentar em terminais através de um navegador Web, permite obter
um sistema robusto, flexível, multi-plataforma e estável.
A criação e a utilização de um servidor Web para estabelecer a comunicação
entre o Agente e o navegador, utilizando a ferramenta SAJAX, permite uma troca
rápida e eficaz de informação entre os componentes que constituem a arquitectura do
sistema.
Por último, a implementação de funcionalidades tais como: Javascript Orientado
a Objectos, representação de diversos tipos de interfaces gráficas, mecanismos de
salvaguarda que permitam uma degradação gradual do sistema, pré-carregadores de
vídeos em Flash/ActionScript e a reprodução de vídeos em vários formatos num
navegador, fazem com que o sistema seja capaz de responder às necessidades da
empresa, adquirindo uma grande autonomia e robustez.
Palavras Chave (Tema): Agentes, Interfaces Gráficas, Conteúdos
Multimédia
Palavras Chave (Tecnologias): JADE, JAVA, Javascript, HTML,
Webserver, Actionscript

César Teixeira vii
Índice
Agradecimentos............................................................................................................iv
Nota de confidencialidade ............................................................................................v
Resumo .........................................................................................................................vi
Índice de Figuras ..........................................................................................................x
Notação e Glossário .....................................................................................................xi
1 Introdução.............................................................................................................1
1.1 Enquadramento............................................................................................................. 2
1.2 Apresentação do projecto/estágio ................................................................................ 2
1.2.1 Planeamento de projecto ........................................................................................................3
1.2.2 Reuniões de acompanhamento...............................................................................................4
1.3 Tecnologias utilizadas................................................................................................... 4
1.3.1 JADE (Java Agent DEvelopment) .........................................................................................5
1.3.2 SAJAX (Simple Ajax Toolkit)...............................................................................................5
1.3.3 Castor.....................................................................................................................................5
1.3.4 Polling....................................................................................................................................6
1.3.5 Adobe Flash ...........................................................................................................................6
1.3.6 Prototype – Javascript Orientado a Objectos .........................................................................6
1.3.7 Gson.......................................................................................................................................6
1.4 Xarevision ...................................................................................................................... 7
1.5 Contributos deste trabalho........................................................................................... 7
1.6 Organização do relatório.............................................................................................. 8
2 Contexto...............................................................................................................10
2.1 Área de Negócio........................................................................................................... 10
2.2 Agentes JADE.............................................................................................................. 10
2.2.1 Arquitectura JADE...............................................................................................................11
2.2.2 Agent Management System .................................................................................................12

César Teixeira 8
2.2.3 Directory Facilitator.............................................................................................................13
2.2.4 Ferramentas de Depuramento ..............................................................................................13
2.2.5 Agente..................................................................................................................................14
2.3 Castor Framework...................................................................................................... 16
2.4 Servidor Web............................................................................................................... 17
2.5 SAJAX.......................................................................................................................... 19
2.6 Front-end ..................................................................................................................... 19
2.6.1 Short-Polling........................................................................................................................22
3 Análise......................................................................................................................24
3.1 Análise de Requisitos .................................................................................................. 24
3.2 Arquitectura do Sistema............................................................................................. 25
3.2.1 Agente – Figura 12, 1) .........................................................................................................25
3.2.2 Servidor Web – Figura 12, 2)...............................................................................................27
3.2.3 Front-end (Navegador) – Figura 12, 3)................................................................................27
4 Descrição técnica .....................................................................................................29
4.1 O Agente....................................................................................................................... 29
4.1.1 Behaviours ...........................................................................................................................29
4.1.1.1 StartWebServer .................................................................................................................30
4.1.1.2 Controller ..........................................................................................................................30
4.1.1.3 CheckInternetConnection..................................................................................................33
4.1.1.4 RequestVideoBehaviour ...................................................................................................33
4.1.1.5 RequestTicketBehaviour...................................................................................................34
4.1.1.6 CheckDiskSpace e CheckCPUTemperature .....................................................................35
4.2 Classe Manager ........................................................................................................... 35
4.2.1 checkAndDownloadFiles .....................................................................................................35
4.2.2 isInternetReachable..............................................................................................................36
4.3 Servidor Web............................................................................................................... 36
4.3.1 ProcessaPost.........................................................................................................................37

César Teixeira 9
4.3.2 RequestVideo e RequestTicketService ................................................................................38
4.4 Front-end ..................................................................................................................... 38
4.4.1 Carregar/Reproduzir vídeos .................................................................................................45
4.4.2 Reprodução de vídeo............................................................................................................46
4.4.2.1 Flash Player.......................................................................................................................47
4.4.2.2 VLC Plugin API................................................................................................................49
4.4.2.3 Alternância de Vídeos.......................................................................................................50
4.5 Plano de Testes ............................................................................................................ 52
5 Conclusões................................................................................................................54
5.1 Resumo do relatório.................................................................................................... 54
5.2 Objectivos realizados .................................................................................................. 55
5.3 Outros trabalhos realizados ....................................................................................... 55
5.4 Conclusões do Projecto............................................................................................... 55
5.5 Limitações & trabalho futuro .................................................................................... 56
6 Apreciação final ......................................................................................................57
7 Bibliografia...............................................................................................................58
Anexo 1........................................................................................................................60
Requisitos para execução da aplicação............................................................................ 60
Anexo 2........................................................................................................................62
Diagrama de Classes Geral de um Xarepoint................................................................. 62
Anexo 3........................................................................................................................63
Diagrama de Classes Kiosk e QueueKiosk ..................................................................... 63
Anexo 4........................................................................................................................64
Diagrama de Classes Player ............................................................................................. 64

César Teixeira x
Índice de Figuras
Figura 1 – Terminal típico Xarevision...........................................................................2
Figura 2 - WBS (“Work Breakdown Structure”) ...........................................................4
Figura 3 - Arquitectecura Plataforma JADE...............................................................11
Figura 4 - Arquitectura Plataforma JADE (Simplificada)...........................................13
Figura 5 - Ciclo de vida de um Agente.........................................................................15
Figura 6 - Castor Framework ......................................................................................17
Figura 7 - Arquitectura Servidor Web .........................................................................18
Figura 8 – Template 1 ..................................................................................................20
Figura 9 – Template 2 ..................................................................................................21
Figura 10 – Template 3 ................................................................................................21
Figura 11 - Polling Cliente/Servidor............................................................................22
Figura 12 - Arquitectura do Sistema............................................................................25
Figura 13 - Diagrama de Classes Package “Xarepoint” ............................................26
Figura 14 - Modelo Página Base .................................................................................40
Figura 15 - Javascript Orientado a Objectos ..............................................................44
Figura 16 - Comunicação entre Javascript e Objecto Flash .......................................47
Figura 17 - Comunicação entre Javascript e Objecto VLC.........................................50

César Teixeira xi
Notação e Glossário
ACL “Agent Communication Language” – Linguagem de Comunicação
entre Agentes
Actionscript Linguagem de programação orientada a objectos que evoluiu dos
recursos de script do Flash Player
Adobe Flash Software utilizado para criação de animações interactivas que podem
ser inseridas em páginas web
AID “Agent Identifier” – Identificador de um Agente
AJAX “Asynchronous JavaScript And XML” – Javascript Assíncrono e
XML
AMS “Agent Management System” – Agente Controlador do Sistema
API “Application Programming Interface” – Interface de Programação
de Aplicações
ASP Active Server Pages
Browser Programa de computador que habilita os seus utilizadores de
interagirem com documentos virtuais da Internet
CASTOR “Open Source data binding framework for Java” – Plataforma em
código aberto para mapeamento de objectos relacionais
desenvolvido na linguagem Java
Container Objecto que contém outros objetos
CSS Cascading Style Sheet
DF “Directory Facilitator” – Páginas Amarelas
DOM “Document Object Model” – Modelo de Objecto de Documentos
FIPA Foundation for Intelligent Physical Agents – Fundação de Agentes
Inteligentes Físicos

César Teixeira xii
Front-end Interface gráfica que possibilita a interacção do utilizador com o
sistema
GSON Biblioteca de Java que converte objectos Java em JSON e vice-versa
GUI “Graphical User Interface” – Interface Gráfica do Utilizador
Host Máquina ou computador conectado a uma rede
HTML “HyperText Markup Language” –Linguagem de Marcação de
Hipertexto
HTTP “Hypertext Transfer Protocol” – Protocolo de Transferência de
Hipertexto
JADE “Java Agent Development” – Plataforma de desenvolvimento de
Agentes
Java Linguagem de programação orientada a objectos
Javascript Linguagem de programação utilizada essencialmente para validação
de formulários em páginas Web e interacção com essas mesmas
páginas
JSON Javascript Object Notation
Linux Termo utilizado para designar sistemas operativos que utilizem
núcleo Linux, sendo um dos mais conhecidos softwares livres
Lua Linguagem de programação poderosa, rápida e leve, utilizada para
estender aplicações
Mozilla
Firefox
É um navegador livre e multi-plataforma desenvolvido pela Mozilla
Foundation
Open Source O mesmo que código aberto, refere-se a software livre
Perl Linguagem de programação estável e multi-plataforma, utilizada no
desenvolvimento de aplicações Web
PHP “Hypertext Preprocessor” – Pré-processador de Hipertexto
Plugin Adicionar funções a outros programas maiores, provendo-os de

César Teixeira xiii
alguma funcionalidade especial ou muito específica
Python Linguagem de programação de alto nível, orientada a objectos e
fortemente tipada
RMA “Remote Management Agent” – Agente Gestor Remoto
Ruby Linguagem de programação fortemente tipada, com gerenciamento
de memória automática
SAJAX “Simple AJAX Toolkit” – Ferramenta de AJAX simplificada
Script Pequenos programas que apoiam outros programas e que efectuam
determinadas tarefas
SGBD Sistema de Gestão de Base de Dados
SQL “Structured Query Library” – Linguagem de Consulta Estruturada
Stream Fluxo de dados num sistema computacional
Thread Possibilita a divisão de um processo em uma ou mais tarefas, que
podem ser executadas concorrentemente
Ubuntu Sistema operativo baseado em Debian, em código aberto, em torno
do núcleo GNU/Linux
VLC Player multimédia em código aberto, capaz de reproduzir quase
todos os formatos de vídeo
WebGL API que permite a reprodução e inserção de aplicações gráficas 3D
em navegadores Web sem a necessidade de Plugins, servindo-se do
elemento Canvas do HTML5
Webserver Programa de computador responsável por aceitar pedidos HTTP de
clientes, geralmente navegadores (“browsers”), e servi-los com
respostas HTTP, como por exemplo páginas web
Windows Sistema operativo criado pela empresa Microsoft
XML “Extensible Markup Language” – Linguagem Padronizada de
Marcação Genérica

César Teixeira 1
1 Introdução
Num mundo onde a informática possui cada vez mais importância e influência
no dia-a-dia da sociedade, torna-se importante e por vezes fundamental o
desenvolvimento de sistemas capazes de realizar operações gradualmente mais
complexas, de forma automática e autónoma.
É neste contexto que os agentes inteligentes assumem um grande protagonismo,
proporcionando aos sistemas robustez, flexibilidade e acima de tudo, grande
autonomia.
Os agentes podem ser baseados em software ou hardware e caracterizam-se,
entre outras, pelas seguintes propriedades:
-Autonomia: possuem a capacidade de controlar as suas próprias acções, não
necessitando de intervenção humana;
-Capacidade Social: comunicam com humanos ou outros agentes de software
ou hardware;
-Reacção: têm percepção do ambiente em que estão inseridos e respondem
atempadamente às alterações que ocorram;
-Proactividade: são capazes de exibir comportamentos guiados por objectivos
e de tomar a iniciativa;
Uma possível definição de agentes é a de que são entidades computacionais que
funcionam de forma contínua e autónoma num ambiente restrito. São “alguém” ou
“algo” que toma decisões e executa as acções, podendo estas servir de auxílio, ou até
mesmo em substituição, ao trabalho humano. Sendo estas acções consideradas como
benéficas ao sistema dentro do contexto onde este se insere.
Ferber e Gasser (1991 – ver bibliografia) definem agente como “uma entidade
real ou abstracta que é capaz de agir sobre ela mesma e sobre seu ambiente, que
dispõe de uma representação parcial deste ambiente que, em um universo multi-
agente, pode comunicar-se com outros agentes, e cujo comportamento é consequência
de suas observações, do seu conhecimento e das interacções com outros agentes”.

César Teixeira 2
1.1 Enquadramento
O estágio desenvolvido enquadra-se na disciplina de Projecto/Estágio, que
integra o último semestre do último ano da licenciatura em Engenharia Informática do
Instituto Superior de Engenharia do Porto.
O estágio foi desenvolvido na empresa Xarevision SA e teve como objectivo o
desenvolvimento de um sistema baseado em agentes capaz de fazer a gestão e
manutenção de interfaces gráficas de terminais distribuídos geograficamente.
1.2 Apresentação do projecto/estágio
Este estágio teve como objectivo o desenvolvimento de um sistema
multi-agente, baseado na plataforma JADE, para fazer a gestão de interfaces gráficas
de terminais distribuídos geograficamente. Paralelamente, pretendia-se que a
apresentação dos conteúdos fosse feita com recurso a tecnologias Web.
Figura 1 – Terminal típico Xarevision
Uma vez que a apresentação de conteúdos nos terminais seria feita via browser,
um dos principais objectivos era o de proporcionar autonomia e flexibilidade ao
sistema, sem comprometer a performance na reprodução de uma lista de vídeos ou a

César Teixeira 3
complexidade de controlo, sendo este um dos pontos mais importantes do trabalho e
simultaneamente o mais crítico.
As tecnologias Web permitem obter um sistema mais robusto, multi-plataforma,
capaz de responder às necessidades da organização. Acresce que o facto de as
tecnologias web estarem em constante evolução proporciona um conjunto cada vez
maior de soluções para problemas e funcionalidades que poderão surgir ou desejar-se
no futuro.
Uma das inovações deste projecto foi o desenvolvimento de um servidor Web
“Multi-threaded” em Java capaz de garantir a comunicação entre o agente e o
browser, permitindo também o tratamento tanto de eventos criados e provocados por
acções de humanos (interacção pessoa-máquina), como de possíveis alterações nas
interfaces, caso o sistema assim o exigisse.
1.2.1 Planeamento de projecto
Para planear o projecto foi feita, no início do projecto, a WBS (“Work
Breakdown Structure”) que se apresenta na figura seguinte. Foram desta forma
planeadas as seguintes actividades:

César Teixeira 4
Figura 2 - WBS (“Work Breakdown Structure”)
1.2.2 Reuniões de acompanhamento
Todas as reuniões com a Doutora Maria João Viamonte, a orientadora do ISEP,
foram feitas quando necessário, de forma informal, não sendo por isso registados os
dias ou os assuntos que nelas se trataram. No entanto, as reuniões serviram
principalmente para dar apoio na realização do relatório final, numa tentativa de
manter sempre a organização necessária, impossível de manter sem esse apoio.
1.3 Tecnologias utilizadas
Nesta secção será feita uma breve abordagem das tecnologias utilizadas para o
desenvolvimento do sistema proposto. Para cada tecnologia é oferecida uma descrição
sucinta, indicando as principais características e funcionalidades.

César Teixeira 5
1.3.1 JADE (Java Agent DEvelopment)
JADE (Java Agent Development) é uma plataforma totalmente implementada
na linguagem Java. É uma plataforma que simplifica o desenvolvimento e a
implementação de sistemas multi-agente, de acordo com as especificações FIPA
(Foundation for Intelligent Physical Agents). A plataforma possui também um
conjunto de ferramentas que permitem e facilitam o depuramento das aplicações. Os
agentes podem estar distribuídos por diferentes máquinas, mesmo que não partilhem o
mesmo sistema operativo, sendo também possível configurar esses mesmos agentes
remotamente a partir da GUI (“Graphical User Interface”) disponibilizada pela
plataforma.
1.3.2 SAJAX (Simple Ajax Toolkit)
SAJAX é uma ferramenta baseada na plataforma AJAX (Assynchronous
Javascript And XML) e que é utilizada para desenvolver páginas Web. O uso de Sajax
simplifica a chamada de métodos desenvolvidos noutras linguagens como ASP, Cold
Fusion, Io, Lua, Perl, PHP, Python ou Ruby numa página Web sem ter que fazer o
recarregamento da mesma. Esta ferramenta cria uma função “stub” em Javascript que
chama métodos exportados pelo “script”. Esta solução mantém a ligação e todas as
informações necessárias, assim como, chama um método de “callback” para tratar os
dados retornados pelos métodos exportados. Os dados passados entre métodos são
codificados em JSON (Javascript Object Notation) e quando retornados ao “script”
são transformados em objectos Javascript.
1.3.3 Castor
Castor é uma plataforma que permite carregar objectos Java a partir de um
XML (Extensible Markup Language), “marshalling”. O processo inverso, de gerar
um XML a partir de objectos Java dá-se pelo nome de “unmarshalling”. O Castor
permite também a persistência entre Java e SQL (Structured Query Language). O
carregamento dos objectos pode ser feito através de um ficheiro de “mapping” no
qual são indicadas as classes existentes em Java e a correspondência entre os
elementos/atributos do XML e os atributos dessas mesmas classes.

César Teixeira 6
1.3.4 Polling
Polling é uma tecnologia que permite uma comunicação bilateral entre o
servidor Web e o navegador Web sendo utilizada para passar informação de um
servidor para uma página Web.
1.3.5 Adobe Flash
Adobe Flash, antes conhecido por Macromedia Flash, ou simplesmente Flash, é
um “software” capaz de suportar imagens “bitmap” e vídeo, e é utilizado geralmente
para a criação de animações interactivas que funcionam embutidas num navegador
Web. As animações geradas pelo Adobe Flash têm a extensão “.swf”, e podem ser
visualizados num navegador web, desde que neste esteja presente um “plugin”
especial, ou então, através do “Flash Player”, que é uma aplicação gratuita, apenas de
leitura, fornecida pela Adobe.
1.3.6 Prototype – Javascript Orientado a Objectos
Prototype é uma plataforma em código aberto, desenvolvida em Javascript,
tendo como principais vantagens ser muito bem estruturado, ser modular e
essencialmente ser orientado a objectos.
1.3.7 Gson
Gson é uma biblioteca de Java capaz de converter objectos Java na sua
representação em JSON. Pode também fazer o processo inverso, convertendo uma
“string” JSON num objecto Java. Esta biblioteca permite a utilização de classes Java
já existentes, mesmo que não se tenha acesso ao código fonte das mesmas.

César Teixeira 7
1.4 Xarevision
A Xarevision SA é uma empresa especializada no desenvolvimento e
exploração de tecnologias que permitem gerir, de forma optimizada, redes dispersas
de “displays” interactivos, criando novos paradigmas de comunicação.
Actua principalmente no desenvolvimento de redes privadas de televisão –
“Corporate Tv” e “Digital Signage Networks” - desenvolvendo meios especializados
para uma comunicação local e contextualizada, complementando outras iniciativas
comunicacionais e de marketing levadas a efeito pelas marcas nas grandes superfícies.
A Xarevision SA pretende criar e explorar novos paradigmas de comunicação:
 mais eficazes;
 com maior impacto;
 mais dirigidos;
 com menores custos,
permitindo maximizar a sua influência na acção e decisão de compra.
1.5 Contributos deste trabalho
Este projecto dota a organização de um sistema multi-plataforma, robusto,
tolerante a falhas, capaz de garantir bons níveis de performance na reprodução de
listas de vídeos, via browser, nos devidos terminais.
O uso de agentes introduz no sistema a capacidade de ser autónomo, proactivo e
reactivo a situações que surjam no ambiente, onde o sistema será inserido, sem ser
necessária a intervenção humana.
A implementação de um paradigma de orientação a objectos em Javascript é
uma mais-valia e um contributo importante, dado que esta linguagem não é
verdadeiramente orientada a objectos. A utilização deste paradigma possibilitou a
criação de classes e objectos, assim como a utilização de herança e uma forma de
polimorfismo entre as classes desenvolvidas.

César Teixeira 8
A arquitectura é também uma grande vantagem do sistema desenvolvido. A
utilização de componentes como um “browser” (sistema aberto) e um sistema
distribuído (com a utilização de agentes) que são independentes de plataforma,
fornecem robustez ao sistema desenvolvido.
O sistema de comunicação entre os componentes existentes torna o sistema
ainda mais robusto, utilizando o AJAX e um servidor Web “multi-threaded”,
permitindo assim uma gestão autónoma por parte do cliente (navegador Web), quando
o agente controlador não é capaz de realizar as suas funções.
Trata-se, portanto, de uma arquitectura que permite implementar mecanismos de
salvaguarda para suportar uma degradação gradual do sistema.
O estudo e a utilização de uma ferramenta como o SAJAX foi outro dos grandes
contributos deste trabalho, pelas melhorias que foram introduzidas. Uma vez que no
SAJAX não era possível a comunicação com Java, foi necessário encontrar soluções
inovadoras para o tornar possível. Outra grande vantagem da utilização desta
ferramenta foi a de facilitar o manuseamento da informação recebida pelo “browser”,
uma vez que utiliza a linguagem JSON e objectos Javascript, ao contrário do habitual
XML, utilizado pelo AJAX.
Finalmente, um outro contributo para o bom desempenho do sistema é o facto
de terem sido desenvolvidos mecanismos de gestão de vídeos, assim como
pré-carregadores de vídeos, de modo a garantir que nunca existam vídeos incompletos
ou em falta.
1.6 Organização do relatório
Este relatório está dividido em cinco partes:
O primeiro capítulo, o da Introdução, onde se pretende dar uma visão geral do
trabalho desenvolvido, abordando as principais características do sistema e as
principais tecnologias utilizadas.
Um segundo capítulo, o do Contexto, onde se descreve com algum detalhe as
tecnologias utilizadas no decorrer do projecto, principais características e
funcionalidades das mesmas, assim como a sua importância no projecto.

César Teixeira 9
No terceiro capítulo encontra-se a Análise, onde se pretende ter uma visão geral
do problema a resolver, assim como as soluções escolhidas. Neste capítulo é
efectuado o levantamento de requisitos. Por último, é apresentada uma proposta da
arquitectura do sistema, para melhor compreender a solução implementada.
Na Descrição Técnica, quarto capítulo deste relatório, faz-se uma análise
detalhada ao projecto desenvolvido durante o estágio. É neste capítulo que se analisa
com detalhe a arquitectura do sistema, descrevendo ao pormenor todo o processo de
execução do sistema desenvolvido, incluindo explicações dos métodos mais
importantes.
No último capítulo, o das Conclusões, é feita uma comparação entre os
objectivos definidos no primeiro capítulo (Introdução) e os objectivos cumpridos,
sendo também feita uma auto-análise crítica ao desempenho do autor.

César Teixeira 10
2 Contexto
2.1 Área de Negócio
A empresa Xarevision S.A, onde foi realizado o estágio curricular, é uma
empresa que opera sobre grandes redes de ecrãs distribuídos geograficamente, que
fazem a apresentação de conteúdos multimédia.
Com a recente expansão da empresa, surgiu a necessidade de optimizar o
sistema existente. Possuir um sistema multi-plataforma, essencialmente para redução
de custos por parte da empresa, como por exemplo na aquisição de licenças de
sistemas operativos, era um dos grandes objectivos e requisito para o sistema a
desenvolver. A possibilidade de ser implementado em vários sistemas operativos,
concebe ao sistema uma mais-valia.
Uma vez que a empresa lida com sistemas críticos, a robustez do sistema é de
extrema importância, sendo assim possível a tolerância a falhas.
Uma outra necessidade da empresa era dispor de um sistema autónomo, capaz
de tomar decisões locais, garantindo que a gestão dos conteúdos apresentados nos
terminais fosse feita o mais automatizada possível. A apresentação dos conteúdos
multimédia nos terminais seria feita com recurso a tecnologias web, pelo que a
necessidade de obter um sistema capaz de apresentar vários conteúdos de vários
formatos era um requisito obrigatório.
2.2 Agentes JADE
O sistema desenvolvido é baseado em agentes. Um sistema multi-agente
permite também fornecer um sistema distribuído, uma vez que os agentes podem
comunicar com outros agentes localizados em dispositivos separados
geograficamente.
Para o desenvolvimento desta aplicação, optou-se por utilizar a plataforma
JADE (Java Agent DEvelopment). O facto da plataforma JADE ser totalmente

César Teixeira 11
implementada na linguagem JAVA permite obter um sistema multi-plataforma,
possível de ser executado em qualquer sistema operativo.
Uma grande vantagem na utilização JADE é a comunicação entre agentes, pois
possui uma arquitectura que possibilita uma troca de mensagens flexível e eficiente
suportada em múltiplos protocolos alternativos.
Toda a comunicação entre agentes é feita através da troca de mensagens, onde a
FIPA ACL (“Agent comunication Language”) é a linguagem que as representa. É da
responsabilidade da plataforma efectuar a gestão das mensagens trocadas entre os
diversos agentes registados na mesma. Para tal, o JADE gere uma fila de mensagens
recebidas (mensagens ACL) privadas entre agentes. Paralelamente, cada agente possui
uma fila de mensagens recebidas às quais pode aceder e eventualmente responder.
2.2.1 Arquitectura JADE
Na figura seguinte é apresentada a arquitectura do JADE, assim como os
principais elementos que a constituem.
Figura 3 - Arquitectecura Plataforma JADE

César Teixeira 12
Uma aplicação desenvolvida em JADE é constituída por um conjunto de
agentes, onde cada um possui um nome único.
Os agentes de cada aplicação executam numa plataforma. Essa plataforma tem a
capacidade e a responsabilidade de fornecer os serviços básicos aos agentes que nela
residem, tais como a troca de mensagens.
Uma plataforma por sua vez é constituída por um ou mais contentores
(“containers”). Cada contentor pode ser executado em diferentes computadores
(“hosts”) e pode possuir zero ou mais agentes. Existe ainda um contentor especial na
plataforma, denominado Contentor Principal (“Main Container”).
O Contentor Principal, embora se trate de um contentor normal onde podem
existir agentes, difere de todos os outros contentores pelo facto de necessitar de ser o
primeiro contentor a ser iniciado na plataforma e de todos os outros contentores se
registarem nele para poderem operar.
O Contentor Principal possui, ainda dois agentes especiais: o AMS (“Agent
Management System”) e o DF (“Directory Facilitator”), também designado por
páginas amarelas (“Yellow Pages”) por ser essa a sua função.
2.2.2 Agent Management System
O agente AMS é o responsável pela supervisão, acesso e utilização da
plataforma.
Qualquer Agente que queira operar numa plataforma tem previamente que se
registar junto do agente AMS, sendo-lhe atribuído por este um endereço AID (“Agent
Identifier”) válido.
O agente AMS é responsável por manter a directoria dos identificadores dos
agentes. É igualmente responsável por guardar o estado de cada agente.
Existe apenas um agente AMS em cada plataforma.

César Teixeira 13
2.2.3 Directory Facilitator
O agente DF é responsável pelo fornecimento de um serviço de páginas
amarelas, no qual os outros agentes podem registar os seus serviços. Assim, quando
um agente se junta à plataforma pode pesquisar junto do agente DF por outros agentes
ou por serviços disponibilizados nesse DF por outros agentes.
Figura 4 - Arquitectura Plataforma JADE (Simplificada)
2.2.4 Ferramentas de Depuramento
O JADE possui ainda um conjunto de ferramentas que ajudam no
desenvolvimento de aplicações para efeitos de depuramento, tais como, “Remote
Monitoring Agent”, “Dummy Agent”, “Sniffer Agent”, “Instropector Agent”,
“Directory Facilitator GUI”:
1. “Remote Monitoring Agent” – trata-se de um agente que implementa uma
consola gráfica para controlo da plataforma, onde podem ser consultados
os estados dos agentes e dos “containers”. Pode existir mais que um
agente RMA na mesma plataforma. No entanto, apenas um agente RMA
pode estar presente num “container;
2. “Dummy Agent” – ferramenta que permite a monitorização e o
depuramento de aplicações. Permite também enviar, receber e visualizar
mensagens ACL trocadas entre agentes;
3. “Sniffer Agent” – através desta ferramenta podem ser espiados agentes.
Pretende-se obter acesso a todas as mensagens dirigidas ou enviadas por
esse agente. No caso de algum agente ou “container” ser criado ou

César Teixeira 14
destruído, o agente “Sniffer Agent” é avisado de imediato pelo agente
RMA;
4. “Instropector Agent” – monitoriza o ciclo de vida de um agente, ou seja,
controla as mensagens enviadas, recebidas e a fila de comportamentos de
um determinado agente;
5. “Directory Facilitator GUI” – fornece serviços de páginas amarelas, no
qual os agentes podem registar os seus serviços ou pesquisar por outros
agentes. Em cada plataforma existe pelo menos um agente DF.
2.2.5 Agente
A classe “Agent” representa uma base comum para definição de agentes. Do
ponto de vista do programador, um agente JADE é simplesmente uma instância de
uma classe Java que estende a classe “Agent”, o que implica uma herança das
características desta, que garante um conjunto de funções básicas para interagir com a
plataforma que o suporta, tais como o registo, a configuração, etc.
Os agentes caracterizam-se por serem multitarefa. Em cada agente, as tarefas,
também conhecidas por comportamentos, são escalonadas sequencialmente e
executadas concorrentemente.
Cada agente é executado numa “thread” separada e podem possuir um conjunto
de métodos, os referidos comportamentos (“behaviours”).
Um agente quando é iniciado possui um método “setup”, no qual são feitas
todas as inicializações, e onde também são adicionados os comportamentos
(“behaviours”) desse agente.
Os “behaviours” podem ser de vários tipos, dependendo da funcionalidade que
cada um terá:
 “OneShotBehaviour” – executados uma vez;
 “CyclicBehaviour” – executados repetidamente;
 “TickerBehaviour” – executados em intervalos de tempos definidos
aquando da sua criação.

César Teixeira 15
É possível o utilizador definir outros modelos de execução, adicionando
comportamentos a qualquer momento.
Cada agente possui um ciclo de vida, representado pela imagem que se segue.
Figura 5 - Ciclo de vida de um Agente
Um agente JADE pode assumir vários estados de acordo com o ciclo de vida da
plataforma onde se inserem, tal como está representado na figura anterior.
Segue-se uma descrição breve de cada um dos estados:
1. Inicial (“Iniciated”) – estado no qual é criado o objecto agente. Neste
estado o agente ainda não está registado no AMS, não tem um nome
(identificador), um endereço e não pode comunicar com outros agentes;
2. Activo (“Active”) – Agente regista-se no AMS, tem um nome e um
endereço e pode aceder a todas as funcionalidades do JADE;
3. Suspenso (“Suspended”) – O objecto agente está parado. A “thread” do
agente está suspensa e nenhum comportamento (“behaviour”) está a ser
executado;

César Teixeira 16
4. Em espera (“Waiting”) – O objecto do agente está bloqueado. A sua
“thread” está adormecida sendo notificada quando alguma condição é
satisfeita, normalmente quando recebe uma mensagem;
5. Morto (“Deleted”) – O agente está morto, a “thread” terminou a sua
execução e não existe mais nenhum registo desse agente no AMS;
6. Transição (“Transit”) – Um agente passa para este estado quando está a
migrar para uma nova localização. Entretanto, o sistema continua a
guardar as mensagens que serão posteriormente enviadas para a nova
localização quando terminar a migração.
2.3 Castor Framework
Castor é uma framework em código aberto (“open source”) totalmente
desenvolvida em Java. O Projecto Castor é formado por dois grandes programas: o
Castor JDO, responsável pela persistência dos objectos Java para os Sistemas de
Gestão de Base de Dados (SGBD); e o Castor XML que tem a função de converter
objectos Java para XML e vice-versa.
No contexto do sistema desenvolvido, foi utilizado o Castor XML. Esta
plataforma, na maioria dos casos utiliza um conjunto de “ClassDescriptors” e
“FieldDescriptors” para saber como é que os objectos Java podem ser gerados a partir
de um XML ou convertidos num XML. O processo de converter objectos Java em
XML (converter um objecto numa “stream” – sequência de “bytes”) é conhecido por
“marshalling”, enquanto que o processo de gerar objectos Java a partir de um XML
(converter um “stream” num objecto) é conhecido por “unmarshalling”.
Os processos de “marshalling” e “unmarshalling” podem ser efectuados de três
modos diferentes:
 “introspection mode”;
 “mapping mode”;
 “descriptor mode” (ou “generation mode”).

César Teixeira 17
O modo “introspection mode” é o mais simples de utilizar pelo utilizador, pois
não requer nenhuma configuração anterior. Neste modo, não é necessário desenvolver
nenhum ficheiro de mapeamento nem indicar à plataforma nenhuma classe pré-
definida – implica no entanto que as classes em causa suportem introspecção. Quando
utilizado este modo, a plataforma é responsável pela ligação entre os elementos
presentes num XML e os atributos e classes existentes em Java, de forma automática.
No modo “mapping mode” o utilizador é responsável por definir um ficheiro de
mapeamento, manualmente, no qual especifica uma configuração própria.
Informações como a relação entre os elementos no ficheiro XML e as classes e
atributos, bem como os métodos a utilizar durante a execução da plataforma são
definidas neste ficheiro de mapeamento.
O modo “descriptor mode” ainda não foi definido pelo próprio projecto.
Segue-se uma imagem que demonstra o funcionamento da framework Castor.
Figura 6 - Castor Framework
2.4 Servidor Web
Um servidor Web pode ser um programa de computador que é responsável por
aceitar pedidos HTTP de clientes (normalmente efectuados por navegadores), e
responder a esses pedidos, podendo nessas respostas incluir dados, como por exemplo
documentos HTML com objectos embutidos. Um servidor Web pode também ser

César Teixeira 18
definido como um computador que executa um programa com as funcionalidades
acima descritas.
Neste projecto, este é o componente responsável pela comunicação entre o
agente e o navegador.
Foi desenvolvido um servidor Web “multi-threaded”, tendo por base um
servidor Java disponibilizado pela empresa Java Sun, para possibilitar a comunicação.
Desta forma podem ser recebidos e tratados múltiplos pedidos HTTP efectuados pelo
navegador.
O servidor, quando iniciado, executa “Worker Threads” que ficam à escuta na
porta 80. Quando algum pedido chega a esta porta o servidor notifica uma das
“Worker Threads”, que se encontram no modo “wait”, sendo o pedido tratado.
Quando o pedido é finalizado a “Worker” que foi responsável pelo seu
tratamento é posta de novo no modo “wait”, passando novamente para a situação de à
escuta, na porta 80, de novos pedidos.
Figura 7 - Arquitectura Servidor Web

César Teixeira 19
Uma vez que o servidor base não suportava pedidos POST, foram
desenvolvidas e adicionadas funcionalidades ao mesmo para que este suporte passasse
a ser possível.
Para fazer os pedidos HTTP por parte do navegador foi utilizada a tecnologia
SAJAX (“Simple Ajax Toolkit”).
2.5 SAJAX
SAJAX é uma ferramenta de programação para o desenvolvimento de páginas
Web, que utiliza a framework AJAX (também conhecida por “XMLHTTPRequest”).
Esta ferramenta pretende tornar, o mais fácil possível, o desenvolvimento dessas
mesmas páginas.
O SAJAX permite exportar métodos noutras linguagens, de modo a poderem ser
chamados via Javascript. Quando um pedido SAJAX é efectuado é definido um
método de resposta que irá receber e tratar a resposta do servidor (equivalente ao
“onreadystatechange” do AJAX), assim que for possível. Esta tecnologia suporta
chamadas de funções em ASP, Cold Fusion, Io, Lua, Perl, PHP, Python ou Ruby, mas
não de Java.
Uma vez que esta tecnologia não suporta a comunicação com Java, foi
desenvolvida uma solução para permitir essa comunicação, sendo este mais um dos
resultados do projecto.
2.6 Front-end
O Front-end é o componente responsável pela apresentação dos conteúdos no
terminal. É neste módulo que existe interacção pessoa-máquina, directa ou indirecta, o
que obrigou a uma grande atenção e dedicação no seu desenvolvimento. Foi
necessário implementar mecanismos de salvaguarda que dessem suporte a uma
degradação gradual de desempenho do sistema.

César Teixeira 20
O navegador possui a responsabilidade de manter a reprodução de conteúdos
multimédia contínua (lista de vídeos), mesmo nos casos em que o agente controlador
do terminal não esteja em condições de completar as suas tarefas.
O terminal pode ter vários tipos de “templates” associados. Podem ser terminais
com a finalidade de interagir directamente com clientes, existindo portanto conteúdos
que possibilitem eventos, tais como botões. Podem também ser terminais em que a
sua finalidade é unicamente informativa, tais como resumos de filas de serviços,
metereologia, notícias, agendas, eventos.
Seguem-se alguns exemplos de “templates” possíveis de serem representados,
de acordo com o contexto em que o sistema se insere.
Figura 8 – Template 1

César Teixeira 21
Para fazer a apresentação dos conteúdos optou-se por utilizar uma página Web
com o apoio de um navegador ou “browser”, neste caso o Mozilla Firefox. A
utilização de um navegador torna o sistema mais estável, multi-plataforma e aberto.

César Teixeira 22
Este módulo é maioritariamente desenvolvido em Javascript com recurso a
tecnologias para comunicação entre a página Web e o agente, construção do
“template” do terminal e reprodução contínua de uma lista de vídeos.
Sendo o Front-end a parte do sistema que mantém uma interacção directa ou
indirecta com as pessoas, foi necessário desenvolver soluções para garantir um
sistema fluido, tolerante a falhas e agradável de ser visualizado.
Todo este módulo é controlado por um agente, mas em caso de falha deste, o
módulo de Front-end tem a capacidade de tomar decisões sobre os seus conteúdos, de
modo a não ser imediatamente notória a falha de parte do sistema.
2.6.1 Short-Polling
O “polling” é uma tecnologia utilizada para efectuar pedidos de informação a
um servidor, com recurso ao AJAX por ser uma tecnologia muito leve, de forma
contínua, mantendo os conteúdos apresentados no terminal sempre actualizados. Os
pedidos são iniciados pelo cliente.
Segue-se uma imagem que demonstra a comunicação entre o cliente e o
servidor.
Figura 11 - Polling Cliente/Servidor

César Teixeira 23
Se o servidor possuir informação para enviar ao cliente, essa informação é
devolvida imediatamente em resposta ao pedido (1). Caso não exista informação a
devolver do lado do servidor, o pedido é “adormecido” no servidor. Após alguns
segundos (definidos no servidor) é devolvida uma resposta a esse pedido (2).
Em ambos os casos, quando uma resposta é recebida, pela página, é efectuado
de imediato um novo pedido de informação ao servidor.

César Teixeira 24
3 Análise
No início do estágio efectuou-se uma análise do sistema a desenvolver, tendo
em conta o problema apresentado e o tipo de solução pretendida para o problema. Na
secção seguinte são apresentados os resultados da análise de requisitos.
3.1 Análise de Requisitos
Os requisitos do sistema são enumerados a seguir e demonstram as
características que o sistema deverá possuir depois de desenvolvido.
Requisitos Função
Sistema Multi-plataforma Evitar custos na obtenção de licenças de
sistemas operativos proprietários
Sistema Robusto Tolerante a falhas, em que falhas no
sistema não comprometam totalmente o
funcionamento do terminal garantindo a
reprodução de conteúdos,
independentemente do estado do agente
controlador e da conectividade à rede
Sistema Aberto Possibilidade de reproduzir vários tipos
de conteúdos multimédia nos terminais e
permitir futuros desenvolvimentos
Sistema Autónomo Reduzir a necessidade de intervenção
humana tanto quanto possível e permitir
reactividade e pro-actividade local
Reprodução de vídeos contínua Reprodução contínua de vídeos, tornando
imperceptível quebras na sucessão dos
mesmos

César Teixeira 25
3.2 Arquitectura do Sistema
Com base nos requisitos levantados, foi desenvolvida uma arquitectura para o
sistema, assim como foram abordadas e estudadas as tecnologias a utilizar.
A figura seguinte propõe uma arquitectura para o sistema desenvolvido:
Figura 12 - Arquitectura do Sistema
Tal como o desenho da arquitectura sugere, o sistema desenvolvido é composto
por três grandes componentes: Agente (1), Servidor Web (2) e Front-end (3). Todos
os componentes estão interligados e comunicam entre si.
3.2.1 Agente – Figura 12, 1)
O agente, desenvolvido na plataforma JADE, é o componente com mais
relevância no sistema, pois é quem controla todo o sistema. É o agente que tem a
AJAX
Castor
HTTP
Requests

César Teixeira 26
responsabilidade de comunicar com o exterior e requisitar informação a um servidor
externo, através de pedidos HTTP. É também neste componente da arquitectura que
toda a informação é tratada e armazenada em memória.
Segue-se o diagrama de classes relativo módulo do agente na arquitectura:
Figura 13 - Diagrama de Classes Package “Xarepoint”
A classe ControllerAgent é onde está desenvolvido o agente controlador do
terminal, incluindo todos os comportamentos do mesmo. Para a obtenção de
conteúdos multimédia, o agente depende da classe Manager. Por último, a
comunicação com o navegador é conseguida através da classe WebServer.
Para terminar, no componente do agente foram também desenvolvidos
comportamentos para que fosse possível responder a situações que pudessem ocorrer
no dia-a-dia, como por exemplo, consultar temperaturas do processador, espaço
disponível em disco e conectividade à Internet. Todos estes comportamentos
desenvolvidos tornam o sistema mais autónomo e robusto, de modo a permitir que a
necessidade de intervenção humana seja cada vez menor.

César Teixeira 27
3.2.2 Servidor Web – Figura 12, 2)
Outro componente do sistema desenvolvido é o Servidor Web inserido no
próprio agente. Este é o componente responsável pela comunicação entre o agente e o
navegador.
Optou-se por utilizar um servidor “multi-threaded” desenvolvido em Java, para
permitir responder a vários pedidos do navegador em simultâneo, tendo sido
necessário adicionar um conjunto de funcionalidades adicionais, para garantir que o
servidor fosse capaz de responder às necessidades do projecto a desenvolver.
O servidor tem como função receber pedidos enviados pelo navegador, como
por exemplo, descarregar um novo vídeo, processar um evento de um botão ou
requisitar actualizações do “template”.
3.2.3 Front-end (Navegador) – Figura 12, 3)
O último componente presente na arquitectura é o Browser. Este é o
componente onde os conteúdos são apresentados.
É, depois do agente, o componente mais importante do sistema desenvolvido,
uma vez que, sendo o componente que apresenta os conteúdos, estabelece um
contacto visual com os clientes, logo, qualquer deficiência ao nível do sistema pode
ser observada neste componente.
Uma vez que a página Web não toma decisões, pretende-se que faça apenas a
apresentação dos conteúdos, efectuando pedidos AJAX consecutivos (“polling”) de
modo a obter actualizações por parte do agente. Os pedidos AJAX são efectuados
com recurso ao SAJAX.
Considerou-se utilizar “websockets” (HTML5) para estabelecer uma
comunicação bidireccional entre o servidor e a página. No entanto, a falta de
documentação sobre esta matéria, assim como o facto de as suas implementações não
serem consideradas estáveis, levou a que se tenha optado por não utilizar esta
tecnologia.

César Teixeira 28
Embora o “browser” não tome decisões sobre os conteúdos do terminal foram
desenvolvidos mecanismos de salvaguarda, para permitir uma diminuição gradual de
desempenho do sistema.
O facto de um dos requisitos do sistema ser a obtenção de uma reprodução
contínua de vídeos no terminal, de forma visualmente imperceptível, obrigou ao
desenvolvimento de soluções que permitissem a continuação da reprodução mesmo
que o agente não informasse o navegador sobre novos vídeos a serem reproduzidos.
Outro aspecto interessante a salientar é o da necessidade de garantir (evitar) que
não seja divulgada má informação ou informação desactualizada por parte do
terminal, em caso de falha de rede, retirando nesse caso todos os indicadores que se
relacionem com resumos de filas, por exemplo.
Relativamente aos “templates” que possuem um objecto Crawler (rodapé da
página), onde, por exemplo, são passados conteúdos informativos como notícias,
estudaram-se algumas alternativas. Inicialmente optou-se por utilizar WebGL com
recurso ao HTML5, nomeadamente, ao elemento Canvas. Após alguns testes durante
cerca de duas semanas em “motherboards” do tipo ITX, concluiu-se que o
desempenho, fruto talvez do processador, diminuía drasticamente, pelo que foram
descartadas estas tecnologias. Também foram testadas pequenas “applets” em
Java3D, tendo-se verificado igualmente uma redução no desempenho do processador.
Por último, optou-se por incluir um objecto Flash animado para onde fosse passado
conteúdo directamente do Javascript. No entanto, com a recente aceleração 3D do
Flash 10.1 é expectável que se possa resolver a questão com esta abordagem.
A utilização do elemento vídeo presente no novo HTML5, para incluir os vídeos
na página Web, também foi uma alternativa pensada. Foi apesar de tudo descartada
logo à partida devido à restrição imposta no formato dos vídeos que suporta. O facto
de apenas reproduzir vídeos no formato “ogg” impossibilitava a sua utilização, pois o
sistema deveria ser capaz de reproduzir qualquer formato de vídeos.

César Teixeira 29
4 Descrição técnica
4.1 O Agente
Esta componente do projecto está desenvolvida numa classe “ControllerAgent”,
que estende a classe “Agent” da plataforma JADE. A classe desenvolvida utiliza uma
outra classe “Manager”, como apoio à execução de algumas funcionalidades.
É no agente que está situada toda a lógica de alto nível do sistema. Toda a
comunicação do sistema com o exterior, dentro ou fora da rede, é feita pelo agente.
O agente, responsável pelo arranque e pela gestão de todo o sistema, é iniciado
automaticamente na linha de comandos. Ao ser iniciado, o agente cria uma estrutura
de dados do tipo “arraylist”, que armazena as informações do terminal a enviar ao
cliente.
O acesso a esta estrutura é feito de forma sincronizada para garantir que a
consulta ao seu conteúdo não é feita simultaneamente por mais que uma “thread”.
Trata-se de uma estrutura do tipo FIFO (“First In First Out”) que permite prioritizar o
envio de dados ao cliente consoante o seu nível de importância para o terminal.
Após a sua inicialização, o agente fica capaz de controlar por completo o
terminal, desde imagens, informações a conteúdos multimédia que nele passam
(vídeos).
4.1.1 Behaviours
Tal como explicado anteriormente, o agente possui um conjunto de
comportamentos, os “behaviours”.
Todos os comportamentos são adicionados ao agente através do método
“addBehaviour()”.
São estes comportamentos que permitem ao agente executar tarefas importantes,
tais como: comunicar com outros agentes; verificar temperaturas da CPU e o espaço
disponível em disco; requisitar XML com informações do terminal; armazenar numa

César Teixeira 30
estrutura as informações a enviar ao cliente; verificar conectividade à rede/internet;
arrancar um servidor Web.
Os comportamentos que o agente do sistema desenvolvido possui são
explicados em detalhe nos pontos seguintes.
4.1.1.1 StartWebServer
Este é o primeiro comportamento a ser adicionado ao agente e é do tipo
“OneShotBehaviour”, o que significa que é executado apenas uma vez, depois de
devidamente escalonado pelo agente.
É o comportamento responsável pelo arranque do servidor Web. O
comportamento cria uma instância da classe “Webserver.java” e chama o método
“main()” dessa classe. O agente ao executar o método “main()” passa por argumento o
seu identificador, mais tarde utilizado pelo servidor para aceder a variáveis existentes
no agente, como por exemplo, a estrutura (do tipo FIFO) onde estarão as informações
a enviar ao cliente.
No fim da execução do “behaviour”, o servidor Web encontra-se iniciado e
pronto a receber pedidos por parte do cliente.
4.1.1.2 Controller
O comportamento “Controller” é o mais importante de todos os
comportamentos do agente. É nele que são executadas algumas das mais importantes
tarefas do agente, como por exemplo:
1 Retirar a informação do ficheiro XML;
2 Instanciar classes Java a partir da informação retirada do XML;
3 Criar “strings” em JSON a partir da estrutura do tipo FIFO;
4 Verificar e fazer o “download” dos conteúdos a apresentar no terminal;
5 Executar um “script” que inicia o “browser” na página Web criada.

César Teixeira 31
Inicialmente, o “behaviour” começa por carregar um ficheiro mapeador
(“mapping file”) previamente criado. Este ficheiro contém todas as informações
necessárias para que a plataforma CASTOR possa fazer a relação entre as classes,
elementos e atributos do ficheiro XML, e as classes, objectos e atributos das classes
Java criadas previamente.
Segue-se um exemplo de um ficheiro de mapeamento referente a um elemento
“class” no XML (futuramente associado a uma classe Java):
<?xml version="1.0"?>
<!DOCTYPE mapping PUBLIC "-//EXOLAB/Castor Mapping DTD Version 1.0//EN"
"http://castor.org/mapping.dtd">
<mapping>
…
…
…
<class name="xarepoint.castor.Template">
<map-to xml="template"/>
<field name="id" type="java.lang.String">
<bind-xml name="id" node="attribute"/>
</field>
<field name="playersTemplate" type="xarepoint.castor.Player" collection="arraylist">
<bind-xml name="player" node="element"/>
</field>
<field name="kioskTemplate" type="xarepoint.castor.Kiosk">
<bind-xml name="kiosk" node="element"/>
</field>
</class>
<class name="xarepoint.castor.QueueKiosk">
<map-to xml="queue"/>
<field name="name" type="java.lang.String">
<bind-xml name="name" node="attribute"/>
</field>
<field name="id" type="java.lang.String" get-method="getId" set-method="setId">
<bind-xml name="id" node="attribute"/>
</field>
<field name="z" type="java.lang.String" get-method="getZ" set-method="setZ">
<bind-xml name="z-index" node="attribute"/>
</field>
<field name="x" type="java.lang.String" get-method="getX" set-method="setX">
<bind-xml name="posx" node="attribute"/>
</field>
<field name="y" type="java.lang.String" get-method="getY" set-method="setY">
<bind-xml name="posy" node="attribute"/>
</field>
<field name="width" type="java.lang.String" get-method="getWidth" set-method="setWidth">
<bind-xml name="sizex" node="attribute"/>
</field>
<field name="height" type="java.lang.String" get-method="getHeight" set-method="setHeight">
<bind-xml name="sizey" node="attribute"/>
</field>

César Teixeira 32
<field name="audioWarningFile" type="java.lang.String">
<bind-xml name="audio_warning_file" node="attribute"/>
</field>
<field name="swfFile" type="java.lang.String">
<bind-xml name="swf_file" node="attribute"/>
</field>
<field name="schemas" type="xarepoint.castor.Schema" collection="arraylist">
<bind-xml name="schema_xml" node="element"/>
</field>
</class>
...
...
...
</mapping>
Para cada elemento “class” (neste caso do tipo “template”) existente no ficheiro
XML é criado uma instância da classe “xarepoint.castor.nomeClasseNoXML”. São
definidas as relações entre os atributos dessa classe Java (de acordo com o seu tipo) e
os elementos e atributos existentes no ficheiro XML.
A relação entre elementos no XML e as classes Java é a seguinte:
Ficheiro XML Classes Java
“class” Instanciar objecto de classe
“node=element” Instanciar objecto de classe
“node=attribute” Inicializar atributo de classe criada
Depois de carregar o ficheiro mapeador, o agente faz o respectivo “unmarshall”
do conteúdo do ficheiro XML instanciando um objecto da classe
“xarepoint.castor.Terminal”. Um objecto da classe Terminal possui todos os objectos
instanciados durante a execução da plataforma Castor.
Depois de terminado o “unmarshall”, o objecto da classe Terminal é convertido
numa “string” JSON através de uma API (“Application Programming Interface”), a
GSON (“Google Son”). Esta API converte objectos Java na sua representação em
JSON. O objecto é convertido para ser devolvido ao cliente, relembrando que o
SAJAX utiliza a codificação dos dados em JSON no seu funcionamento.
Uma vez extraída toda a informação presente no ficheiro XML, é então
necessário verificar se os ficheiros (vídeos, imagens, etc.) estão disponíveis
localmente. Se não estiverem, o “ControllerAgent” faz o descarregamento dos
mesmos a partir de um servidor central. Para tal, são pesquisados todos os nomes

César Teixeira 33
desses ficheiros nos objectos Java criados e feita uma verificação através de métodos
presentes numa classe “Manager” (ponto 4.3). Se o ficheiro não existir, efectua o
“download” para uma pasta específica, de acordo com o tipo de conteúdo (vídeo ou
imagem).
Finalmente, o comportamento executa um “script” que abre o “browser” numa
página localizada localmente no servidor.
Este comportamento é um “OneShotBehaviour”, pois é executado apenas uma
vez, quando o agente é iniciado.
4.1.1.3 CheckInternetConnection
Este comportamento verifica a conectividade à Internet. É um comportamento
do tipo “TickerBehaviour”, sendo executado a cada cinco segundos.
É criada uma instância da classe “Manager”, para se poder aceder ao método
“isInternetReachable()”. Sendo este um método “booleano”, se o retorno desse
método for verdadeiro, significa que existe conectividade e passados cinco segundos,
é feita uma nova verificação. No caso de o retorno ser falso, é porque não existe
conectividade do sistema à Internet, e assim é armazenado na estrutura do agente
(“returnToBrowserArraylist”) uma “string” JSON estruturada de modo que quando
for devolvida ao navegador o informa de que não existe conectividade e assim sejam
feitas as alterações no terminal.
4.1.1.4 RequestVideoBehaviour
Este é o comportamento do agente no qual é definido qual o próximo, ou
próximos vídeos, a reproduzir no terminal e é executado pelo agente sempre que é
efectuado um pedido por vídeos.
Sempre que é feito um pedido de vídeos pela página, é verificado no servidor se
está a ser requisitado um ou dois vídeos. De seguida é adicionado ao agente (o
servidor recebe por parâmetro, aquando da sua criação, uma referência para o agente),
um comportamento do tipo “RequestVideoBehaviour”.

César Teixeira 34
Neste comportamento, existe uma variável global com o número de vídeos
requisitados. Uma vez sabido o número de vídeos a retornar, o comportamento
armazena na variável “returnToBrowserArraylist” uma “string” JSON com a
informação necessária sobre os vídeos a reproduzir.
A “string” criada tem o seguinte formato:
+:{"returnType":"videos","nameVideo":"video1","extension":"avi"}
As informações sobre vídeos são sempre prioritárias, pois só assim é
possibilitada uma manutenção de uma reprodução de vídeos contínua por parte do
navegador. Sendo assim, todas as “strings” JSON geradas por este comportamento
são sempre inseridas na primeira posição da estrutura “returnToBrowserArraylist”
(estrutura do tipo FIFO).
4.1.1.5 RequestTicketBehaviour
No ponto 2 (Contexto), foi dito que os terminais devem ser capazes de
apresentar variados tipos de configurações gráficas. Sendo assim, podem existir
elementos nos terminais que permitam uma interacção directa com o sistema, como
por exemplo botões.
Se existirem botões, cada botão tem um serviço ou fila associada, dependendo
do contexto em que o terminal se insere. Para tal, cada botão terá um evento
associado, como por exemplo, a impressão de uma senha. É esta a responsabilidade
deste comportamento do agente. Quando o servidor recebe um pedido da página a
indicar que um botão foi pressionado é adicionado este comportamento ao agente,
sendo executado apenas uma vez.
O comportamento comunica com um terminal central, do qual obtém
informação relativa ao número da senha do serviço ou fila requisitada. Este
comportamento tem também a capacidade de devolver informação sobre o número de
pessoas em espera num determinado serviço.

César Teixeira 35
4.1.1.6 CheckDiskSpace e CheckCPUTemperature
O sistema desenvolvido é capaz de gerir a máquina onde se insere, de forma a
garantir que, quer a nível de “Hardware” ou de “Software”, não existam problemas.
Os comportamentos desenvolvidos permitem a verificação da temperatura da
CPU (“CheckCPUTemperature”) e o espaço em disco (“CheckDiskSpace”). Ambos
são comportamentos do tipo “CyclicBehaviour” o que significa que são executados
repetidamente, enquanto o agente se encontrar no estado activo.
Os comportamentos desenvolvidos executam “scripts” que retornam a
informação necessária para que o agente seja capaz de resolver um eventual
problema: no caso da temperatura da CPU, se esta for superior a 80ºC, o
comportamento pode, por exemplo, enviar um alarme de pedido de manutenção; no
caso do comportamento que verifica o espaço disponível em disco, pode por exemplo,
ser feita uma eliminação de ficheiros que não são utilizados por um período de tempo
determinado.
4.2 Classe Manager
A classe “Manager” é a classe que possui métodos de apoio ao agente, tais
como, verificar a existência de ficheiros em disco, descarregamento de ficheiros de
um servidor central, ou verificar se existe conectividade à Internet.
4.2.1 checkAndDownloadFiles
O agente quando cria todos os objectos Java a partir do conteúdo do ficheiro
XML, de acordo com as especificações do “template” do terminal, necessita de
verificar se todos os conteúdos multimédia estão presentes no disco, e se não
estiverem, efectuar o “download” dos mesmos. Para tal, o comportamento
“Controller” instancia um objecto da classe “Manager” e chama o método
“CheckAndDownloadFiles()”, que é do tipo booleano. São ainda passados dois
argumentos por parâmetro: o nome do ficheiro e a sua localização no disco (vídeos e
imagens são colocados em pastas diferentes).

César Teixeira 36
O método verifica se o ficheiro existe na localização passada por parâmetro. Se
existir, o retorno do método é verdadeiro e o comportamento do agente continua a sua
execução. Nos casos em que o ficheiro não esteja presente na localização indicada é
chamado o método “downloadFile()” que, como o nome indica, vai descarregar esse
ficheiro de um servidor externo.
Este método recebe por parâmetro três argumentos: nome parcial do ficheiro
(sem extensão), localização para armazenar e nome completo. É então feito um
pedido a um “webservice”, situado num servidor central, com o nome parcial do
ficheiro e é efectuado o descarregamento do ficheiro para a localização pretendida.
Terminado o descarregamento de todos os ficheiros necessários, o
comportamento do agente continua a sua execução.
4.2.2 isInternetReachable
Uma vez que o agente é o responsável por informar o cliente (navegador) de
quais os conteúdos multimédia a apresentar e esses conteúdos são obtidos a partir da
comunicação com outros agentes presentes na rede, era necessário garantir que a
reprodução desses conteúdos não falhasse. Foi então desenvolvido um método que é
executado de cinco em cinco segundos e que fosse capaz de verificar a conectividade
à internet. O método tenta comunicar com um URL, como por exemplo,
“http://www.google.com” (Google). Se alguma excepção acontece, por exemplo, tipo
URL Desconhecido (“UnknownHostException”) retorna o valor falso, caso contrário
retorna verdadeiro.
4.3 Servidor Web
O sistema desenvolvido utiliza uma página Web para apresentar os conteúdos.
Trata-se de um servidor “multi-threaded”, totalmente implementado em Java e serve
como ponte de comunicação bidireccional entre o agente e a página Web. É nele que
todos os pedidos efectuados pelo navegador são tratados por “threads” na porta 80.

César Teixeira 37
O servidor Web utilizado na realização deste projecto não estava preparado para
receber pedidos HTTP POST, pelo que foi necessário implementar funcionalidades
adicionais que permitissem o tratamento deste tipo de pedidos.
Quando o servidor recebe um pedido, por parte do cliente (“browser”), retira o
tipo de pedido indicado na primeira linha do cabeçalho HTTP. Segue-se um exemplo
de um pedido HTTP POST recebido pelo servidor.
POST /HTML/HTML_Template/Xarepoint.html HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pt-PT; rv:1.9.2.6) Gecko/20100625
AskTbUT2V5/3.8.0.12304 Firefox/3.6.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-pt,pt;q=0.8,en;q=0.5,en-us;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Method: POST http://localhost:8080/HTML/HTML_Template/Xarepoint.html HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://localhost:8080/HTML/HTML_Template/Xarepoint.html
Content-Length: 44
Pragma: no-cache
Cache-Control: no-cache
rs=updateTemplate&rsargs=%5B%22update%22%5D&_
Se o pedido for do tipo POST, é invocado o método “ProcessaPost()” que é
responsável por tratar esse pedido.
4.3.1 ProcessaPost
Inicialmente, o método retira os argumentos do cabeçalho HTTP. Sabendo qual
o formato do cabeçalho, é possível armazenar numa estrutura do tipo “string” esses
argumentos. Uma vez que o cabeçalho pode estar codificado em UTF-8, foi utilizada
uma biblioteca do Java para descodificar esses argumentos retirados
(“java.net.URLDecoder”).
Criada a estrutura com os argumentos do pedido, é necessário saber qual o
propósito do pedido, se requisitar vídeos novos, eventos de botões, ou outro tipo de
pedido. Para tal, segue-se a decomposição dessa estrutura para se obter o método
(método que efectuou o pedido em Javascript) e os argumentos do mesmo.
Segue-se um exemplo de uma das estruturas a decompor:

César Teixeira 38
rs=MÉTODO&rsargs=ARGUMENTOS_PEDIDO
Podem existir três métodos diferentes:
 requestVideos – requisita 1 ou 2 vídeos;
 requestTicket – requisita senha;
 updateTemplate – requisita actualizações a fazer ao terminal.
Quando é recebido um pedido no servidor do tipo “requestVideos”, são
retirados os argumentos (1 ou 2) e é chamado o método “RequestVideo” (ponto
4.3.2). Se o método do pedido for do tipo “requestTicket” são retirados igualmente os
argumentos (nome do serviço/fila que efectuou o pedido) e é chamado o método
“RequestTicketService” (ponto 4.4.3). No caso do método do pedido ser do tipo
“updateTemplate” é verificado se a estrutura do agente que armazena informações a
devolver tem elementos: se tiver elementos, é retirado o primeiro elemento dessa
estrutura e devolvida uma resposta ao pedido; se a estrutura não tiver elementos, o
sistema está preparado para esperar três segundos, após os quais volta a verificar se
existem elementos na estrutura. Se existirem devolve novamente o primeiro elemento,
caso contrário devolve o valor “NULL”.
4.3.2 RequestVideo e RequestTicketService
Estes dois métodos são ambos responsáveis por adicionar comportamentos
(“behaviours”) ao agente para serem escalonados. Se o pedido recebido pelo servidor
requisitar vídeos, é adicionado um comportamento do tipo “RequestVideoBehaviour”.
Caso o pedido seja referente a um evento, por exemplo, um botão de um serviço ou
fila, é adicionado um comportamento do tipo “RequestTicketBehaviour” ao agente.
4.4 Front-end
Este módulo do sistema é responsável pela apresentação dos conteúdos do
terminal. É totalmente controlado pelo agente e consiste numa página Web
apresentada com o apoio de um navegador, neste caso o Mozilla Firefox.

César Teixeira 39
Sendo o Front-end a parte do sistema que interage directa ou indirectamente
com os clientes, através da visualização de vídeos ou da interacção com botões, uma
falha do agente controlador não pode comprometer o desempenho do sistema, como
por exemplo, não haver indicação sobre qual o próximo vídeo a ser reproduzido. Para
garantir que tal não acontece, foram desenvolvidos mecanismos de salvaguarda para
suportar uma degradação gradual de “performance” do sistema. Desenvolver uma
solução para que a reprodução de vídeos seja contínua por parte do terminal,
independentemente da conectividade ou estado do agente, é um bom exemplo destes
mecanismos.
Como já foi referido e exemplificado no capítulo 2 (Contexto), o sistema é
capaz de representar vários tipos de “templates”. No entanto, todos eles seguem um
modelo base para uma página Web, segundo o qual se definiram métodos para os
desenhar utilizando DOM (“Document Object Model”) e também Javascript
Orientado a Objectos (“Javascript Object Oriented”).
A página base de todos os “templates” é composta por quatro elementos base,
do tipo “div” (ou contentores), usados para agrupar e estruturar o conteúdo do
documento HTML. Esses elementos principais são: “PlayerDiv”, “Player2Div”,
“KioskDiv” ou “QueueKioskDiv” e “CrawlerDiv”. Os elementos “PlayerDiv” e
“Player2Div” estão ambos sobrepostos.
Segue-se uma imagem que exemplifica o modelo de uma página base:

César Teixeira 40
Figura 14 - Modelo Página Base
No sistema desenvolvido, o Front-end é executado apenas na fase final do
arranque. Antes de terminar a execução do “behaviour” Controller do agente é
executado um “script” que executa o Mozilla Firefox no endereço:
http://localhost:8080/Agent-Castor-Webserver/HTML/HTML_Template/Xarepoint.html
O desenvolvimento do Front-end pode ser dividido em três partes:
 Comunicação bidireccional navegador - Agente;
 Reprodução contínua da lista de vídeos;
 Mecanismos de salvaguarda.
A comunicação, bidireccional entre o servidor e a página Web é conseguida
através da utilização do “short-polling” (utilizando o SAJAX), mantendo assim o
terminal actualizado. Em cada pedido é indicado um método, os argumentos e uma
função que recebe a resposta a esse pedido (“callback”).
Segue-se um excerto de código no qual é exemplificado um pedido SAJAX:
Método: updateTemplate;
Argumentos: update;

César Teixeira 41
Método de retorno: updateTemplateCallback.
function updateTemplate()
{
// definição de argumentos (“update”) e de método de retorno (“updateTemplateCallback”)
x_updateTemplate("update", updateTemplateCallback);
}
function x_updateTemplate()
{
// pedido SAJAX para actualização do template
return sajax_do_call("updateTemplate", arguments, "POST", true, "");
}
Foram definidos três tipos de pedidos: os pedidos de actualizações do terminal,
feitos continuamente pela página; os pedidos de vídeos depois de construída a página;
os pedidos referentes a eventos resultantes da interacção directa com o sistema, tais
como botões.
Inicialmente, quando a página é carregada, efectua um pedido por actualizações
ao servidor. Neste momento, a única informação presente no Agente para o terminal é
sobre o tipo de “template” que este vai possui. Desta forma, o método
“updateTemplateCallback”, responsável por tratar as respostas aos pedidos de
actualizações, recebe um objecto Javascript que é encaminhado para um outro método
“templateCallback()”. É neste método que vai ser gerado todo o código HTML da
página que vai representar o terminal. O objecto recebido possui as especificações dos
elementos que fazem parte do “template” a ser construído: tamanhos de “divs”
(largura/altura), formatação do texto, imagens de fundo.
O método “templateCallback()” começa por definir as propriedades CSS
(“Cascade Style Sheet”) do documento HTML, tais como margens, largura e altura da
página. De seguida é definida uma imagem de fundo para página. Uma vez definidas
estas propriedades, é necessário criar os elementos da página base. Para isso foram
desenvolvidos métodos para criar esses elementos, com o apoio de código Javascript
Orientado a Objectos.
Desenvolveu-se então uma classe que define as características (efeito geral)
comuns a todos os elementos do documento, como altura, largura, posição X e Y na
página e um “Z-Index”.

César Teixeira 42
// Classe Javascript para Efeito Geral
function rootEffect(object, type) {
this.posX = object.x;
this.posY = object.y;
this.zIndex = object.z;
this.width = object.width;
this.height = object.height;
// declaração métodos get
this.getPosX = getPosX;
this.getPosY = getPosY;
this.getZIndex = getZIndex;
this.getWidth = getWidth;
this.getHeight = getHeight;
// declaração métodos set
this.setPosX = setPosX;
this.setPosY = setPosY;
this.setZIndex = setZIndex;
this.setWidth = setWidth;
this.setHeight = setHeight;
// método que retorna o valor de X
function getPosX()
{
return this.posX;
}
// método que retorna o valor de Y
function getPosY()
{
return this.posY;
}
// método que define valor de X
function setPosX(posX)
{
this.posX = posX;
}
// método que define valor de Y
function setPosY(posY) {
this.posY = posY;
}
}
Para cada elemento da página base é criado um objecto da classe “rootEffect”
com as características gerais desse elemento (altura, largura, posição X e Y, “Z-
Index”) e um outro objecto que possui as propriedades exclusivas desse elemento,

César Teixeira 43
como o nome e o identificador. Este último objecto é capaz de herdar todas as
propriedades definidas no elemento geral a partir da classe “prototype” do Javascript.
Deste modo é simulado o princípio de herança numa linguagem não orientada a
objectos como o Javascript.
Este tipo de desenvolvimento permite a criação de elementos a qualquer
momento, indicando apenas o nome e o identificador do mesmo, aproveitando-se o
facto de existir um objecto com as especificações gerais do tipo de elemento a ser
criado.
Segue-se um excerto de código onde se demonstra a criação de dois elementos
“div” a partir de um objecto que possui as propriedades gerais desses elementos e
consequente inserção desses elementos no documento HTML.
// função que cria elementos Div do tipo “Player” e que recebe por parâmetro o objecto Javascript
// que contém especificações do Div
function setPlayerTemplate(playerSpec)
{
// cria rootEffect object
playerEffect = new rootEffect(playerSpec, "player");
// herança de object player
playerObject.prototype = playerEffect;
// cria objectos Player
var playerOneDiv = new playerObject(playerSpec);
var playerTwoDiv = new playerObject(playerSpec);
// insere Divs criados no document HTML
document.body.appendChild(playerOneDiv);
document.body.appendChild(playerTwoDiv);
}
// função que define especificações do elemento Div do Player a criar
function playerObject(player)
{
var playerDiv = document.createElement("div");
playerDiv.id = "playerDiv"+idPlayer;
playerDiv.name = player.name;
playerDiv.style.width = this.width;
playerDiv.style.height = this.height;
playerDiv.style.marginLeft = this.posX;
playerDiv.style.marginTop = this.posY;
// Verifica se element Div do Player é inserido à frente ou atrás no template
if(idPlayer%2 != 0)
{
playerDiv.style.zIndex = "2";
playerDiv.style.backgroundColor = "green";

César Teixeira 44
}
else
{
playerDiv.style.zIndex = "1";
playerDiv.style.backgroundColor = "white";
}
playerDiv.style.position = "absolute";
playerDiv.style.padding = "0px 0px 0px 0px";
playerDiv.style.backgroundRepeat = "no-repeat";
// incrementar id playerDiv
idPlayer++;
return playerDiv;
}
No caso de o elemento criado ser do tipo “player”, sabendo que existem dois
destes elementos sobrepostos numa mesma página, no momento da sua criação
detecta-se qual o elemento que fica na frente.
A imagem seguinte exemplifica, de forma simples, a herança entre os objectos
Javascript:
Figura 15 - Javascript Orientado a Objectos
Depois de todos os elementos terem sido criados e inseridos no documento
HTML (“template” está desenhado) é necessário iniciar a reprodução de vídeos. Para
tal, no fim da execução do método “templateCallback()”, são requisitados os dois
primeiros vídeos a serem reproduzidos, através do método “requestVideos(2)”.

César Teixeira 45
A reprodução de vídeos foi sem dúvida o maior desafio no desenvolvimento de
todo o sistema, pois envolvia a reprodução de vídeos de vários formatos, de forma
ininterrupta, independentemente do estado do agente.
O uso de tecnologias Web, bem como de um navegador, possibilita a utilização
de “plugins” para a visualização e reprodução de conteúdos multimédia, como vídeos
e animações. No entanto, a necessidade de reprodução ininterrupta de vídeos
(visualmente imperceptível), originou outro problema para resolver. Pelo que, surgiu a
ideia de utilizar dois elementos “div” sobrepostos para reproduzir vídeos, em que estes
seriam trocados sempre que um vídeo terminasse a sua execução. Esta trata-se de uma
das grandes mais-valias do projecto desenvolvido.
4.4.1 Carregar/Reproduzir vídeos
Como já foi referido anteriormente, a reprodução de uma “playlist” de vídeos
foi um desafio no desenvolvimento deste projecto.
Quando é recebido por parte do “browser” um objecto Javascript em que o seu tipo é
“vídeos”, esse objecto é tratado por um método específico
(“videosCallback(objectoVideo)”). Este método, inicialmente, verifica quantos vídeos
são informados no objecto recebido e seguidamente armazena em duas variáveis os
dois elementos de vídeo sobrepostos.
Se o retorno for de um vídeo, esse vídeo será carregado no elemento da página,
responsável pela reprodução do mesmo, que estiver atrás (não visível).
String JSON no Agente – 1 vídeo:
+:{"returnType":"videos","numVideos":"1","extension":"avi","nameVideo":"kizdania"}
Objecto Javascript recebido no navegador – acesso aos conteúdos do objecto:
obj.returnType  “videos”
obj.numVideos  “1”
obj.extension  “avi”
obj.nameVideo  “kizdania”
O vídeo inserido é apenas carregado e só começa a ser reproduzido quando este
elemento “player” é passado para a frente (passa a ser visível).

César Teixeira 46
Se o método “VideosCallback()” receber um objecto com informação de dois
vídeos, são também retirados os dois elementos de vídeo presentes na página (“divs”
sobrepostos), no entanto, vão ser carregados vídeos em ambos os elementos: no
elemento da frente (visível) é carregado e reproduzido imediatamente um vídeo; no
elemento de trás é carregado o outro vídeo através do método
“checkTypeAndLoadVideo()”.
String JSON no Agente – 2 vídeos:
+:{"returnType":"videos","extension2":"swf","numVideos":"2","nameVideo2":"spot_xare","extension"
:"avi","nameVideo":"kizdania"}
Objecto Javascript recebido no navegador – acesso aos conteúdos do objecto:
obj.returnType  “videos”
obj.numVideos  “2”
obj.extension  “avi”
obj.nameVideo  “kizdania”
obj.extension2  “swf”
obj.nameVideo2  “spot_xare”
Para evitar que não haja “próximos” vídeos na lista de reprodução do terminal, o
sistema está preparado para recorrer ao objecto inicial recebido (com informações do
terminal) e retirar deste um vídeo para carregar. Para isso cria uma estrutura
Javascript do tipo “array” e armazena nesta estrutura informações do vídeo: nome,
extensão, tipo e elemento onde o inserir.
Array gerado (esquema):
nameVideo extension playerToEmbedVideo returnType
Array Javascript:
videos[0] = nameVideo
videos[1] = extension
videos[2] = playerToEmbedVideo
videos[3] = returnType
4.4.2 Reprodução de vídeo
A reprodução de vídeos foi alcançada com o apoio de reprodutores de vídeo que
suportam a utilização de vários sistemas operativos (multi-plataforma). Foram
utilizados os “plugins” da Adobe Flash, assim como, a API que o VLC disponibiliza.

César Teixeira 47
De seguida são explicados detalhadamente os dois “plugins”, assim como, a sua
integração e contributo para o sistema desenvolvido.
4.4.2.1 Flash Player
Os vídeos “swf” podiam ser compostos, ou seja, os conteúdos dessas animações
podiam necessitar de informações armazenadas, por exemplo em bases de dados.
Sendo assim, podiam surgir situações em que estes vídeos não estivessem completos,
faltando um ou mais componentes dos mesmos. Para resolver estas situações foi
necessário desenvolver um pré-carregador de ficheiros Flash desenvolvido em
Actionscript 2.0.
Este componente consiste na utilização de um “swf” externo que é capaz de
carregar, controlar e reproduzir vídeos, bem como comunicar com o Javascript. No
“swf” externo existe um MovieClip vazio.
A comunicação entre o Javascript e o Flash é possível através da utilização da
classe “ExternalInterface”. Para isso, são exportados métodos desenvolvidos em
Actionscript 2.0, para que seja possível invocar esses mesmos métodos pelo
Javascript.
Figura 16 - Comunicação entre Javascript e Objecto Flash
Quando é necessário reproduzir, ou carregar, um ficheiro “swf” na página, é
inserido um objecto “Preloader” (ficheiro “swf” vazio onde é carregado o vídeo a
reproduzir) num elemento da página responsável pela reprodução de vídeos. Depois
de ser inserido, é invocado em Javascript o método “loadSWF(nome_video)” presente
no código ActionScript, em que é passado por parâmetro o nome do vídeo a carregar.
Este método carrega o vídeo com o nome recebido por parâmetro no MovieClip
existente no “swf” externo. Quando totalmente carregado o vídeo é avançado e parado

César Teixeira 48
na primeira “frame”, sendo alterada uma variável do Javascript, informando que o
vídeo foi totalmente carregado e está pronto a ser reproduzido, através da invocação
de um método desenvolvido no Javascript. No MovieClip existente no “swf” externo
foram adicionados eventos, como por exemplo, percentagem de vídeo carregado e fim
de carregamento de vídeo.
No momento em que esse vídeo vai ser reproduzido é testada a variável do
Javascript, que é alterada quando o vídeo é carregado com sucesso. Se a variável não
tiver sido alterada significa que o vídeo não foi totalmente carregado, logo é
carregado e reproduzido um outro vídeo escolhido aleatoriamente pela página.
Javascript
var flashObject = document.getElementById("embedFront");
flashObject.loadSWF(swfToLoad);
Actionscript
// **************
// Métodos invocados pelo Javascript previamente exportados
// pelo Actionscript/ExternalInterface
// **************
function loadSWFIntoMC(movieName:String)
{
movieClipLoaderInstance.loadClip("../SWF/"+movieName,novoMC);
}
// **************
// Event Handlers
// **************
// Evento que determina percentagem do swf carregado
movieClipLoaderInstanceListener.onLoadProgress = function(target, loadedBytes, totalBytes)
{
trace(Math.round((loadedBytes / totalBytes) * 100) + "%");
};
// Evento executado quando swf tiver sido completamente carregado
movieClipLoaderInstanceListener.onLoadComplete = function(mc)
{
trace("numFramesLoaded: "+mc._totalFrames);
ExternalInterface.call("loadedSWF", "1");
mc.gotoAndStop(1);
};
Uma vez carregado com sucesso, pode ser iniciada a sua reprodução via
Javascript, através da invocação do método “playSWF()” desenvolvido em
ActionScript.

César Teixeira 49
No momento em que começa a ser reproduzido é adicionado um novo “event
handler” ao MovieClip. Este novo evento (“onEnterFrame”) é executado sempre que
o vídeo entra numa “frame” durante a sua reprodução e testa se o número da “frame”
actual é igual ao número total de “frames” desse vídeo. Se o número for diferente,
significa que o vídeo ainda está a ser reproduzido, enquanto que se o número total de
“frames” for igual ao número da “frame” actual, o vídeo chegou terminou e é
invocado um método em Javascript que é responsável pela troca dos elementos “div”
que contém os “players”. Quando o vídeo termina, é também retirado do MovieClip.
novoMC.onEnterFrame = function() {
if(novoMC._currentFrame == novoMC._totalFrames)
{
unloadMovie("novoMC");
ExternalInterface.call("changeDivZIndex", "");
}
}
4.4.2.2 VLC Plugin API
Como já foi referido, os vídeos reproduzidos podiam ser de vários formatos.
Enquanto que para reproduzir vídeos Flash é utilizado um “plugin” específico
disponibilizado pela Adobe, para os restantes formatos, optou-se por utilizar o
reprodutor multimédia VLC.
O “plugin” do VLC exporta vários objectos que podem ser acedidos via
Javascript de modo a controlar os vídeos nele reproduzidos. Quando o acesso a estes
objectos é feito de forma inapropriada, a API que permite este acesso lança excepções
que incluem a explicação do que originou esse erro.
Quando um objecto do tipo VLC “plugin” é embutido num dos reprodutores de
vídeo existentes na página, passa a ser possível o acesso a algumas propriedades desse
objecto, como por exemplo: audio, vídeo e lista de reprodução. Quando um vídeo de
um formato suportado por este reprodutor é adicionado à lista de reprodução do
objecto VLC embutido é possível ter acesso a métodos de controlo desse mesmo
vídeo, como por exemplo reproduzir, parar, pausar.

César Teixeira 50
Figura 17 - Comunicação entre Javascript e Objecto VLC
Para reproduzir a lista de reprodução do objecto VLC embutido na página é
invocado o método “play()”, fornecido pela API, que inicia a reprodução de todos os
elementos presentes na lista.
Quando é iniciada a reprodução de um vídeo, é necessário verificar o estado de
reprodução (terminado/em reprodução). Para tal, recorreu-se ao método “setInterval”
do Javascript, que permite definir um método a ser invocado e um intervalo de tempo
para o invocar. A cada intervalo de tempo, o método definido acede ao objecto VLC
embutido na página, e para verificar se o vídeo terminou ou ainda está em execução
acede a uma propriedade desse objecto que informa sobre o estado do vídeo
(vlcObject.playlist.isPlaying). Se o valor desta propriedade for verdadeiro, significa
que o vídeo ainda está a reproduzir. Caso o retorno seja falso, significa que o vídeo
terminou a sua execução, pelo que é necessário limpar os elementos da lista de
reprodução e efectuar a troca dos “divs” que possuem reprodutores de vídeo
embutidos na página.
4.4.2.3 Alternância de Vídeos
Como já foi explicado anteriormente, um “template” possui sempre no mínimo
dois elementos “div” onde são embutidos reprodutores de vídeo, objectos VLC ou
Flash Players. Os dois elementos ficam sobrepostos para permitir que, enquanto um
vídeo está a ser reproduzido, o outro seja carregado, ficando pronto a ser reproduzido
logo que o vídeo da frente termine a sua reprodução.
Quando um vídeo termina a reprodução é lançado um evento que faz com que o
elemento onde o vídeo está a ser reproduzido seja trocado com o “div” posicionado
atrás deste. No momento em que os “divs” são trocados, é imediatamente iniciada a

Gestão de interfaces gráficas com agentes JADE

Gestão de interfaces gráficas com agentes JADE

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Gestão de interfaces gráficas com agentes JADE

Semelhante a Gestão de interfaces gráficas com agentes JADE (20)

Gestão de interfaces gráficas com agentes JADE