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

Visão de Implantação

Interfaces do Sistema

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

Visão Lógica  Cliente

Visão Física  Provider

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

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

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

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

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

Visão Lógica  Front-End

Visão Lógica  Server

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.

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.

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.

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.

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.

Sequência – Visualizar Wave

Sequência – Atualizar Wave

Sequência – Atualizar Wave Remota

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