Google wave José Dihego Rafael Carício Rafael Bernardo {jdso,rjcf,rbdb}@cin.ufpe.br 

Email World

Wave “Universe”

Características[1] Lista de usuários Chats colaborativos, grupais/privados Pós-editaveis Playback exibe história do conteúdo Albuns(imagens, vídeos) Sincronização automática atômica(caracter a caracter, foto a foto) Identificação pontual autor-edição

Características[2] Troca de conteúdos entre waves (albuns, chats) Desenvolvido usando Google Web Toolkit

Dispositivos Mobile (Android) Desktop Palmtop

Extensions Check spelling Gadgets Games (xadrez, Sudoku Puzzle) Google maps Vídeos Youtube Integração com blogs Pool wave Twitter wave Bugzila wave Inside translate ... (entre outras)

Requisitos Criar uma nova wave Adicionar/remover participantes Editar contéudo(vídeo,fotos,texto) Edição de conteudo intregada ao google search Share media, discussion groups, blogs, games Sincronização de todos os tipos de media

Requisitos Não-funcionais Usabilidade: Sistema com interface intuitiva, drag-and-drop para usuários, documentos e widgets; Os usuários não devem precisar de mais de 3 cliques para realizar uma operação. Extensibilidade: Extensível a novas funcionalidades (widgets e robots); Deve-se possibilitar a criação e deployment do novo plugin em tempo de execução (sem necessidade de reiniciar o servidor).

Requisitos Não-funcionais Portabilidade: Deve ser possível acessar o sistema com o uso de dispositivos móveis (celulares, tablets) com acesso a internet. Disponibilidade: O sistema deve estar disponível 99,999% do tempo, pois poderá ser de utilização crítica para uma organização cliente.

Requisitos Não-funcionais Tolerante a falhas: Deve retornar ao ar automaticamente quando algum erro ocorrer. Escalabilidade: O sistema deve ser distribuído em diversas máquinas. Segurança: Permitir comunicação segura entre os provedores de wave. Ter controle de acesso dentro dos wavelets.

Requisitos Não-funcionais Independência de plataforma: As tecnologias utilizadas no desenvolvimento do sistema deve estar disponível para uso em Linux, Windows e Mac OSX. Isso permitirá aos providers escolherem qual sistema operacional desejam utilizar. Descentralização: As partes do sistema (providers) devem funcionar de forma independente. Desempenho: O sistema não deve demorar mais que 3 segundos para carregar uma tela.

Diagrama de componentes OhCircus specication Diagramas Diagrama de componentes OhCircus specication

Google Wave Architecture Rafael Jacinto, adicionar o tipo de comunicação com o banco 14

Componentes e conectores

Módulo

Open Local Wave

Open Local Wave - Gadget

Open Remote Wave

Implantação

Modelo de dados

Decisões Arquiteturais Linguagem para o Backend- Java Prós: Independente de plataforma, Grande aceitação na comunidade, Portabilidade. Contra: Desempenho. Requisitos afetados: Portabilidade, Independência de plataforma,

Decisões Arquiteturais Utilização de Java + Flex para implementação do Frontend. Prós: Flexibilidade nas interfaces gráficas e menor tempo de desenvolvimento. Alternativa: Ajax Requisitos afetados: Usabilidade, Extensibilidade, Portabilidade.

Decisões Arquiteturais Utilização do protocolo Jabber/XMPP Prós: Comunicação descentralizada. Vários servidores são utilizados para a comunicação entre diversas entidades. Não há um ponto central de falha. Permite chamadas de voz e vídeo, colaboração, integrações, distribuição de conteúdo e roteamento de dados XML. Permite autenticação e checagem de integridade. Requisitos afetados: Descentralização, Tolerante a falhas, Escalabilidade, Segurança.

Decisões Arquiteturais Utilização do Transport Layer Security (TLS) Prós: Permite o estabelecimento de uma conexão segura entre um "cliente e um servidor". Assegura que a comunicação não é alterada em trânsito. Requisitos afetados: Segurança.

Decisões Arquiteturais Não-utilização de um banco de dados distribuído e não-relacional (BigTable like) Prós: Permite facilmente evolução do sistema (mudança do esquema dos dados), rápida manipulação de dados e replicação de dados é automática quando definidos os clusters. Contras: Tecnologia nova (revisão dos conceitos de armazenamento de dados existentes), Adaptação de bibliotecas de terceiros para acesso a os dados armazenados. Sistemas em desenvolvimento e com problemas de ponto de falha graves (centralização). Não existe garantia de integridade de dados (propriedades ACID). Requisitos afetados: Escalabilidade, Tolerância a falha, Descentralizado, Disponibilidade.

Decisões Arquiteturais Utilização de banco de dados relacional Prós: Garantia das propriedades ACID (Atomicity, Consistency, Isolation, Durability), rápido acesso e manipulação de dados, tecnologia madura e amplamente utilizada. Contras: Difício configuração de clusters para replicação de dados, alto custo de manutenção (tempo e dinheiro), evolução de esquema é feita de forma semi-automática ou manual. Requisitos afetados: Escalabilidade, Tolerância a falha, Descentralizado, Disponibilidade.

Decisões Arquiteturais Escolha do RDBMS: Escolha entre os RDBMS mais utilizados pelo mercado: MySQL: Velocidade de manipulação de dados, possibilidade de suporte pela empresa que criou (pago). PostgreSQL Muitos plugins para domínios específicos como Data Warehousing e Geo. Escolhido MySQL: Acesso aos dados é um requisito crítico do sistema.

Obrigado!