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

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

José Dihego Rafael Carício Rafael Bernardo

Apresentações semelhantes


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

1 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

14 Google Wave Architecture

15 Diagrama de componentes OhCircus specication

16 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, Desempenho.

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

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

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

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

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

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

23 Obrigado!


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

Apresentações semelhantes


Anúncios Google