Google Wave (Arquitetura) Ademir Junior / Felipe Ferreira / Fernando Kakimoto.

Apresentação em tema: "Google Wave (Arquitetura) Ademir Junior / Felipe Ferreira / Fernando Kakimoto."— Transcrição da apresentação:

1 Google Wave (Arquitetura) Ademir Junior / Felipe Ferreira / Fernando Kakimoto

2 Visão de Implantação

3 Interfaces do Sistema

4 Visão Física  Cliente  Composto apenas pela máquina do usuário

5 Visão Lógica  Cliente

6 Visão Física  Provider

7 Disponibilidade do Serviço  Decisão  Como garantir que o serviço fique disponível mesmo em situações de falha ou de grande demanda  Restrição  Sistema deve ficar disponível 99% do tempo

8 Disponibilidade do Serviço  Alternativas  Replicação/Redundância  Uso de múltiplas instâncias com balanceamento de carga entre as instâncias  Servidor de Ponta dedicado  Uso de um servidor de alto desempenho dedicado  Efeitos  Custo da solução através da aquisição de equipamentos adicionais  Expectativa do usuário em relação ao tempo de resposta no uso do sistema

9 Armazenamento de Dados  Decisão  Correspondente à forma como os dados (waves e informações de usuários) serão persistidos no sistema  Restrições  Quando um dado é atualizado, este deve estar imediatamente disponível à todos os usuários  O sistema deverá permanecer disponível mesmo em caso de falhas e atualizações  O sistema será desenvolvido em Java

10 Armazenamento de Dados  Alternativas  Cassandra:  Agrupa tecnologias do Dynamo  Modelo de dados do Bigtable  Eventually Consistent  Hbase  Implementação open-source do Bigtable  Sub-projeto do Apache Hadoop  Desenvolvido em Java

11 Armazenamento de Dados  Alternativas (Cont.)  Hypertable  Implementação open-source do Bigtable  Pode ser integrado a diversos sistemas de arquivos  Desenvolvido em C++  Efeitos  Utilização de uma instância do Hadoop Distributed File System  Servidores para rodar os componentes do Hbase

12 Visão Lógica  Front-End

13 Visão Lógica  Server

14 Controle de Concorrência  Decisão  Resolução de conflitos durante a edição colaborativa de uma wave/wavelet por mais de um usuário ativo ao mesmo tempo.  Restrições  Consistência: todos os usuários ativos deverão estar com a versão atualizada do documento.  Performance: baixa latência nas atualizações dos dados.

15 Controle de Concorrência  Restrições (Cont.)  Disponibilidade: o documento deve estar disponível mesmo em caso de conflito.  Cliente Otimista: cliente sempre assume que o servidor aceitou a atualização dos dados.  Controle de versão dos documentos para o uso do play back.

16 Controle de Concorrência  Alternativas  Controle de concorrência Otimista  Não bloqueia os recursos (lock-free).  Modificações dos usuários são desfeitas em caso de conflito.  Lock  Para fazer qualquer modificação é necessário adquirir um lock do objeto.  Demora muito no tempo de resposta.  Perigo de deadlock.

17 Controle de Concorrência  Alternativas (Cont.)  Timestamps  Método não baseado em lock.  Transações executadas pela ordem de timestamp.  Problema na consistência dos dados.  Transformações operacionais (OT)  Framework de controle de concorrência (lock-free).  Suporte a edição colaborativa de documentos de texto simples.  Capacidade de resolução de conflito.  Edição de documentos de forma estruturada em XML.

18 Controle de Concorrência  Efeitos  A escolha de transformações operacionais (OT) como controle de concorrência não terá nenhum impacto nos requisitos dos stakeholders.

19 Sequência – Visualizar Wave

20 Sequência – Atualizar Wave

21 Sequência – Atualizar Wave Remota

22 Google Wave (Arquitetura) Ademir Junior / Felipe Ferreira / Fernando Kakimoto