A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Google wave José Dihego Rafael Carício Rafael Bernardo

Apresentações semelhantes


Apresentação em tema: "Google wave José Dihego Rafael Carício Rafael Bernardo"— Transcrição da apresentação:

1 Google wave José Dihego Rafael Carício Rafael Bernardo

2 World

3 Wave “Universe”

4 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

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

6 Dispositivos Mobile (Android) Desktop Palmtop

7 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)

8 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

9 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).

10 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.

11 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.

12 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.

13 Diagrama de componentes OhCircus specication
Diagramas Diagrama de componentes OhCircus specication

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

15 Componentes e conectores

16 Módulo

17 Open Local Wave

18 Open Local Wave - Gadget

19 Open Remote Wave

20 Implantação

21 Modelo de dados

22 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,

23 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.

24 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.

25 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.

26 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.

27 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.

28 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.

29 Obrigado!


Carregar ppt "Google wave José Dihego Rafael Carício Rafael Bernardo"

Apresentações semelhantes


Anúncios Google