Dissertacao ANDREPONTESSAMPAIO

Universidade Federal do Cear Centro de Tecnologia Departamento de Engenharia de Teleinformtica Programa de Ps Graduao em Engenharia de Teleinformtica
JxAula - Proposta de um Arcabouo para a Construo de Servios P2P no contexto de Sistemas de Ensino Distncia
Andr Pontes Sampaio
Orientador
Prof. Dr. Jos Neuman de Souza
Fortaleza Cear Agosto 2008
Universidade Federal do Cear Centro de Tecnologia Departamento de Engenharia de Teleinformtica Programa de Ps Graduao em Engenharia de Teleinformtica
Autor Andr Pontes Sampaio Orientador
Prof. Dr. Jos Neuman de Souza
Dissertao de Mestrado apresentada Coordenao em da do Curso de de Ps-Graduao Teleinformtica requisitos para Engenharia
Universidade do grau
Federal do Cear como parte dos obteno de Mestre
em Engenharia de Teleinformtica.
Fortaleza Cear Agosto 2008
Andr Pontes Sampaio
Esta dissertao foi julgada adequada para a obteno do ttulo de Mestre em Engenharia de Teleinformtica e aprovada em sua forma nal pelo programa de Ps-Graduao em Engenharia de Teleinformtica da Universidade Federal do Cear.
Andr Pontes Sampaio Banca Examinadora:
Prof. Dr. Jos Neuman de Souza Orientador
Prof. Dr. Antnio de Barros Serra Centro Federal de Educao Tecnolgica do Cear
Prof. Dr. Joaquim Celestino Jnior Universidade Estadual do Cear
Prof. Dr. Jos Marques Soares Universidade Federal do Cear
Prof. Dr. Danielo Gonalves Gomes Universidade Federal do Cear Fortaleza, 19 de agosto de 2008
Resumo
s arquiteturas peer-to-peer (P2P) tm sido cada vez mais utilizadas para dar suporte ao desenvolvimento de sistemas distribudos, permitindo a
interoperabilidade entre aplicaes e o compartilhamento de recursos e servios computacionais atravs de redes cooperativas auto-organizveis. Destacam-se como um importante cenrio da atuao de solues P2P as aplicaes colaborativas de ensino a distncia (EaD), uma vez que so formadas por um conjunto de participantes distribudos que realizam atividades de cooperao. Visando minimizar o esforo realizado entre a concepo e o desenvolvimento de aplicaes distribudas, este trabalho apresenta uma arquitetura reutilizvel, adaptvel e apropriada para a criao de aplicaes de ensino-aprendizagem, no com o objetivo de substituir as plataformas existentes, mas com o objetivo de complement-las com funcionalidades que tratem adequadamente o contexto de sistemas para ensino a distncia. Assim, o trabalho dene um arcabouo com funcionalidades relacionadas criao de um ambiente colaborativo capaz de organizar seus participantes em salas virtuais, possibilitando, por exemplo, o envio de mensagens e o compartilhamento de arquivos. Os middlewares desenvolvidos a partir do modelo apresentado neste trabalho podem ser congurados e implementadas atravs de qualquer plataforma bsica P2P, por exemplo: JXTA, Pastry e Windows P2P Networking. Como forma de ilustrar a utilizao do arcabouo, denominado JxAula, desenvolveu-se o middleware JXTAula baseado na plataforma JXTA. Avalia-se o trabalho desenvolvido em relao aos requisitos funcionais e no funcionais atravs de mtricas e processos de qualidade. Alm disso, um estudo de caso apresentado ao utilizar este trabalho em um sistema real de ensino a distncia, destacando-se as principais atividades necessrias para utilizar este trabalho no desenvolvido de outros sistemas aplicativos.
Abstract
eer -to-peer (P2P) architectures have been increasingly used to support the development of distributed systems, allowing interoperability between
applications and sharing resources and services through cooperatives computer networks. E-learning environments takes an important place for P2P solutions, since they are formed by a number of distributed participants that acts in a cooperative manner. To minimize the eort between the design and development of distributed applications, this work presents a reusable and adaptable architecture, suitable for the creation of applications for teaching and learning environments, not to replace the existing platforms, but to supplement them with features that address adequately the context of e-learning systems. Thus, this work establishes a framework with features related to the creation of a collaborative environment capable of organizing its participants in virtual rooms, allowing, for example, them to send messages and share le. Middlewares developed from the presented model can be congured and implemented through any basic P2P platform, for example: JXTA, Pastry and Windows P2P Networking. In order to illustrate the use of framework, called JxAula, it has been developed the middleware JXTAula based on JXTA platform. The evaluation of this work is done for functional and non-functional requirements, through metrics and processes of quality. Moreover, a case of study is presented by using this work in a real e-learning system, identifying the main activities required to use this work in other systems.
Dedico este trabalho aos meus pais, a minha irm e principalmente a Deus.
Sumrio
Lista de Figuras Lista de Tabelas Lista de Cdigos Lista de Siglas 1 Introduo

1.1 1.2 1.3 1.4 2.1 Motivao . . . . . . . . . . . . . Estabelecimento da problemtica Objetivos da Dissertao . . . . . Diviso do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii ix x xi 1
1 3 3 4
2 Reviso Bibliogrca
2.2
Estado da arte em Ensino Distncia . . . . . . . . . . . . . . . . . . 2.1.1 Modalidades dos sistemas de EaD . . . . . . . . . . . . . . . . 2.1.2 Caractersticas dos ambientes para aprendizagem cooperativa . 2.1.3 Enquadramento deste trabalho e funcionalidades fornecidas . . Estado da arte em plataformas P2P . . . . . . . . . . . . . . . . . . . 2.2.1 JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Windows P2P Networking . . . . . . . . . . . . . . . . . . . . 2.2.4 Groove Development Kit . . . . . . . . . . . . . . . . . . . . . 2.2.5 Tabela comparativa entre as arquiteturas apresentadas . . . . 2.2.6 Por que o JXTA? . . . . . . . . . . . . . . . . . . . . . . . . . Descrio geral da arquitetura JxAula . . . . . Arquitetura proposta . . . . . . . . . . . . . . 3.2.1 Arquitetura em Camadas . . . . . . . . 3.2.2 Camadas da Arquitetura do Arcabouo Caractersticas do arcabouo proposto . . . . iv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 7 8 10 13 13 16 18 23 27 29
3 Denio do arcabouo JxAula

3.1 3.2 3.3
32
32 34 34 34 35
3.4
3.3.1 Requisitos funcionais . . . . . 3.3.2 Requisitos no funcionais . . . Funcionalidades do JxAula . . . . . . 3.4.1 Gesto do Ambiente . . . . . 3.4.2 Gesto de Salas . . . . . . . . 3.4.3 Gesto de Participante . . . . 3.4.4 Gesto de Comunicao . . . 3.4.5 Gesto de Localizao . . . . 3.4.6 Gesto de Compartilhamento 3.4.7 Gesto de Desempenho . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
36 37 39 40 44 47 48 50 52 53
4 Estudo de caso: o middleware JXTAula

4.1 4.2
4.3 5.1
Viso geral sobre o JXTAula . . . . . . . . . . . . . . . . . . Funcionamento do middleware . . . . . . . . . . . . . . . . . 4.2.1 Iniciando o uso de uma aplicao . . . . . . . . . . . 4.2.2 Ingressando no mundo P2P e no grupo Escola . . . . 4.2.3 Descobrindos as salas e os participantes do ambiente 4.2.4 Estabelecendo comunicaes entre os participantes do Um paralelo entre o JXTA e o JXTAula . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . ambiente . . . . . . . . . . . . .
55
55 55 56 58 59 60 63 65 65 66 68 68 69 72 72
5 Integrao do middleware JXTAula a um sistema de EaD
5.2 5.3
Arquitetura do COGEST . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Descrio geral sobre o projeto . . . . . . . . . . . . . . . . 5.1.2 Arquitetura centralizada do COGEST . . . . . . . . . . . . Proposta de nova arquitetura ao COGEST . . . . . . . . . . . . . . 5.2.1 Descrio geral sobre as vantagens da nova arquitetura . . . 5.2.2 Arquitetura descentralizada do COGEST . . . . . . . . . . . Passos para a integrao do COGEST ao JXTAula . . . . . . . . . 5.3.1 Adaptaes de interfaces grcas (GUI) . . . . . . . . . . . . 5.3.2 Adaptaes do cliente para incorporar funes providas anteriormente pelo servidor . . . . . . . . . . . . . . . . . . 5.3.3 Adaptaes no mtodo de envio e recepo de mensagens . . Requisitos da avaliao . . . . . . . . . . . . . . . . . . 6.1.1 Propsito da avaliao e produto a ser avaliado 6.1.2 Modelo de qualidade a ser utilizado . . . . . . . Especicao da avaliao . . . . . . . . . . . . . . . . 6.2.1 Mtricas utilizadas e seus nveis de pontuao . 6.2.2 Critrios para julgamento . . . . . . . . . . . . Planejamento e Execuo da avaliao . . . . . . . . . 6.3.1 Avaliao dos requisitos funcionais . . . . . . . . 6.3.2 Avaliao dos requisitos no funcionais . . . . . Avaliao nal . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Resultado nal . . . . . . . . . . . . . . . . . . 6.4.2 Avaliao dos resultado obtidos . . . . . . . . . v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
. 74 . 74 . . . . . . . . . . . .
6 Resultados obtidos e avaliao nal

6.1 6.2 6.3 6.4
76
76 76 77 78 79 79 79 80 84 90 91 91
7 Concluso e trabalhos futuros

7.1 7.2
Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 . . . . . . . . . . JxAula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 98 99 99 99 101 103 104 106 108 109
94
Apndice A Padres de Projeto no arcabouo JxAula
A.1 Utilizao de padres de projeto no arcabouo JxAula . . A.1.1 Padres de Projeto . . . . . . . . . . . . . . . . . A.1.2 Utilizao de Padres de Projeto nas Camadas do A.2 Mdulos do JxAula . . . . . . . . . . . . . . . . . . . . . A.2.1 Gesto do Ambiente . . . . . . . . . . . . . . . . A.2.2 Gesto de Salas . . . . . . . . . . . . . . . . . . . A.2.3 Gesto de Participante . . . . . . . . . . . . . . . A.2.4 Gesto de Comunicao . . . . . . . . . . . . . . A.2.5 Gesto de Localizao . . . . . . . . . . . . . . . A.2.6 Gesto de Compartilhamento . . . . . . . . . . . A.2.7 Gesto de Desempenho . . . . . . . . . . . . . . . B.1 Relacionamento entre as classes do JXTAula e JXTA B.2 Classe Boot . . . . . . . . . . . . . . . . . . . . . . . B.2.1 Conguraes do peer . . . . . . . . . . . . . B.2.2 Ingresso no grupo principal . . . . . . . . . . B.3 Classe Group . . . . . . . . . . . . . . . . . . . . . . B.3.1 Manuteno de salas . . . . . . . . . . . . . . B.3.2 Grupos no ambiente P2P . . . . . . . . . . . . B.4 Classe Find . . . . . . . . . . . . . . . . . . . . . . . B.4.1 Buscas baseadas no protocolo PDP do JXTA B.5 Classe Peer . . . . . . . . . . . . . . . . . . . . . . . B.5.1 A criao do canal de entrada . . . . . . . . . B.5.2 O estabelecimento da comunicao . . . . . . B.5.3 Recebendo mensagens de outros participantes . . . . . . . . . . . . . . . . . . . . . . . . . .
98
Apndice B Cdigos do middleware JXTAula
110
110 110 110 113 114 114 116 117 117 121 122 123 125
Apndice C Cdigos da integrao entre COGEST e JXTAula
C.1 Adaptaes no mtodo de envio e recepo de mensagens . . . . . . . 127 C.1.1 Modelo Centralizado - Classe TCPConnectionManager . . . . 127 C.1.2 Modelo P2P - Classe P2PConnector . . . . . . . . . . . . . . . 130
127
Referncias Bibliogrcas
139
vi
Lista de Figuras
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 4.1 4.2 4.3 5.1
Funcionalidades de um ambiente virtual de aprendizagem cooperativa Arquitetura do JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocolos da especicao do JXTA . . . . . . . . . . . . . . . . . . Mecanismo de localizao do Pastry . . . . . . . . . . . . . . . . . . . Arquitetura do Windows Peer-to-Peer Networking . . . . . . . . . . . Identicadores PNRP (PNRP IDs ) . . . . . . . . . . . . . . . . . . . Cenrio para localizao atravs do PNRP . . . . . . . . . . . . . . . Processo de localizao atravs do PNRP . . . . . . . . . . . . . . . . Espao de trabalho do Groove . . . . . . . . . . . . . . . . . . . . . . Comunicao atravs de Firewalls pelo Servidor Relay . . . . . . . . . Integrao dos dados armazenados no Groove com outros aplicativos . Quadrante com as principais caractersticas das plataformas P2P . . Diviso da arquitetura em arcabouo, middleware e plataforma Arquitetura do arcabouo JxAula em camadas . . . . . . . . . Casos de Uso do Arcabouo JxAula . . . . . . . . . . . . . . . Mdulo de Gesto do Ambiente . . . . . . . . . . . . . . . . . Congurao do JxAula . . . . . . . . . . . . . . . . . . . . . Representao das salas e dos participantes na Escola . . . . . Mdulo de Gesto de Salas . . . . . . . . . . . . . . . . . . . . Representao da Escola e Salas Virtuais do ambiente . . . . . Mdulo de Gesto de Participantes . . . . . . . . . . . . . . . Mdulo de Gesto de Comunicao . . . . . . . . . . . . . . . Desmembramento e serializao de mensagens . . . . . . . . . Mdulo de Gesto de Localizao . . . . . . . . . . . . . . . . Mdulo de Gesto de Compartilhamento . . . . . . . . . . . . Mdulo de Gesto de Desempenho . . . . . . . . . . . . . . . P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 15 16 18 19 22 23 24 25 27 28 31 33 36 38 41 43 44 44 46 47 48 49 50 52 53
Componentes do Middleware JXTAula . . . . . . . . . . . . . . . . . 56 Aba avanada do JXTA Congurator . . . . . . . . . . . . . . . . . . 57 Protocolo de controle para as descobertas de participantes nos grupos 61 Interface grca do COGEST . . . . . . . . . . . . . . . . . . . . . . 67 vii
5.2 5.3 5.4 5.5 5.6 6.1
Arquitetura centralizada . . . . . . . . . . . . . . . . . . . . . . . . . Distribuio e balanceamento de carga entre os participantes da rede Arquitetura descentralizada proposta ao COGEST . . . . . . . . . . . Escolha da arquitetura de comunicao . . . . . . . . . . . . . . . . . Tela das funcionalidades providas pelo JXTAula . . . . . . . . . . . .
67 70 71 73 73
Viso geral do processo de avaliao de avaliao de qualidade de software - ISO/IEC 14598 . . . . . . . . . . . . . . . . . . . . . . . 6.2 Caractersticas e sub-caractersticas denidas pela norma ISO/IEC 9126 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Aplicativo de avaliao dos requisitos funcionais . . . . . . . . . . . 6.4 Questionrio utilizado na avaliao dos requisitos funcionais . . . . 6.5 Resultado da avaliao dos requisitos funcionais . . . . . . . . . . . 6.6 Questionrio utilizado na avaliao dos requisitos no funcionais . . 6.7 Resultado da avaliao dos requisitos no funcionais . . . . . . . . . 6.8 Latncia de transmisso no cenrio cliente-servidor . . . . . . . . . 6.9 Latncia de transmisso no cenrio P2P . . . . . . . . . . . . . . . 6.10 Comparao entre o tempo mdio de recebimento . . . . . . . . . . A.1 Criao de gestores do ambiente . . . . . . . . . . . . . . . . . A.2 Encontrar as salas e os participantes da Escola . . . . . . . . . A.3 Processo de criao de Sala . . . . . . . . . . . . . . . . . . . A.4 Processo de entrar em uma determinada Sala . . . . . . . . . A.5 Processo de trocar e sair de uma determinada Sala . . . . . . A.6 Processo de criao do participante . . . . . . . . . . . . . . . A.7 Processo de criao da comunicao do participante . . . . . . A.8 Processo de iniciao de comunicao com participante remoto A.9 Herana e Composio das comunicaes . . . . . . . . . . . . A.10 Localizao das salas e dos participantes do ambiente . . . . . A.11 Herana e Composio dos anncios do ambiente . . . . . . . B.1 Diagrama de classes do Middleware JXTAula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 77 . . . . . . . . . . . . . . . . . . . . 78 82 83 84 85 86 90 91 92 100 101 102 102 103 104 105 105 106 107 108
. . . . . . . . . . . . . 111
viii
Lista de Tabelas
2.1 3.1 4.1 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11
Tabela comparativa entre as arquiteturas peer-to-peer . . . . . . . . . 30 Mtricas de avaliao dos requisitos no funcionais . . . . . . . . . . 40
Anlise comparativa entre a plataforma JXTA e o middleware JXTAula 64 Caractersticas selecionadas e mtricas da avaliao . . . . Plano de testes para os requisitos funcionais . . . . . . . . Resultado da avaliao para as mtricas funcionais . . . . Resultado da avaliao para as mtricas no funcionais . . Conguraes das mquinas utilizadas nos testes . . . . . . Quantidade de mensagens no cenrio cliente-servidor . . . Quantidade de mensagens no cenrio P2P . . . . . . . . . Tempo de transmisso no cenrio cliente-servidor . . . . . Tempo de transmisso no cenrio P2P . . . . . . . . . . . Resultados obtidos para os cenrios cliente-servidor e P2P Resultados obtidos na avaliao nal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 81 83 86 87 88 89 89 89 91 92
ix
Lista de Cdigos
B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 B.9 C.1
Utilizao da classe NetworkCongurator . . . . . . . . . . . . . . . . Entrar no grupo principal do JXTA (NetPeerGroup) . . . . . . . . . Criao, remoo, entrada e sada em grupos . . . . . . . . . . . . . . Grupos do JXTAula baseado em PeerGroups . . . . . . . . . . . . . . Buscas por grupos e participantes do ambiente . . . . . . . . . . . . . Criao do canal de comunicao de entrada do participantes . . . . . Criao do canal de comunicao de sada com participantes remotos Recebimento e tratamento das mensagens recebidas . . . . . . . . . . Interface utilizada para comunicao com a aplicao . . . . . . . . . Classe que prov as funcionalidades de conexo entre o cliente e o servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.2 Classe que utiliza as funcionalidades do JXTAula . . . . . . . . . . .
110 113 114 116 117 122 123 125 126 127 130
Lista de Siglas
API CPU DNS EAD IM IP IPv4 IPv6 ISO J2EE JVM JXTA GDK GMC GUID GRC NTP P2P PBP PDP PEP PIP PNRP PRP RAM
Application Programming Interface Central Processing Unit Domain Name Server Ensino Distncia Instant Messaging Internet Protocol Internet Protocol verso 4 Internet Protocol verso 6 International Organization for Standarization Java 2 Platform, Enterprise Edition (J2EE) Java Virtual Machine Juxtapose Groove Development Kit Group Membership Certicate Global Unique Identier Group Root Certicate Network Time Protocol Peer to Peer Pipe Binding Protocol Peer Discovery Protocol Peer Endpoint Protocol Peer Information Protocol Peer Name Resolution Protocol Peer Resolver Protocol Random Access Memory xi
Lista de Cdigos
xii
RMI RTT TCP VNC VPN TTL XML
Remote Method Invocation Round Trip Time Transmission Control Protocol Virtual Network Computing Virtual Private Network Time To Live eXtensible Markup Language
Captulo
Introduo
Neste captulo so apresentadas as principais motivaes para o desenvolvimento deste trabalho, estabelecendo-se a problemtica e seus principais objetivos.
1.1 Motivao
A educao a Distncia (EaD) cresceu de forma forte e signicativa. uma rea de grande interesse, tanto em pesquisa quanto em desenvolvimento. Dentre os principais desaos dos sistemas atuais de EaD est a construo de ambientes colaborativos capazes de propiciar servios que supram as necessidades dos participantes, oferecendo alta interatividade e facilidade de uso. Novas arquiteturas e tecnologias tm sido utilizadas para suportar o desenvolvimento deste tipo de sistemas distribudos, visando uma possvel interoperabilidade entre aplicaes criadas por equipes distintas, atravs de modelos bem denidos e exveis. Dentre essas arquiteturas, destacam-se os modelos cliente-servidor e peer-to-peer (P2P ). O modelo cliente-servidor o mais usado atualmente na Internet e no desenvolvimento de muitas aplicaes. Por este modelo ser baseado em uma arquitetura centralizada, ele requer que os servidores suportem uma alta taxa de requisio, e se o servidor no estiver preparado para responder muitas requisies, isto pode ser um gargalo, degradando o desempenho do sistema. Alm disso, existe um ponto nico de falha, pois caso um servidor que no possua contingncia deixe de funcionar, os servios disponibilizados por ele caro indisponveis. Portanto, pode-se perceber que ele no explora a real capacidade da rede, nem
1.1. Motivao
o potencial uso de processamento distribudo. J a arquitetura P2P, baseada em um modelo descentralizado, permite que os recursos e servios computacionais sejam compartilhados, podendo ser utilizada em uma ampla gama de solues de comunicao, onde os dispositivos (peers ) podem construir redes cooperativas auto-organizveis (ROCHA et al., 2004). Entre diferenas notveis de aplicaes cliente-servidor para aplicaes P2P, podem-se destacar como sendo caractersticas exclusivas das arquiteturas P2P :
i. Ausncia de controle central dos computadores participantes do ambiente

distribudo, bem como dos processos e recursos localizados nos mesmos;
ii. Imprevisibilidade, tanto em nmero de participantes, quanto ao tempo que os

mesmos caro conectados ao ambiente;
iii. No-conabilidade da comunicao entre os participantes; iv. Heterogeneidade de plataformas e de poder computacional;
Dentre as tecnologias de desenvolvimento de aplicaes que utilizam o modelo cliente-servidor, algumas das plataformas j consagradas no desenvolvimento de aplicativos com suporte arquitetura centralizada so: Java , Delphi e Visual Basic. Com relao ao Java, o J2EE com certeza a principal referncia, possuindo suporte a criao de um ambiente capaz de fornecer diversas funcionalidades a inmeros usurios remotos, geralmente disponibilizadas atravs do uso de portais (pginas virtuais) hospedados em servidores WEB ou em componentes denominados Beans. Dentre as funcionalidades que podem ser utilizadas pelo desenvolvedor da aplicao, destacam-se a utilizao de componentes de interface com o usurio, mecanismos para manipular imagens grcas, funcionalidades relacionadas com a criao de aplicaes multimdia (streams ), manipulao de documentos XML, funcionalidade de comunicao (sockets ), chamadas remotas de mtodos (RMI ) e mecanismos de persistncia de objetos, dentre outros. (JOHNSON et al., 2004). J o modelo P2P adota uma abordagem onde qualquer dispositivo pode funcionar como cliente ou como servidor, permitindo que recursos e servios computacionais sejam compartilhados. Possibilita-se, com isso, a utilizao deste tipo de arquitetura para que os dispositivos (peers ) possam construir redes cooperativas auto-organizveis. Dentro desta perspectiva, destacam-se como um
1.2. Estabelecimento da problemtica
importante cenrio da atuao de solues P2P as aplicaes de ensino, uma vez que so formadas por um conjunto de participantes distribudos que realizaam atividades de cooperao. Algumas das plataformas para desenvolvimento de aplicaes Peer-to-Peer (P2P) mais populares so: JXTA (JXTA, 2008), Windows
P2P Networking (MICROSOFT, 2008d) e FreePastry (FREEPASTRY, 2008).
1.2 Estabelecimento da problemtica

Mesmo dispondo de plataformas P2P, os desenvolvedores de aplicativos voltados ao ensino distncia ainda precisam desenvolver suas aplicaes considerando funcionalidades muito elementares (ou seja, difcil codicao) e se preocupar com requisitos que no esto diretamente atrelados ao objetivo nal do sistema. Dessa forma, dentre os principais desaos dos sistemas atuais de EaD est a construo de ambientes capazes de proporcionar servios de colaborao voltados aprendizagem, que supram as necessidades de alta interatividade, compartilhamento de informaes e facilidade de uso. Essas caractersticas poderiam estar disponveis sobre a plataforma de rede considerada a m de minimizar o custoso caminho entre a concepo e a implementao da aplicao distribuda. O arcabouo proposto neste trabalho engloba uma arquitetura reutilizvel, adaptvel e apropriada para a interao entre os participantes envolvidos no processo de ensino-aprendizagem, no com o objetivo de substituir as plataformas existentes, mas com o objetivo de complement-las com o fornecimento de funcionalidades que tratem adequadamente as aplicaes no contexto de sistemas de ensino distncia.
1.3 Objetivos da Dissertao

Este trabalho tem os seguintes objetivos especcos:
i. Mapear as necessidades dos sistemas de ensino distncia e as funcionalidades

fornecidas pelas plataformas P2P existentes;
ii. Proporcionar servios de colaborao que supram as necessidades de alta

interatividade, compartilhamento de informaes e facilidade de uso para sistemas colaborativos;
iii. Conrmar a possibilidade de se utilizar as arquiteturas P2P no fornecimento

de servios que utilizam o consagrado modelo cliente-servidor, substituindo-os
1.4. Diviso do trabalho
com desempenho equivalente ou superior;
iv. Retirar da responsabilidade dos desenvolvedores de sistemas colaborativos a

necessidade de projetar suas aplicaes considerando requisitos que no esto diretamente relacionados ao objetivo nal do aplicativo;
v. Minimizar o custoso caminho entre a concepo e o desenvolvimento de

aplicaes distribudas que necessitam prover servios de comunicao entre seus participantes, permitindo o rpido desenvolvimento de aplicaes com funcionalidades de colaborao, troca de informaes e experincias utilizando uma plataforma P2P.
vi. Denir um arcabouo que possa ser instanciado para diversas plataformas P2P,
garantindo a possibilidade de denio de novos servios, e a escalabilidade de componentes j desenvolvidos;
1.4 Diviso do trabalho

No captulo 2, realiza-se um levantamento sobre estado da arte em relao aos sistemas de ensino distncia, e sobre as principais plataformas P2P. So apresentadas classicaes baseadas nas caractersticas que os sistemas de EAD possuem. Tambm so evidenciadas as principais funcionalidades presentes nesse tipo de aplicativo, visando denir os principais servios que sero fornecidos pelo arcabouo (framework ) proposto neste trabalho. Para isso, verica-se as principais plataformas de desenvolvimento P2P disponveis e suas caractersticas. Finalmente, o captulo possui uma tabela comparativa entre as plataformas P2P apresentadas. No captulo 3, as funcionalidades do arcabouo JxAula so descritas, levando-se em considerao os conceitos e funcionalidades de ensino distncia (EaD) destacados no captulo 2. apresentada a arquitetura modular do arcabouo, enfatizando-se o fato dos componentes serem independentes, o que permite que o
middleware possa ser alterado para se adaptar diferentes requisitos. Em seguida,

os mdulos do arcabouo so apresentados, e os padres de projeto empregados so destacados. No captulo 4, descrito o middleware JXTAula, desenvolvido como um estudo de caso para o arcabouo proposto no captulo 3. feita uma descrio geral
1.4. Diviso do trabalho
sobre os servios do middleware e sua relao com as funcionalidades providas pela plataforma JXTA, escolhida dentre as plataformas apresentadas no captulo 2. No captulo 5, aborda-se a integrao do middleware JXTAula a um sistema real de ensino a distncia atualmente em desenvolvimento no Departamento de Engenharia de Teleinformtica da Universidade Federal do Cear, denominado COGEST (Comunicao Gestual com Humanides Virtuais). A arquitetura do sistema COGEST baseada no modelo cliente-servidor ser explicada, e em seguida ser proposta a utilizao de uma nova arquitetura peer-to-peer atravs do JXTAula, demonstrando-se como pode ser realizada a integrao de aplicativos ao JXTAula No captulo 6, so avaliados os resultados obtidos com a arquitetura proposta ao utilizar o middleware JXTAula no sistema COGEST. Dessa forma, fundamenta-se a importncia desse trabalho e enfatiza-se a sua contribuio atravs da avaliao dos requisitos funcionais e no funcionais. No captulo 7, apresentada a concluso deste trabalho com as principais contribuies desta dissertao, alm de serem apresentados os trabalhos futuros.
Captulo
Reviso Bibliogrca
Este captulo apresenta um levantamento do estado da arte em ensino distncia e das principais plataformas P2P. Atravs dessa pesquisa, so denidos os principais servios que podem ser fornecidos pelo arcabouo JxAula. Finalmente, este captulo possui uma tabela comparativa entre as arquiteturas P2P apresentadas.
2.1 Estado da arte em Ensino Distncia

A crescente demanda por ensino e treinamento, conseqncia da intensa evoluo produzida pela cultura, pela cincia e pela tecnologia, vem recebendo respostas positivas atravs da educao distncia. Entretanto, deve-se considerar, antes de tudo, que qualquer que seja a tecnologia utilizada para ensino distncia, essa no substitui nem ir substituir a gura do professor, visto que a mesma somente um instrumento que, se bem utilizado, ir contribuir para ampliar as possibilidades da educao. A democratizao e a facilidade do acesso escolarizao so idias bsicas na educao distncia. Esse um dos desaos que a sociedade atual, mergulhada no desenvolvimento tecnolgico, nos apresenta, ou seja, a questo que est colocada como essa tecnologia pode ser til para a capacitao de pessoas. Em pases como o nosso, com dimenses continentais, onde as coletividades mais afastadas dos grandes centros tm diculdades para realizar seus estudos, onde a proposta de ensino distncia encontra mais aplicabilidade (PERRONE, 2005). Os mecanismos de educao distncia assumem as mais diferentes formas, desde a mais simples, caracterizada pelo "ensino por correspondncia", at os mais
2.1. Estado da arte em Ensino Distncia
sosticados meios que incluem esquemas interativos de comunicao no presencial atravs de redes de comunicao avanadas, como por exemplo, atravs de satlites. Essas novas tecnologias tm sido incorporadas ao longo do tempo e visam melhorar a comunicao entre professor e alunos, permitindo a troca de experincia, vivncia e, conseqentemente, otimizao no tempo de resposta de forma a facilitar o aprendizado. Com a Internet, as fronteiras para a educao distncia se expandiram, possibilitando reunir em um s meio de comunicao as vantagens de compartilhar informaes e idias. Assim, inmeros trabalhos foram surgindo com o objetivo de utilizar a Internet na educao presencial e a distncia. Atravs da Internet, pode-se trocar informaes de forma rpida; acessar especialistas em inmeras reas; manter-se atualizado sobre inmeros tpicos de interesse; formar equipes para trabalho cooperativo independentemente de distncias geogrcas e acessar vrias formas de arquivos e repositrios de informaes, por exemplo, trabalhos publicados, textos e artigos. Dessa forma, as informaes disponveis tornam-se fonte de pesquisa, permitindo o acesso fcil e rpido por pessoas de qualquer parte do mundo conectadas Internet.
2.1.1 Modalidades dos sistemas de EaD

Segundo (LYRA et al., 2003), o uso educacional das tecnologias de rede est apoiada em diferentes vertentes de pesquisa e desenvolvimento, podendo ser reunido nas seguintes modalidades:
i. Aplicaes hipermdia para fornecer instruo distribuda : nesta modalidade

encontram-se os cursos multimdia (com tarefas a serem realizadas pelos alunos, formas de avaliao e suporte para comunicao com o professor) e cursos no formato hipertexto (compostos de pginas Web, seguindo o modelo de livro-texto);
ii. Sites educacionais : Oferecem um conjunto de funcionalidades para uso

educacional na Internet atravs de sites de acesso pblico, que servem como suporte educao virtual reunindo diferentes formas de apoio ao trabalho docente e ao aprendizado autnomo dos estudantes;
iii. Portais educativos : preocupam-se principalmente em distribuir informao

atravs de cursos, notcias, artigos e livros eletrnicos (e-books ).
iv. Sistemas de autoria para cursos distncia : destacam-se por prover um

ambiente que possibilita a criao e execuo de cursos pela internet. Os sistemas de autoria para ambientes virtuais de ensino-aprendizagem so aplicaes que fornecem um conjunto de ferramentas para a construo e manuteno de ambientes educacionais onde h a simulao das formas tradicionais de ensino ou disponibilio de ferramentas que permitem maior exibilidade na estruturao dos ambientes.
v. Salas de aula virtuais : ampliam o conceito de sistemas de autoria para cursos

distncia ao fornecerem suporte cooperao entre docentes e alunos atravs de ferramentas, como por exemplo, grupo de notcias (newsgroups ), fruns,
chats e e-mails. O contedo desses cursos engloba imagens, textos, vdeos e

aplicaes para simulaes laboratoriais.
vi. Arcabouos (frameworks) para aprendizagem cooperativa : conjuntos integrados

de ferramentas para aprendizagem cooperativa que permitem a personalizao de ambientes tanto para trabalho quanto para aprendizagem em cooperao. So exveis, permitindo, a partir de componentes bsicos de interface e de objetos fornecidos, o desenvolvimento de aplicaes cooperativas personalizadas, sendo adaptveis necessidade do usurio e podendo integrar diversas ferramentas.
vii. Ambientes distribudos para aprendizagem cooperativa : caracterizam-se por

fornecer aos seus usurios um ambiente em que todos possam compartilhar experincias e discutir questes em grupos. Dentre as modalidades descritas, este trabalho engloba caractersticas que esto principalmente voltadas para ambientes distribudos para aprendizagem cooperativa, e desta forma, faz-se necessrio entender e identicar quais so as principais necessidades deste tipo de sistemas. Paralelamente, engloba-se ainda algumas caractersticas relacionadas ao uso de salas de aulas virtuais, embora estas faam parte do ambiente distribudo para aprendizagem cooperativa.
2.1.2 Caractersticas dos ambientes para aprendizagem cooperativa

Esforos tm sido feitos em pesquisas para identicar os modelos mais apropriados para ambientes de aprendizagem cooperativa, ou seja, tem-se buscado
identicar quais so as caractersticas que esse tipo de ambiente deve ter para suportar ecientemente o processo de ensino-aprendizagem virtual. Dentre essas caractersticas (HARASIN, 1998) destaca as seguintes:
Aprendizagem Colaborativa : O estudante visto como um participante ativo

no processo de aprendizagem, construindo conhecimento por um processo de discusso e interao com o aprender. Essa interao entre estudantes que distingue as atitudes cooperativas de outros ambientes de aprendizagem. O ambiente colaborativo particularmente apropriado para aproximaes de aprendizagem que enfatizam interao de grupo.
Aprendizagem Ativa :
Os estudantes fazem anotaes regularmente, no
apenas sobre as discusses ocorridas nas conferncias, mas tambm escrevendo mensagens aos demais participantes. Essa atividade oferece aos participantes uma oportunidade de analisar suas aes no ambiente, possibilitando ainda o registro dessas interaes no sistema. Assim, estatsticas podem ser geradas sobre a quantia de participao de cada estudante do ambiente. Isso pode ser utilizado para vericar e controlar as aes dos participantes, estimulando a participao daqueles menos ativos, ou seja, que interagiram pouco com os demais. A participao ativa cria um ambiente rico de informao, uma vez que proporciona mltiplas perspectivas de idias ou temas do processo colaborativo.
Aprendizagem Interativa :
mas tambm interativa.
A aprendizagem no deve ser somente ativa, A construo de conhecimento se d quando os
participantes do ambiente exploram assuntos, examinam os argumentos de um e de outro, concordam, discordam e questionam posies. Aqueles que estiverem exercendo um papel de instrutor podem requerer aos demais que enviem comentrios e leituras para os temas abordados, ou ainda, os demais participantes podem enviar informaes de maneira espontnea. Uma outra perspectiva fornecida por (MARTINS, 2000), onde se observa que um ambiente virtual de aprendizagem cooperativa deve gerar um espao para a criao de "comunidades de aprendizagem", em que os participantes podem publicar contedo, gerar cooperao, colaborao e promover interatividade, de forma que os outros participantes do ambiente virtual possam ser capazes de acessar o contedo
10
disponibilizado, produzir novos contedos em co-autoria a partir da discusso, debate, interao, anlise e avaliao do contedo disponibilizado. (MARTINS, 2000) ainda acrescenta que tais ambientes poderiam usar metforas fsicas da escola, com espaos para a pesquisa e produo de conhecimento. Dessa forma, nesse tipo de ambiente deve existir:
i. Um ambiente para criao de cursos em salas virtuais; ii. Um espao de publicao de contedos e atividades; iii. Um conjunto de ferramentas de interao sncrona e assncrona; iv. Recursos para avaliao do aprendizado; v. Recursos para administrao e gerncia do sistema.
A gura 2.1 resume as principais funcionalidades que devem ser consideradas na construo de um ambiente virtual de aprendizagem cooperativa.
Figura 2.1: Funcionalidades de um ambiente virtual de aprendizagem cooperativa
2.1.3 Enquadramento deste trabalho e funcionalidades fornecidas

At o momento, este trabalho identicou as principais modalidades dos sistemas de EaD (dentre as quais esto compreendidos os ambientes virtuais para aprendizagem cooperativa). seguintes servios: Com base nas caractersticas descritas, buscou-se mapear as funcionalidades necessrias para este tipo de sistema, obtendo-se os
i. O ambiente colaborativo deve ser capaz de organizar seus participantes em

salas virtuais (grupos);
11
ii. O sistema deve prover funcionalidades para localizar as salas criadas pelos
participantes e para criar novas salas;
iii. Os participantes devem ser capazes de localizar uns aos outros, bem como
comunicarem-se entre si visando a cooperao e o aprendizado colaborativo;
iv. O ambiente virtual deve permitir que um participante do ambiente possa

enviar mensagens a todos os participantes de uma determinada sala ou a outro participante em particular;
v. Deve haver a possibilidade de compartilhar arquivos entre os participantes que

estejam no ambiente colaborativo. A questo que surge : ser que uma topologia de comunicao baseada em
P2P a melhor opo? Essa uma pergunta difcil de ser respondida, pois, na
verdade, o que este trabalho pretende disponibilizar uma alternativa para que os desenvolvedores de sistemas de EaD possam utilizar uma abordagem diferente do modelo centralizado. Para isso, ser comparado e avaliado esta perspectiva no captulo 6, e neste momento, suciente esclarecer que se espera que a arquitetura desenvolvida tenha um desempenho equivalente ou superior ao modelo centralizado. Contudo, vale observar as principais motivaes que determinaram a escolha de uma arquitetura P2P :
Comunicao interativa : possibilita a utilizao de servios de troca de

mensagens, voz e vdeo atravs de uma infra-estrutura descentralizada, que no necessitam da existncia de um servidor para manter o sistema funcionando. Alm disso, atravs da diviso do ambiente em de grupos, otimiza-se o trfego de mensagens enviadas e recebidas.
Colaborao e distribuio de contedo : possibilita o compartilhamento de

espaos de trabalhos, documentos e experincias atravs organizao de participantes que possuem interesses semelhantes, tais como a distribuio e compartilhamento de documentos de texto, apresentaes, audio, vdeo e
softwares para todos os participantes de um grupo. Processamento distribudo : possibilita o uso de recursos compartilhados,
tais como o uso de processamento distribudo. Dessa forma, um processo que levaria muito tempo para ser executado, devido ao seu alto custo de
12
processamento, poderia ser dividido em tarefas menores, de forma que cada parte da tarefa pudesse ser executada em um peer do grupo. Assim, todas as tarefas estariam executando em paralelo, reduzindo signicativamente o tempo total de nalizao do processo. Vale ressaltar ainda que no est no escopo deste trabalho denir o mecanismo de persistncia a ser utilizado pelas aplicaes. Est uma caractersticas bastante peculiar do sistema de EaD, o qual normalmente utilizar uma das seguintes abordagens:
Banco de Dados Centralizado no Coordenador : Os dados so armazenados

em uma nica mquina central (normalmente denominado de coordenador ). Pode-se observar que essa no uma arquitetura muito expansvel, principalmente em ambientes com grandes quantidades de dados, pois essa mquina central pode se tornar o gargalo do sistema. Caso no haja nenhum mecanismo de replicao das informaes, se por algum motivo essa mquina sair do ambiente, todas as informaes caro indisponveis aos demais usurios do sistema.
Banco de Dados Replicado com Coordenador :
Nesta abordagem, cada
participante pode possuir uma cpia dos dados do ambiente, como forma de garantir que as informaes estejam sempre disponveis, pois no h dependncia de uma nica mquina. Porm, esta arquitetura necessita de alguma forma de controle ou autoridade para sincronismo das informaes, onde somente o coordenador pode atualizar as informaes do ambiente.
Banco de Dados Replicado sem Coordenador :
Esta abordagem bem
semelhante anterior, porm, no existe um controle de autoridade, de forma que qualquer participante pode atualizar as informaes do ambiente. Deve existir um mecanismo de controle de concorrncia, uma vez que diversos participante podem tentar atualizar a mesma informao ao mesmo tempo, o que poderia deixar o sistema em um estado inconsistente.
Bando de Dados Distribudo : Neste caso o banco de dados dividido e

distribudo entre mltiplas mquinas (como se cada mquina tivesse um "pedao "do banco de dados). Assim, cada mquina responsvel por manter determinadas informaes do ambiente, pois quando um participante deseja
2.2. Estado da arte em plataformas P2P
13
atualizar ou requisitar alguma informao, este dever faz-lo atravs de uma requisio mquina que est responsvel por quele segmento de informao do ambiente.
2.2 Estado da arte em plataformas P2P

Essa seo apresenta as principais plataformas de desenvolvimento P2P, com o objetivo de identicar suas caractersticas e arquiteturas. Com base nessas caractersticas, so apresentadas as principais motivaes que determinaram a escolha da plataforma JXTA para a criao do middleware descrito no Captulo 4.
2.2.1 JXTA Descrio Geral

O JXTA (JXTA, 2008) - do ingls juxtapose (que signica sobrepr) - visa criar uma rede virtual auto-organizvel sobre uma topologia de rede fsica. Foi uma iniciativa da Sun Microsystems, e que atualmente um projeto de cdigo livre (open source ) desenvolvido pela comunidade. Este projeto constitudo de uma especicao independente de linguagem e plataforma computacional para comunicao entre dispositivos de uma rede, onde os peers podem assumir um dos seguintes papis:
Edge Peers : so peers que no desempenham nenhuma funo especial para a

rede P2P, geralmente sendo os computadores desktops dos usurios conectados na Internet ;
Rendezvous Peers : desempenham um papel especial no fornecimento de

informaes sobre a rede, atuando na descoberta de recursos e funcionando como indexadores (cache ) para facilitar as buscas, sendo geralmente os peers com maior poder computacional e com endereo IP no dinmico;
Relay Peers : so responsveis por realizar o roteamento de informaes

de/para peers que estejam protegidos por um rewall ou NAT, geralmente sendo o mesmo peer que desempenha o papel de rendezvous.
14
Portanto, a plataforma JXTA formada por um conjunto de peers que so descobertos na rede atravs de seus anncios. Os peers podem ser reunidos em grupos (denominado peer group ), de forma que pipes (canais de comunicao) podem ser criados entre dois peers (unicast pipe ) ou para um determinado grupo de peers (propagate pipe ). Quando um pipe criado para um grupo de peers, qualquer mensagem enviada atravs deste pipe recebida por todos os peers que fazem parte deste grupo. Tanto as mensagens, quanto os anncios de peers, de grupos ou de pipes, so armazenados e transmitidos atravs da linguagem XML. Assim, os pipes no esto associados nenhum dispositivo especco, pois no possuem informaes tais como um endereo IP, sendo descobertos e mapeados para um determinado dispositivo de maneira dinmica, atravs de mecanismos de resoluo de anncios. Estes mecanismos de resoluo so normalmente providos atravs dos super-peers (rendezvous ), que agregam a funo de armazenadores de ndices que referenciam os diversos anncios da rede P2P.
Caractersticas da Arquitetura
O JXTA foi projetado para ser independente de linguagens de programao (atualmente existem implementaes em C, Perl, Python e Java), de plataformas (por exemplo, Microsoft Windows e Unix), e dos protocolos de rede (por exemplo, TCP/IP e Bluetooth). Desta maneira, o JXTA abrange PCs, laptops, PDAs, sensores, eletrnicos, roteadores, servidores de data-centers e sistemas de armazenamento (JUNIOR, 2005). Conforme (GRADECKI, 2002), a arquitetura do JXTA composta por trs camadas, demonstrado na gura 2.2:
Camada de Aplicao : onde o desenvolvedor da aplicao constroi a interface

grca do sistema que ser disponibilizada para o usurio nal, visando possibilitar o uso de comunicao baseada no modelo P2P do JXTA;
Camada de Servios : responsvel por fornecer as funcionalidades para os

desenvolvedores de aplicaes, baseados nos protocolos da camada de ncleo;
Camada de Ncleo : onde o cdigo responsvel pela implementao dos

protocolos do JXTA se encontra. Os protocolos so responsvel por fornecer as
15
funcionalidades para os peers, grupos, segurana, mecanismos de localizao, troca de mensagens, etc.
Figura 2.2: Arquitetura do JXTA

Conforme (BROOKSHIER et al., 2002), a especicao do JXTA inclui os seguintes protocolos, demonstrado na gura 2.3:
Peer Discovery Protocol (PDP) : peers utilizam este protocolo para descobrir
recursos do JXTA dinamicamente. Em uma rede IP, a implementao deste protocolo consiste de duas tarefas: o envio de uma mensagem multicast atravs da rede local e do envio de uma mensagem ao rendezvous para a descoberta de
peers alm da rede local. Os rendezvous so usados para armazenar anncios

de recursos. Alguns rendezvous so providos pela prpria Sun com o objetivo de permitir a localizao e utilizao da rede JXTA pela Internet ;
Pipe Binding Protocol (PBP) : o protocolo responsvel por conectar o pipe

(canal de comunicao);
Peer Information Protocol (PIP) : este protocolo coleta informaes sobre o

estado de um peer, sendo til para monitoramento de desempenho da rede, podendo ser usado para vericar se um determinado peer est on-line;
Peer Resolver Protocol (PRP) : este protocolo serve de infra-estrutura para

outros protocolos do JXTA, tais como os protocolos Peer Information (PIP) e o Peer Discovery (PDP) ;
16
Peer Endpoint Protocol (PEP) : estabelece um conjunto de mensagens de

buscas usadas para encontrar informaes de roteamento, antes da execuo do envio de uma mensagem entre peers. As rotas encontradas so armazenadas localmente, e incluem informaes sobre o remetente, o destinatrio, o
time-to-live (TTL) e a seqncia ordenada de peers que devem ser utilizados

da origem ao destino;
Rendezvous Protocol : Responsvel por propagar mensagens dentro de um

grupo e controlar esta propagao, alm de permitir a utilizao dos servios providos em um grupo;
Membership Protocol : Utilizado na validao de peers que desejam entrar em

determinado grupo.
Figura 2.3: Protocolos da especicao do JXTA
2.2.2 Pastry Descrio Geral

Pastry (ROWSTRON; DRUSCHEL, 2001) tem como intuito construir uma plataforma para o desenvolvimento de aplicaes peer-to-peer descentralizadas, auto-organizveis e tolerantes falhas, baseadas no modelo DHT (XIE, 2003) para compor uma topologia estruturada em anel. Existem duas implementaes disponveis e que podem ser utilizadas pelos desenvolvedores de aplicaes: FreePastry e SimPastry/VisPastry, sendo a primeira a mais utilizada na maioria dos projetos que utilizam esta tecnologia P2P na Internet. O funcionamento deste modelo se baseia na atribuio de chave aos recursos e dispositivos da rede, onde cada chave (que representa um recurso) mapeada
17
para um dispositivo (peer ) do anel, baseado na proximidade dos valores nmericos atribudos s chaves dos recursos e dos dispositivos. Esta topologia utilizada para localizar os recursos da rede de forma eciente, onde a pesquisa feita a partir de uma determinada chave, e possvel localizar o dispositivo que ter uma copia do recurso procurado.
Um sistema Pastry constitudo por ns e objetos que se encontram distribudos em um anel e podem ser encontrados atravs de identicadores (chaves). O dispositivo que possui o identicador numericamente mais prximo da chave de um determinado objeto responsvel por ele, ou seja, para acessar o objeto, ser necessrio se comunicar com este dispositivo. Os dispositivos conectados ao Pastry possuem uma chave de 128 bits denominada
NodeID (MICROSOFT, 2008b). Sempre que um novo peer entra no sistema, este
nmero escolhido de forma nica e aleatoriamente. Os peers que possuem NodeID prximos esto distribudos prximos uns dos outros na topologia em anel. Da mesma forma, cada chave (key ), que representa os recursos compartilhados (object ), mapeada pela rede P2P para um dispositivo (peer ). O FreePastry (FREEPASTRY, 2008), por exemplo, fornece o armazenamento e localizao de objetos baseada no Past (DRUSCHEL; ROWSTRON, 2001). Os comandos disponveis pelo componente so: put(key, object) que insere um objeto para ser compartilhado na rede e o atribui uma chave; remove(key) que remove a associao de uma chave a um determinado objeto e get(key) que retorna o objeto associado a uma certa chave. Para realizar a busca na rede P2P de maneira estruturada, as mensagens so encaminhadas para o peer que possua identicador (NodeID ) mais prximo da chave. A gura 2.4 ilustra este mecanismo. Neste modelo, cada peer mantm uma tabela de roteamento, um conjunto de vizinhos e um conjunto de ns folhas. A tabela de roteamento formada pelos prexos dos peers, de forma que os registro contenham os endereos IPs dos peers que esto mais prximos entre si. O conjunto de vizinhana contm os NodeIDs dos peers que esto mais prximos e so normalmente utilizado no roteamento das mensagens. O conjunto de folhas formado pelos peers sucessores e peers predecessores do n. Para fornecer as funcionalidade de comunicao em grupo, o FreePastry utiliza o Scribe (CASTRO et al., 2002), componente que permite que os participantes possam
18
Figura 2.4: Mecanismo de localizao do Pastry

se inscrever em um determinado grupo baseado em uma topologia de rvores. No Scribe, os grupos so denominado de tpicos, portanto, cada participante pode criar diversos tpicos, aos quais outros participantes podem se inscrever de forma a comear a participar da comunicao do grupo.
2.2.3 Windows P2P Networking Descrio Geral

Windows Peer-to-Peer Networking (MICROSOFT, 2008d) uma plataforma
suportada atualmente pelos sistemas operacionais Windows XP e Windows Vista. Com a utilizao de uma topologia baseada no modelo descentralizado, esta tecnologia visa proporcionar melhor utilizao dos recursos disponveis nos computadores, suportando aplicaes com comunicaes em tempo real (real-time communications, RTC ), colaborao entre participantes, distribuio de documentos e processamento distribudo. Esta tecnologia utiliza o protocolo IPv6 para prover o modelo de comunicao de rede entre os participantes, e o protocolo PNRP para a descoberta de peers (servio de resoluo de nomes), sem que haja a necessidade de utilizar um servidor DNS para este propsito. Como forma de reunir os diversos participantes, utiliza-se grafos (para fornecer as funcionalidades de encaminhamento de mensagens e replicao de informaes) ou grupos (para fornecer as funcionalidades de autenticao e comunicao segura).
19
A arquitetura do Windows P2P Networking baseada em um mecanismo de comunicao puramente P2P, propiciando as funcionalidades de descoberta de peers, grafos, grupos, armazenamento replicado e mecanismos de localizao. A gura 2.5 representa a sua arquitetura.
Figura 2.5: Arquitetura do Windows Peer-to-Peer Networking

Como essa uma tecnologia relativamente nova e existe pouca bibliograa em portugus sobre o assunto, este trabalho detalha um pouco mais o tema. A seguir, so descritos os elementos que compem a arquitetura:
Grafos (Graphing)
Um grafo usado para representar a idia de uma relao entre objetos. Aparecem representados por uma gura com ns ou vrtices unidos por um trao denominado aresta que representa a relao entre esse ns. Para o conceito de comunicao em redes P2P, os vrtices so representaes dos peers, e as arestas das conexes entre esses peers. Dessa forma, o grafo nada mais que um conjunto de ns interconectados, propiciando a transferncia de dados atravs de mecanismos de inundao (denominado ooding ) com o estabelecimento de uma conexo TCP. Cada informao encaminhada pela rede identicada atravs de um GUID (Global Unique Identier ), representado por um nmero de verso e o tempo de emisso, propiciando a vericao de informaes mais recente. Alm disso, este identicador utilizado pelo processo de sincronizao de informaes (que utiliza
20
o ooding para propagao das atualizaes), responsvel por manter consistentes todas as informaes existentes nos participantes que fazem parte do grafo. Cada peer possui um identicador denominado NodeID, que criado atravs de uma funo aleatria quando ele entra em um grafo. Cada grafo possui seu identicador, o qual o menor NodeID de seus integrantes, que utilizado para detectar participaes de grafos, evitando que existam partes da rede que no possam ser alcanadas. Se um determinado grafo for particionado, cada partio vai possuir um identicador distinto, propiciando que se detecte tal fenmeno e haja um processo de conexo do grafo original para solucionar o problema. Quando um peer deseja se conectar a um grafo, ele deve inicialmente utilizar os servios de localizao, por exemplo o PNRP, para se conectar a outro n que j pertena ao grafo. Os peer que j pertencem ao grafo esto limitados a se conectar a um nmero mximo de outros peers, e caso este peer ainda no tenha atingido este limite, ele envia uma mensagem de aceitao ao peer que est desejando entrar no grafo. Caso o limite j tenha sido atingido, o peer envia uma mensagem de negao ao peer que est desejando entrar no grafo, porm esta mesma mensagem informa uma lista de outros peers que pertencem ao grafo para que se possa tentar estabelecer a comunicao com eles. J no processo de desconectar-se de um grafo, o peer envia uma mensagem com a informao que est saindo da rede, e neste caso, deve-se observar que esse processo pode ocasionar uma partio na rede. Essa mensagem contm uma lista dos vizinhos do n que est se desconectando, de forma que quando outro peer recebe a mensagem, ele tenta se conectar a um n da lista, como forma de minimizar a probabilidade de partio no grafo.
Grupos (Grouping)
Diferentemente dos grafos que so meras associaes entre peers e que no provem nenhum mecanismo de segurana, os grupos so responsveis tanto por gerenciar as credenciais dos membros do grupo (fornecendo mecanismos de autenticao e autorizao), bem como pela publicao de registros no grupo de forma segura, garantindo a condencialidade nas conexes estabelecidas. Cada grupo possui um identicado denominado GroupID, que usado pelos membros para identicar grupos formados entre diferentes peers. Cada membro do grupo possui
21
credenciais para comprovar que ele realmente pertence ao grupo e para garantir a autenticidade das informaes enviadas. Quando um grupo criado, as chaves criptogrcas (pblica e privada) so criadas para o grupo. O participante que armazena a chave privada do grupo denominado de dono do grupo (owner ). Quando um peer decide criar um novo grupo, o primeiro passo a criao de um certicado raiz para o grupo (Group
Root Certicate - GRC ). Este certicado baseado no nome do grupo e na chave

privada do participando que est criando o grupo. Aps a criao do certicado raiz, dene-se o identicado do grupo (GroupID), e este registrado no servio de localizao PNRP, para que o grupo possa ser encontrado por outros peers. Em seguida, o criador do grupo dene um conjunto de polticas de segurana para o grupo, visando o controle dos participantes do grupo. A partir da, podem ser enviados convites atravs de mensagens XML contendo parmetros que autorizem a entrada de um participante no grupo. Dessa forma, para entrar em um grupo, um peer deve inicialmente receber um convite do dono do grupo (owner ) que possui algumas informaes sobre o grupo, que sero utilizadas durante o ingresso do participante. Ao receber esse convite, o
peer utiliza os parmetros enviados no convite para descobrir um dos membros do

grupo atravs do protocolo PNRP. Somente aps a autenticao de ambas as partes (peer que deseja entrar no grupo e um membro do grupo que foi localizado) o peer estabelece uma conexo com o membro do grupo, se tornando um novo membro do grupo. Com o tempo, o novo membro descobre e estabelecer novos vizinhos, visando a otimizao da topologia da rede. Para que um membro possa participar e utilizar os servios providos pelo grupo, ele deve possuir credenciais vlidas. Estas credenciais so certicados X.509 denominados de certicados de membro do grupo (Group Membership
Certicate - GMC ). A segurana nos grupos garante a integridade dos dados

que estejam armazenados no banco de dados do grupo e permite que somente membros devidamente autorizados possam acessar esses registros. Tais registros so informaes que esto replicadas em todos os membros do grupo, de forma que quando um determinado peer deseja localizar uma determinada informao, esta busca pode ser feita de maneira local (pesquisa em cache ) ou de maneira distribuda para os demais membros do grupo (pesquisa remota).
PNRP (Peer Name Resolution Protocol)
22
Uma diferena notvel entre as arquiteturas centralizadas e descentralizadas que as primeiras utilizam um servio de localizao de nomes baseado em servidores DNS, os quais registram os nomes dos computadores servidores, de forma que os mesmos possam ser consultados pelos clientes. J no ambiente distribudo das redes
P2P, existe a necessidade de um servio de localizao baseado em atualizaes

dinmicas, com mecanismos interativos que no utilizem uma entidade centralizada, e que no caso do Windows Peer-to-Peer Networking, o protocolo utilizado o PNRP (Peer Name Resolution Protocol ) (MICROSOFT, 2008c). A pesquisa por nomes na rede pode se relacionar a um computador, usurio, grupo, servio, ou mesmo a qualquer outro dispositivo que utilize um endereo IPv6. Os nomes so publicados de maneira segura na rede atravs de certicados e com assinatura digital. Os identicadores PNRP so uma combinao de 256 bits construdos a partir do identicador do peer e do identicador do servio (Service
Location ), conforme gura 2.6.
Figura 2.6: Identicadores PNRP (PNRP IDs )

Para entender o funcionamento do mecanismo de localizao do PNRP, pode-se observar o exemplo da gura 2.7, que representa um conjunto com 5 participantes:
A (cujo PNRP ID 200 ), B (cujo PNRP ID 450 ), C (cujo PNRP ID 500 ), D (cujo PNRP ID 350 ) e E (cujo PNRP ID 800 ). As setas representam os
participantes que um determinado peer conhece, por exemplo, o participante A tem em sua base os peers B e C. Dessa forma, quando o participante A deseja localizar o PNRP ID 800, ocorre o seguinte processo:
i. J que o PNRP ID 500 o mais prximo do PNRP ID 800, o peer A faz uma
pesquisa neste n (Peer C) - seta 1 da gura 2.8.
23
Figura 2.7: Cenrio para localizao atravs do PNRP
ii. O Peer C no possui em sua base o PNRP ID 800, nem to pouco, nenhum
PNRP ID que seja mais prximo do PNRP ID 800. Dessa forma, ele responde de volta ao Peer A indicando que no foi possvel localizar nenhuma informao mais prximo do PNRP ID procurado - seta 2 da gura 2.8.
iii. Em seguida, j que o PNRP ID 450 o o mais prximo do PNRP ID 800, o

Peer A faz uma pesquisa neste n (Peer B) - seta 3 da gura 2.8.
iv. Uma vez que o Peer B possui em sua base o PNRP ID 800, ele responde de
volta ao Peer A indicando o endereo IPv6 do PNRP ID procurado - seta 4 da gura 2.8.
v. Com isso, o Peer A capaz de localizar o Peer E (PNRP ID 800) e, com isso,
estabelecer uma comunicao com o mesmo - setas 5 e 6 da gura 2.8.
2.2.4 Groove Development Kit Descrio Geral

O Groove (GROOVE, 2008) um ambiente para colaborao em equipe que permite o compartilhamento de dados entre usurios, onde os participantes so adicionados e organizados em grupos lgicos de trabalho denominados espao de trabalho. Isto o torna uma tima ferramenta de colaborao, principalmente quando
24
Figura 2.8: Processo de localizao atravs do PNRP

se trata de cenrios mveis, em que usurios precisam ser capazes de trabalhar de maneira desconectada da rede, mas com a possibilidade de ler, acessar e atualizar os dados compartilhados quando estiverem conectados. O Groove no uma plataforma de desenvolvimento, conforme os demais componentes descritos anteriormente neste captulo, e sim um programa de trabalho em grupo que suporta colaborao, comunicao e coordenao de vrios usurios em uma rede. Entretanto, ele foi includo neste trabalho devido sua ampla utilizao e referncia na bibliograa de redes P2P. Ele inclui a integrao de correio eletrnico, calendrio, espaos de trabalho, listas de discusso e sistemas de gerenciamento de documentos atravs de uma topologia P2P hbrida, descrita posteriormente. Os desenvolvedores de aplicativos podem utilizar as funcionalidades providas pelo Groove como forma de coletar informaes, porm ser necessrio desenvolver uma camada intermediria que integre seus aplicativos aos dados armazenados no Groove atravs da tecnologia Web Service. Uma vez criado um espao de trabalho, pode-se enviar um convite para que outros participantes se unam a esse espao colaborativo e comecem a acessar e gerar informaes compartilhadas. Esse convite mostra uma noticao para cada participante, permitindo que eles faam o download do espao de trabalho para suas mquinas locais. A partir do momento que o usurio armazena o espao de trabalho em sua mquina local, o mesmo estar apto colaborar, e qualquer alterao que
25
um participante faa prpria base local do espao de trabalho, tais como adicionar ou alterar um arquivo ou tpico de discusso, ser propagado de modo automtico e seguro para todos os demais participantes que estiverem conectados a este grupo de trabalho. A gura 2.9 mostra o espao de trabalho da ferramente Groove, com suas principais funcionalidades.
Figura 2.9: Espao de trabalho do Groove
O Groove tem uma arquitetura P2P hbrida, baseada em clientes e servidores. A plataforma armazena todos os dados nos participantes, em vez de armazen-los em um servidor central. Alm disso, os dados so sempre criptografados, tanto os armazenados em discos locais dos usurios, quanto as mensagens de comunicao enviadas pela rede. Dessa forma, pode-se utilizar uma conexo pblica pela Internet, sem a necessidade de congurar e utilizar conexes VPN (rede virtual privada) para sincronizar alteraes, pois a sincronizao automtica j utiliza mecanismos de criptograa. Outra caracterstica importante da arquitetura que somente as partes alteradas do espao de trabalho so efetivamente sincronizadas atravs dos
26
participantes do grupo, em vez de enviar todo o espao de trabalho, de forma a otimizar a utilizao dos recursos de rede. Esta uma funcionalidade importante quando se leva em considerao que os participantes do ambiente podem estar espalhados por uma rede distribuda de baixa velocidade. As comunicaes entre os participantes da rede utilizam mensagens XML, as quais so enviadas de maneira criptografada. Se um participante est desconectado da rede, ele continua tendo acesso aos dados e quaisquer alteraes no espao de trabalho so armazenadas de forma local, para que quando o mesmo se conecte rede, estas alteraes sejam enviadas aos outros participantes, atualizando e sincronizando os dados. Assim, os partipantes de um grupo de trabalho se comunicam entre si de forma individual e direta, mantendo uma topologia puramente
P2P para sincronismo de informaes. Porm, observa-se que este mecanismo de

sincronismo de informaes baseado no modelo P2P mais eciente nos casos em que os participantes estejam conectados rede na maior parte do tempo, atravs de conexes com bom desempenho e velocidade. Para contornar essa diculdade, pois normalmente este no o cenrio das redes P2P, o Groove utiliza um servidor relay que atua como um servio de armazenamento e encaminhamento, de modo que os clientes possam se comunicar atravs de rewalls e tentam minimizar as diculdades enfrentadas pelos participantes conectados baixas velocidades. de informaes. As alteraes feitas pelos clientes que esto conectados ao ambiente so enviadas ao servidor relay, o qual as armazena em uma la, de forma a serem encaminhadas posteriormente aos outros participantes. Assim, quando um participante entrar na rede, ele recebe e atualiza as informaes que foram feitas por outros peers, bem como envia quaisquer alteraes que tenham realizado enquanto estava desconectado. A gura 2.10 representa a arquitetura hbrida do Groove atravs dos participantes (peers ) e de um servidor relay (MICROSOFT, 2008a). O servidor relay tambm armazena cpias criptografadas temporrias para otimizar o trfego de atualizao
Integrao de aplicativos ao Groove

A integrao de outros aplicativos ao programa colaborativo Groove envolve duas etapas. Inicialmente, dever ser criado um formulrio para entrada de dados pelo usurio, onde podem estar disponveis as diversas funcionalidades do Groove, dentre
27
Figura 2.10: Comunicao atravs de Firewalls pelo Servidor Relay

elas: colaborao, comunicao, coordenao de usurios, integrao com correio eletrnico, calendrio, espaos de trabalho, listas de discusso, udio-conferncia e sistemas de gerenciamento e compartilhamento seguro de documentos. Em seguida, os dados coletados pelos formulrios que estaro disponveis de forma sincronizada entre os diversos participantes do grupo podem ser lidos e acessados por outros aplicativos atravs do uso da tecnologia Web Services. Para isso, ser necessrio que o desenvolvedor utilize uma camada intermediria responsvel por ler as informaes disponveis no programa Groove atravs de componentes da API (Application
Programming Interface) do Groove SDK (SAID; RAMAMURTHY, 2003). A gura

2.11 demonstra o mecanismo de integrao do Groove com outros aplicativos.
2.2.5 Tabela comparativa entre as arquiteturas apresentadas

At agora, foram apresentadas as principais plataformas de desenvolvimento
P2P, com o objetivo de identicar suas principais caractersticas e arquitetura.

A comparao que est a seguir uma das contribuies deste trabalho, visto que importante que seja feita uma anlise dos critrios e caractersticas de cada arquitetura, acrescentando ao trabalho uma comparao entre diversos arquitetura para desenvolvimento de sistemas baseados em P2P. Foram selecionados para serem analisados os seguintes critrios, conforme demonstra a tabela 2.1:
28
Figura 2.11: Integrao dos dados armazenados no Groove com outros aplicativos
i. Topologia da arquitetura : verica o tipo de topologia de rede que a plataforma

P2P utiliza, podendo ser: anel, descentralizada, hbrida (contm aspectos das
redes centralizadas e descentralizadas) ou hierrquica (TAYLOR, 2004);
ii. Modelo de mensagens :
verica o tipo de mensagem trocada entre os
participantes da rede, geralmente baseadas em linguagem de marcao (XML) ou chamada de mtodos em objetos remotos (RMI);
iii. Comunicao em grupo : verica se a plataforma P2P fornece este servio de

forma nativa;
iv. Identicao das entidades da rede : verica como a plataforma P2P identica
os recursos da rede, podendo tais recursos serem: peer, canais de comunicao,
29
arquivos compartilhados ou outros dispositivos;
v. Segurana : verica se existem mecanismos para garantir a autenticidade e

condencialidade das informaes que trafegam pela rede ou de informaes que estejam armazenadas em seus participantes;
vi. Compartilhamento de arquivos : verica se a plataforma disponibiliza esta

funcionalidade para as aplicaes das camadas superiores de forma nativa;
vii. Armazenamento distribudo :

P2P ;
verica se a plataforma disponibiliza o
armazenamento de informaes distribudas entre os participantes da rede
viii. Plataformas suportadas : verica quais so os sistemas operacionais que

podero ser usados, tais como: Windows, Linux, Solaris, etc;
ix. Protocolos e especicaes : verica se os protocolos utilizados pela plataforma

P2P so abertos - domnio pblico - ou proprietrios - pertencem empresa(s);
x. Linguagens suportadas : verica quais so as linguagens de desenvolvimento

que podero ser usadas;
xi. Desenvolvedor do componente : verica se os responsveis por manter a

plataforma P2P so comunidades ou empresas privadas;
2.2.6 Por que o JXTA?

Para determinar a escolha da plataforma P2P a ser utilizada neste trabalho, analisou-se as caractersticas de cada uma das plataformas apresentadas nas sees anteriores. A gura 2.12 ilustra, de forma simplicada, as caractersticas que algumas dessas plataformas possuem em comum. Destacando-se o quadrante inferior a esquerda, verica-se que as plataformas JXTA, Windows P2P Networking e Groove fornecem as funcionalidades de comunicao em grupo atravs de mensagens XML; porm, observando-se o quadrante superior a esquerda, ca claro que somente as plataformas
FreePastry e JXTA so multi-plataformas e suportam a linguagem Java.

Ao desenvolver um trabalho cientco, algumas caractersticas tornam-se mais importantes, tais como o uso de tecnologias no proprietrias com o uso de padres
30
Tabela 2.1: Tabela comparativa entre as arquiteturas peer-to-peer
e protocolos abertos.
Dessa forma, para este trabalho, no interessante o Tambm foi
uso da plataforma Windows P2P Networking, embora a mesma fornea diversas funcionalidades para facilitar o desenvolvimento de aplicativos. descartado o uso do Groove, pois o mesmo tambm possui uma arquitetura proprietria. Finalmente, as plataformas mais indicadas para serem utilizadas no desenvolvimento do trabalho proposto seriam JXTA ou FreePastry. Escolheu-se o JXTA como base para desenvolvimento do middleware proposto no captulo 4 devido ao suporte de comunicaes em grupos, especicao aberta e mantida pela comunidade open-source com a possibilidade de estudo do cdigo fonte da plataforma, suporte dispositivos mveis, utilizao de mensagens XML que possibilitam interoperabilidade de dados, suporte diversas linguagens de
31
Figura 2.12: Quadrante com as principais caractersticas das plataformas P2P

desenvolvimento, mecanismos de autenticao para prover segurana na troca de mensagens criptogrcas e por ser amplamente utilizada em diversos projetos, nas reas de aplicaes colaborativas para troca de mensagens (instant messaging ), com suporte texto, voz e vdeo no projeto MyJXTA (MYJXTA, 2008); processamento distribudo no projeto JNGI ((JNGI, 2008)) e distribuio de contedo no projeto CMS ((JXTA-CMS, 2008)). Assim, o qu determinou a escolha do JXTA frente ao FreePastry foi o fato deste ltimo no possuir suporte a implementao em diversas linguagens com uma especicao aberta e bem denida; no suportar diversos dispositivos, tais como dispositivos mveis e no fornecer mecanismos de segurana que garantam a autenticao e criptograa das informaes trafegadas.
Captulo
Denio do arcabouo JxAula

Este captulo descreve as principais funcionalidades do arcabouo JxAula, com o objetivo de servir como modelo ao desenvolvimento de middlewares voltados s aplicaes de ensino distncia (EaD). Utiliza-se uma arquitetura modular, de forma a garantir que o arcabouo possa ser instanciado para diversas plataformas P2P, onde os componentes podem ser alterados para permitir que o middleware se adapte a diferentes requisitos, garantindo a escalabilidade do arcabouo atravs da adio de novos mdulos que supram as necessidades de alta interatividade, compartilhamento de informaes e facilidade de uso para sistemas colaborativos.
3.1 Descrio geral da arquitetura JxAula

O arcabouo JxAula ilustra uma arquitetura abstrata a ser utilizada no desenvolvimento de middlewares baseados em P2P de acordo com os conceitos apresentados no Captulo 2. Com a utilizao deste arcabouo, objetiva-se extrair dos desenvolvedores de sistemas colaborativos a necessidade de projetar suas aplicaes considerando requisitos que no esto diretamente relacionados ao objetivo nal do aplicativo, minimizando o custoso caminho entre a concepo e o desenvolvimento de aplicaes distribudas, permitindo o rpido desenvolvimento de aplicaes com funcionalidades de colaborao e troca de informaes utilizando uma arquitetura P2P. Com isso, o arcabouo dene o uxo bsico das principais funcionalidades dos aplicativo de EaD, como forma de criar uma abstrao da plataforma P2P que esteja sendo utilizada. Os middlewares desenvolvidos a partir do JxAula podem ser congurados e
3.1. Descrio geral da arquitetura JxAula
33
implementados atravs de qualquer plataforma bsica P2P que dena uma estrutura baseada em troca de mensagens, tais como as arquiteturas demonstradas no captulo 2. Como forma de ilustrar a utilizao do arcabouo JxAula, desenvolveu-se o
middleware JXTAula, baseada na plataforma JXTA, que ser demonstrada no

prximo captulo. Este trabalha utiliza o termo arcabouo para se referir ao um conjunto de interfaces, classes abstratas e classes concretas, implementadas na linguagem Java, responsveis pelo comportamento bsico e uxo de mensagens da soluo proposta. arcabouo. Essas interfaces e classes abstratas podem ser implementadas ou Em outras palavras, os middlewares so as implementaes do herdadas de diversas maneiras pelos middlewares que forem criados a partir do arcabouo genrico para uma determinada plataforma P2P. Dessa forma, os
middlewares implementados a partir do arcabouo podem ser adaptados para

reetir as especicidades da plataforma P2P escolhida, como forma de atender s necessidades dos desenvolvedores que utilizaro o middleware para desenvolver seus ambientes cooperativos. A gura 3.1 ilustra as principais diferenas e os relacionamentos entre os mesmos.
Figura 3.1: Diviso da arquitetura em arcabouo, middleware e plataforma P2P
3.2. Arquitetura proposta
34
3.2 Arquitetura proposta

3.2.1 Arquitetura em Camadas
A arquitetura composta por camadas, onde cada camada tem uma responsabilidade especca. responsabilidades em comum. Segundo (BACHMANN et al., 2000), a viso da arquitetura atravs de camadas (layers ) uma das vises mais comuns e bastante utilizada em arquiteturas de sistemas, facilitando a manuteno e portabilidade desses sistemas. Portanto, o padro de projeto escolhido para ser utilizado na arquitetura do arcabouo foi o padro Layer. Isso signica que cada camada ir agrupar classes, pacotes e outros componentes que possuam responsabilidades em comum, ou seja, classes responsveis pelas mesmas funcionalidades so agrupadas em uma mesma camada, com o objetivo de apresentar as seguintes vantagens ao projeto: De acordo com (TANENBAUM, 2003), utiliza-se o seguinte conceito: camadas so divises lgicas de componentes agrupados por
i. Padro arquitetural conhecido que facilita a comunicao e entendimento entre

os desenvolvedores.
ii. Reduzem complexidade, pois agrupam componentes e simplicam a

comunicao entre eles;
iii. Reduzem dependncia e acoplamento, uma vez que utilizam interfaces bem
denidas e evitam dependncias diretas entre os componentes de camadas diferentes;
iv. Favorecem a coeso, levando-se em considerao que componentes com

responsabilidades relacionadas so agrupados dentro da mesma camadas;
v. Promovem a reusabilidade, pois camadas podem ser reutilizadas em outros

sistemas ou podem ser substitudas.
3.2.2 Camadas da Arquitetura do Arcabouo

O arcabouo divido nas seguintes camadas, conforme a gura 3.2, as quais utilizam os padres de projetos no Apndice A:
3.3. Caractersticas do arcabouo proposto
35
Camada de Aplicao: a camada superior (camada 4) responsvel

pelas telas de interao com o usurio. Nessa camada esto contidas as classes e pacotes responsveis pelo recebimento de comandos do usurio e por demonstrar os resultados desses comandos executados.
Camada do JxAula: a camada 3 da arquitetura composta pelo arcabouo

JxAula. Nessa camada esto os servios que sero oferecidos aos aplicativos de ensino distncia, atravs de mtodos que eliminam a preocupao de criar todo um ambiente peer-to-peer. Dentre esses servios, podemos destacar os mdulos de gesto de criao do ambiente, gesto de salas, de participantes e de comunicao no ambiente, alm do mdulo que fornece mecanismos de localizao na rede P2P, medidas de desempenho dos participantes e compartilhamento e distribuio de arquivos. funcionalidades destacadas no item 3.3.1. Esses servios so a base para que o desenvolvedor do sistema EaD possa utilizar os requisitos e
Camada de Adaptao ao servio P2P: a terceira camada ser composta

pelo middleware que funcionar como uma ponte entre o arcabouo JxAula e uma implementao particular de uma plataforma P2P. Para exemplicar a aplicabilidade do arcabouo, desenvolveu-se neste trabalho o middleware JXTAula, uma implementao dos servios denidos para a plataforma JXTA que ser descrita no captulo 4. Nessa camada, so inseridos os cdigos especcos da plataforma P2P escolhida, e por isso esse mdulo denominado de adaptador, j que est adaptando o JxAula uma plataforma P2P especca.
Camada da Plataforma P2P: a camada inferior (camada 1) representada

pela plataforma peer-to-peer escolhida para implementar o middleware, que utilizar os principais servios providos atravs de componentes reutilizveis, geralmente disponibilizados atravs de DLL (Dynamic Link Library) ou JAR (Java ARchieve).
3.3 Caractersticas do arcabouo proposto

As seguintes premissas foram denidas durante o incio dos trabalhos, sendo perseguidas durante todo o processo de planejamento e construo do arcabouo.
36
Figura 3.2: Arquitetura do arcabouo JxAula em camadas

Para garantir essas caractersticas, utilizou-se neste trabalho os padres de projeto expostos no Apndice A: A arquitetura deve ser exvel de modo que permita que apenas as funcionalidades necessrias sejam utilizadas. Dever possuir a caracterstica de ser recongurvel, uma vez que pode existir a necessidade de alterao para se adaptar necessidades particulares. Outra caracterstica indispensvel a sua escalabilidade, pois novos mdulos podem ser denidos no arcabouo para que novos servios sejam suportados.
3.3.1 Requisitos funcionais

Aps a anlise das caractersticas e necessidades dos desenvolvedores de sistemas de ensino distncia (EaD) efetuada no item 2.1.2, objetiva-se aqui documentar o conjunto de requisitos que exprimem as funcionalidades que foram contempladas no desenvolvimento do arcabouo JxAula. Dentre os requisitos funcionais que esto contemplados no arcabouo JxAula, pode-se citar:
37
i. Permitir ao participante entrar no ambiente sem se preocupar com as

complexidades envolvidas nesta atividade.
ii. Permitir ao participante criar novas salas. iii. Permitir ao participante entrar e sair de salas. iv. Permitir ao participante trocar de sala, dentre as quais ele j pertence. v. Permitir ao participante consultar quais as salas em que ele est, bem como,
listar os participantes de uma determinada sala.
vi. Permitir ao participante listar todas as salas do ambiente, bem como, listar
todos os participantes do ambiente.
vii. Permitir o estabelecimento de comunicao entre os participantes que estejam

no ambiente.
viii. Permitir o envio de mensagens a todos os participantes de uma determinada

sala, bem como a um participante em particular.
ix. Permitir o compartilhamento de arquivos com a distribuio de contedo nas

salas ou em toda a escola.
x. Permitir a vericao do tempo de resposta de determinado participante do

ambiente (ping ). A gura 3.3 representa as principais funcionalidades que esto disponveis no JxAula:
3.3.2 Requisitos no funcionais

Especicaes no funcionais so assim chamadas por adicionar outras funcionalidades que no as diretamente requeridas pelo sistema. Embora para o usurio o programa parea estar executando somente suas tarefas especcas, outras tarefas acontecem em segundo plano e podem passar despercebidas, embora isso no lhes diminua a importncia. Ao contrrio, por serem objetivos comuns maioria dos programas, fornecem oportunidade de otimizao atravs de reuso de cdigo. Devido ao fato dos requisitos no funcionais no serem nem o foco principal do sistema, o desenvolvedor ganharia bastante tempo se a implementao
38
Figura 3.3: Casos de Uso do Arcabouo JxAula

de tais requisitos j estivessem disponveis em mdulos de software reutilizveis, de preferncia sem grande exigncia de envolvimento por parte do desenvolvedor (CYSNEIROS; LEITE, 2001). Nesse contexto, o arcabouo JxAula se preocupa em fornecer algumas caractersticas visando diminuir o tempo de desenvolvimento e garantir a utilizao de mdulos de software previamente testados. Nesse projeto, os seguintes requisitos no funcionais foram considerados:
Funcionalidade :
permite vericar se o arcabouo est fazendo o que
se propem fazer, englobando ainda as caractersticas de segurana com mecanismos de criptograa e autenticao de forma que o trfego trocado entre os dispositivos seja condencial, garantindo a autenticidade das informaes trafegadas;
Usabilidade : possui uma interface (API ) consistente e fcil de utilizar, com
3.4. Funcionalidades do JxAula
39
aprendizado intuitivo, atravs de poucas funes e extrema abstrao das complexidades envolvidas no desenvolvimento dos elementos internos;
Ecincia : diz respeito quantidade de recursos do dispositivo que estar

sendo utilizado durante a execuo das funcionalidades do componente, bem como a quantidade de mensagens e o tempo de propagao dessas mensagens enviadas e recebidas pela rede.
Manutenibilidade : verica a facilidade de adicionar novos mdulos, com

interdependncia entre si, de forma a controlar o acesso a cada mdulo atravs de interfaces bem denidas;
Portabilidade : garante que o arcabouo desenvolvido poder ser utilizado em

diversas plataformas computacionais (Windows, Linux, etc ) e est de acordo com padres e protocolos abertos e bem denidos. Para a avaliao da qualidade de produtos de software, as organizaes internacionais de normalizao deniram a norma ISO/IEC 9126 com caractersticas de qualidade (ISO/IEC, 1991). Neste modelo, mtricas devem ser escolhidas com seus respectivos nveis de aceitabilidade, tendo-se uma escala de avaliao para cada requisito, possibilitando vericar o grau de satisfao para cada atributo avaliado (BOTELLA et al., 2001). Finalmente, este conjunto de mtricas pode ser combinada para se ter uma avaliao nal das caractersticas da qualidade do arcabouo. Dessa forma, construiu-se a tabela 6.1, que ser utilizada no Captulo 6, quando da avaliao dos resultados do trabalho desenvolvido.
3.4 Funcionalidades do JxAula

Nessa seo, sero apresentados os mdulos que compem o arcabouo. A apresentao de cada mdulo est organizada nas seguintes divises: componentes da arquitetura; funcionalidades do mdulo e caractersticas tcnicas. Pretende-se, com isso, especicar, documentar e visualizar as interaes entre os diferentes objetos do arcabouo. A aderncia aos padres de projeto de cada mdulo destacada no Apndice A
40
Tabela 3.1: Mtricas de avaliao dos requisitos no funcionais
3.4.1 Gesto do Ambiente Componentes da Arquitetura

O mdulo de gesto do ambiente formado por quatro componentes, conforme ilustra a gura 3.4:
41
Figura 3.4: Mdulo de Gesto do Ambiente
Funcionalidades do Mdulo i. Criao de um ambiente colaborativo denominado Escola, sem a preocupao

com as complexidades envolvidas nesta atividade.;
ii. Controle centralizado das funcionalidades providas pelo arcabouo; iii. Congurao dos parmetros do arcabouo, tais como: middleware que ser
utilizado (exemplo: JXTAula), tempo de timeout (exemplo: 2 segundos) e nomenclaturas utilizadas pelo servio de localizao do arcabouo.
Caractersticas Tcnicas
Fachada do JxAula
O ponto de entrada para os desenvolvedores que estejam utilizando esse arcabouo atravs da fachada do JxAula. Este componente fornece uma entrada unicada para o conjunto de funcionalidades do arcabouo atravs de uma interface abstrata de alto nvel que tem como objetivo tornar o uso do subsistema mais fcil. Pelo uso desse componente, objetiva-se alcanar maior desacoplamento entre os componentes do arcabouo, reduzindo assim a interdependncia entre os mdulos. Desacoplar signica minimizar tanto a quantidade quanto a qualidade das dependncias. A qualidade de uma dependncia medida levando-se em conta quanta informao est na especicao de uma classe em relao a outra, ou seja, quanta informao est trafegando na mensagem de uma classe outra. Quanto menos informao, menor a dependncia. No caso extremo, no h informao
42
alguma na dependncia, e temos um caso de dependncia fraca na qual uma classe depende apenas da existncia de outra. A maneira mais efetiva de se reduzir o acoplamento projetando as partes de maneira que sejam simples e bem denidas, unindo aspectos do sistema que sejam relacionados e separando aspectos que no o sejam. Portanto, a fachada do ambiente responsvel por representar todas as funcionalidades do arcabouo (e apenas isso), e por apresentar estas funcionalidades para a camada de aplicao atravs de mtodos de nvel mais alto. Esta interface menos dependente dos mdulos internos se comparada a chamadas diretamente aos mtodos dos componentes do arcabouo pela camada de aplicao. Dessa forma, possvel alterar os componentes que esto encapsulados, enquanto se mantm a especicao de fachada inalterada, de forma que nenhuma parte da camada de aplicao seja afetada.
Gestor do Ambiente
A classe de Gesto do Ambiente responsvel por criar os demais gestores: Gestor de Salas, de Participantes, de Localizao, de Comunicao, de Desempenho e de Compartilhamento, onde cada gestor responsvel por atender determinado tipo de solicitao. A responsabilidade de garantir que exista somente uma instncia de cada gestor desta classe, pois o gestor do ambiente o nico responsvel por criar os demais gestores. Esse procedimento feito uma nica vez, quando o mtodo
inicializar chamado pela aplicao.
Congurao do JxAula
O componente de Congurao do JxAula o responsvel por conter os mtodos de adequao do arcabouo JxAula ao middleware escolhido e a ser implementado. Por exemplo, quando da utilizao do middleware JXTAula, esta classe responsvel por conter as caractersticas e conguraes especcas. utilizao da classe de Congurao do JxAula. A gura 3.5 ilustra a
Grupo Escola
43
Figura 3.5: Congurao do JxAula

A Escola representa o grupo principal do arcabouo. Quando algum participante inicia o JxAula, ele entra primeiramente neste grupo, pois somente a partir dele que podem ser utilizados os demais servios, por exemplo, criao de salas virtuais e estabelecimento de comunicao com outros participantes. Qualquer participante que esteja no ambiente obrigatoriamente faz parte do grupo escola, pois este grupo desempenha o papel bsico para que todas as funcionalidades sejam executadas. Tanto as Salas, que sero descritas posteriormente, como a Escola herdam as caractersticas da classe GrupoP2P. na classe GrupoP2P que sero inseridas as caractersticas peculiares e particulares de um grupo para a plataforma P2P escolhida. No caso do middleware JXTAula, conforme veremos no prximo captulo, a classe GrupoP2P possui as caractersticas de um grupo da plataforma JXTA denominado PeerGroup, conforme discutido no captulo 2. Assim como os gestores, existe somente uma nica instncia dessa classe Escola. Essa instncia a responsvel por conter todos os objetos que representam as salas (atravs de um vetor de objetos do tipo Sala ) e a lista dos participantes que esto no ambiente (atravs de um vetor de objetos do tipo Participante ). A gura 3.6 representa as salas da escola e os participantes da escola.
44
Figura 3.6: Representao das salas e dos participantes na Escola
3.4.2 Gesto de Salas Componentes da Arquitetura

O mdulo de gesto de salas formado por dois componentes, conforme ilustra a gura 3.7:
Figura 3.7: Mdulo de Gesto de Salas
Funcionalidades do Mdulo i. Possibilita que o ambiente colaborativo seja capaz de organizar seus
participantes em salas virtuais com a criao de grupos de participantes que possuem interesses semelhantes e que propicia a otimizao do trfego de mensagens enviadas e recebidas dentro desses grupos;
45
ii. Possibilita que o participante possa criar novas salas. iii. Possibilita que o participante possa entrar e sair de salas. iv. Possibilita que o participante possa trocar de sala, dentre as quais ele j
pertence.
v. Possibilita que o participante possa consultar quais as salas em que ele est
e a descrio de uma determinada sala, bem como listar os participantes de uma sala.
Gestor de Salas
A classe de Gesto de Salas responsvel por fornecer ao ambiente todas as funcionalidades relacionadas s salas, dentre as quais destacam-se a criao de salas e o processo de entrar e sair de uma determinada sala. No processo de criao de sala, a fachada do arcabouo JxAula envia uma mensagem ao Gestor de Salas para a criao de uma nova sala. A primeira ao que o gestor toma, vericar se a sala j existe no ambiente, atravs do Gestor de Localizao, para que caso a sala j exista, seja lanada uma exceo para avisar a camada de aplicao sobre este fato. Caso contrrio, a sala ainda no existe e o Gestor de Salas cria uma nova sala na
Escola.
Outra funcionalidade fornecida por esse componente o processo de entrar em uma determinada sala. Para entrar na sala, o Gestor de Salas verica se a sala j foi criada. Caso no exista essa sala, uma exceo lanada para avisar camada de aplicao sobre este fato, porm, caso a sala exista, o participante ingressa na Sala. Para fornecer as funcionalidade de trocar e sair de uma sala, o Gestor de Salas verica as salas que o participante pertence. Cada participante possui uma nica sala ativa, denominada Sala Atual, que uma das salas que o participante ingressou anteriormente.
Sala
46
As salas funcionam como um meio de se agrupar participantes que tenham interesse em comum, onde os recursos compartilhados dentro de uma sala provavelmente interessam a todos que pertencem quela sala, e somente a estes. A gura 3.8 ilustra o conceito de Escola e de Salas Virtuais, considerando que um participante pode estar em mais de uma sala ao mesmo tempo:
Figura 3.8: Representao da Escola e Salas Virtuais do ambiente

Cada sala mantm um canal de comunicao da sala e atravs desse canal que uma mensagem enviada a mesma direcionada a todos os seus participantes. Pode-se imaginar que esse tipo de comportamento esteja funcionando em broadcast 1 , mas na verdade o que existe um multicast 2 dentro da segmentao lgica imposta pelo grupamento virtual de uma sala. Esse conceito importante por manter e restringir o trfego de mensagens somente aos participantes que pertenam a sala virtual onde a mensagem foi enviada. Por exemplo, caso os participantes estejam trocando informaes dentro de uma sala de fsica, essas mensagens no chegam aos participantes de uma sala de portugus os quais, provavelmente, pouco interesse teriam naquela informao - embora todos esses participantes pertenam ao grupo escola.
1 BROADCAST : 2 MULTICAST :
envio de uma informao a todos os participantes de uma rede envio de uma informao para um grupo de participantes de uma rede
47
3.4.3 Gesto de Participante Componentes da Arquitetura

O mdulo de gesto do participante formado por dois componentes, conforme ilustra a gura 3.9:
Figura 3.9: Mdulo de Gesto de Participantes
Funcionalidades do Mdulo i. Criao de um participante (peer ) na rede P2P com suas conguraes
especcas (por exemplo: seu nome) sem se preocupar com as complexidades envolvidas nesta atividade;
ii. Publicar o anncio do participante na rede para que o mesmo possa ser
localizados por outros participantes que esto na Escola.
Gestor de Participantes
A classe de Gesto do Participante responsvel pelas funcionalidades relacionadas com iniciao do participante no ambiente P2P e neste processo de iniciao do participante que ocorre a vericao do login e da senha do usurio. Caso o usurio esteja tentando entrar com credenciais invlidas, lanada uma exceo para a camada de aplicao, porm, caso as credencias estejam corretas, o Gestor de Participante cria o participante na escola e publica o anncio do participante na rede P2P.
Participante
48
Cada participante responsvel por armazenar suas informaes em um objeto da classe AnuncioParticipante, pois atravs desse anuncio que o Gestor de
Localizao consegue descobrir os participantes que esto na Escola ou numa

determinada sala. Uma das informaes que os participantes possuem sobre o seu canal de comunicao de entrada. atravs desse canal que uma mensagem enviada ao participante direcionada somente a ele, possibilitando o comportamento denominado de unicast (nico destino). Esse conceito importante por manter e restringir o trfego de mensagens somente ao participante destinatrio da mensagem, fornecendo a infra-estrutura de comunicao ponto-a-ponto entre os participantes da
Escola.
3.4.4 Gesto de Comunicao Componentes da Arquitetura

O mdulo de gesto de comunicao formado por dois componentes, conforme ilustra a gura 3.10:
Figura 3.10: Mdulo de Gesto de Comunicao
Funcionalidades do Mdulo i. Possibilita a utilizao de servios de troca de mensagens, fornecendo

a infra-estrutura de comunicao ponto-a-ponto entre os participantes do ambiente;
ii. Permite o envio de mensagens a todos os participantes de uma determinada

sala, bem como a um participante em particular.
iii. Possibilita a fragmentao de mensagens longas para que as mesmas possam

ser enviadas pelos canais de comunicao.
49
Gestor de Comunicao
As funcionalidades desse gestor esto relacionadas com a criao do canal de comunicao do participante; com o estabelecimento e nalizao de uma comunicao entre dois participantes; com o envio e recepo de mensagens em uma comunicao j estabelecida e com o envio e recepo de uma mensagem dentro da sala ou na Escola. Outra funcionalidade provida por este mdulo a fragmentao de mensagens longas. Objetos ou arquivos que ultrapassem o tamanho mximo permitido, devem ser fragmentados para que possam ser enviados. Dessa forma, permite-se o envio de fragmentos de mensagens longas que no poderiam ser enviadas pela rede em sua forma original, de forma que quando todos os fragmentos chegarem ao destinatrio, a mensagem original reconstruda e entregue para a aplicao, garantindo, inclusive, a integridade dos dados. A gura 3.11 ilustra o processo descrito.
Figura 3.11: Desmembramento e serializao de mensagens
Comunicao
Muitas aplicaes de ensino a distncia necessitam que um determinado usurio possa enviar uma informao para um conjunto de outros usurios ao mesmo tempo. Fazendo uma aluso com a sala de aula real, quando um aluno levanta o brao e indaga o professor sobre uma questo, ele ao mesmo tempo est enviando a mesma questo a todos os outros alunos que estejam presentes na sala. Da mesma forma, quando uma aplicao necessita enviar a mesma informao a todos os participantes
50
de uma sala, pode-se utilizar a funcionalidade do canal de comunicao da sala, em vez de criar um canal de comunicao de sada com cada participante da sala. O canal de comunicao da sala criado assim que o participante ingressa em uma sala, sendo mantida enquanto o participante continuar na mesma. J para os casos em que uma informao tem de ser compartilhada somente entre dois participantes, outra forma de comunicao que fornecida por esse mdulo a comunicao unicast, responsvel pelo estabelecimento de uma comunicao privativa entre dois participantes. Quando um usurio entra no ambiente, ele cria o canal de comunicao de entrada do participante, sendo em seguida publicado na rede para que outros participantes sejam capazes de encontr-lo. atravs desse canal que outro participante consegue estabelecer uma comunicao de sada com esse participante.
3.4.5 Gesto de Localizao Componentes da Arquitetura

O mdulo de gesto de localizao formado por dois componentes, conforme ilustra a gura 3.12:
Figura 3.12: Mdulo de Gesto de Localizao
Funcionalidades do Mdulo i. Possibilita que os participantes do ambiente possam localizar as salas criadas
por outros;
51
ii. Nessas salas, possibilita que os participantes possam ser capazes de localizar
uns aos outros;
iii. Possibilita que os participantes possam localizar os arquivos que esto sendo
compartilhados em uma determinada sala ou em toda a Escola.
Gestor de Localizao
Ao entrar no ambiente, geralmente o participante deseja conhecer esse ambiente para que possa comear a interagir e essa descoberta feita atravs desse mdulo do arcabouo. O gestor de localizao o responsvel por procurar na rede P2P os anncios referentes s salas virtuais, aos participantes e aos arquivos que estejam sendo compartilhados. Dependendo do tipo de anuncio, o contexto da busca pode ser diferente. Por exemplo, quando o usurio deseja localizar todas as salas da escola, a busca enviada dentro do grupo escola. Por outro lado, quando o usurio deseja vericar quais so os arquivos que esto sendo compartilhados por um determinado participante, a busca enviada somente para esse participante. inundaes. Quando um participante deseja descobrir um recurso, ele envia uma solicitao e aguarda um determinado tempo para que as mensagens de resposta possam ser recebidas. Mltiplas respostas solicitao podem ser recebidas, embora tambm possa ocorrer do participante no receber nenhuma resposta, devido ao fato de redes P2P serem imprevisveis e no conveis. Pode ocorrer, por exemplo, o caso em que os participantes que conheciam determinado recurso no estarem mais na rede P2P. Com isso, as mensagens que trafegam na rede so enviadas de forma controlada, no ocasionando
Anncios do Ambiente
Os seguintes anncios fazem parte do arcabouo e so utilizados para localizar os recursos no ambiente:
i. Anncio de Sala: O anncio de sala representa uma sala que j foi criada
anteriormente, e seu anuncio foi publicado na rede P2P. Quando um usurio deseja entrar em uma sala, ele verica se a sala j existe atravs da localizao do anncio dessa determinada sala na rede P2P, e caso exista esse anuncio, o participante entra na sala.
52
ii. Anncio de Comunicao: O anncio de comunicao representa a

comunicao de entrada de um participante remoto. Quando um usurio deseja iniciar uma comunicao com um determinado participante remoto, ele tenta localizar na rede P2P esse participante, e caso o anuncio da comunicao seja encontrado, o usurio poder criar uma comunicao de sada o participante remoto.
iii. Anncio de Participante: O anncio de participante armazena o anuncio

de comunicao do participante remoto e o nome desse participante remoto.
iv. Anncio de Arquivo: O anncio de arquivo representa um determinado

arquivo que est sendo compartilhado por um participante da rede P2P.
3.4.6 Gesto de Compartilhamento Componentes da Arquitetura

O mdulo de gesto de compartilhamento formado por dois componentes, conforme ilustra a gura 3.13:
Figura 3.13: Mdulo de Gesto de Compartilhamento
Funcionalidades do Mdulo i. Possibilita a disponibilizao de contedo no ambiente, para que haja o

compartilhamento de arquivo entre os usurios;
Gestor de Compartilhamento
53
Algumas pessoas consideram o termo P2P sinnimo de compartilhamento de arquivos. Isso se deve ao fato da maioria de sistemas P2P serem utilizados com a nalidade de transmisso de arquivos, tais como msicas e lmes, tornando este tipo de aplicao a mais popular da tecnologia P2P. Mesmo que as aplicaes que utilizem a arquitetura P2P no precisem estar limitadas s funcionalidades de compartilhamento de arquivos, deve-se admitir que tal funcionalidade uma das mais importantes em um ambiente distribudo. No contexto de educao distncia, tal necessidade se demonstra no fato da troca de conhecimento e compartilhamento de informaes atravs de apresentaes, livros, documentos tcnicos, dentre outros. Desenvolveu-se um mecanismo simples de compartilhamento e envio de arquivos entre os participantes do ambiente, na perspectiva que arquivos compartilhados na Escola devam estar disponveis a todos os participantes do ambiente, enquanto que arquivos compartilhados em uma determinada sala virtual estaro restritos aos participantes da sala. Este servio levou em considerao o uso de funcionalidade de compresso das mensagens enviadas, visando diminuir a utilizao da rede e minimizar o retardo da transmisso.
3.4.7 Gesto de Desempenho Componentes da Arquitetura

O mdulo de gesto de desempenho formado por dois componentes, conforme ilustra a gura 3.14:
Figura 3.14: Mdulo de Gesto de Desempenho
Funcionalidades do Mdulo i. Possibilita o envio de mensagens para vericar se um determinado usurio

ainda est conectado;
54
ii. Possibilita a vericao da capacidade de processamento e da quantidade de

memria RAM de um participante conectado rede P2P;
iii. Verica que um usurio no est mais no ambiente, tratando esta sada
de maneira adequada - por exemplo: nalizao da comunicao com o participante e interrupo do envio de um arquivo;
Gestor de Desempenho
Na maioria das aplicaes que funcionam em um ambiente distribudo, desejvel que exista um mecanismo capaz de gerenciar e monitorar as atividades dos dispositivos remotos. Estas funcionalidades vo desde a obteno de informaes sobre o participante remoto - tais como a quantidade de mensagens enviadas e recebidas - at o controle avanado de recursos que estejam disponveis aos demais membros da rede - tais como o compartilhamento de processamento e de memria para armazenamento de arquivos de forma distribuda. Este mdulo visa possibilitar a vericao da latncia entre dois participantes remotos atravs do envio de mensagens ping/pong para o clculo do RTT (round
trip time ), alm da vericao da capacidade de processamento e da quantidade

de memria RAM de um participante remoto atravs da tecnologia JNI (AUSTIN;
PAWLAN, 2000).
Objetiva-se assim fornecer informaes para aplicaes que
necessitam determinar quais participantes possuem maior poder de processamento, por exemplo, para assumir um papel de coordenador da sala ou desempenhar uma funo especial.
Captulo
Estudo de caso: o middleware JXTAula

Este captulo aborda uma descrio geral sobre a instanciao dos servios abstratos do arcabouo JxAula atravs da utilizao da plataforma JXTA, escolhida dentre as arquiteturas apresentadas no captulo 2. Assim, alm de ilustrar como o arcabouo JxAula pode ser utilizado para o desenvolvimento de um middleware, a construo do JXTAula representa, por si s, uma contribuio deste trabalho.
4.1 Viso geral sobre o JXTAula

O middleware JXTAula representa a camada 3 - adaptao ao servio JXTA da arquitetura mostrada anteriormente na gura 3.2, funcionando como uma ponte entre o arcabouo JxAula e a plataforma JXTA. O middleware JXTAula formado pelos componentes ilustrados na gura 4.1.
4.2 Funcionamento do middleware

Para entender as funcionalidades construdas no JXTAula, e as que so utilizadas a partir do JXTA, descreve-se, a seguir, o processo em sua ordem cronolgica. Inicialmente, o participante entra no ambiente e verica quais so os grupos existentes para que possa ingressar em algum desses grupos, podendo, a partir da, estabelecer comunicaes com outros participantes. Todas as informaes desta seo levam em considerao a verso 2.5 da plataforma JXTA.
4.2. Funcionamento do middleware
56
Figura 4.1: Componentes do Middleware JXTAula
4.2.1 Iniciando o uso de uma aplicao Congurao do JXTA

Quando uma aplicao JXTA executada pela primeira vez, uma janela (JXTA
Congurator ) aberta para que sejam conguradas as informaes do peer. Esta

ferramenta possui trs abas: conguraes bsicas (para que seja congurado o nome do peer e sua senha), conguraes avanadas (onde possvel especicar se este peer ir funcionar como um rendezvous ou relay, alm de congurar parmetros que sero utilizados nas comunicaes que utilizam os protocolos TCP e HTTP) e conguraes de rendezvous/relay (possibilitando que sejam inseridas as informaes sobre rendezvous/relay, tais como um endereo que possui informaes sobre rendezvous/relays pblicos). A gura 4.2 ilustra as opes de congurao da aba avanada. Com a utilizao do JXTA Congurator, as conguraes so armazenadas no diretrio .jxta, porm, no caso do JXTAula, utilizou-se a pasta .jxtaula. Neste diretrio, adicionado o arquivo PlatformCong, um arquivo XML que contm as conguraes da plataforma, e o diretrio cm, que o gerenciador de cache da plataforma JXTA, responsvel por armazenar os anncios recebidos.
57
Figura 4.2: Aba avanada do JXTA Congurator
Congurao transparente aplicao

No caso do JXTAula, no interessante que durante a execuo de uma aplicao, a janela de congurao do JXTA seja aberta, pois, uma vez que so exigidas conguraes especcas do JXTA, nenhuma transparncia fornecida sobre a plataforma P2P. Com isso, outra forma de congurar uma aplicao que utiliza o JXTA atravs da classe NetworkCongurator. Esta classe possibilita que sejam atribudos os parmetros necessrios a partir de seus mtodos, de tal forma que podem ser utilizadas as seguintes funcionalidades:
i. Congurar o nome do participante, sua senha e descrio; ii. Congurar o n como sendo: ADHOC ; EDGE ; RENDEZVOUS ; RELAY ou
PROXY, dependendo do papel desempenhado pelo peer na rede JXTA.
aconselhvel que cada aplicao tenha pelo menos um Rendezvous, e pode-se utilizar a classe RendezvousListener para capturar o evento que indica que o participante se conectou a um Rendezvous ;
58
iii. Habilitar ou no o transporte atravs dos protocolos HTTP e TCP, e suas

conguraes especcas;
iv. Congurar um endereo onde podem ser localizados servios para

Rendezvous (exemplo: http://rdv.jxtahosts.net/cgi-bin/rendezvous.cgi?2 ) e Relay (exemplo: http://rdv.jxtahosts.net/cgi-bin/relays.cgi?2 );
v. Possibilitar o armazenamento das conguraes no arquivo PlatformCong ; vi. Possibilitar que as conguraes armazenadas anteriormente no arquivo
PlatformCong sejam carregadas.
Assim, essa classe possibilita a congurao dos mesmos campos exibidos na janela da gura 4.2, porm de forma transparente aplicao. No JXTAula, estas funcionalidades so utilizadas a partir da classe Boot, que a responsvel por criar as conguraes do participante caso estas ainda no existam, ou carreg-las caso j existam. Aps a criao da congurao do peer, o prximo passo efetivamente entrar na plataforma JXTA atravs da instanciao do grupo principal
WorldPeerGroup, tambm denominado de NetPeerGroup. Os cdigos da classe Boot

responsveis por criar as conguraes do participantes so ilustrados no Apndice B.
4.2.2 Ingressando no mundo P2P e no grupo Escola Grupos do ambiente

A rede JXTA possui um grupo principal denominado WorldPeerGroup ou
NetPeerGroup, no qual todos os participantes entram automaticamente.

No caso do JXTAula, aps o ingresso no grupo principal da rede JXTA, a aplicao entra automaticamente no grupo denominado Escola. durante esse processo de inicializao que ocorre a autenticao das credenciais de usurio/senha, pois estas sero validadas com as conguraes j existentes na mquina local (criadas no passo anterior pelo NetworkCongurator ). No JXTAula, tanto as salas virtuais, como a Escola, so representaes de uma classe denominada GrupoP2P, que herdam, para o caso do JXTA, as caractersticas da classe denominada PeerGroup, o que garante com que os grupos do ambiente possuam algumas funcionalidades bsica que so disponibilizadas pelos PeerGroups. A estrutura da classe GrupoP2P est no Apndice B.
59
A classe Group responsvel pelo mecanismo de ingresso nos grupos. Os grupos podem ser criados de duas maneiras: grupos pblicos (os quais no necessitam de
login /senha para que os participantes possam ingressar) e grupos privados (os quais
exigem uma validao dessas credenciais). Para garantir que no haver duplicidade de salas com o mesmo nome, utiliza-se uma funo Hash do nome da sala no momento em que se est criando o ID do PeerGroup.
Remoo de grupos no ambiente

No JXTA, no possvel remover PeerGroups da rede P2P (BROOKSHIER et al., 2002). Para contornar este fato, o middleware JXTAula fornece um mecanismo para que cada participante possa remover uma sala de sua cache local, embora uma sala s ser realmente removida da rede P2P se todos os participantes que estiverem na Escola removerem-na de sua cache local. Do contrrio, quando um participante que removeu a sala enviar uma mensagem de descoberta, ele ir descobrir novamente aquela sala, uma vez que outro participante da Escola ainda a possui. Caso existisse a gura de um Coordenador Geral da Escola, este poderia ter autoridade para remover determinada sala em todos os participantes. Os mtodos relacionados a criao e remoo das salas, bem como para bem como entrar e sair de uma sala so demonstrados no Apndice B.
4.2.3 Descobrindos as salas e os participantes do ambiente

Ao entrar no WorldPeerGroup, os peers tero possibilidades de utilizar os servios bsicos que esto disponveis a partir deste grupo, tais como a descoberta de grupos criados por outros participantes. O servio de descoberta do JXTAula, implementado na classe Find, baseado em dois mecanismos: utilizao do protocolo PDP (Peer Discovery Protocol ), fornecido pela classe PeerGroup, e o envio de mensagens de solicitaes que devem ser respondidas por outros participantes.
Buscas baseadas no protocolo PDP do JXTA

O protocolo PDP permite que a descoberta de anncios por recursos que tenham sido publicados nos grupos ocorra nas seguintes formas: buscas locais e buscas remotas. A busca local realizada na cache do prprio participante (diretrio
.jxtaula/cm ), enquanto que a busca remota feita atravs da consulta s caches

dos demais participantes da rede P2P, incluindo os Rendezvous. Sempre que uma busca remota efetuada, os anncios recebidos so armazenados na cache local do
60
participante, para que os mesmos possam ser localizados atravs da busca local. H tambm a possibilidade de se utilizar a classe DiscoveryListener para capturar um evento de retorno de uma busca remota. Os anncios podem descrever uma variedade de recursos, e para que um recurso possa ser descoberto na rede, ele deve ter um anncio associado si publicado anteriormente em um grupo. O JXTAula utiliza este mecanismo para descobrir as salas criadas na Escola e os participantes da Escola, pois nestes casos necessrio guardar os anncios dessas entidades na
cache local.
Buscas atravs do envio de mensagens

J para o mecanismo de descoberta atravs do envio de mensagens de solicitao, o JXTAula aproveita todo o cdigo desenvolvido no Gestor de Localizao do arcabouo JxAula, que se baseia no envio de mensagens em uma determinada sala ou para um participante. Este um exemplo da re-utilizao de cdigo do arcabouo pelo middleware. Por exemplo, para descobrir os participantes que pertencem uma sala, envia-se uma mensagem para esta sala, e aqueles participantes que receberem esta mensagem devem respond-la. Assim, o participante aguarda um tempo para que os peers que estejam neste grupo possam responder suas solicitaes (funcionamento sncrono). Com isso, peers que responderem solicitao sero encontrados, porm os que demorarem a responder podem ser descobertos somente em uma prxima busca. Outro exemplo deste mesmo tipo de busca a descoberta de arquivos que esto sendo compartilhados por um participante, baseado no envio de solicitao somente ao participante. Portanto, o JXTAula utiliza este mecanismo para descobrir os participantes de um determinado grupo e os arquivos que esto sendo compartilhados por um participante. O diagrama da gura 4.3 ilustra os estados que os participantes de um grupo podem se encontrar com relao ao processo de atualizao da lista de participantes.
4.2.4 Estabelecendo comunicaes entre os participantes do ambiente A utilizao de Pipes

Os pipes so usados para comunicao entre peers dentro de um grupo, sendo denido como um canal de comunicao abstrato baseado na utilizao dos
61
Figura 4.3: Protocolo de controle para as descobertas de participantes nos grupos

protocolos de transporte da Internet, tais como o HTTP e o TCP/IP. A especicao do JXTA dene o Pipe como sendo o canal de comunicao entre os peers da rede, de maneira que quando uma informao enviada em um lado do canal, essa informao deve ser recebida pelo outro lado, ou seja, no destino. Atravs dos Pipes, as mensagens podem ser enviadas entre os peers sem que haja a preocupao com a topologia da rede ou onde cada peer est localizado. Assim, um dos protocolos mais utilizados da especicao do JXTA o Pipe Binding Protocol
(PBP).
O JXTA possui trs tipos de Pipes: Unicast Pipe (utilizado para conectar um peer a outro), Propagate Pipe (utilizado para conectar um peer a diversos outros) e Secure Pipe (utilizado para conectar um peer a outro de maneira segura, ou seja, com o envio de mensagens criptografadas) (GONG; OAKS; TRAVERSAT, 2002). O JXTAula utiliza os Pipes Unicast e Secure para fornecer a comunicao privativa entre dois participantes (dependendo da necessidade de criptograa ou no) e o Propagate Pipe para fornecer a funcionalidade do envio de uma mensagem
62
a todos os participantes da Escola ou de uma determinada sala virtual.
1o passo: A criao do canal de entrada

Quando um peer ingressa na rede, ele deve criar um pipe de entrada para possibilitar que ele seja encontrado. O processo de criao do canal de entrada do peer obedece aos seguintes passos:
i. Cria-se o anncio de entrada do participante; ii. Cria-se o listener que vai escutar os eventos ocorridos neste pipe de entrada,
por exemplo, recebimento de mensagens;
iii. Cria-se o pipe de entrada; iv. Publica-se o anncio do pipe de entrada do participante.
Maiores detalhes sobre o processo acima so dados no Apndice B.
2o passo: O estabelecimento da comunicao

A simples criao de um pipe de entrada no signica a existncia de um canal de comunicao. O peer deve utilizar o servio de descoberta (discovery service ) para descobrir os pipes de outros participantes e estabelecer uma comunicao entre o seu pipe de entrada e o pipe de sada de outro participante. Somente a partir da, o participante poder receber mensagens dos demais usurios da rede. Da mesma forma, para que ele possa enviar mensagens, o uxo inverso dever ser estabelecido: deve-se associar um canal de comunicao entre o pipe de entrada do participante remoto e um pipe de sada (normalmente criado no momento do estabelecimento desta conexo). Portanto, o processo de criao do canal de comunicao de sada com um determinado participante baseado nas seguintes etapas:
i. feita uma pesquisa pelos canais de comunicao de todos os participantes; ii. Verica se o anncio do canal de comunicao do participante procurado foi
encontrado;
iii. Caso o mesmo tenha sido encontrado, cria-se uma comunicao com o canal
de comunicao do participante remoto.
4.3. Um paralelo entre o JXTA e o JXTAula
63
3o passo: Recebendo mensagens de outros participantes

No JXTA, existem dois mecanismo de recebimento das mensagens nos pipes : mtodo sncrono (onde deve car sendo vericado se chegou alguma mensagem) e mtodo assncrono (onde o evento PipeMsgEvent chamado caso chegue uma mensagem). No caso do JXTAula, optou-se por utilizar o mecanismo assncrono. A classe ComunicacaoEntradaP2P a responsvel por implementar a interface
PipeMsgListener e receber as mensagens, direcionando-as s aplicaes (no caso

de mensagens externas ao JXTAula) ou tratando-as adequadamente nos casos de mensagens internas do prprio middleware. Maiores detalhes sobre o processo acima so dados no Apndice B.
4.3 Um paralelo entre o JXTA e o JXTAula

Neste momento, importante destacar quais so as principais diferenas entre a utilizao do JXTA, e quais as novas funcionalidades providas com a utilizao do JXTAula, destacando as motivaes para o uso deste middleware em sistemas colaborativos. A tabela 6.4 demonstra as principais caractersticas e vantagens que os desenvolvedores poderiam tirar proveito ao optarem pelo desenvolvimento de seu sistema utilizando o middleware JXTAula, em vez de utilizar simplesmente a plataforma JXTA.
4.3. Um paralelo entre o JXTA e o JXTAula
64
Tabela 4.1: Anlise comparativa entre a plataforma JXTA e o middleware JXTAula

JXTA
Exige conguraes especcas e conhecimento profundo dos componentes internos do framework Possui estrutura de dados complexas, que devem ser administradas pelo desenvolvedor do sistema Os anncios descobertos anteriormente so sempre exibidos, pois cam armazenados por um longo perodo na cache do participante A localizao baseada no servio Discovery (protocolo PDP) Envio de mensagens de tamanho limitado Alm da localizao ser baseada no protocolo PDP, utiliza-se tambm a troca de mensagens que garante maior conabilidade Mecanismos que garatem a fragmentao, compresso e serializao para enviar mensagens grandes Permite a criao de grupos com o mesmo nome, porm cada grupo ter seu ID Permite obter o uptime de um peer e a quantidade de mensagens enviadas pela rede (network trac ) atravs do protocolo PIP No h duplicidade de salas com o mesmo nome, pois para cada sala existe um nico ID Complementa as funcionalidades do JXTA, permitindo a vericao de latncia, da capacidades de processamento e de memria RAM S so exibidos os usurios que esto conectados naquele momento ao ambiente,
JXTAula
Utiliza uma interface intuitiva e com poucos mtodos, baseada em conceitos de EaD que abstrai do desenvolvedor o seu funcionamento interno Possui estruturas de dados simples, manipuladas a partir de Strings
Captulo
Integrao do middleware JXTAula a um sistema de EaD

Este captulo aborda a integrao do middleware JXTAula a um sistema real de ensino a distncia atualmente em desenvolvimento no Departamento de Engenharia de Teleinformtica da Universidade Federal do Cear, denominado COGEST (Comunicao Gestual com Humanides Virtuais). A arquitetura do sistema COGEST baseada no modelo cliente-servidor ser explicada, e em seguida ser proposta a utilizao de uma nova arquitetura peer-to-peer atravs do JXTAula, demonstrando-se como pode ser realizada a integrao de aplicativos ao JXTAula.
5.1 Arquitetura do COGEST

5.1.1 Descrio geral sobre o projeto
O COGEST um ambiente colaborativo que apresenta seus participantes representados em um espao virtual e que valoriza a comunicao gestual atravs de traduo de aes em movimentos executados pelos avatares. Neste contexto, um problema enfrentado freqentemente por usurios de ferramentas de comunicao a distncia a diminuio da percepo do grupo e das aes individuais de usurios distantes. Com isso, o projeto visa melhorar essa comunicao e a percepo mtua das aes de participantes sicamente dispersos atravs do comportamento gestual de avatares, uma vez que a percepo mtua da presena e das aes de usurios distantes representam um elemento de particular importncia no projeto de ambientes de colaborao a distncia. Por exemplo, para um tutor ou
5.1. Arquitetura do COGEST
66
professor exercendo uma atividade de coordenao em um trabalho colaborativo, determinante saber quem est executando uma operao sobre um objeto compartilhado e o que exatamente ele est fazendo. atravs dos elementos perceptivos que os membros do grupo conseguem identicar inconsistncias em seu raciocnio e interagir de maneira a trocar informaes e referncias para auxiliar na resoluo de problemas. Assim, uma maneira bastante intuitiva de perceber quem est fazendo o qu atravs da observao dos gestos dos avatares. (SOARES et al., 2006), (SOARES, 2004) A interface grca compreende um espao aplicativo e um espao perceptivo. O espao aplicativo corresponde aplicao ou documento compartilhado que mapeado como textura em um quadro virtual. J o espao perceptivo um mundo 3D habitado, onde cada usurio representado por um humanide 3D articulado que representa as aes de movimento dos usurios, denido segundo a norma H-ANIM (H-ANIM/ISO/IEC, 2008). Uma sala de aula ou de reunio contendo um quadro virtual, onde os usurios podem interagir e colaborar, utilizada como metfora na interface grca do sistema, conforme ilustra a gura 5.1. Ao conectar-se, o usurio tem seu avatar inserido em um dos lados do quadro virtual, e ao se desconectar, seu avatar retirado do ambiente. Tem-se assim a percepo visual da chegada ou partida de um usurio do ambiente, bem como de sua permanncia. A comunicao gestual se d atravs de movimentos corporais dos avatares, associados de maneira coerente s aes dos respectivos usurios, por exemplo, movimentao do cursor do mouse. O ambiente desenvolvido permite ainda o compartilhamento de aplicaes imersas no mundo virtual tridimensional atravs da adaptao de um cliente VNC (Virtual Network Computing ) (REALVNC, 2008), conforme apresentado em (SOARES;
HORAIN; BIDEAU, 2003). Sempre que o usurio executa alguma funo na aplicao
2D, so gerados e enviados eventos a um servidor que se encarrega de atualizar a posio do avatar no mundo virtual tri-dimensional.
5.1.2 Arquitetura centralizada do COGEST

A gura 5.2 ilustra a arquitetura centralizada do ambiente e o funcionamento da difuso dos eventos. A arquitetura centralizada constituda pelos seguintes componentes:
5.1. Arquitetura do COGEST
67
Figura 5.1: Interface grca do COGEST
Figura 5.2: Arquitetura centralizada
i. Servidor de Eventos : Responsvel por manter o estado atual do ambiente

e pela difuso de eventos entre os clientes. Sempre que um cliente deseja se comunicar no ambiente, este envia uma mensagem ao servidor de eventos, para que este servidor encaminhe a mensagem ao destino. Por exemplo, no caso de um novo usurio ingressar no ambiente, seu avatar adicionado ao mundo tri-dimensional e uma mensagem enviada do servidor de eventos para os demais usurios, informando que o novo usurio entrou no ambiente;
ii. Servidor VNC : Mantm a aplicao que est sendo compartilhada no quadro
virtual. O cliente que est interagindo com o quadro virtual, envia os
5.2. Proposta de nova arquitetura ao COGEST
68
eventos para o servidor VNC, para que estes sejam realizados na aplicao compartilhada;
iii. Cliente Ativo : Usurio que est interagindo com o quadro virtual; iv. Cliente Inativo : Usurio que no est interagindo com o quadro virtual.
5.2 Proposta de nova arquitetura ao COGEST

5.2.1 Descrio geral sobre as vantagens da nova arquitetura
Analisando a arquitetura apresentada na gura 5.2, identica-se as seguintes caractersticas passveis de melhorias:
i. O ambiente suporta somente uma sala de aula virtual, de forma que as

mensagens de difuso de eventos so enviadas inicialmente ao servidor, para que em seguida seja encaminhada todos os participantes do ambiente;
ii. Existe um servidor de eventos que responsvel por propagar as

movimentaes dos avatares aos demais participantes do ambiente. Caso este servidor que inoperante, todo o sistema para de funcionar;
iii. Existe um servidor nico de VNC que responsvel por fornecer o servio
para compartilhamento de aplicaes aos participantes do ambiente. Caso este servidor que inoperante, a funcionalidade de compartilhamento de aplicativos para de funcionar; Com a utilizao do JXTAula, tem-se a possibilidade de criar diversas salas de aula virtuais, garantindo assim maior escalabilidade do sistema. Como cada sala mantm um canal de comunicao separado, as mensagens de difuso de eventos so enviadas diretamente aos participantes da sala, sem necessidade de serem encaminhadas por um servidor. Este trfego de mensagens feito de maneira controlada, uma vez que os demais participantes do ambiente, que no estejam nesta sala, no recebero tais mensagens. Para evitar que o sistema tenha um ponto nico de falha, que o servidor de eventos, cada sala passa a ser mantida por um de seus participantes, denominado coordenador da sala, escolhido dentre os membros da sala atravs de um mecanismo
69
de eleio. O coordenador da sala o responsvel por enviar o estado atual do sistema aos novos usurios que ingressem no ambiente e, caso este coordenador se torne inoperante, uma nova eleio poder ser realizada, possibilitando que o sistema continue funcionando com tolerncia falha. Assim, embora o coordenador da sala desempenhe algumas das funes do servidor de eventos, este coordenador eleito dinamicamente, dentre os participantes que esto na sala virtual. A funcionalidade de eleio do coordenador da sala no est no escopo do middleware JXTAula, e portanto deve ser implementada na camada de aplicao. Finalmente, para prover redundncia no fornecimento do servio VNC, em vez de se ter somente uma mquina que possui o servio VNC, pode-se disponibilizar este servio em diversas mquinas da rede, por exemplo, atravs da criao de mquinas virtuais utilizando um dos seguintes aplicativos: VMWare (VMWARE, 2008); VirtualBox (VIRTUALBOX, 2008); Qemu (QEMU, 2008). Com isso, deve haver pelo menos um servio VNC ativo em cada sala de aula virtual, de forma que uma mquina seja eleita para ser utilizada como provedor do servio VNC na sala. Caso a mquina provedora do servio VNC pare de funcionar, pode-se eleger uma das mquinas restantes para ser utilizada, garantindo a continuidade do servio VNC com tolerncia falha, embora a aplicao que estivesse sendo compartilhada no seja disponibilizada no mesmo estado em que estava no peer que falhou. A funcionalidade de eleio do provedor do servio VNC no est no escopo do middleware JXTAula, e portanto deve ser implementada na camada de aplicao.
5.2.2 Arquitetura descentralizada do COGEST

Com a utilizao da arquitetura descentralizada, a primeira grande vantagem a eliminao da necessidade do servidor de eventos, uma vez que a comunicao entre os participantes da sala passa a ser feita de maneira direta, sem envolver nenhuma entidade para encaminhamento das mensagens. Contudo, um coordenador da sala deve ser eleito para desempenhar a funo especial de inicializao dos novos usurios que entrarem no sistema (esta funo denominada de bootstrap ). Assim, tem-se a possibilidade de distribuir melhor a utilizao de recursos de processamento dos usurios da rede, havendo um melhor balanceamento da carga entre os diversos participantes do ambiente, pois anteriormente o processamento era feito unicamente pelo servidor de eventos. Alm disso, em vez de se utilizar um nico servidor de VNC, prope-se agora a
70
utilizao de um conjunto de mquinas que possuem o servio VNC, funcionando como um cluster 1 para o servio VNC. A gura 5.3 ilustra esta topologia, onde possvel a distribuio de processamento entre os usurios do ambiente, bem como o balanceamento de carga entre diversos servidores VNC. Na gura, tem-se que as salas so mantidas por usurios distintos, de forma que nenhum deles sobrecarregado para manter mais de uma sala do ambiente. Da mesma forma, caso haja mais de um servidor VNC no ambiente, poder haver balanceamento de carga entre os mesmos, para que nenhum que sobrecarregado no fornecimento do servio VNC para todas as salas do ambiente.
Figura 5.3: Distribuio e balanceamento de carga entre os participantes da rede

A gura 5.4 ilustra a arquitetura descentralizada proposta ao ambiente e o funcionamento da difuso dos eventos. A arquitetura proposta constituda pelos seguintes componentes:
i. Coordenador da sala : Responsvel por enviar o estado atual do ambiente

aos novos usurios que entrarem na sala. Embora todos os participantes possuam o mesmo estado do ambiente, o coordenador o participante eleito para enviar este estado aos novos usurios. Assim, aps a entrada de novos usurios, o coordenador envia uma mensagem para os demais, informando que
Conjunto de computadores interligados em rede que trabalham como se fossem uma nica mquina, fornecendo virtualizao dos servios que estejam sendo providos.
1 CLUSTER :
71
Figura 5.4: Arquitetura descentralizada proposta ao COGEST

um novo usurio entrou no ambiente, para que os mesmos atualizem o estado do ambiente;
ii. Provedor do servio VNC : Mantm a aplicao que est sendo compartilhada
no quadro virtual. O cliente que est interagindo com o quadro virtual, envia os eventos para o servidor VNC, para que estes sejam realizados na aplicao compartilhada;
iii. Cliente Ativo : Usurio que est interagindo com o quadro virtual; iv. Cliente Inativo : Usurio que no est interagindo com o quadro virtual.
A arquitetura proposta ao COGEST considera que as comunicaes entre os usurios podem ser feitas de maneira descentralizada, pois as mensagens so enviadas diretamente de um usurio a outro, sem envolver um servidor para repasse das mensagens. Porm, quanto ao servio VNC, h a necessidade de se ter pelo menos um servidor capaz de prover este servio para os usurios do ambiente, uma vez que a mquina que est provendo o servio VNC no pode ser um dos usurios do sistema. Tal caracterstica se deve ao fato de que uma mquina VNC no pode ser cliente dela mesma, pois a rea de trabalho compartilhada com os demais usurios, para que os mesmos possam interagir e realizar o compartilhamento das aplicaes. Portanto, a rea de trabalho da mquina que estiver provendo o servio VNC deve estar dedicada para tal m. O que se prope para o servio VNC que o mesmo no esteja disponvel em uma nica mquina, mas em um cluster de mquinas para
5.3. Passos para a integrao do COGEST ao JXTAula
72
que haja um certo nvel de redundncia visando suportar um mnimo de tolerncia falha dos servidores VNC. Tal servio poderia ser disponibilizado a partir de ferramentas de virtualizao (utilizando, por exemplo, um dos seguintes aplicativos: VMWare (VMWARE, 2008); VirtualBox (VIRTUALBOX, 2008); Qemu (QEMU, 2008)) nas mquinas dos participantes do ambiente, para no fosse necessrio dispor de outras mquinas fsicas.
5.3 Passos para a integrao do COGEST ao JXTAula

Essa seo visa fornecer uma idia geral de como deve ser feita a integrao de um aplicativo ao JXTAula. Como o estudo de caso foi desenvolvido com o aplicativo COGEST, descreve-se a seguir as principais etapas e atividades que tiveram de ser percorridas para essa integrao.
5.3.1 Adaptaes de interfaces grcas (GUI)

Para manter a compatibilidade com a verso anterior do sistema, desenvolveu-se uma tela para que o usurio possa selecionar qual arquitetura de rede ser utilizada: cliente-servidor (centralizada) ou P2P (descentralizada). Caso o usurio determine que utilizar a arquitetura centralizada, ele deve informar o endereo IP do servidor de eventos e o endereo IP do servidor VNC. Porm, caso ele opte por utilizar a arquitetura P2P, as conguraes relacionadas ao servidor de eventos no precisam ser fornecidas, pois, como j foi explicado, ocorrer a eleio de um determinado usurio da sala para ser o coordenador. Porm, devido caracterstica centralizada do servio VNC, tambm deve ser fornecido um endereo IP do cluster de servidores VNC (ou de pelo menos um servidor). A gura 5.5 demonstra essa tela. Uma outra necessidade foi a criao da tela responsvel por fornecer acesso s funcionalidades providas pelo JXTAula. Dessa forma, foram criados botes para permitir ao participante a utilizao das seguintes funcionalidades, conforme ilustra a gura 5.6.
i. Entrar no ambiente. ii. Criar, excluir, entrar e sair das salas. iii. Listar todas as salas do ambiente, bem como, listar todos os participantes do
ambiente.
73
Figura 5.5: Escolha da arquitetura de comunicao
iv. Enviar mensagens a todos os participantes de uma determinada sala, bem

como a um participante em particular.
v. Compartilhar arquivos nas salas ou em toda a escola. vi. Vericar o tempo de resposta de determinado participante do ambiente (ping ).
Figura 5.6: Tela das funcionalidades providas pelo JXTAula
74
5.3.2 Adaptaes do cliente para anteriormente pelo servidor
incorporar
funes
providas
Ao migrar de uma soluo cliente-servidor para uma P2P, os desenvolvedores devem ter em mente que a principal caracterstica de um peer que ele pode desempenhar papis tanto de cliente como de servidor, dependendo do momento. Dessa forma, deve ser identicado quais so as principais funcionalidades providas pelo servidor, para que as mesmas passem a ser desempenhadas pelos peers do sistema. Com relao ao COGEST, foram mapeadas as seguintes atividades como sendo de responsabilidade do servidor de eventos:
i. Processo de inicializao e manuteno do estado do ambiente. ii. Encaminhamento de mensagens entre os clientes.
Conforme j discutido, o processo de inicializao do ambiente passa a ser fornecido pelo Coordenador da Sala, uma vez que o estado do ambiente replicado por todos os participantes. Assim, todos tem as mesmas informaes e a mesma viso do ambiente, de forma que caso o peer responsvel por inicializar novos usurios deixe de funcionar, outro peer, determinado atravs de uma eleio dinmica, possa desempenhar esta funo de forma transparente aos demais participantes da rede. Com relao ao envio de mensagens de forma independente do servidor de eventos, foram feitas as adaptaes descritas no prximo item.
5.3.3 Adaptaes no mtodo de envio e recepo de mensagens

Uma adaptao necessria aos programas que esto alterando seu modelo de comunicao est relacionada aos mtodos de envio e recepo de mensagens. preciso identicar os trechos de cdigos responsveis por enviar e receber as mensagens, para que os mesmos passem a ser utilizados a partir dos mtodos do JXTAula. Para o caso do COGEST, a arquitetura do modelo de comunicao cliente-servidor baseada na criao de uma conexo socket entre o cliente e o servidor. A classe responsvel por prover essas funcionalidades a que utiliza as
TCPConnectionManager.
Essa classe foi substituda pela classe P2PConnector, funcionalidades do JXTAula para prover o envio e recepo de mensagens baseado
75
em um modelo de comunicao descentralizado. Neste novo cenrio, em vez das mensagens serem enviadas ao servidor de eventos atravs do socket fornecido pela classe TCPConnectionManager, elas passam a ser enviadas para a sala atravs da funcionalidade enviarMensagemSala() fornecida pelo JXTAula. Maiores detalhes sobre o processo acima so dados no Apndice C
Captulo
6
O arcabouo desenvolvido ser
Resultados obtidos e avaliao nal

Este captulo apresenta os resultados obtidos na avaliao da arquitetura proposta, ao utilizar o middleware JXTAula. avaliado em relao s caractersticas da norma ISO/IEC 9126 (ISO/IEC, 1991), que dene um conjunto de aspectos relacionados qualidade de software. Para a realizao desta avaliao, foi utilizado o processo denido pela norma ISO/IEC 14598 (ISO/IEC, 1999). Assim, alm de avaliar este trabalho com relao aos requisitos funcionais e no funcionais atravs de caractersticas de qualidade, valida-se a arquitetura proposta na utilizao de um sistema real de ensino distncia. O restante do captulo foi dividido de acordo com as etapas do processo de avaliao de um produto de software, conforme a norma ISO/IEC 14598, demonstrado na gura 6.1.
6.1 Requisitos da avaliao

Antes de iniciar a avaliao da qualidade de um software, importante estabelecer um conjunto de requisitos que devem ser observados durante o processo. Inicialmente, a norma dene que seja estabelecido o propsito da avaliao, o produto a ser avaliado e o modelo de qualidade para as caractersticas do software que ser avaliado.
6.1.1 Propsito da avaliao e produto a ser avaliado

A avaliao proposta neste captulo visa vericar a qualidade do middleware JXTAula desenvolvido e especicado no captulo anterior. Atravs de normas
6.1. Requisitos da avaliao
77
Figura 6.1: Viso geral do processo de avaliao de avaliao de qualidade de software ISO/IEC 14598
e processos amplamente utilizados no processo de desenvolvimento de sistemas, objetiva-se demonstrar a qualidade do produto gerado, e com isso, estimular a utilizao deste trabalho por desenvolvedores de sistemas de EaD, ou ainda, por outros desenvolvedores que desejem construir suas aplicaes baseada em uma arquitetura P2P. Um outro propsito deste captulo adaptar e documentar os procedimento de avaliao de softwares baseado em normas reconhecidas e utilizadas mundialmente, para que essses processos possam ser utilizados em outros projetos do grupo de pesquisa do Departamento de Engenharia de Tele-informtica da Universidade Federal do Cear.
6.1.2 Modelo de qualidade a ser utilizado

Utilizou-se neste trabalho uma adaptao do modelo de qualidade denido pela norma ISO/IEC 9126. Essa norma foi publicada pela International Organization for
Standarization (ISO) para representar a atual padronizao mundial de qualidade

de produtos de software, e que possui sua traduo para o Brasil sob a forma da norma NBR 13596. As caractersticas e sub-caractersticas da norma ISO/IEC 9126 so demonstradas na gura 6.2. Na avaliao deste trabalho, foram utilizadas as sub-caractersticas que se aplicavam ao domnio do middleware. Embora a atual norma ISO 9126/NBR
6.2. Especicao da avaliao
78
Figura 6.2: Caractersticas e sub-caractersticas denidas pela norma ISO/IEC 9126

13596 enumere as caractersticas e sub-caractersticas de um software, ela no dene como dar uma nota a um software em cada um destes tens. Ficou a cargo do processo denido pela norma ISO/IEC 14598 as atividades relacionadas medio, e portanto, nas prximas sees so descritos os critrios utilizados para julgar as caractersticas denidas.
6.2 Especicao da avaliao

Com base nessas caractersticas e sub-caractersticas, adequou-se as que se aplicavam ao middleware JXTAula, de tal forma que para cada sub-caracterstica selecionada, deniu-se sua mtrica e seus nveis de pontuao dentro de uma escala de avaliao. De acordo com a norma ISO/IEC 9126, as avaliaes efetuadas em um produto
6.3. Planejamento e Execuo da avaliao
79
de software devem observar os seguinte preceitos:
Repetvel : repetindo-se a avaliao de um mesmo produto, com a mesma

especicao da avaliao e pela mesma equipe de testes, deve-se obter o mesmo resultado;
Reproduzvel : repetindo-se a avaliao de um mesmo produto, com a mesma

especicao, embora seja efetuada por diferentes equipes de teste, deve-se obter o mesmo resultado;
Imparcial : a avaliao deve ser livre de tendncias injustas, ou seja, no deve

ser inuenciada, por exemplo, pelos sentimentos ou opinies de terceiros.
6.2.1 Mtricas utilizadas e seus nveis de pontuao

Para julgar a qualidade do produto, convm que se prepare um procedimento para este m, com critrios especcos para as diversas caractersticas, de tal forma que a medio quantitativa dos requisitos seja feita pelo uso de mtricas. A tabela 6.1 demonstra as caractersticas que foram selecionadas e as mtricas denidas para serem utilizadas durante o processo de avaliao deste trabalho.
6.2.2 Critrios para julgamento

O julgamento das mtricas leva em considerao a sua classicao em nveis de aceitabilidade. Para cada mtrica, foram determinados parmetros para classic-la como "Satisfatria"; "Regular"ou "Ruim". Conforme ser descrito na prxima seo, os testes sero realizados por usurios com pers e conhecimentos diferentes, para se obter uma melhor amostragem na avaliao. Assim, o conjunto de notas ser sintetizado, e ser feita uma declarao sobre o quanto o produto de software atende aos requisitos denidos.
6.3 Planejamento e Execuo da avaliao

A etapa de planejamento da avaliao engloba a criao e denio de um Plano
de Teste, descrevendo as tcnicas de avaliao e os critrios de aceite para cada

teste realizado. J a execuo da avaliao feita quando se realiza o que est previsto no Plano de Teste, onde as mtricas selecionadas so aplicadas ao produto de software, obtendo-se uma medio dentro dos nveis de aceitao que foram
80
Tabela 6.1: Caractersticas selecionadas e mtricas da avaliao
denidos. As sees a seguir avaliam os requisitos funcionais (mais especicamente, a primeira caracterstica da tabela 6.1: funcionalidade ) e os requisitos no funcionais (as demais caractersticas da tabela 6.1: usabilidade, ecincia, manutenibilidade e
portabilidade ).
6.3.1 Avaliao dos requisitos funcionais

Os requisitos funcionais esto ligados ao fato do arcabouo estar fazendo o que se propem fazer, englobando ainda as caractersticas de segurana. No caso dos
81
requisitos de segurana, o que estar sendo avaliado a possibilidade do arcabouo enviar mensagens com mecanismos de criptograa e autenticao de forma que o trfego trocado entre os dispositivos seja condencial, embora no esteja no escopo do Plano de Teste a captura de trfego na rede (por exemplo, atravs de ferramentas de snier 1 ). Para avaliar as caractersticas de Funcionalidade, foi denido o Plano
de Teste da tabela 6.2.
Tabela 6.2: Plano de testes para os requisitos funcionais

Ferramenta para capturar o trfego na rede e analis-lo atravs de procedimentos de identicao de protocolos.
1 SNIFFER:
82
Cenrios dos testes

Para executar os planos de testes descritos, foram selecionados 03 (trs) alunos da disciplina de Sistemas Distribudos do Departamento de Engenharia de Tele-informtica da Universidade Federal do Cear. Esses alunos caram incumbidos de desenvolver um aplicativo que utilizasse a plataforma JXTAula para fornecer uma ferramenta de Chat, com a possibilidade de agrupar os participantes em diversas salas e com a funcionalidade de compartilhamento de arquivos. A gura 6.3 representa um dos aplicativos que foi desenvolvido.
Figura 6.3: Aplicativo de avaliao dos requisitos funcionais

Os procedimentos denidos na coluna "Tcnica de Validao" da tabela 6.2 foram executados pelos alunos e, aps a execuo dos Casos de Teste, os alunos avaliaram as sub-caractersticas relacionadas Funcionalidade (Adequao,
Acurcia, Interoperabilidade e Segurana ) conforme o questionrio demonstrado na

gura 6.4.
Resultados obtidos
Os resultados foram obtidos aps cada um dos alunos responder o questionrio de avaliao. Para calcular a nota obtida nas sub-caractersticas do questionrio da gura 6.4, utilizou-se um valor ponderado, considerando que as respostas recebem
0 (zero) ; 1 (um) e 2 (dois) correspondentes aos nveis de aceitao ruim ; regular e satisfatrio, respectivamente, da tabela 6.1. Por exemplo, para avaliar o requisito
83
Figura 6.4: Questionrio utilizado na avaliao dos requisitos funcionais

funcional Acurcia, foram executados os testes denidos na tabela 6.2 e obtidos os resultados esperados em todos os 21 (vinte e um) requisitos funcionais. Assim, calculou-se a nota ponderada das respostas, consolidando-as na gura 6.5. Com base nos dados coletados, obteve-se a avaliao da tabela 6.3:
Tabela 6.3: Resultado da avaliao para as mtricas funcionais

Sub-caracterstica
Adequao Acurcia Interoperabilidade Segurana
Resultado
Satisfatrio Satisfatrio Satisfatrio Satisfatrio
84
Figura 6.5: Resultado da avaliao dos requisitos funcionais
6.3.2 Avaliao dos requisitos no funcionais

Algumas caractersticas so mais fceis de serem mensuradas que outras. Por exemplo, algumas podem ser medidas de forma bem objetiva, tais como o tempo de execuo de uma funcionalidade ou o nmero de erros encontrados em uma sesso de testes. Por outro lado, existem atributos que so mais difceis de serem mensurados de forma objetiva. Para avaliar as caractersticas relacionadas aos requisitos no funcionais, inicialmente preciso identicar aquelas que podem ser medidas de maneira objetiva, e aquelas que devem ser medida de forma subjetiva. Para as caractersticas subjetivas, criou-se uma srie de perguntas do tipo sim ou
no, onde as perguntas que tiverem respostas sim obtero uma melhor nota para a
caracterstica. Assim, caractersticas de usabilidade e manutenabilidade esto relacionadas aos requisitos subjetivos e sero avaliados atravs de questionrios, enquanto que as caractersticas ecincia e portabilidade esto relacionadas aos requisitos objetivos e sero mensuradas atravs da descrio e execuo de experimentos em laboratrio.
Usabilidade e Manutenibilidade
Cenrios dos testes

Para avaliar a usabilidade e a manutenibilidade do arcabouo, elaborou-se o questionrio da gura 6.6 para ser respondido pelos mesmos alunos que zeram a avaliao do item anterior. A usabilidade est relacionada ao fato do middleware
85
possuir uma interface (API) consistente e fcil de utilizar, com aprendizado intuitivo atravs de poucas funes e extrema abstrao das complexidades envolvidas no desenvolvimento dos elementos internos. J a manutenibilidade est relacionada ao processo de vericao e facilidade de realizao dos testes durante o desenvolvimento de aplicativos que utilizam o JXTAula, facilitando o controle atravs de logs do sistemas que garantam a rastreabilidade dos mtodos que foram executados.
Figura 6.6: Questionrio utilizado na avaliao dos requisitos no funcionais
Resultados obtidos
86
Os resultados coletados a partir do questionrio de avaliao dos requisitos no funcionais foram consolidados na gura 6.7.
Figura 6.7: Resultado da avaliao dos requisitos no funcionais

Com base nos dados coletados, obteve-se a avaliao da tabela 6.4:
Tabela 6.4: Resultado da avaliao para as mtricas no funcionais

Sub-caracterstica
Inteligibilidade Facilidade de aprender Facilidade de utilizar Facilidade em realizar testes
Resultado
Satisfatrio Satisfatrio Satisfatrio Regular
Ecincia e Portabilidade
Para avaliar as caractersticas relacionadas a ecincia e portabilidade, foram feitos os testes em laboratrios atravs do COGEST, cujos detalhes sero descritos a seguir. A caracterstica ecincia diz respeito quantidade de recursos que estar sendo utilizado durante a execuo das funcionalidades do componente, bem como com a quantidade de mensagens e o tempo de propagao dessas mensagens enviadas e recebidas pela rede. Os resultados obtidos sero comparados ao modelo cliente-servidor utilizado anteriormente pelo COGEST. J a portabilidade est relacionada ao fato da plataforma poder ser utilizada em diversos sistemas operacionais (Windows, Linux, etc ). Para garantir a portabilidade, utilizou-se a tecnologia Java, pois essa possui independncia do sistema operacional que o sistema esteja sendo utilizado. Alm disso, para garantir que o middleware est de acordo
87
com protocolos abertos, foi escolhido a plataforma JXTA, que baseado em uma especicao aberta e utiliza padres abertos, tais como o XML, alm de ser um projeto open-source, cujo cdigo fonte est disponvel para estudo pela comunidade. Finalmente, adotou-se a utilizao de padres de projeto (demonstrados no Apndice A) no desenvolvimento dos componentes interno do middleware JXTAula para garantir que o mesmo esteja de acordo com as principais convenes utilizadas no desenvolvimento de sistemas.
Cenrios dos testes

Os testes foram realizados considerando dois cenrios: utilizao de uma
arquitetura P2P atravs do JXTAula e utilizao de uma arquitetura cliente-servidor atravs da utilizao de sockets da linguagem Java. Para o cenrio P2P, foram utilizadas quatro mquinas (peers ) interconectadas por uma rede ethernet com largura de banda de 100 Mbps; enquanto que para o cenrio cliente-servidor, alm destas quatro mquinas (clientes), foi utilizada mais uma mquina para atuar na funo de servidor, atravs da rede ethernet com as mesmas caractersticas do cenrio anterior. Para garantir o requisito de portabilidade, sistemas operacionais diferentes foram utilizados nessas mquinas. As conguraes de cada mquina esto descrita na tabela 6.5.
Tabela 6.5: Conguraes das mquinas utilizadas nos testes

Mquina 1 Processador Memria principal Sistema operacional
Pentium 4 3.06 GHz 512 MB Linux Ubuntu
Peers / Clientes Mquina 2 Mquina 3

Intel Core 2 1.8 GHz 1 GB Microsoft Windows XP Athlon 64 2.41GHz 1 GB Microsoft Windows XP
Mquina 4
Pentium 4 3 GHz 1 GB Microsoft Windows Vista
Servidor Mquina 5
Intel Centrino Duo 1.73 GHz 2 GB Linux Slackware
Enquanto no cenrio P2P cada mensagem enviada diretamente aos participantes de uma determinada sala, no cenrio cliente-servidor, cada mensagem enviada ao servidor e este o responsvel por replicar as mensagens aos demais participantes. Para garantir que os testes fossem feitos de forma homognea, uma seqncia de movimentos predeterminada foi gravada em um arquivo, de forma que ao executar esta seqncia de movimentos, o participante envia pela rede um total
88
de 51 (cinqenta e uma) mensagens. Na avaliao da ecincia do middleware, sero analisadas duas de suas sub-caractersticas:
Utilizao de recursos : relaciona-se com a quantidade de mensagens

enviadas/recebidas pela rede quando comparados os modelos P2P (JXTAula) e cliente-servidor (sockets em Java);
Tempo de resposta : relaciona-se ao tempo de propagao de mensagens

enviadas/recebidas pela rede quando comparados os modelos P2P (JXTAula) e cliente-servidor (sockets em Java).
Quantidade de mensagens enviadas pela rede

Para medir a quantidade de mensagens no cenrio cliente-servidor, iniciou-se primeiramente o servio do servidor, para que em seguida, cada cliente se conectasse ao mesmo e entrasse no ambiente. Aps a conexo das quatro mquinas clientes, deniu-se que a Mquina 1 seria a responsvel pelo envio das mensagens. Por se tratar de um modelo centralizado, essas mensagens foram enviadas para o servidor, para que em seguida, o mesmo enviasse cada mensagem aos demais participantes. A tabela 6.6 resume o quantitativo de envio e recepo de mensagens trafegada pela rede para cada mquina do cenrio.
Tabela 6.6: Quantidade de mensagens no cenrio cliente-servidor

Mquina 1 Mensagens Enviadas Mensagens Recebidas Mensagens enviadas na Rede
51 0
Clientes Mquina 2 Mquina 3

0 51 0 51 4*(51)
Mquina 4
0 51
Servidor Mquina 5
3*(51) 51
J no cenrio P2P, por se tratar de um ambiente no centralizado, no existe a gura do servidor. Cada peer se conectou ao ambiente e em seguida, aps a criao da sala Teste, todos os participantes entraram na sala. Utilizou-se a mesma mquina do cenrio anterior para ser a responsvel pelo envio das mensagens. A tabela 6.7 resume o quantitativo no envio e recepo de mensagens trafegada pela rede para cada mquina do cenrio. O prximo item descreve o teste realizado para medir o tempo de propagao de mensagens enviadas/recebidas pela rede.
89
Tabela 6.7: Quantidade de mensagens no cenrio P2P

Mquina 1 Mensagens Enviadas Mensagens Recebidas Mensagens enviadas na Rede
3*(51) 0
Peers Mquina 2 Mquina 3

0 51 3*(51) 0 51
Mquina 4
0 51
Tempo mdio entre o envio e a recepo das mensagens

Para medir o tempo de propagao (latncia) entre o envio de cada mensagem, o primeiro cuidado que teve de ser tomado foi o sincronismo de relgio entre todas as mquinas. Para isso, antes da realizao dos testes, foi utilizado um servidor NTP (Network Time Protocol ) para garantir que os tempos (clocks ) nas mquinas estivessem sincronizados, pois cada mquina seria responsvel por registrar o tempo (hora, minuto, segundo e milissegundo) de envio/recepo de cada mensagem. As tabelas 6.8 e 6.9 resumem os tempos (expressos em milissegundos) de transmisso das mensagens pela rede para cada mquina dos cenrios, onde a linha Tempo de
incio e Tempo nal referem-se ao incio/m da transmisso para a Mquina 1 e

incio/m de recepo para as demais mquinas.
Tabela 6.8: Tempo de transmisso no cenrio cliente-servidor

(expresso em milissegundos)
Mquina 1
0 3125
Clientes Mquina 2 Mquina 3

422 3547 937 4062
Mquina 4
219 3281
Servidor Mquina 5
123 3192
Tempo de incio Tempo nal Tempo total de transmisso
4062
Tabela 6.9: Tempo de transmisso no cenrio P2P

(expresso em milissegundos)
Mquina 1 Tempo de incio Tempo nal Tempo total de transmisso

0 3140
Peers Mquina 2 Mquina 3

453 3515 1015 4078
Mquina 4
281 3531
4078
Para se obter o tempo de transmisso mdio de cada mensagem nos testes, calculou-se a mdia do tempo de recepo para cada uma das mensagens. Por exemplo, para calcular o tempo mdio de recepo da primeira mensagem,
6.4. Avaliao nal
90
calculou-se a mdia dos tempos de recepo das Mquinas 2, 3 e 4 para a primeira mensagem. Essa mesma lgica foi utilizada para as demais mensagens de forma a se obter o tempo mdio de cada mensagem. Os grcos das guras 6.8 e 6.10 representam o tempo de envio e o tempo mdio de recepo para cada um dos cenrios dos testes:
Figura 6.8: Latncia de transmisso no cenrio cliente-servidor
Resultados obtidos
Essa seo analisou os cenrios de comunicao baseados nas arquiteturas cliente-servidor e peer-to-peer (P2P) para se avaliar a ecincia do middleware JXTAula. Fez-se um comparativo entre a quantidade de mensagens enviadas; tempo de transmisso total e tempo mdio de transmisso de cada mensagem para os cenrios descritos. Finalmente, os resultados so sumarizados tabela 6.10. A gura ilustra o comparativo entre o tempo mdio de recebimento das mensagens para o cenrio cliente-servidor e P2P.
6.4 Avaliao nal

Aps descrever cada plano de teste e execut-los, essa seo compara os resultados obtidos com os nveis de aceitao que foram denidos na tabela 6.1,
6.4. Avaliao nal
91
Figura 6.9: Latncia de transmisso no cenrio P2P Tabela 6.10: Resultados obtidos para os cenrios cliente-servidor e P2P
(expressos em milissegundos)
Cliente-Servidor
4*(51) 4062 546
P2P
3*(51) 4078 562
Resultado
Satisfatrio (Menos mensagens no modelo P2P) Regular (P2P equivalente ao Cliente-Servidor) Regular (P2P equivalente ao Cliente-Servidor)
Quantidade de mensagens enviadas pela rede Tempo de transmisso total Tempo mdio de transmisso de cada mensagem
fazendo-se uma avaliao nal dos requisitos abordados neste trabalho.
6.4.1 Resultado nal

A tabela 6.11 resume a avaliao nal que foi apresentada neste captulo.
6.4.2 Avaliao dos resultado obtidos

A primeira caracterstica que foi avaliada foi a de funcionalidade. Com base nos questionrios respondidos pelos estudantes, os requisitos funcionais que foram denidos no captulo 3, seo 3.3.1, foram implementados e avaliados no middleware JXTAula. Alm disso, os alunos avaliaram os resultado obtidos na execuo Como todos os de cada funcionalidade do middleware, conforme a tabela 6.2.
alunos do experimento conseguiram integrar os seus sistemas com o JXTAula, eles
6.4. Avaliao nal
92
Figura 6.10: Comparao entre o tempo mdio de recebimento Tabela 6.11: Resultados obtidos na avaliao nal
avaliaram de forma satisfatria a sub-caracterstica de interopebilidade. Finalmente, aproveitando-se do uso de Secure Pipe do JXTA, conforme explicado no captulo 4, o
6.4. Avaliao nal
93
JXTAula forneceu a funcionalidade de enviar mensagens criptografadas, garantindo o requisito de segurana. Em seguida, os mesmos alunos avaliaram o arcabouo com relao a sua usabilidade e manutenibilidade. Foi constatado o fato do middleware possuir uma interface (API) consistente e fcil de utilizar, com aprendizado intuitivo atravs de poucas funes e extrema abstrao das complexidades envolvidas no desenvolvimento dos elementos internos. Entretanto, detectou-se a possibilidade de melhorar as mensagens de log utilizadas na rastreabilidade dos mtodos para facilitar o desenvolvimento dos aplicativos, melhorando-se o requisito de manutenibilidade. Com relao a ecincia, foi comparado o desempenho do envio de mensagens utilizando uma arquitetura P2P (atravs de pipes do JXTA) e uma arquitetura cliente-servidor (atravs de sockets do Java). O trabalho no pretende demonstrar que o modelo proposto (baseado em P2P) melhor que o modelo cliente-servidor, e sim que existe uma alternativa a esse modelo centralizado, com desempenho equivalente e baseada em uma arquitetura sem um ponto central de falha. Assim, conclui-se que o modelo P2P possui desempenho bastante semelhante, o que conrma a possibilidade de se utilizar esta arquitetura no centralizada no desenvolvimento de aplicativos. Finalmente, para atender a caracterstica de portabilidade, escolheu-se a utilizao da linguagem Java, pois ela possui independncia de sistemas operacionais, pois executada pela mquina virtual java (JVM) que fornece uma abstrao do sistema operacional que esteja sendo utilizado. Para garantir que o middleware utilize protocolos abertos, foi escolhido a plataforma JXTA, baseado em uma especicao aberta que mantido pela comunidade open-source.
Captulo
Concluso e trabalhos futuros

7.1 Concluso
Este trabalho apresentou uma arquitetura para desenvolvimento de aplicaes baseadas em uma infra-estrutura P2P capaz de proporcionar servios de colaborao baseado em troca de mensagens, compartilhamento de informaes e facilidade de uso. O arcabouo proposto neste trabalho engloba uma arquitetura reutilizvel, adaptvel, provendo meios distribudos para a interao entre participantes envolvidos no processo de ensino-aprendizagem, no com o objetivo de substituir as plataformas existentes, mas com o objetivo de complement-las com o fornecimento de funcionalidades capazes de dar suporte s aplicaes no contexto de sistemas de ensino distncia. Deniu-se, neste trabalho, um arcabouo com as principais funcionalidades dos aplicativo de EaD, como forma de criar uma abstrao da plataforma P2P que estivesse sendo utilizada. Tais funcionalidades esto relacionadas com a criao de um ambiente colaborativo capaz de organizar seus participantes em salas virtuais, possibilitando, por exemplo, o envio de mensagens e o compartilhamento de arquivos. Os middlewares desenvolvidos com base no arcabouo apresentado podem ser implementados tendo por base diversas plataforma P2P, tais como as plataformas JXTA, Pastry e Windows P2P Networking. Como forma de ilustrar a utilizao do JxAula, desenvolveu-se o middleware JXTAula baseado na plataforma JXTA. A utilizao das plataformas P2P existentes no uma tarefa trivial, pois as mesmas exigem um conhecimento aprofundado de seu funcionamento e de suas estruturas internas, consumindo um tempo precioso no desenvolvimento do
7.1. Concluso
95
aplicativo. Para o caso da plataforma JXTA, a falta de bibliograa atualizada sobre a plataforma dicultou ainda mais a compreenso e sua utilizao durante o desenvolvimento do middleware JXTAula, principalmente devido a falta de livros atualizados, pois os ltimos livros especcos sobre a plataforma datam de 2002: (GONG; OAKS; TRAVERSAT, 2002), (GRADECKI, 2002) e (BROOKSHIER et al., 2002). Portanto, foram consumidos vrios meses de estudos e testes com exemplos disponibilizados pela plataforma para que houvesse o entendimento correto de seu funcionamento, sendo necessrio um esforo adicional no estudo do cdigo fonte da plataforma para que houvesse o entendimento dos elementos envolvidos na utilizao de suas funcionalidades. Baseado nessa experincia, considerada de certo modo negativa, uma vez que esse esforo desnecessrio para o desenvolvedor e diculta o desenvolvimento e utilizao da plataforma, teve-se a preocupao com que o middleware JXTAula conseguisse abstrair do desenvolvedor toda essa complexidade, sendo a facilidade de uso uma das principais motivaes para a sua utilizao. As funcionalidades providas pelo middleware foram avaliadas atravs da execuo de um plano de testes, que buscou cobrir os requisitos denidos. Alm disso, avaliou-se a usabilidade, que est relacionada ao fato de se ter um aprendizado intuitivo, e a manutenibilidade, que est relacionada a facilidade de realizao dos testes durante o desenvolvimento de aplicativos que utilizam o JXTAula. Outra caracterstica explorada no desenvolvimento deste trabalho foi a portabilidade, garantindo-se que o middleware pudesse ser utilizados em diversos sistemas operacionais. Abordou-se tambm a integrao do middleware JXTAula, a principal contribuio deste trabalho, a um ambiente virtual colaborativo para aplicaes de ensino distncia, que est em fase de desenvolvimento no Departamento de Engenharia de Teleinformtica da Universidade Federal do Cear no contexto do projeto COGEST (Comunicao Gestual com Humanides Virtuais). Demonstra-se, com isso, um caso real da utilizao do trabalho desenvolvido, destacando-se as principais atividades necessrias para utilizar este trabalho no desenvolvido de outros sistemas aplicativos durante a migrao de uma arquitetura centralizada para descentralizada. A arquitetura do ambiente virtual COGEST, baseada no modelo cliente-servidor, foi substituda por uma nova arquitetura peer-to-peer atravs do JXTAula. Neste
7.2. Trabalhos futuros
96
estudo de caso, foi comparado o desempenho do envio de mensagens utilizando uma arquitetura P2P (atravs de pipes do JXTA) e uma arquitetura cliente-servidor (atravs de sockets do Java). A comparao entre cliente-servidor e P2P tem como propsito vericar a viabilidade de aplicaes que usem arquiteturas centralizadas poderem migrar para descentralizadas. Durante a avaliao desses dois modelos, foi constatada tal possibilidade, baseada no fato de se ter desempenhos equivalentes entre as duas plataformas, e que no foi necessria nenhuma modicao signicativa no sistema original para integr-lo ao middleware JXTAula. Assim, acredita-se que embora este trabalho tenha sido concebido para as necessidades dos desenvolvedores de sistemas de ensino distncia, acredita-se que o mesmo possa ser utilizado por desenvolvedores de qualquer sistemas que deseje migrar para uma arquitetura distribuda, eliminando-se possvel ponto nico de falha. O trabalho no pretende demonstrar que o modelo proposto (baseado em P2P) melhor que o modelo cliente-servidor, mas que existe uma alternativa ao modelo centralizado, com desempenho equivalente e baseada em uma arquitetura sem um ponto central de falha. A partir dos testes realizados em laboratrio, concluiu-se que o modelo P2P possui desempenho bastante semelhante, conrmando a possibilidade de se utilizar esta arquitetura no centralizada no desenvolvimento de aplicativos colaborativos.
7.2 Trabalhos futuros

A denio e implementao de uma arquitetura baseada em P2P com conceitos e funcionalidade de sistemas colaborativos abre um grande conjunto de possibilidades de trabalhos futuros, pois embora este trabalho tenha abordado algumas importantes caractersticas desse tipo de aplicao, muitas outras podem ser incorporadas e melhoradas. Como principal possibilidade de agregar novas funcionalidades a este trabalho, indicamos a denio e implementao de componentes relacionados com o trfego multimdia (udio e vdeo) e integrao com e-mail. Esse tipo de funcionalidade bastante til para as aplicaes colaborativas, e sua implementao envolve inmeras complexidades, sendo justamente por isso que esses temas tm sido estudados e avaliados pela comunidade cientca. Uma outra possibilidade de trabalho futuro est relacionado s funcionalidades de armazenamento distribudo e replicao de dados. A motivao de se ter
7.2. Trabalhos futuros
97
sincronismo de informaes entre os participantes do ambiente reside no fato de que em um ambiente distribudo, normalmente um objeto compartilhado pode ser acessado por mais de um participante ao mesmo tempo, da a necessidade de se implementar mecanismos de controle de concorrncia. Outra caracterstica bastante importante o fornecimento de persistncia aos objetos do ambiente, para que os mesmos possam ser recuperados em um momento posterior, mesmo que o participante tenha sado do ambiente. Finalmente, outro tema desaador o desenvolvimento de um mdulo para tentar diminuir a imprevisibilidade associada aos ambiente P2P, atravs de mensagens de controle e mecanismos de tolerncia a falha que abstraiam das camadas superiores os eventos de falhas ocorridos nos participantes da rede P2P, garantindo maior conabilidade ao ambiente. Dessa forma, quando um participante sair da rede P2P, seja por motivo de falha no peer, ou pelo simples fato do mesmo ter sado sem avisar aos demais, este mdulo detectaria o ocorrido e seria responsvel por vericar qualquer interao que estivesse ocorrendo com o peer que falhou - tais como compartilhamento de aplicaes, comunicao ou envio de arquivos em andamento - para que os recursos fossem desalocados de maneira adequada e transparente s camadas superiores.
Apndice
Padres de Projeto no arcabouo JxAula

A.1 Utilizao de padres de projeto no arcabouo JxAula
A.1.1 Padres de Projeto
Segundo (CHRISTENSEN, 2004), padres de projeto (design patterns ) tm tido um impacto signicativo na maneira como os sistemas orientados a objetos so projetados, modelados e desenvolvidos na ltima dcada. Padres estruturados so geralmente documentados atravs da linguagem unicada de modelagem UML (BOOCH; RUMBAUGH; JACOBSON, 1998) por meio de diagramas. Entretanto, padres de projetos vo muito alm de um conjunto de classes representados por diagramas, pois eles descrevem papis e responsabilidades na colaborao entre os objetos de um sistema. No trabalho de (GAMMA et al., 1995), tambm conhecidos como a "Gangue dos Quatro", diversos padres de projetos so denidos e organizados em padres de criao, estruturais e comportamentais. Os padres de criao so relacionados criao de objetos, os estruturais tratam das associaes entre classes e objetos e os comportamentais das interaes e divises de responsabilidades entre as classes ou objetos. Esses padres foram utilizados nesse trabalho, conforme veremos no decorrer deste captulo. Alm disso, (GAMMA et al., 1995) dene um arcabouo (framework ) como sendo um conjunto de classes cooperativas que resulta em um projeto reutilizvel para uma classe especca de software. Este trabalho, portanto, desenvolve
A.2. Mdulos do JxAula
99
um arcabouo cujas classes fornecem as diversas funcionalidades necessrias s aplicaes colaborativas de EaD, deixando claro que diversos padres trabalham junto, denindo os papis e responsabilidades para cada mdulo do arcabouo.
A.1.2 Utilizao de Padres de Projeto nas Camadas do JxAula i. Layers : divises lgicas de componentes agrupados por responsabilidades em
comum;
ii. Faade : utilizao de interfaces bem denidas que evitam dependncias diretas
entre os componentes de camadas diferentes;
iii. Bridge :
funciona como uma ponte entre o arcabouo JxAula e uma
implementao particular de uma plataforma P2P;
iv. Adapter : cria uma implementao para uma arquitetura P2P particular; v. Component : utiliza-se a plataforma JXTA como o componente bsico da
infra-estrutura, fornecendo seus servios atravs de componentes reutilizveis;
A.2 Mdulos do JxAula

Nessa seo, sero apresentados a aderncia a padres de projeto de cada mdulo que compem o arcabouo.
A.2.1 Gesto do Ambiente

A classe de Gesto do Ambiente responsvel por instanciar os demais gestores: Gestor de Salas, de Participantes, de Localizao, de Comunicao, de Desempenho e de Compartilhamento, os quais so chamados pelo Gestor do Ambiente, conforme o padro Chain of Responsibility (ver A), de forma a direcionar ao gestor responsvel por atender cada tipo de solicitao. Utilizando o padro Singleton (GAMMA et al., 1995), centraliza-se a responsabilidade de que s existe uma nica instncia de cada gestor, pois o gestor do ambiente o nico responsvel por criar os demais gestores atravs do padro
Factory Method (GAMMA et al., 1995), conforme demonstra a gura A.1. Esse
procedimento feito uma nica vez, quando o mtodo inicializar chamado pela aplicao atravs da fachada do arcabouo descrita no item anterior.
100
Figura A.1: Criao de gestores do ambiente

A motivao de utilizar o padro Singleton nos gestores do ambiente garantir que exista somente uma instncia de cada gestor, fornecendo um ponto global de acesso para os mesmos atravs do gestor do ambiente. J o padro Factory Method utilizado pelo gestor do ambiente para criar cada instncia dos gestores. A classe Escola tambm implementado atravs do padro de projeto Singleton (GAMMA et al., 1995), pois existe somente um nico objeto dessa classe, que responsvel por conter as referncias s salas e aos participantes do ambiente. A gura A.2 representa o uxo de listar as salas da escola e os participantes da escola.
Utilizao de Padres de Projeto i. Faade : oferece uma interface nica para um conjunto de funcionalidades de
nvel mais elevado, tornando o subsistema mais fcil de ser utilizado;
101
Figura A.2: Encontrar as salas e os participantes da Escola
ii. Singleton : garante a existncia de uma nica instncia da classe; iii. Factory Method : responsvel por construir objetos individuais para um
propsito especco, neste caso, responsvel pela instanciao dos demais gestores, uma nica vez;
iv. Chain of Responsibility : mantm os objetos com acoplamento fraco, fazendo

com que mudanas tenham pequeno risco de causarem falhas, pois detalhes de implementao so isolados em classes mais especcas (cada gestor responsvel por funcionalidades especicas);
A.2.2 Gesto de Salas

A classe de Gesto de Salas responsvel pela criao de salas e o pelo processo de entrar e sair de uma determinada sala. No processo de criao de sala, a fachada do arcabouo JxAula envia uma mensagem ao Gestor de Salas para a criao de uma nova sala e caso a sala ainda no exista, o Gestor de Salas cria uma nova sala na Escola, utilizando neste processo o padro Factory Method para criar salas na
Escola. A gura A.3 ilustra esse uxo:

Quando um participante entra em uma determinada sala, o objeto que representa essa Sala inserido no vetor de salas do Gestor de Salas, que a estrutura de dados responsvel por guardar as salas que o participante pertence. O uxo da gura A.4 representa as aes envolvidas no processo para entrar em uma determinada sala. Para trocar a sala atual do participante, o Gestor de Salas verica no vetor de salas do participantes se existe a sala especicada e em seguida atualiza a referncia da sala atual. J para sair de uma determinada sala, o uxo tambm segue a mesma
102
Figura A.3: Processo de criao de Sala
Figura A.4: Processo de entrar em uma determinada Sala

lgica, vericando se o participante pertence a sala especicada e, caso pertena, o participante sai da sala, removendo-a do vetor de salas do participantes. A gura
103
A.5 representa o uxo para trocar a sala atual do participante e para sair de uma determinada sala.
Figura A.5: Processo de trocar e sair de uma determinada Sala
Utilizao de Padres de Projeto i. Singleton : garante a existncia de uma nica instncia do Gestor; ii. Factory Method : responsvel por construir objetos individuais para um
propsito especco, neste caso, responsvel pela instanciao das salas do ambiente;
A.2.3 Gesto de Participante

Caso o usurio esteja tentando entra com credenciais vlidas no ambiente P2P, o Gestor de Participante cria o participante na escola e publica o anncio do participante na rede P2P, utilizando neste processo o padro Factory Method. A criao de uma instncia do participante depende da criao do AnuncioParticipante - objeto que contm as informaes sobre o participante, por exemplo: nome do participante. Este uxo indicado na gura A.6.
104
Figura A.6: Processo de criao do participante

Cada usurio que entra no ambiente Escola representado como sendo uma instncia da classe Participante. Este objeto responsvel por armazenar as informaes em um objeto da classe AnuncioParticipante. atravs desse anuncio que o Gestor de Localizao consegue descobrir os participantes que esto na Escola ou numa determinada sala.
propsito especco, neste caso, responsvel pela instanciao dos participantes do ambiente;
A.2.4 Gesto de Comunicao

No processo de criao do canal do participante, o Gestor do Participante solicita ao Gestor de Comunicao que crie o canal de comunicao, pois atravs desse canal que os demais participantes estabelecem uma conexo com o usurio, para transferncia de mensagens, conforme ilustra a gura A.7.
105
Figura A.7: Processo de criao da comunicao do participante

Quando um participante encontra o anuncio de um canal de comunicao de outro participante - utilizando o Gestor de Localizao - ele pode estabelecer uma conexo com o mesmo, de forma que essa comunicao denominada de canal de comunicao de sada. O gestor atribui ao objeto Comunicao a responsabilidade de tratar os eventos que acontecem neste canal, por exemplo, recebimento de mensagens ou nalizao da comunicao, conforme ilustra a gura A.8.
Figura A.8: Processo de iniciao de comunicao com participante remoto

A classe Comunicao responsvel por representar trs funcionalidades do ambiente atravs do padro de projeto Composite : comunicao entre os participantes de uma determinada sala; comunicao de entrada do participante e comunicao de sada para um participante remoto. A gura A.9 a estrutura das classes relacionadas s comunicaes.
106
Figura A.9: Herana e Composio das comunicaes

Quando um participante deseja estabelecer a comunicao com outro, ele localiza o anuncio da comunicao de entrada do participante remoto, e estabelece uma comunicao de sada com esse participante. Somente depois de estabelecida essa comunicao que os participantes podem enviar mensagens uns aos outros.
Utilizao de Padres de Projeto i. Singleton : garante a existncia de uma nica instncia do Gestor; ii. Factory Method :
comunicaes; responsvel por construir objetos individuais para um propsito especco, neste caso, responsvel pela instanciao de
iii. Composite : compe objetos em estruturas do tipo rvore para representar

hierarquias, fazendo com que o tratamento dos objetos individuais e de suas composies seja uniforme, neste caso, torna uniforme o tratamento de comunicaes do participante e da sala;
A.2.5 Gesto de Localizao

O gestor de localizao o responsvel por procurar na rede P2P os anncios referentes s salas virtuais, aos participantes e aos arquivos que estejam sendo
107
Dependendo do tipo de anuncio, o contexto da busca pode
compartilhados.
ser diferente. A gura A.10 ilustra a funcionalidade de atualizar as salas e os participantes da Escola, que efetuada atravs de uma busca de anncios de participantes ou salas no grupo Escola.
Figura A.10: Localizao das salas e dos participantes do ambiente

Cada recurso que trafega pela rede deve implementar a interface Anuncio, responsvel por conter os anncios que sero enviados e recebidos pelos participantes da rede, funcionando basicamente como continer de dados, de modo que para descobrir os recursos que esto na rede, o usurio deve examinar os anncios que so recebidos aps enviar uma solicitao (busca) na rede atravs do Gestor de
Localizao.
A idia que quando novos recursos sejam adicionados ao arcabouo, estes possam ser facilmente integrado ao gestor de localizao atravs da denio de uma nova categoria de anncio, atravs da utilizao do padro Composite, conforme ilustra a gura A.11.
propsito especco, neste caso, responsvel pela instanciao de anncios;
iii. Composite : compe objetos em estruturas do tipo rvore para representar

hierarquias, fazendo com que o tratamento dos objetos individuais e de suas
108
Figura A.11: Herana e Composio dos anncios do ambiente

composies seja uniforme, neste caso, torna uniforme o tratamento dos anncios de arquivos compartilhados no ambiente, das comunicaes, dos participantes e das salas;
A.2.6 Gesto de Compartilhamento

A classe Compartilhamento responsvel por armazenar a lista de arquivos que esto sendo compartilhados. Esses arquivos podem estar sendo compartilhados em uma determinada sala ou para todos os participantes da escola. Essa classe fornece as funcionalidades de envio do arquivo e armazenamento do mesmo no disco rgido de um participantes remoto, aps a nalizao de um download.
propsito especco, neste caso, responsvel pela instanciao de arquivos que estejam sendo compartilhados no ambiente;
109
A.2.7 Gesto de Desempenho

Fornece as funcionalidades relacionadas com o clculo do RTT (round trip
time ) entre os participantes do ambiente, alm da vericao da capacidade de

processamento e da quantidade de memria RAM de um participante remoto.
Utilizao de Padres de Projeto i. Singleton : garante a existncia de uma nica instncia do Gestor;
Apndice
Cdigos do middleware JXTAula

Este apndice contm os trechos de cdigos do middleware JXTAula que so citados no captulo 4.
B.1 Relacionamento entre as classes do JXTAula e JXTA

A gura B.1 ilustra o relacionamento entre as classes que foram construidas no JXTAula e as diversas classes que foram utilizadas do JXTA. Classe ou interfaces que foi construda no
middleware
JXTAula:
ServicoP2PAbstrato ; AdaptadorJXTA; Boot ; Find ; GrupoP2P ; Group ; Peer ; ComunicacaoP2P ; ComunicacaoEntradaP2P ; ComunicacaoSaidaP2P.
Foram utilizadas as seguintes classes do JXTA: NetworkCongurator ;
RendezvousListener ; PeerGroup ; DiscoveryListener ; PipeAdvertisement ; InputPipe ; PipeMsgListener ; OutputPipe ; OutputPipeListener.
B.2 Classe Boot

B.2.1 Conguraes do peer
Os cdigos da classe Boot responsveis por criar as conguraes do participantes so ilustrados a seguir:
Cdigo B.1: Utilizao da classe NetworkCongurator

public c l a s s Boot implements R e n d e z v o u s L i s t e n e r {
NetworkConfigurator c o n f i g ;
B.2. Classe Boot
111
Figura B.1: Diagrama de classes do Middleware JXTAula

private f i n a l s t a t i c F i l e home = new F i l e ( System . g e t P r o p e r t y
5
( " JXTA_HOME " , ".jxtaula" ) ) ; F i l e instanceHome ; PeerGroup netpg ;
public void c r i a r C o n f i g u r a c a o P 2 P ( S t r i n g l o g i n , S t r i n g senha )
B.2. Classe Boot
112
10
throws E x c e p t i o n { try {
// Fazer c o n f i g u r a e s
c o n f i g = new N e t w o r k C o n f i g u r a t o r ( ) ; instanceHome = new F i l e ( home , l o g i n ) ;
15
c o n f i g . setHome ( instanceHome ) ;
if (! config . exists () ) {
System . out . p r i n t l n ( "No existe arquivo de configurao , criando ... HOME = "+home ) ; c o n f i g . s e t P e e r I D ( IDFactory . newPeerID ( PeerGroupID . defaultNetPeerGroupID ) ) ; c o n f i g . setName ( l o g i n ) ; c o n f i g . s e t D e s c r i p t i o n ( "Nome do Participante : "+l o g i n ) ; c o n f i g . setMode ( N e t w o r k C o n f i g u r a t o r .EDGE_NODE) ; config . setPrincipal ( login ) ; c o n f i g . s e t P a s s w o r d ( senha ) ; try { c o n f i g . addRdvSeedingURI ( new URI ( "http :// rdv. jxtahosts .net/cgi -bin/ rendezvous .cgi ?2" ) ) ; c o n f i g . addRelaySeedingURI ( new URI ( "http :// rdv. jxtahosts .net/cgi -bin/relays.cgi ?2" ) ) ; } catch ( j a v a . n e t . URISyntaxException u s e ) { use . printStackTrace ( ) ; } try { c o n f i g . save ( ) ; System . out . p r i n t l n ( "Arquivo de configurao criado" ) ; } catch ( IOException i o ) { io . printStackTrace () ; } } els e { config . load () ; } } catch ( E x c e p t i o n e ) { throw new E x c e p t i o n ( " criarConfiguracaoP2P - No foi possvel criar as configuraes do JXTA" ) ; } } }
20
25
30
35
40
45
50
B.2. Classe Boot
113
B.2.2 Ingresso no grupo principal

Os cdigos da classe Boot responsveis por entrar no grupo principal do JXTA so ilustrados a seguir:
Cdigo B.2: Entrar no grupo principal do JXTA (NetPeerGroup)

public c l a s s Boot implements R e n d e z v o u s L i s t e n e r {
// Entrar no grupo p r i n c i p a l do JXTA > NetPeerGroup
5
public PeerGroup i n i c i a l i z a r S e r v i c o P 2 P ( ) throws E x c e p t i o n { try { NetPeerGroupFactory f a c t o r y = new NetPeerGroupFactory

( ( ConfigParams ) c o n f i g . g e t P l a t f o r m C o n f i g ( ) , instanceHome . toURI ( ) ) ; PeerGroup netpg = f a c t o r y . g e t I n t e r f a c e ( ) ; RendezVousService r e n d e z v o u s = netpg . g e t R e n d e z V o u s S e r v i c e ( ) ;
10
r e n d e z v o u s . a d d L i s t e n e r ( this ) ;
return netpg ; } catch ( E x c e p t i o n e ) {

e . printStackTrace () ;
throw new E x c e p t i o n ( " inicializarServicoP2P - No foi

15
possvel criar as configuraes do JXTA" ) ; } }
public synchronized void ren dez vous Eve nt ( RendezvousEvent e v e n t )

20
i f ( e v e n t . getType ( ) == RendezvousEvent .RDVCONNECT | |

e v e n t . getType ( ) == RendezvousEvent .RDVRECONNECT ) { System . out . p r i n t l n ( "Evento recebido de RENDEZVOUS -
CONECTADO " ) ;
25
c o m L i s t e n e r . conectadoSuperNo ( ) ; } } }
B.3. Classe Group
114
B.3 Classe Group

B.3.1 Manuteno de salas
A classe Group fornece os mtodos de criar e remover PeerGroups, bem como para entrar e sair de um determinado PeerGroup. Os cdigos responsveis por essas funcionalidades so demonstrados a seguir:
Cdigo B.3: Criao, remoo, entrada e sada em grupos

public c l a s s Group {
PeerGroup c r i a r G r u p o ( PeerGroup parentpg , S t r i n g grupo , S t r i n g d e s c )
5
throws E x c e p t i o n { try {
ModuleImplAdvertisement implAdv = parentpg . getAllPurposePeerGroupImplAdvertisement ( ) ;
// Cria p e e r g r o u p
10
PeerGroup grupopg = p a r e n t p g . newGroup ( grupoID ( grupo ) , implAdv , grupo , d e s c ) ;
// P u b l i c a r anuncio
publicarNoGrupo ( parentpg , grupopg . getPeerGroupAdvertisement () ) ;
15
System . out . p r i n t l n ( "Grupo Criado:
20
"+grupopg . getPeerGroupName ( )+" "+grupopg . getPeerGroupID ( ) ) ; return grupopg ; } catch ( E x c e p t i o n e ) { throw new E x c e p t i o n ( "Erro ao criar Grupo: "+grupo ) ; } }
void removerGroupCache ( PeerGroup grupopg ) throws E x c e p t i o n {

grupopg . getParentGroup ( ) . g e t D i s c o v e r y S e r v i c e
25
( ) . f l u s h A d v e r t i s e m e n t ( grupopg . getPeerGroupAdvertisement ( ) ) ; }
void l o g i n ( PeerGroup group , S t r i n g l o g i n , S t r i n g password ) throws

Exception {
30
try {
S t r i n g A u t h e n t i c a t o r auth = null ; MembershipService membership = group . g e t M e m b e r s h i p S e r v i c e ( ) ;
B.3. Classe Group
115
C r e d e n t i a l c r e d = membership . g e t D e f a u l t C r e d e n t i a l ( ) ;
35
i f ( c r e d == null ) {
A u t h e n t i c a t i o n C r e d e n t i a l authCred = new A u t h e n t i c a t i o n C r e d e n t i a l ( group , " StringAuthentication " , null ) ;
try {
auth = ( S t r i n g A u t h e n t i c a t o r ) membership . apply
40
( authCred ) ; } catch ( E x c e p t i o n f a i l e d ) { } // c o n t i n u a
i f ( auth != null ) {
auth . setAuth1_KeyStorePassword ( password . toCharArray
45
() ) ; auth . s e t A u t h 2 I d e n t i t y ( group . getPeerID ( ) ) ; auth . s e t A u t h 3 _ I d e n t i t y P a s s w o r d ( password . toCharArray () ) ;
50
i f ( auth . i s R e a d y F o r J o i n ( ) ) {
membership . j o i n ( auth ) ; } els e {
throw new E x c e p t i o n ( "Erro ao entrar na sala

55
60
"+group . getPeerGroupName ( )+ " com credencial "+l o g i n ) ; } } } } catch ( E x c e p t i o n e ) { throw new E x c e p t i o n ( "Erro ao entrar na sala "+group . getPeerGroupName ( )+ " com credencial "+l o g i n ) ; } }
65
public void l o g o u t ( PeerGroup group ) throws E x c e p t i o n

{
try {
MembershipService membership = group . g e t M e m b e r s h i p S e r v i c e ( ) ;
70
membership . r e s i g n ( ) ; } catch ( E x c e p t i o n e ) {
throw new E x c e p t i o n ( "Erro ao sair da sala

"+group . getPeerGroupName ( ) ) ; } }
75
B.3. Classe Group
116
PeerGroupID grupoID ( S t r i n g grupo ) throws E x c e p t i o n {
try {
M e s s a g e D i g e s t md = M e s s a g e D i g e s t . g e t I n s t a n c e ( "MD5" ) ;
80
byte [ ] t e x t = md. d i g e s t ( grupo . g e t B y t e s ( ) ) ; return ( PeerGroupID ) IDFactory . newPeerGroupID ( t e x t ) ; } catch ( E x c e p t i o n ns ) { throw new E x c e p t i o n ( "Erro ao criar o ID do grupo "+grupo ) ;
} }
85
s t a t i c void publicarNoGrupo ( PeerGroup grupopg , A d v e r t i s e m e n t Adv) throws E x c e p t i o n

{
90
grupopg . g e t D i s c o v e r y S e r v i c e ( ) . p u b l i s h (Adv) ; grupopg . g e t D i s c o v e r y S e r v i c e ( ) . r e m o t e P u b l i s h (Adv) ; } }
B.3.2 Grupos no ambiente P2P

No JXTAula, tanto as salas virtuais, como a Escola, so representaes de uma classe denominada GrupoP2P, que herdam, para o caso do JXTA, as caractersticas da classe denominada PeerGroup. Como todo PeerGroup contm algumas funcionalidades bsica, denominadas servios, que esto disponveis para serem utilizados pelos peers da rede JXTA, as salas virtuais e a Escola possuem tais servios. Exemplos desses servios so: Descoberta (Discovery) e Troca de Mensagens (Pipes).
Cdigo B.4: Grupos do JXTAula baseado em PeerGroups

public c l a s s GrupoP2P { protected PeerGroup grupopg ; protected S t r i n g nome ; protected S t r i n g d e s c ; protected GrupoP2P ( GrupoP2P g ) { this . grupopg = g . grupopg ; this . nome = g . nome ; this . d e s c = g . d e s c ;
10
B.4. Classe Find
117
} GrupoP2P ( PeerGroup pg ) { grupopg = pg ;

15
nome = pg . getPeerGroupAdvertisement ( ) . getName ( ) ; d e s c = pg . getPeerGroupAdvertisement ( ) . g e t D e s c r i p t i o n ( ) ; }
20
public S t r i n g getNome ( ) { return nome ;

}
public S t r i n g g e t D e s c ( ) { return d e s c ;
25
} }
B.4 Classe Find

B.4.1 Buscas baseadas no protocolo PDP do JXTA
O JXTAula utiliza o protocolo PDP para descobrir as salas criadas na Escola e os participantes da Escola, pois nestes casos necessrio guardar os anncios dessas entidades na cache local :
Cdigo B.5: Buscas por grupos e participantes do ambiente

public c l a s s Find {
GrupoP2P l o c a l i z a r G r u p o ( PeerGroup grupopg , S t r i n g grupo ) {
int count = 3 ;
5
Enumeration ae = null ;
while ( count > 0 ) { try {

ae = l o c a l i z a r G r u p o C a c h e ( grupopg , grupo ) ;
10
i f ( ( ae != null ) && ae . hasMoreElements ( ) ) break ; // Achou

l o c a l i z a r G r u p o R e m o t o ( grupopg , grupo ) ;
// Espera um tempo para p e r m i t i r que os p e e r s respondam

15
a consulta
B.4. Classe Find
118
try {
Thread . s l e e p ( P2PConfig . t i m e o u t ) ; } catch ( I n t e r r u p t e d E x c e p t i o n i e ) {} } catch ( E x c e p t i o n e ) {
20
System . out . p r i n t l n ( "Erro ao enviar o comando de
localizao : "+grupo ) ; } }
25
i f ( ae == null | | ! ae . hasMoreElements ( ) ) return null ; el se { // Encontrou a l g u n s na l i s t a try {

PeerGroupAdvertisement grupoAdv = ( PeerGroupAdvertisement ) ae . nextElement ( ) ;
30
PeerGroup pgp ( grupoAdv . getPeerGroupID ( ) ) ;
= grupopg . newGroup
return new GrupoP2P ( pgp ) ; } catch ( E x c e p t i o n e ) { return null ;

35
} } }
40
public Vector<AnuncioSala> l o c a l i z a r T o d o s G r u p o ( PeerGroup grupopg ) throws E x c e p t i o n { Enumeration ae = null ; try {

l o c a l i z a r G r u p o R e m o t o ( grupopg ) ;
// Espera um tempo para p e r m i t i r que os p e e r s respondam a

45
consulta
try {
Thread . s l e e p ( P2PConfig . t i m e o u t ) ; } catch ( I n t e r r u p t e d E x c e p t i o n i e ) {} ae = l o c a l i z a r G r u p o C a c h e ( grupopg ) ;
50
} catch ( E x c e p t i o n e ) { System . out . p r i n t l n ( "Erro ao enviar o comando de
localizao : Todas as salas da escola" ) ; }

55
i f ( ae == null | | ! ae . hasMoreElements ( ) ) return null ; el se { // Encontrou grupo try {
B.4. Classe Find
119
Vector<AnuncioSala> g r u p o s = new Vector<AnuncioSala>
() ;
60
while ( ae . hasMoreElements ( ) ) {
PeerGroupAdvertisement grupoAdv = ( PeerGroupAdvertisement ) ae . nextElement ( ) ; PeerGroup gpg ( grupoAdv . getPeerGroupID ( ) ) ; = grupopg . newGroup
65
g r u p o s . add ( new AnuncioSala ( new GrupoP2P ( gpg ) ) ) ; }
return g r u p o s ; } catch ( E x c e p t i o n e ) { throw new E x c e p t i o n ( "Erro ao listar todas as salas da

70
escola" ) ;
} } }
75
public Vector<A n u n c i o P a r t i c i p a n t e > l o c a l i z a r T o d o s P a r t i c i p a n t e s ( PeerGroup grupopg , S t r i n g l o g i n ) throws E x c e p t i o n { Enumeration ae = null ; try {

System . out . p r i n t l n ( grupopg . getPeerGroupName ( )+" -
80
85
90
"+grupopg . getPeerGroupID ( ) . t o S t r i n g ( ) ) ; l o c a l i z a r P e e r R e m o t o ( grupopg ) ; // Espera um tempo para p e r m i t i r que os p e e r s respondam a consulta try { Thread . s l e e p ( P2PConfig . t i m e o u t ) ; } catch ( I n t e r r u p t e d E x c e p t i o n i e ) {} ae = l o c a l i z a r P e e r C a c h e ( grupopg ) ; } catch ( E x c e p t i o n e ) { System . out . p r i n t l n ( "Erro ao enviar o comando de localizao : Todos os participantes da escola" ) ; }
95
i f ( ae == null | | ! ae . hasMoreElements ( ) ) return null ; el se { // Encontrou p e e r try { Vector<A n u n c i o P a r t i c i p a n t e > p a r t i c i p a n t e s = new

Vector<A n u n c i o P a r t i c i p a n t e >() ;
while ( ae . hasMoreElements ( ) ) {
P e e r A d v e r t i s e m e n t peerAdv =
B.4. Classe Find
120
100
( P e e r A d v e r t i s e m e n t ) ae . nextElement ( ) ; A n u n c i o P a r t i c i p a n t e ap = new A n u n c i o P a r t i c i p a n t e ( peerAdv . getName ( ) , peerAdv . getPeerID ( ) . t o S t r i n g ( ) ,
null ) ; i f ( p a r t i c i p a n t e s . c o n t a i n s ( ap ) == f a l s e )
105
p a r t i c i p a n t e s . add ( ap ) ;
i f ( peerAdv . getName ( ) . compareTo ( l o g i n ) !=

0) { removerPeerCache ( grupopg , peerAdv ) ;
110
} }
return p a r t i c i p a n t e s ; } catch ( E x c e p t i o n e ) { throw new E x c e p t i o n ( "Erro ao listar todos os

115
participantes da escola" ) ; } } }
// Funes a u x i l i a r e s
Enumeration l o c a l i z a r G r u p o C a c h e ( PeerGroup grupopg , S t r i n g grupo )
120
throws IOException { return grupopg . g e t D i s c o v e r y S e r v i c e ( ) .

125
g e t L o c a l A d v e r t i s e m e n t s ( D i s c o v e r y S e r v i c e .GROUP, "Name" , grupo ) ; }
void l o c a l i z a r G r u p o R e m o t o ( PeerGroup grupopg , S t r i n g grupo ) {

grupopg . g e t D i s c o v e r y S e r v i c e ( ) .
130
getRemoteAdvertisements ( null , D i s c o v e r y S e r v i c e .GROUP, "Name" , grupo , 5 0 , null ) ; } Enumeration l o c a l i z a r G r u p o C a c h e ( PeerGroup grupopg ) throws
135
IOException {
return grupopg . g e t D i s c o v e r y S e r v i c e ( ) .
g e t L o c a l A d v e r t i s e m e n t ( D i s c o v e r y S e r v i c e .GROUP, "Name" , P2PConfig . g e t N o m e S e r v i c o A b s t r a t o ( )+":*" ) ; }
140
void l o c a l i z a r G r u p o R e m o t o ( PeerGroup grupopg ) {
B.5. Classe Peer
121
grupopg . g e t D i s c o v e r y S e r v i c e ( ) .
getRemoteAdvertisements ( null , D i s c o v e r y S e r v i c e .GROUP, "Name" , P2PConfig . g e t N o m e S e r v i c o A b s t r a t o ( )+":*" , 5 0 , null ) ;

145
} Enumeration l o c a l i z a r P e e r C a c h e ( PeerGroup grupopg ) throws IOException {
return grupopg . g e t D i s c o v e r y S e r v i c e ( ) .
150
g e t L o c a l A d v e r t i s e m e n t s ( D i s c o v e r y S e r v i c e .PEER, null , null ) ; }
void removerPeerCache ( PeerGroup grupopg , P e e r A d v e r t i s e m e n t peerAdv ) throws IOException {

155
grupopg . g e t D i s c o v e r y S e r v i c e ( ) . f l u s h A d v e r t i s e m e n t ( peerAdv ) ; }
void l o c a l i z a r P e e r R e m o t o ( PeerGroup grupopg ) {

160
grupopg . g e t D i s c o v e r y S e r v i c e ( ) . getRemoteAdvertisements ( null , D i s c o v e r y S e r v i c e .PEER, null ,
null , 5 0 , null ) ;
}
165
Enumeration l o c a l i z a r C o m u n i c a c a o C a c h e ( PeerGroup grupopg ) throws IOException {
return grupopg . g e t D i s c o v e r y S e r v i c e ( ) . g e t L o c a l A d v e r t i s e m e n t s ( D i s c o v e r y S e r v i c e .ADV, null , null ) ;

}
170
void l o c a l i z a r C o m u n i c a c a o R e m o t a ( PeerGroup grupopg ) {

grupopg . g e t D i s c o v e r y S e r v i c e ( ) . getRemoteAdvertisements ( null , D i s c o v e r y S e r v i c e .ADV, null ,
null , 5 0 , null ) ;
175
} }
B.5 Classe Peer

O servio de troca de mensagens (pipe service ) obtido a partir de um peergroup do qual o participante seja um membro. Este servio prov as funcionalidades
B.5. Classe Peer
122
relacionadas criao de pipes de entrada e de sada, alm da criao das mensagens (objetos) que podem ser enviadas atravs dos pipes de sada e recebidas nos pipes de entrada.
B.5.1 A criao do canal de entrada

Processo de criao do canal de entrada do peer:
i. Cria-se o anncio de entrada do participante - no trecho de cdigo abaixo o

objeto: PipeAdvertisement meuAnuncio ;
ii. Cria-se o listener que vai escutar os eventos ocorridos neste pipe de entrada,
por exemplo, recebimento de mensagens - no trecho de cdigo abaixo o objeto: ComunicacaoEntradaP2P ce ;
iii. Cria-se o pipe de entrada - no trecho de cdigo abaixo, atravs do mtodo:

pg.getPipeService().createInputPipe(meuAnuncio, ce) ;
iv. Publica-se o anncio do pipe de entrada do participante - no trecho de cdigo

abaixo, atravs do mtodo: Group.publicarNoGrupo(pg, meuAnuncio);.
Cdigo B.6: Criao do canal de comunicao de entrada do participantes

public c l a s s Peer implements D i s c o v e r y L i s t e n e r {
ComunicacaoEntradaP2P c r i a r C o m u n i c a c a o P a r t i c i p a n t e P 2 P ( GestaoAmbiente ga , JXTAulaListener c l , PeerGroup pg , S t r i n g
5
comunicacao ) throws E x c e p t i o n {
try {
P i p e A d v e r t i s e m e n t meuAnuncio = ( P i p e A d v e r t i s e m e n t ) A d v e r t i s e m e n t F a c t o r y . newAdvertisement ( P i p e A d v e r t i s e m e n t . getAdvertisementType ( ) ) ;
10
meuAnuncio . s e t P i p e I D ( Boot . pipeID ( pg . getPeerGroupID ( ) , comunicacao ) ) ; meuAnuncio . setName ( comunicacao ) ; meuAnuncio . setType ( P i p e S e r v i c e . UnicastType ) ;
15
ComunicacaoEntradaP2P c e = new ComunicacaoEntradaP2P ( ga , c l , meuAnuncio ) ; I n p u t P i p e meuCanal = pg . g e t P i p e S e r v i c e ( ) . c r e a t e I n p u t P i p e ( meuAnuncio , c e ) ;
B.5. Classe Peer
123
c e . s e t C a n a l ( meuCanal ) ; Group . publicarNoGrupo ( pg , meuAnuncio ) ;
20
25
return c e ; } catch ( E x c e p t i o n e ) { throw new E x c e p t i o n ( "No foi possivel criar o canal de

comunicao de entrada do participante : "+comunicacao ) ; } }
30
B.5.2 O estabelecimento da comunicao

Para que haja troca de informao entre os participantes da rede, dever ser estabelecida uma comunicao entre os pipes de entrada e de sada dos peers. O processo de criao do canal de comunicao de sada com um determinado participante descrito a seguir:
i. feita uma pesquisa pelos canais de comunicao de todos os participantes; ii. Verica se o anncio do canal de comunicao do participante procurado foi
encontrado;
iii. Caso o mesmo tenha sido encontrado, cria-se uma comunicao com o canal
de comunicao do participante remoto.
Cdigo B.7: Criao do canal de comunicao de sada com participantes remotos

public c l a s s Peer implements D i s c o v e r y L i s t e n e r {
ComunicacaoSaidaP2P iniciarComunicacaoRemota ( C o m u n i c a c a o L i s t e n e r c l , PeerGroup grupopg , S t r i n g n o m e P a r t i c i p a n t e ) throws E x c e p t i o n {
5
AnuncioComunicacao ac ; Enumeration ae = null ;
try {
f i n d . l o c a l i z a r C o m u n i c a c a o R e m o t a ( grupopg ) ;
// Espera um tempo para p e r m i t i r que os p e e r s respondam a

10
consulta
try {
Thread . s l e e p ( P2PConfig . t i m e o u t ) ;
B.5. Classe Peer
124
} catch ( I n t e r r u p t e d E x c e p t i o n i e ) {} ae = f i n d . l o c a l i z a r C o m u n i c a c a o C a c h e ( grupopg ) ;
15
} catch ( E x c e p t i o n e ) { System . out . p r i n t l n ( "Erro ao enviar o comando de
localizao : Iniciar comunicacao com participante "+n o m e P a r t i c i p a n t e ) ; }

20
// V e r i f i c a t o d a s as comunicaes remotas que foram e n c o n t r a d a s
i f ( ae == null | | ! ae . hasMoreElements ( ) ) return null ; el se { while ( ae . hasMoreElements ( ) ) {

P i p e A d v e r t i s e m e n t adv ;
25
try {
adv = ( P i p e A d v e r t i s e m e n t ) A d v e r t i s e m e n t F a c t o r y . newAdvertisement (
new MimeMediaType ( "text/xml" ) , new ByteArrayInputStream ( ae . nextElement

30
() . toString () . getBytes () ) ) ; } catch ( E x c e p t i o n e ) { continue ; }
// V e r i f i c a s e o c a n a l de e n t r a d a o do p a r t i c i p a n t e procurado
i f ( ( adv . getName ( ) . toLowerCase ( ) . compareTo

35
( n o m e P a r t i c i p a n t e . toLowerCase ( ) ) ) == 0 ) {
try {
// Cria c a n a l de s a i d a com o u t r o P a r t i c i p a n t e
ComunicacaoSaidaP2P comsaida = new ComunicacaoSaidaP2P ( c l , n o m e P a r t i c i p a n t e , adv ) ;
40
grupopg . g e t P i p e S e r v i c e ( ) . c r e a t e O u t p u t P i p e ( adv , comsaida ) ;
return comsaida ; } catch ( E x c e p t i o n e ) { throw new E x c e p t i o n

( " Participante encontrado , mas no foi possvel estabelecer a
45
50
comunicacao com "+n o m e P a r t i c i p a n t e ) ; } } } } return null ; }

}
B.5. Classe Peer
125
B.5.3 Recebendo mensagens de outros participantes

A interface PipeMsgListener quem permite que sejam recebidos eventos do tipo
PipeMsgEvent de maneira assncrona. Um objeto que implemente esta interface deve

adicionar o mtodo pipeMsgEvent(PipeMsgEvent event). Este mtodo tem acesso ao objeto PipeMsgEvent, que recupera o objeto recebido no pipe atravs da funo
getMessage().
Os cdigos responsveis por essa funcionalidade so demonstrados a seguir:
Cdigo B.8: Recebimento e tratamento das mensagens recebidas

public c l a s s ComunicacaoEntradaP2P extends ComunicacaoP2P implements
PipeMsgListener {
// Receber Mensagem Chegou mensagem no Pipe : MeuCanal

5
public void pipeMsgEvent ( PipeMsgEvent e v e n t ) { Message msg=null ; try {

msg = e v e n t . getMessage ( ) ;
10
i f ( msg == null ) { return ;

} Mensagem mensagem = ( Mensagem ) e x t r a i r M s g ( msg ) ;
// P r o c e s s a r Mensagens i n t e r n a s :
15
i f ( ga . GestorComunicacao . processadorMensagem . processarMensagem ( mensagem . getDados ( ) , c o m L i s t e n e r ) != null ) {

// Neste caso uma Mensagem e x t e r n a
c o m L i s t e n e r . mensagemRecebida ( new ComunicacaoEvent ( this , mensagem . getDados ( ) , mensagem . getOrigem ( ) , mensagem . g e t D e s t i n o ( ) ) ) ;
// Evento e n v i a d a para a a p l i c a o
20
} } catch ( E x c e p t i o n e ) { e . printStackTrace () ;
return ;
}
25
// E x t r a i mensagem r e c e b i d a
public Object e x t r a i r M s g ( Message msg ) throws IOException ,

ClassNotFoundException {
30
S t r i n g nameSpace = "JXTAula" ; S t r i n g elemName = "Mensagem" ;
B.5. Classe Peer
126
InputStream i s = getInputStreamFromMessage ( msg , nameSpace , elemName ) ;

35
i f ( null == i s ) { return null ;

} ObjectInputStream o i s = new ObjectInputStream ( i s ) ;
return o i s . r e a d O b j e c t ( ) ;
40
public s t a t i c InputStream getInputStreamFromMessage ( Message message , S t r i n g nameSpace , S t r i n g elemName ) throws IOException { InputStream r e s u l t = null ;
45
MessageElement e l e m e n t = message . getMessageElement ( nameSpace , elemName ) ;
i f ( e l e m e n t . getMimeType ( ) . e q u a l s (GZIP_MEDIA_TYPE) ) { r e s u l t = new GZIPInputStream ( e l e m e n t . getStream ( ) ) ; } el se i f ( e l e m e n t . getMimeType ( ) . e q u a l s ( MimeMediaType .AOS) ) {

50
r e s u l t = e l e m e n t . getStream ( ) ; }
return r e s u l t ;
}
55
Assim, para que as aplicaes possam receber as mensagens enviadas atravs do JXTAula, foi criada a interface callback denominada JXTAulaListener. Atravs dessa interface, quando da ocorrncia de eventos, uma mensagem recebida direcionada aplicao para que a mesma possa trat-la da forma adequada.
Cdigo B.9: Interface utilizada para comunicao com a aplicao

public interface JXTAulaListener extends E v e n t L i s t e n e r { public public public public public
}
void void void void void
conectadoSuperNo ( ) ; mensagemRecebida ( ComunicacaoEvent e ) ; downloadCompleto ( S t r i n g s t r ) ; downloadErro ( S t r i n g s t r ) ; pingTime ( S t r i n g p a r t i c i p a n t e , S t r i n g RTT) ;
Apndice
Cdigos da integrao entre COGEST e JXTAula

Este apndice contm os trechos de cdigos relacionados a integrao entre COGEST e o middleware JXTAula que so citados no captulo 5.
C.1 Adaptaes no mtodo de envio e recepo de mensagens

C.1.1 Modelo Centralizado - Classe TCPConnectionManager
Para o caso do COGEST, a arquitetura do modelo de comunicao cliente-servidor baseada na criao de uma conexo socket entre o cliente e o servidor. A classe responsvel por prover as funcionalidades relacionadas essas funcionalidades a classe TCPConnectionManager.
Cdigo C.1: Classe que prov as funcionalidades de conexo entre o cliente e o servidor
public c l a s s TCPConnectionManager
{
private private private private private
Socket socket ; ObjectInputStream i n ; ObjectOutputStream out ; MessageHandler r e c e i v e r ;
boolean waitForMessage = f a l s e ;
10
public TCPConnectionManager ( MessageHandler r e c e i v e r , I n e t A d d r e s s host , int p o r t ) throws UnknownHostException , IOException
C.1. Adaptaes no mtodo de envio e recepo de mensagens
128
this ( r e c e i v e r , new S o c k e t ( host , p o r t ) ) ;

}
15
public TCPConnectionManager ( MessageHandler r e c e i v e r , S o c k e t

socket )
throws IOException {
20
this . r e c e i v e r = r e c e i v e r ; this . s o c k e t = s o c k e t ;
initStreams () ; }
25
public void s t a r t A u t o R e c e i v e ( )
{ Thread r e c e i v e T h r e a d =
new Thread (
30
new Runnable ( ) { public void
run ( ) { r e c e i v e ( ) ; } }
);
receiveThread . s t a r t () ; }
35
private void i n i t S t r e a m s ( ) throws IOException { out = new ObjectOutputStream ( new BufferedOutputStream ( s o c k e t . getOutputStream ( ) ) ) ;
out . f l u s h ( ) ;
40
i n = new ObjectInputStream (
new B u f f e r e d I n p u t S t r e a m (
socket . getInputStream ( ) ) ) ; }
45
public void send ( Object msg ) { try {

out . w r i t e O b j e c t ( msg ) ; out . f l u s h ( ) ;
50
catch ( IOException e ) {
r e c e i v e r . errorReport ( e ) ; }
129
}
55
public Object r e c e i v e M e s s a g e ( int t i m e o u t ) throws IOException , ClassNotFoundException

{ s o c k e t . setSoTimeout ( t i m e o u t ) ;
60
return i n . r e a d O b j e c t ( ) ;
}
private void r e c e i v e ( )
{
65
waitForMessage = true ;
while ( waitForMessage )
{
70
try {
re c e i v e r . receiveMessage ( receiveMessage (3000) ) ; }
75
catch ( SocketTimeoutException e ) { continue ;

}
catch ( E x c e p t i o n e ) {
re c e i v e r . errorReport ( e ) ;
break ;
80
} } closeConnection () ; }
85
public void d i s c o n n e c t ( )
{
i f ( waitForMessage )
waitForMessage = f a l s e ;
els e
90
closeConnection () ; }
private void c l o s e C o n n e c t i o n ( )
{
95
try {
130
in . close () ; out . c l o s e ( ) ; socket . close () ; }

100
catch ( IOException e ) {
r e c e i v e r . errorReport ( e ) ; } }
105
public S o c k e t g e t S o c k e t ( )
{
return s o c k e t ;
}
110
C.1.2 Modelo P2P - Classe P2PConnector

A classe TCPConnectionManager foi substituda pela classe P2PConnector, que utiliza as funcionalidades do JXTAula para prover o envio e recepo de mensagens baseado em um modelo de comunicao descentralizado. Neste novo cenrio, em vez das mensagens serem enviadas ao servidor de evento atravs do socket fornecido pela classe TCPConnectionManager, elas passam a ser enviadas para a sala atravs da funcionalidade enviarMensagemSala() fornecida pelo JXTAula.
Cdigo C.2: Classe que utiliza as funcionalidades do JXTAula

public c l a s s P2PConnector implements Connector , JXTAulaListener
{ JXTAula j x t a u l a = new JXTAula ( ) ;
5
Vector<S t r i n g > activeConn = new Vector<S t r i n g >() ; ServicoEleicao eleicao () ;
public void e n t r a r N a E s c o l a ( S t r i n g l o g i n , S t r i n g password ) throws E x c e p t i o n

10
{ j x t a u l a . i n i c i a l i z a r ( l o g i n , password , this ) ; }
131
15
public Vector<S t r i n g > getNomesDasSalas ( ) throws E x c e p t i o n

{
return j x t a u l a . g e t S a l a s E s c o l a ( ) ;
}
20
public S t r i n g g e t D e s c r i c a o D a S a l a ( S t r i n g roomName )
{
try { return j x t a u l a . g e t D e s c r i c a o S a l a ( roomName ) ;

} catch ( E x c e p t i o n e ) {
25
return e . getMessage ( ) ;
} }
30
public void c r i a r S a l a ( S t r i n g name , S t r i n g d e s c r i p t i o n ) throws E x c e p t i o n

{ j x t a u l a . c r i a r S a l a ( name , d e s c r i p t i o n ) ; }
35
public void e n t r a r N a S a l a ( S t r i n g roomName ) throws E x c e p t i o n

{ j x t a u l a . e n t r a r S a l a ( roomName ) ; S t r i n g c o o r d e n a d o r = e l e i c a o . getCoordenador ( ) ;
40
i f ( c o o r d e n a d o r . e q u a l s ( C l i e n t . s e t t i n g s . userName )
{
// s i g n i f i c a que a s a l a e s t a v a v a z i a
e o usurio atual
45
// passou a s e r o coordenador . porm ,

s e r n e c e s s r i o c r i a r uma c o n f i g u r a o para a s a l a . C l i e n t . manager . c r e a t e C o n f i g u r a t i o n ( roomName ) ; }
els e
50
/ Neste caso , o c l i e n t e apenas e n v i a s u a s configuraes

para o coordenador e aguarda r e s p o s t a para
construir
132
55
o ambiente l o c a l m e n t e . /
enviarMensagem ( coordenador , Client . getInformation () ) ; }
60
/
Envia a mensagem msg para o c l i e n t e userName . /
65
public void enviarMensagem ( S t r i n g userName , A bs tra ct Me ss ag e

msg ) {
try
{
i f ( ! activeConn . c o n t a i n s ( userName ) )
70
{ jxtaula . iniciarComunicacaoParticipante ( userName ) ; activeConn . add ( userName ) ; }
75
j x t a u l a . enviarMensagemParticipante ( userName , msg ) ; }
catch ( E x c e p t i o n e1 ) {
80
e1 . p r i n t S t a c k T r a c e ( ) ; } }
85
public void enviarMensagemSala ( A bs tr ac tM ess ag e msg )

{
try {
j x t a u l a . enviarMensagemSala ( j x t a u l a . g e t S a l a A t u a l ( ) , msg ) ;
90
} catch ( E x c e p t i o n e ) { e . printStackTrace () ; } }
95
public void s a i r D a E s c o l a ( )
{
133
jxtaula . sairEscola () ; }
100
public void s a i r D a S a l a A t u a l ( ) throws E x c e p t i o n

{
i f ( C l i e n t . manager . getConnectedRoomName ( ) != null )

j x t a u l a . s a i r S a l a ( C l i e n t . manager . getConnectedRoomName ( ) ) ;
105
public void s o l i c i t a r S e r v i c o ( Ab st rac tM es sa ge r e q u e s t ) throws

Exception {
110
j x t a u l a . enviarMensagemParticipante ( C l i e n t . manager . c o n f i g . coordenador , r e q u e s t ) } ;
115
public void mensagemRecebida ( ComunicacaoEvent e )

{ Abs tr ac tMe ss ag e msg = ( Ab st ra ct Mes sa ge ) e . getMensagem ( ) ;
switch ( msg . getType ( ) >> 6 )

120
case 0 : case 1 :
125
C l i e n t . manager . processSCM ( msg ) ;
break ;
C l i e n t . manager . processCCM ( msg ) ;
break ; default : break ;

} }
130
public void conectadoSuperNo ( ) {

JOptionPane . showMessageDialog ( null , " CONECTADO AO SUPER
N" ) ;
}
135
public void downloadCompleto ( S t r i n g s t r ) { JOptionPane . showMessageDialog ( null , "Download completo :

"+s t r ) ;
}
134
140
public void downloadErro ( S t r i n g s t r ) {

JOptionPane . showMessageDialog ( null , "Download
erro: "+s t r ) ; }
145
public void pingTime ( S t r i n g p a r t i c i p a n t e , S t r i n g RTT) { JOptionPane . showMessageDialog ( null , "Ping com

["+p a r t i c i p a n t e+"] : "+RTT) ; }
150
AUSTIN, C.; PAWLAN, M. Advanced Programming for the Java 2 Platform, chapter
5: Java Native Interface (JNI) Technology. [S.l.], Setembro 2000.

BACHMANN, F.; BASS, L.; CARRIERE, J.; CLEMENTS, P.; GARLAN, D.; IVERS, J.; NORD, R.; LITTLE, R. Software Architecture Documentation
in Practice: Documenting Architectural Layers. [S.l.], Maro 2000. Special

Report. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unied Modeling Language
User Guide. 1a . ed. [S.l.]:

0201571684.
Addison-Wesley Professional, 1998. ISBN
BOTELLA, P.; BURGUES, X.; FRANCH, X.; HUERTA, M.; SALAZAR, G. Modeling Non-Functional Requirements. 2001. Web. Disponvel em:
<http://citeseer.ist.psu.edu/botella01modeling.html>.
BROOKSHIER, D.; GOVONI, D.; KRISHNAN, N.; SOTO, J. C. JXTA: Java P2P
Programming. 1. ed. [S.l.]: Sams, 2002. ISBN 0-672-32366-4.

CASTRO, M.; DRUSCHEL, P.; KERMARREC, A.; ROWSTRON, A. Scribe: A large-scale and decentralized application-level multicast infrastructure. IEEE
JOURNAL, 2002.
CHRISTENSEN, H. B. Frameworks: Putting design patterns into perspective.
9th Annual SIGCSE Conference on Innovation and Technology in Computer Science Education, p. 142145, 2004.
135
136
CYSNEIROS, L.; LEITE, J. Using uml to reect non-functional requirements.
Requirements Proceedigns of the 11 CASCON, IBM Canada, pp:202-216, 2001.

DRUSCHEL, P.; ROWSTRON, A. Past: A large-scale, persistent peer-to-peer storage utility. Proc. HotOS VIII, Maio 2001. FREEPASTRY. FreePastry. Julho 2008. Web. A scalable, decentralized,
self-organizing and fault-tolerant substrate for peer-to-peer applications. GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns:
Elements of Reusable Object-Oriented Software. 1a . ed. [S.l.]: Addison-Wesley

Professional, 1995. ISBN 0201633612. GONG, L.; OAKS, S.; TRAVERSAT, B. JXTA in a Nutshell: A Desktop Quick
Reference. 1. ed. [S.l.]: OReilly Associates Inc, 2002. ISBN 0.

GRADECKI, J. D. Mastering JXTA: Building Java Peer-to-Peer Applications. [S.l.]: John Wiley & Sons, 2002. ISBN 0471250848. GROOVE. Groove Networks. Julho 2008. Web. The Groove virtual oce solutions using familiar tools, languages and development environments. H-ANIM/ISO/IEC. Humanoid Animation Working Group (H-Anim), ISO/IEC
FCD19774:200x,
Web3D
Consortium.
2008.
Web.
Disponvel
em:
<http://h-anim.org>.
HARASIN, L. On-line education: A new domain. Mindweave: Communication,
Computers and Distance Education, 1998.

ISO/IEC. ISO/IEC 9126: Software engineering - Product quality - Quality model. [S.l.], Setembro 1991. ISO/IEC. ISO/IEC 14598: Information Technology - Software Product Evaluation
- General overview. [S.l.], Setembro 1999.

JNGI. P2P Distributed Computing Framework. Julho 2008. Web. JNGI is a framework that users can use to submit jobs. These jobs are split and distributed among several peers. JOHNSON, R.; HOELLER, J.; ARENDSEN, A.; SAMPALEANU, C.; DAVISON, D.; KOPYLENKO, D.; RISBERG, T.; POLLACK, M. Spring - Java/J2EE
Application Framework. [S.l.], Outubro 2004. Reference Documentation.
137
JUNIOR, J. N. D. A. Garantia de Disponibilidade de Objetos Distribudos em
Redes P2P Utilizando Replicao Coordenada. Dissertao (Mestrado)

COPPE/Universidade Federal do Rio de Janeiro, Novembro 2005. JXTA. JXTA(TM) Community Projects. Julho 2008. Web. JXTA technology is a set of open protocols that enable any connected device on the network, ranging from cell phones and wireless PDAs to PCs and servers, to communicate and collaborate in a P2P manner. JXTA-CMS. A simple CMS implemtation for JXSE. Julho 2008. Web. The CMS is a simple JXTA service that builds o of other JXTA services such as the Resolver and Endpoint Messenger to allow les to be shared and searched for within a peergroup. LYRA, A.; LEITO, D.; AMORIM, G.; GOMES, A. Ambiente virtual para anlise de software educativo. Workshop Brasileiro de Informtica Educativa, 2003. MARTINS, R. X. Aprendizagem Cooperativa Via Internet - A Implantao de
Dispositivos Computacionais para a Viabilidade Tcnica de Cursos On-Line.

Dissertao (Mestrado) Universidade Federal de Santa Catarina, Outubro 2000. MICROSOFT. Microsoft Oce Groove 2007. Maro 2008. Web. One of the most exciting additions to 2007 Microsoft Oce System is the collaboration tool Oce Groove 2007. MICROSOFT. Pastry - A scalable, decentralized, self-organizing and fault-tolerant
substrate for peer-to-peer applications. Maro 2008. Web. Pastry is a generic,

scalable and ecient substrate for peer-to-peer applications. MICROSOFT. Peer Name Resolution Protocol. Maro 2008. Web. PNRP is an ecient, protected, low cost, dynamic protocol that uses an iterative, serverless method for name resolution. MICROSOFT. Windows Peer-to-Peer Networking. Maro 2008. Web. Windows Peer-to-Peer Networking is an operating system component that enables the creation of new peer-to-peer (P2P) applications. MYJXTA. A JXTA Technology based collaboration application. Julho 2008. Web. MyJXTA is a prototypical IM application based upon JXTA.
138
PERRONE, J. L. F. Proposta de um ambiente de educao distncia (educnet).
Fundao Visconde de Cairu, 2005.

QEMU. QEMU, a generic and open source machine emulator and virtualizer. 2008. Web. Disponvel em: <http://fabrice.bellard.free.fr/qemu/>. REALVNC. Virtual Network Computing (VNC) - RealVNC Ltd. 2008. Web. Disponvel em: <http://www.realvnc.com>. ROCHA, J.; DOMINGUES, M.; CALLADO, A.; SOUTO, E.; SILVESTRE, G.; KAMIENSKI, C.; SADOK, D. Peer-to-peer: Computao colaborativa na internet. Simpsio Brasileiro de Redes de Computadores, 2004. ROWSTRON, A.; DRUSCHEL, P. Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems. Proc. of the 18th IFIP/ACM
International Conference on Distributed Systems Platforms (Middleware 2001), Novembro 2001.

SAID, D.; RAMAMURTHY, G. B. New Practices in Flexible Learning, Groove
educational tool suite for Peer-to-Peer collaborative learning environments.

[S.l.], Setembro 2003. Technical specication manual for Role-Play tool. SOARES, J. M. Contribution la communication gestuelle dans les environnements
virtuels
collaboratifs.
Tese
(Doutorado)
Instituto
Nacional
de
Telecomunicaes da Frana, Setembro 2004. Tese apresentada para a obteno do grau de Doutor no Instituto Nacional de Telecomunicao. SOARES, J. M.; ANSELMO, F. J. M.; MATTOS, C. M. J.; MARCELINO, P. A. M.; BARROSO, G. C.; CORTEZ, P. C. Uma infra-estrutura para a colaborao distncia com suporte comunicao gestual. SEMISH - XXXIII Seminrio
Integrado de Software e Hardware, XXVI Congresso da Sociedade Brasileira de Computao, p. 418-432, 2006.
SOARES, J. M.; HORAIN, P.; BIDEAU, A. Sharing and immersing applications in a 3d virtual inhabited world. Laval Virtual 5th virtual reality international
conference, Laval, France, pp. 27-31., 2003.

TANENBAUM, A. S. Redes de Computadores. 4a . ed. Rio de Janeiro: Campus, 2003. ISBN 8535211853.
139
TAYLOR, I. J. From P2P to Web Services and Grids: Peers in a Client/Server
World. [S.l.]: Springer, 2004.

VIRTUALBOX. innotek VirtualBox, a family of powerful x86 virtualization
products. 2008. Web. Disponvel em: <http://www.virtualbox.org/>.

VMWARE. VMware:
Virtualization, Virtual Machine and Virtual Server
Consolidation. 2008. Web. Disponvel em: <http://www.vmware.com/>.

XIE, M. P2p systems based on distributed hash table. University of Ottawa, 2003.

Dissertacao ANDREPONTESSAMPAIO

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Dissertacao ANDREPONTESSAMPAIO

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal do Cear Centro de Tecnologia Departamento de Engenharia de Teleinformtica Programa de Ps Graduao em Engenharia de Teleinformtica

Andr Pontes Sampaio

Fortaleza  Cear Agosto 2008

Federal do Cear como parte dos obteno de Mestre

Andr Pontes Sampaio

Andr Pontes Sampaio Banca Examinadora:

Prof. Dr. Jos Neuman de Souza Orientador

Prof. Dr. Joaquim Celestino Jnior Universidade Estadual do Cear

Prof. Dr. Jos Marques Soares Universidade Federal do Cear

Lista de Figuras Lista de Tabelas Lista de Cdigos Lista de Siglas 1 Introduo

3 Denio do arcabouo JxAula

4 Estudo de caso: o middleware JXTAula

5 Integrao do middleware JXTAula a um sistema de EaD

6 Resultados obtidos e avaliao nal

7 Concluso e trabalhos futuros

Apndice A Padres de Projeto no arcabouo JxAula

Apndice B Cdigos do middleware JXTAula

Apndice C Cdigos da integrao entre COGEST e JXTAula

5.2 5.3 5.4 5.5 5.6 6.1

RMI RTT TCP VNC VPN TTL XML

i. Ausncia de controle central dos computadores participantes do ambiente

ii. Imprevisibilidade, tanto em nmero de participantes, quanto ao tempo que os

1.2. Estabelecimento da problemtica

P2P Networking (MICROSOFT, 2008d) e FreePastry (FREEPASTRY, 2008).

1.2 Estabelecimento da problemtica

1.3 Objetivos da Dissertao

i. Mapear as necessidades dos sistemas de ensino distncia e as funcionalidades

ii. Proporcionar servios de colaborao que supram as necessidades de alta

iii. Conrmar a possibilidade de se utilizar as arquiteturas P2P no fornecimento

1.4. Diviso do trabalho

com desempenho equivalente ou superior;

iv. Retirar da responsabilidade dos desenvolvedores de sistemas colaborativos a

v. Minimizar o custoso caminho entre a concepo e o desenvolvimento de

1.4 Diviso do trabalho

middleware possa ser alterado para se adaptar diferentes requisitos. Em seguida,

1.4. Diviso do trabalho

2.1 Estado da arte em Ensino Distncia

2.1. Estado da arte em Ensino Distncia

2.1.1 Modalidades dos sistemas de EaD

i. Aplicaes hipermdia para fornecer instruo distribuda : nesta modalidade

ii. Sites educacionais : Oferecem um conjunto de funcionalidades para uso

iii. Portais educativos : preocupam-se principalmente em distribuir informao

2.1. Estado da arte em Ensino Distncia

iv. Sistemas de autoria para cursos distncia : destacam-se por prover um

v. Salas de aula virtuais : ampliam o conceito de sistemas de autoria para cursos

chats e e-mails. O contedo desses cursos engloba imagens, textos, vdeos e

vi. Arcabouos (frameworks) para aprendizagem cooperativa : conjuntos integrados

vii. Ambientes distribudos para aprendizagem cooperativa : caracterizam-se por

2.1.2 Caractersticas dos ambientes para aprendizagem cooperativa

2.1. Estado da arte em Ensino Distncia

Aprendizagem Colaborativa : O estudante visto como um participante ativo

Os estudantes fazem anotaes regularmente, no

A aprendizagem no deve ser somente ativa, A construo de conhecimento se d quando os

2.1. Estado da arte em Ensino Distncia

Figura 2.1: Funcionalidades de um ambiente virtual de aprendizagem cooperativa

2.1.3 Enquadramento deste trabalho e funcionalidades fornecidas

i. O ambiente colaborativo deve ser capaz de organizar seus participantes em

2.1. Estado da arte em Ensino Distncia

iv. O ambiente virtual deve permitir que um participante do ambiente possa

v. Deve haver a possibilidade de compartilhar arquivos entre os participantes que

Comunicao interativa : possibilita a utilizao de servios de troca de

Colaborao e distribuio de contedo : possibilita o compartilhamento de

2.1. Estado da arte em Ensino Distncia

Fortaleza Cear Agosto 2008

3 Denio do arcabouo JxAula

6 Resultados obtidos e avaliao nal

iii. Conrmar a possibilidade de se utilizar as arquiteturas P2P no fornecimento

Figura 2.3: Protocolos da especicao do JXTA

Root Certicate - GRC ). Este certicado baseado no nome do grupo e na chave

Certicate - GMC ). A segurana nos grupos garante a integridade dos dados

Location ), conforme gura 2.6.

Figura 2.6: Identicadores PNRP (PNRP IDs )

Programming Interface) do Groove SDK (SAID; RAMAMURTHY, 2003). A gura

P2P, com o objetivo de identicar suas principais caractersticas e arquitetura.

i. Topologia da arquitetura : verica o tipo de topologia de rede que a plataforma

verica o tipo de mensagem trocada entre os

iii. Comunicao em grupo : verica se a plataforma P2P fornece este servio de

v. Segurana : verica se existem mecanismos para garantir a autenticidade e

vi. Compartilhamento de arquivos : verica se a plataforma disponibiliza esta