Arquitetura-Google-Wave-Parte2

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


Servidor de Ponta dedicado


Uso de múltiplas instâncias com balanceamento de carga entre as
instâncias
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