Implantao Personalizvel e Extensvel para Aplicaes Mobile/Cloud

Irene Zhang
Adriana Szekeres
Dana Van Aken
Isaac Ackerman
Steven D. Gribble*
Arvind Krishnamurthy
Henry M. Levy
Universidade de Washington

Resumo
As aplicaes modernas enfrentam novos desafios na gesto de ambiente altamente distribudo e heterogneo de hoje. Por
exemplo, eles devem unir cdigo que atravessa smartphones, tablets, dispositivos pessoais e servios de nuvem, ligados por
variveis redes de longa distncia, tais como Wi-Fi e 4G. Este artigo descreve a Sapphire, uma plataforma de programao
distribuda que simplifica a programao de aplicaes mveis / nuvem de hoje. O recurso de design chave da Sapphire o
seu sistema de execuo distribuda, que suporta uma flexvel e extensvel camada de implantao para resolver tarefas de
sistemas distribudos complexos, tais como a tolerncia a falhas, cdigo-descarregamento e armazenamento em cache. Ao
invs de escrever cdigo de sistemas distribudos, os programadores escolhem gerentes de implantao que se estendem do
kernel do Sapphire para atender aos requisitos de implantao de seus aplicativos. Desta forma, cada aplicativo
executado em uma plataforma subjacente que customizado para suas prprias necessidades de distribuio.

Introduo

Em menos de uma dcada, a paisagem de computao passou por duas mudanas revolucionrias: o desenvolvimento de
dispositivos mveis pequenos, mas extremamente poderosos, e a mudana para a computao em nuvem em escala macia.
Essas mudanas levaram a uma mudana de aplicaes desktop tradicionais para aplicaes mveis / nuvem modernas.
Como consequncia, as aplicaes modernas tornaram-se inerentemente distribudas, com dados e cdigo espalhados
por backends na nuvem e dispositivos de usurios, tais como telefones e tablets. Programadores de aplicativos enfrentam
novos desafios que eram visveis apenas para projetistas de sistemas distribudos de larga escala no passado. Entre eles
esto coordenando dados compartilhados entre vrios dispositivos e servidores, o descarregamento de cdigo a partir de
dispositivos para a nuvem, e integrao de componentes heterogneos com pilhas de software muito diferentes e recursos de
hardware.
Para enfrentar esses desafios, os programadores devem fazer inmeras decises de desenvolvimento distribudos, tais
como:
Onde os dados e computao devem estar localizados
Quais dados devem ser replicados ou armazenada em cache
Qual nvel de consistncia de dados necessrio.
Estas decises dependem de requisitos de aplicao - como a escalabilidade e tolerncia a falhas - que foram desempenho
difcil vs. funo trade-offs. A dependncia entre os requisitos de aplicao e decises de implantao leva programadores
para misturar decises de implantao com a lgica de aplicao complexa no cdigo, o que torna as aplicaes mobile /
nuvem difcil de implementar, depurar, manter e evoluir. Pior ainda, a rpida evoluo dos dispositivos, redes, sistemas e
aplicaes significa que os trade-offs que o impacto destas decises de implementao esto em movimento constante. Por
todas estas razes, os programadores precisam de uma forma flexvel sistema que permite que elas facilmente criar e
modificar as implementaes de aplicativos distribudos sem a necessidade de reescrever partes principais de sua
aplicao.
Este artigo apresenta Sapphire, uma plataforma de programao distribuda de propsito geral que simplifica muito o
design e implementao de aplicaes abrangendo dispositivos mveis e nuvens. Sapphire remove grande parte da
complexidade do gerenciamento de um ambiente multi-plataforma de rea ampla, mas ainda fornece aos desenvolvedores o
controle fine grained necessria para atender s necessidades de aplicaes crticas. Um conceito-chave do projeto de
Sapphire a separao da lgica de aplicao da lgica de implantao. Ou seja, cdigo de implantao est consignado
fora do cdigo do aplicativo, permitindo ao programador se concentrar na lgica da aplicao. Ao mesmo tempo, o
programador tem total controle sobre decises de implantao e flexibilidade para personaliz-los.

A arquitetura de Sapphire facilita essa separao com um sistema - kernel/tempo de execuo - distribudos altamente
extensvel. Na camada inferior, o Kernel de desenvolvimento Sapphire (DK Deployment Kernel) integra heterogneos
dispositivos mveis e servidores de nuvem atravs de um conjunto de mecanismos de baixo nvel comuns, incluindo a
comunicao de melhores esforos RPC(Chamadas de Processo Remoto), deteco de falhas, e encontrar localizao. Entre
o kernel e o aplicativo uma camada de implantao - Uma coleo de plugveis Gerentes de implantao (DM
Deployment Manager), mdulos que estendem o kernel para suportar necessidades de implantao de aplicaes
especficas, tais como replicao e cache. DMs so escritas de uma forma genrica, a aplicao transparente, usando
interposio para interceptar eventos de aplicativos importantes, tais como chamadas RPC. A DK fornece um poderoso
ambiente distribudo simples execuo e API para DMs que os torna extremamente fcil de escrever e estender.
Conceitualmente, arquitetura DM/DK do Sapphire cria um sistema de tempo de execuo distribudos sem costura que
personalizado especificamente para as necessidades de cada aplicao.
Ns implementamos um prottipo Sapphire em servidores Linux, telefones celulares e tablets Android. O prottipo
inclui uma biblioteca de 26 gerentes de implantao suportando uma ampla gama de tarefas de gerenciamento distribudos,
tais como consistente cache do cliente, as transaes durveis, replicao de Paxos e descarregamento de cdigo dinmico
entre dispositivos mveis e da nuvem. Tambm construmos 10 aplicativos Sapphire, incluindo um clone inteiramente
caracterizado Twitter, um jogo multi-player, e um editor de texto compartilhado.
A nossa experincia e avaliao mostram que a arquitetura de trs camadas expansvel da Sapphire simplifica muito a
construo de aplicaes mveis / nuvem e funes implantao distribuda. Por exemplo, uma nica linha de alterao de
cdigo de aplicativo - alternar de uma DM para outro - suficiente para transformar um jogo multi-player baseado em
nuvem em um P2P verso (de dispositivo para dispositivo) que melhora significativamente o desempenho do jogo. A
diviso de funes entre as camadas DK e DM faz implantaes extremamente fcil de cdigo; por exemplo, o DM para
apoiar a replicao mquina de estado Paxos apenas 129 linhas de cdigo, uma ordem de magnitude menor do que uma
aplicao C ++ construdo sobre uma biblioteca RPC. Ns tambm demonstramos que a estrutura da Sapphire oferece um
controle refinado sobre desempenho trade-offs, proporcionando um desempenho compatvel com mecanismos de
comunicao populares de hoje como REST.
A prxima seo fornece fundo em aplicaes mveis / nuvem atuais e discute relacionadas com o trabalho. Seo 3
smulas Sapphire e seu sistema de tempo de execuo distribudos ncleo. A Seo 4 apresenta o modelo de programao
de aplicaes. Seo 5 os detalhes do projeto do Kernel implantao, enquanto a Seo 6 foca gerentes de implantao, que
se estendem da DK com mecanismos de implantao distribuda personalizados. O prottipo de implementao Sapphire
descrito na Seo 7 e avaliada no ponto 8, e conclui-se na seco 10.

Motivao e fundo

A Figura 1 mostra a implantao de uma aplicao tpico mvel / cloud. Atualmente, os programadores devem implantar
aplicativos em um mosaico de dispositivos de usurios, servidores de nuvem, e servios de back-end, enquanto satisfaz
requisitos exigentes, tais como a capacidade de resposta e disponibilidade. Por exemplo, os programadores podem precisar
aplicar tcnicas de caching, executar diviso do cdigo especfico do aplicativo em clientes e servidores, e desenvolver
solues para compartilhamento rpido e conveniente de dados, escalabilidade e tolerncia a falhas.
Servios Backend Compartilhados

Cdigo da Aplicao do lado do Servidor

Cdigo da Aplicao do lado do Cliente

Figura 1: Cdigo para aplicaes de hoje abrange servidores em nuvem e dispositivos mveis. cdigo do lado do cliente executado em
plataformas mveis variados, enquanto o cdigo do lado do servidor executado na nuvem, geralmente usando servios de back-end
compartilhado como armazenamento distribudo.

Os programadores usam ferramentas e sistemas quando eles correspondem s necessidades de sua aplicao. Em alguns
casos um sistema existente pode suportar uma aplicao completamente; por exemplo, uma aplicao simples que requer
apenas a sincronizao de dados pode usar um servio de armazenamento de backend como o Dropbox [23], Parse [53] ou
S3 [58]. Mais aplicaes complexas, porm, deve integrar vrias ferramentas e sistemas em uma plataforma personalizada
que atenda s suas necessidades. Esses sistemas incluem o armazenamento do lado do servidor, como Redis [56] ou
MySQL [49] para a tolerncia a falhas, protocolos como RESTO [25] e SOAP [62] ou bibliotecas como Java RMI e Thrift
[3] para a comunicao distribuda, servidores de balanceamento de carga para escalabilidade, armazenamento em cache do
lado do cliente para a latncia de rea ampla inferior, e sistemas de notificao [1], a coordenao [9, 33], e
acompanhamento [18].
Sapphire fornece um ambiente flexvel, cujo mecanismo de extenso pode subsumir as funes de muitos desses
sistemas, ou pode integr-los na plataforma de uma forma transparente. Os programadores podem facilmente personalizar o
sistema de execuo para atender as necessidades de suas aplicaes. Alm disso, os programadores podem mudar
rapidamente solues de implantao para responder ao ambiente ou exigncia mudanas, ou simplesmente para testar e
comparar alternativas durante o desenvolvimento. Finalmente, o quadro Deployment Manager da Sapphire simplifica o
desenvolvimento ou a extenso do cdigo de implantao distribuda.

Sapphire Overview

Sapphire uma plataforma de programao distribuda projetado para flexibilidade e extensibilidade. Nesta seo, ns
cobrimos os nossos objetivos na concepo Sapphire, o modelo de implantao que assumimos, e arquitetura de sistema da
Sapphire.
3.1
Metas de Design
Ns projetamos Sapphire com trs objetivos principais:
1.
Criar uma plataforma de programao distribuda abrangendo dispositivos e nuvem. Uma plataforma
comum integra o ambiente distribudo heterogneo e simplifica as comunicaes, cdigo / mobilidade de dados e
replicao.
2.
lgica da aplicao separada da lgica de implantao. O cdigo da aplicao focada em atender
pedidos de clientes, em vez de distribuio. Isto simplifica a programao, evoluo e otimizao.
3.
Facilitar a extenso do sistema e personalizao. A delegao de gesto de distribuio a uma camada
implantao extensvel d aos programadores a flexibilidade de realizar ou alterar as opes de implantao
facilmente.
Sapphire projetado para implantar aplicativos em dispositivos mveis e servidores em nuvem. Este ambiente causa
significativa complexidade, como o programador deve unir uma coleo distribuda de componentes de software e hardware
altamente heterogneos, com um amplo espectro de capacidades, apesar de se cumprir as metas de aplicao.
Sapphire no projetado para implantao de servios de back-end como Spanner [16] ou ZooKeeper [33]; suas
aplicaes interagir com esses servios de back-end usando chamadas diretas, semelhantes aos aplicativos atuais. Um
Deployment Manager Sapphire pode facilmente integrar um servio de backend de forma transparente para o aplicativo, por
exemplo, usando ZooKeeper de coordenao ou Spanner para tolerncia a falhas. Sapphire tambm no projetado para a
construo de interfaces com o usurio; esperamos aplicativos para personalizar suas interfaces de usurio para os
dispositivos que empregam.
3.2

Arquitetura do sistema

A Figura 2 mostra uma vista de nvel de aplicativo da arquitetura de Sapphire. Uma aplicao Sapphire, que engloba todos
os lado do cliente e lgica de aplicao do lado do servidor, composto por uma coleo de safira Objects (SOs). Cada
funes Sapphire objeto como uma nica unidade de distribuio, como um n virtual. Objetos de safira em um aplicativo
compartilham um espao de endereamento lgico que se estende por todos os servidores em nuvem e dispositivos do lado
do cliente. Ou seja, uma aplicao Sapphire est escrito para que todos os SOs posam invocar diretamente entre si atravs
de chamadas de procedimento independente de localizao simples.

Sapphire Application

Deployment Management Layer

Figure 2: Sapphire runtime architecture. A Sapphire application consists of a distributed collection of Sapphire Objects executing on a
distributed Deployment Kernel (DK). A DK instance runs on every device or cloud node. The Deployment Management (DM) layer
handles distribution management/deployment tasks, such as replication, scalability, and performance.

A camada inferior da Figura 2 o ncleo de implantao (DK), que um sistema tempo de execuo distribudo flexvel
e extensvel. Ele fornece apenas o mais funes de distribuio de base, incluindo SO endereamento e rastreamento de
localizao, melhor comunicao baseada em RPC esforo, para a migrao e gerenciamento bsico de recursos. Ele no
suporta tarefas mais complexas, como a tolerncia a falhas, gerenciamento de falhas, confiabilidade e consistncia. Desta
forma, o DK se assemelha a mensagens de rede IP de nvel - um servio bsico que se baseia em nveis mais elevados de
software para atender as metas do programa mais exigente. O kernel assim deployment agnostic e no favorece (ou limitar
a aplicao a) quaisquer abordagens especficas para problemas de implantao.
Mais tarefas de gerenciamento complexas so suportadas na camada implantao extenses para o DK, chamados de
gerentes de implantao (DMS). Cada objecto de safira pode, opcionalmente, ter um DM em anexo - mostrados no meio da
Figura 2 -, que proporciona o suporte de distribuio de tempo de execuo para alm das caractersticas mnimas de DK. O
programador seleciona uma DM para gerir cada SO; por exemplo, ele pode escolher um DM que lida com falhas para
melhorar a tolerncia a falhas, ou um para armazenar dados localmente em um dispositivo mvel para o desempenho. Ns
construmos uma biblioteca de DMs apoiando tarefas de distribuio comuns usados por aplicativos hoje.
A separao entre a Dinamarca e DMs proporciona flexibilidade significativa e extensibilidade dentro da plataforma de
programao Sapphire distribudo. Como extenses para o DK, gerentes de implantao fornecer recursos de gerenciamento
de distribuio adicionais ou garantias para SOs individuais. Muitas vezes, esses recursos envolvem desempenho trade-offs;
Assim, nem todas as aplicaes ou a cada SO vai querer ou precisar de uma DM. Finalmente, separando a lgica do
aplicativo (no programa de aplicao) da lgica de implantao (fornecido pela DMS), podemos reduzir bastante a
complexidade da aplicao e permitir que os programadores para mudar facilmente a implementao do aplicativo ou
comportamentos de desempenho.

Modelo de programao

O modelo de programao de aplicaes Sapphire baseado em objeto e pode ser integrado com qualquer linguagem
orientada a objetos. Nossa implementao (Seo 7) usa Java.
Objetos de safira so as abstraes de programao chave para o gerenciamento de cdigo do aplicativo e localidade de
dados. Para desenvolver uma aplicao Sapphire, o programador primeiro constri a lgica do aplicativo como um nico
programa orientado a objetos. Em seguida, ele rompe a aplicao em componentes distribudos por declarar um conjunto de
objetos de aplicao para ser Sapphire Objects. Objetos de safira ainda pode chamar uns aos outros atravs de invocao de
mtodo normal, no entanto, essas chamadas podem agora ser chamadas remotas. Finalmente, o programador aplica gerentes
de implantao (DMS) para SOs como desejado para recursos adicionais de gerenciamento distribudo. Nesta seo, vamos
mostrar que o modelo de programao Sapphire fornece: (1) a facilidade de programao em um ambiente distribudo, (2) a
flexibilidade na implementao, e (3) o controle do programador sobre o desempenho.

Definindo Sapphire Objects. Programadores definem Sapphire Objects como classes usando uma declarao
sapphireciass, em vez da declarao de classe padro. Como exemplo, a Figura 3 mostra um trecho de cdigo do
nosso Twitter-clone, Azulo. Todas as instncias da classe de usurio definido aqui esto SOs independentes. Neste
caso, o programador tambm forneceu uma MS para a classe, chamada Consistent Caching, para melhorar o
desempenho do objeto.
SOs pode encapsular objetos definidos pelo lingusticas interna
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public sapphireclass User uses ConsistentCaching {

// user handle
String username;
// people who follow me
User [] followers;
// people who I follow
User [] friends;
....
public String getUsername () {
return username;
}
public User [] getMyFollowers () {
return followers;
}
public User [] getPeopleIFollow () {
return friends;
}
public Tweet [] getMyTweets () {
return myTweets.getTweets ();
}
}

Figura 3: Exemplo Sapphire objeto do Azulo.

(Objetos Java em nosso sistema), como a cadeia de Usurio e matrizes. Estes so apresentados como pequenos crculos a cheio na Figura
2; as setas slidas na figura so referncias entre objetos internos dentro de um SO. objetos SO-internos no pode se mover de forma
independente ou ser acedido directamente do exterior do SO. O SO , portanto, a granularidade da distribuio e decomposio em
Sapphire. Movendo um SO sempre se move todos os seus objetos internos junto com ele; portanto, o programador sabe que todos os
objetos SO-internos sempre ser co-localizado com o SO.
Um objeto Sapphire encapsula os dados e computao em um "n virtual" que: (1) assegura que cada dados / unidade computacional
(um objeto Sapphire) ter sempre o seu cdigo e dados no mesmo n, (2) permite que o sistema de forma transparente mudar ou
descarregar essa unidade, (3) suporta fcil replicao de unidades, e (4) fornece uma unidade de fcil compreenso de falha e recuperao.
Esses benefcios fazem Sapphire Objetos uma poderosa abstrao; usando refinadas definida pelo programador Sapphire objetos, em vez
de uma arquitetura cliente / servidor de granulao grossa, aumenta ambos flexibilidade no controle implantao e programador
distribudos sobre o desempenho.

Chamando Sapphire Objects. Objetos de safira comunicam atravs de invocao de mtodo. As linhas tracejadas na Figura 2
mostram referncias cruzadas-SO, que so usados para invocar o alvo SO mtodos pblicos. A invocao independente da localizao
esimtrico; ela pode ocorrer de forma transparente a partir do dispositivo mvel para o servidor, do servidor para o dispositivo, de
dispositivo para dispositivo, ou entre servidores na nuvem. Um SO pode ser movido por seu DM ou pela DK como resultado de restries
de recursos no n de execuo. Portanto, entre duas chamadas consecutivas do SO A para SO B, um ou ambos os objetos podem alterar a
localizao; DK esconde essa mudana a partir das partes que se comunicam. Invocaes pode falhar, por exemplo, devido rede ou falha
de n; DMs ajudar a lidar com o fracasso em nome da SOS.
SOs so passados por referncia. Todos os outros argumentos e
valores de retorno a partir de ento invocaes so passados por valor. Por exemplo, o valor de retorno de getUsername () na Figura 3
uma cpia do objeto nome de usurio armazenado dentro do SO, enquanto getMyFollowers () retorna uma cpia da matriz contendo
referncias ao usurio SOs. Isso preserva as propriedades de encapsulamento e isolamento de safira objetos, uma vez que impossvel
exportar o endereo de objetos internos dentro deles.
Nosso objetivo era criar um modelo de programao uniforme integrao de dispositivos mveis ea nuvem semescondendo custos de
desempenho e trade-offs do programador. Portanto, o programador faz escolhas explcitas na decomposio da aplicao em OE; uma vez
que a escolha feita, o sistema fornece comunicao independente do local, o que simplifica a programao no ambiente distribudo.

Escolhendo gerentes de implantao. Programadores empregam a palavra-chave usos para especificar uma DM para definir um
objeto de Sapphire. Por exemplo, na Figura 3, a declarao sapphireclass (linha 1) liga-se a DM ConsistentCaching classe do utilizador.
Neste caso, cada instncia de usurio criado pelo programa tero a DM ConsistentCaching ligado a ele. fcil mudar a ligao com uma
simples mudana na definio sapphireclass DM.
Apoiando DMs em uma base classe permite que os programadores especificar diferentes caractersticas ou propriedades para diferentes
componentes de aplicao. Embora a ligao entre um SO e sua DM poderia ser especificado fora da lngua (por exemplo, atravs de um
arquivo de configurao), sentimos que esta escolha deve ser visvel no cdigo porque as decises de implantao sobre o SO esto
intimamente ligadas s exigncias de uma ASSIM.
Sapphire fornece uma biblioteca de DMs padro, ea maioria dos programadores ser capaz de escolher o comportamento que eles
querem da biblioteca padro. Alm disso, DMs so extensveis; discutimos a API para constru-las na prxima seo. Como os
programadores podem construir os seus prprios Mestres e Mestres so projetados para serem reutilizveis, esperamos que a biblioteca
para crescer naturalmente ao longo do tempo.
Um SO pode ter no mximo um DM, e cada instncia do SO deve usar o mesmo DM. Ns escolhemos estas restries para
simplicidade e previsibilidade, tanto na concepo de aplicaes e DMs. Em particular, o comportamento de vrios dm ligados a um SO
depende da ordem em que as funes dos vrios DMS so invocadas, e DMS poderia interferir potencialmente com cada outra. Por este
motivo, os programadores alcanar o mesmo resultado por DMs explicitamente que compem usando herana. Isso permite que o
programador para controlar com preciso as aes do DM composta. Desde instncias do mesmo SO devem ter os mesmos requisitos de
implantao, optamos por no permitir que diferentes DMs para diferentes instncias do mesmo SO.
cdigo de gesto separada DMs em genrica, reutilizvel mdulos que: (1) implantar automaticamente a aplicao de formas

complexas, (2) do programadores componente controle per-aplicao- sobre implantao trade-offs, e (3) permitir que os
programadores para mudar facilmente decises de implantao. Essas vantagens fazem DMs um poderoso mecanismo para
a implantao de aplicaes distribudas.

implantao Kernel

safira de implantao Kernel um sistema de execuo distribuda para aplicaes de safira. Em um nvel alto, o objetivo
da DK criar uma plataforma de execuo integrada em dispositivos mveis e servidores. As principais funes fornecidas
pelo DK incluem: (1) gesto e localizao de monitoramento de safira Objetos, (2) localizao transparente entre objetos
comunicaes (RPC), (3) o apoio rplica de baixo nvel, e (4) servios para simplificar a escrita e execuo de gerentes de
implantao.
Um exemplo DK fornece implantao de melhor esforo de um nico aplicativo Sapphire. Ele consiste em um conjunto
de servidores que correm em todos os dispositivos de computao mvel e back-end usado pelo aplicativo, e um sistema de
rastreamento de objeto centralizado (OTS) para rastreamento de safira Objects.
A Sapphire OTS uma distribudos, servio de coordenao tolerante a falhas, semelhante ao Chubby [9], ZooKeeper
[33] e Tango [4]. O OTS responsvel por rastrear Sapphire objetos entre servidores DK. servidores DK nica comunicar
ocasionalmente com o OTS ao criar ou mover SOs. servidores DK no tem que entrar em contato com o OTS em cada RPC
porque SO referncias contm uma cpia em cache da ltima localizao do SO,
Cada servidor DK abriga uma srie de SOs, agindo como um servidor de eventos para o OE, recepo e expedio de
RPCs. O servidor DK tambm hospeda e gerencia o DMs para os SOs. servidores DK instanciar SOs localmente por
inicializar a memria do SO, criando a sua DM (que potencialmente tem componentes em vrios ns), e registrar o SO com
o OTS. Uma vez criado, o servidor pode mover o SO a qualquer momento, porque ento a localizao e movimento so
invisveis para a aplicao.
A DK fornece primitiva SO agendamento e colocao. Se um servidor DK torna-se sobrecarregado, ele entrar em
contato com o OTS para encontrar um novo servidor para hospedar o SO, mova o SO para o novo servidor, e atualizar o
OTS com a nova localizao do SO. A API DK, descrito na Seo 6, fornece primitivas que permitem DMs para expressar
as polticas de colocao e de programao mais complexos, tais como tolerncia a falhas replicado-geo, balanceamento de
carga, etc.
Para encaminhar uma RPC para um SO, o servidor DK chamando envia a solicitao RPC para o servidor de destino em
cache na referncia SO. Se o destino no hospeda o SO, os contatos de chamada que o OTS para obter o novo endereo. Se
o servidor de destino no estiver disponvel, o servidor de chamada retorna um erro, porque RPC na DK sempre melhor
esforo; DMs implementar o tratamento mais avanado RPC, como RPCs tentando, RPCs de roteamento entre rplicas, etc.
servidores DK no so tolerantes a falhas: quando eles falham, eles simplesmente reiniciar. Ou seja, na recuperao,
servidores DK no recuperar o SOs que eles hospedado em caso de falha; eles simplesmente registrar com o OTS e comear
a hospedagem novos SOs. As falhas so inteiramente tratadas por DMs. Assumimos, h um sistema de deteco de falhas,
tais como FALCON [39], para notificar o OTS quando os servidores falhar, o que ir, em seguida, notificar o DMs do SOs
que foram hospedado no servidor falhou.

Esperamos dispositivos para ser conectado Internet na maioria das vezes, uma vez que as aplicaes hoje
frequentemente dependem do acesso on-line para servidores de nuvem. Quando um dispositivo estiver desconectado, o seu
servidor DK continua a funcionar, mas a aplicao no ser capaz de fazer ou receber chamadas de procedimento remoto
remotos. Quaisquer SOs hospedados em um dispositivo desconectado ser, assim, inacessvel a dispositivos e servidores
externos. O OTS mantm uma lista de dispositivos mveis endereos IP para rapidamente voltar a registar SOs hospedado
nesses dispositivos quando eles se reconectar. DMs pode fornecer mais acesso offline avanado.

Gerentes de implantao

Uma caracterstica fundamental do kernel Sapphire o suporte para a programao e execuo de gerentes de implantao,
que personalizar e controlar o comportamento de SOs individuais no ambiente mvel / cloud distribuda. A DK fornece
suporte API direta para DMs. Essa API est disponvel para desenvolvedores DM, que esperamos ser tecnicamente mais
sofisticado do que os desenvolvedores de aplicativos, embora o quadro DM pode ser usado por qualquer pessoa
personalizar ou construir novas DMs. Como esta seco vai mostrar, DMs pode realizar tarefas de implantao distribudos
complexos com muito pouco cdigo. Isto devido ao factoring cuidadosa da funo entre o DMs ea DK: o DK faz o
trabalho pesado, enquanto o DMs simplesmente dizer o DK que para levantar atravs de API do DK.
6.1

Biblioteca DM

Sapphire fornece programadores com uma biblioteca de DMs que englobam muitos recursos de gerenciamento, incluindo
controles sobre a colocao e semntica de RPC, a tolerncia a falhas, balanceamento de carga e de escala, cdigo-descarga
e implantao peer-to-peer. A Tabela 1 apresenta os DMS que construmos junto com uma descrio ea contagem LoC (de
SLOCCount [71]) para cada um. Ns construmos esses DMs ambos para fornecer programadores com DMs teis para suas
aplicaes e para ilustrar a flexibilidade e facilidade de programao no quadro da programao DM.
6.2

Estrutura DM e API

Ns projetamos a API DM para proporcionar o mnimo de uma interface possvel enquanto ainda apoio a uma vasta gama
de extenses. A DM estende a funcionalidade do DK para atender os requisitos de implantao de um determinado SO
interpondo em eventos DK para o SO. Por exemplo, em um RPC para o SO, o DK far um upcall para o DM

para esse SO. DMs so implementados como objetos, pois cada DM pode executar um cdigo em cada upcall e Estado de
lojas
entre
upcalls.
Tabela 1: Biblioteca de Gestores de Implantao
escalabilidade
LoadBalanced FrontEnd balanceamento de carga simples w / nmero esttico de rplicas e sem consistency53
ScaleUpFrontEnd Balanceamento de carga w / alocao dinmica de rplicas e sem consistency88
LoadBalancedMasterSlave
alocao dinmica de rplicas MS balanceamento de carga w / eventual consistency177

A DM composto por trs tipos de componentes: o proxy, o gerente Instncia, e pelo coordenador. Um programador
constri uma DM atravs da definio de trs classes de objetos, um para cada tipo. Desde DMs destinam-se a gerir a
distribuio, o DK cria um ambiente de execuo distribuda em que operam; ou seja, um DM distribuda em si e os seus
componentes podem operar em ns diferentes. Quando o DK instancia um objeto Sapphire com uma DM anexado, tambm
instancia e distribui componentes do DM. A DK fornece RPC transparente entre os componentes do DM de uma instncia
SO para a coordenao entre os componentes.
A Figura 4 mostra um exemplo de implantao dos componentes do DM para um nico Sapphire Objeto A. A DK pode
instanciar muitos proxies e Gestores instncia, mas no mximo um Coordenador, como mostrado nesta figura. A caixa
central (marcado "Instncia A") indica que A tem duas rplicas, rplica marcados 1 e rplica 2. Cada rplica tem a sua
prpria cpia do Gestor Instncia. Foram o DM para solicitar uma terceira rplica do A, a DK tambm criaria uma nova
instncia Manager para essa rplica. Uma rplica e seu gerente Instncia esto sempre localizadas no mesmo n.
Sapphire Objeto A, com Deployment Manager

Figura 4: Deployment Manager (DM) organizao. Os componentes nomeados Proxy, Instncia Mgr, e Coordenador so todos parte do
DM para uma ocorrncia de Object Sapphire (mostrado aqui com duas rplicas). DK-FT um conjunto de ns DK tolerantes a falhas, que
tambm hospedam o OTS, que suportam tarefas centralizadas confiveis para DMs ea DK.

Cada componente do DM responsvel por um determinado conjunto de tarefas distribudas. Proxies so responsveis por
tarefas do lado do chamador, como roteamento de chamadas de mtodo. Gestores de instncia so responsveis por tarefas
do lado do receptor, como manter rplicas do SO sincronizado. Note-se que, devido

 natureza simtrica da SOS, o chamador do mtodo pode ser em um servidor de nuvem e a assim em si pode ser de um
dispositivo de cliente. Por ltimo, o coordenador responsvel pelatarefas centralizadastais como tratamento de falhas.
Todos os trs componentes so opcionais; um DM pode definir um ou mais dos componentes, e a DK instanciar apenas os
componentes que so definidos.
Tabela 2: Implantao Managers upcall API.

A DK administra completamente componentes DM; eles correm apenas quando invocado, eles residem apenas quando o
DK coloca-los e so limitadas a comunicao com outros componentes na mesma instncia DM, que esto ligados a um
nico SO. A DK invoca componentes DM usandoupcalls,que so apresentados na Tabela 2. Cada componente recebe um
conjunto diferente de upcalls de acordo com as responsabilidades do componente. Deinterpondo em eventos de objeto de
safira, como chamadas de mtodo, DMs pode implementar uma variedade de gerenciamento distribudo apresenta de forma
transparente e genericamente.
Em cada upcall, o componente DM pode executar vrias tarefas de gerenciamento no SO usando um conjunto de
primitivas suportadas pelo DK. A Tabela 3 lista essas primitivas. Os componentes do DM de uma instncia SO podem se
comunicar diretamente uns com os outros atravs de um mecanismo RPC transparente fornecido pela DK. Note que o DK
suporta apenas as funes de replicao mais bsicas, ou seja, a criao de uma nova rplica para um SO e relatrios sobre
locais de rplica. Todas as decises sobre o nmero de rplicas, quando criar ou apag-los, como sincroniz-los, e como
lidar com as falhas ocorrem no nvel DM.
A caixa mais esquerda na Figura 4 mostra quatro outros SOs. Cada um contm uma referncia a um, como um toco
RPC na figura, para que o DK tem anexado um exemplo de componente de proxy DM Uma. Fazer uma RPC para um
atravs da DK e suas DM prossegue da seguinte forma. A DK reflete a chamada atravs de um onRPC () upcall para o
proxy em anexo. O upcall ao Proxy permite de uma interceptao DM uma RPCno n do chamadoronde, por exemplo,
pode implementar o cache local ao cliente. Se o Proxy quer encaminhar a chamada para rplica 1 de A, ele simplesmente
invoca rplica 1 de Instance Manager que executado no mesmo servidor DK como rplica 1. O Gestor Instncia vai passar
o RPC atravs de rplicas de 1 A.
Porque os gestores de proxies e Instncia para que

comuniquem entre si diretamente atravs de RPCs.

Finalmente, o DK instancia um coordenador para cada
instncia DM, mostrado na caixa mais direita da Figura 4.
A OTS administra coordenadores, mantendo-os tolerante a
falhas e centralmente acessvel. bem conhecido que um
coordenador centralizado pode simplificar muitos
algoritmos distribudos (por exemplo, eliminando a
necessidade de eleio do lder). Uma vez que o DK
precisa dos OTS para rastreamento Sapphire Objects, foi
fcil para fornecer tolerncia a falhas para algumas DMs
tambm. Ns no esperamos que cada DM para ter um
coordenador, e mesmo se h um Coordenador, ele usado
com moderao para tarefas de gerenciamento que so mais
fceis tratados centralmente, como instanciar novas rplicas
em caso de falhas. Neste sentido, os coordenadores so
semelhantes a outros sistemas de gesto centralizada, como
Chubby [9] orZooKeeper [33].
Os programadores podem facilmente estender ou
compor DMs existentes usando herana. O novo DM herda
todo o comportamento de classes de objetos que compem
o super-DM. O programador pode, ento, substituir ou
combinar upcalls em cada componente. Enquanto
consideramos composio automtica,
classe pblica LeasedCaching estende DManager {LCProxy classe pblica estende Proxy {
Locao de locao;
SapphireObject lo;
Objeto pblica onRPC (SapphireRPC rpc) {
if (lease.isValid () || lease.isExpired ()!) {locao = Sapphire.getReplica () getLease (.); if (! lease.isValid ()) {
throw new SONotAvailableException (
'' No foi possvel obter locao. '');
} outro {
So = lease.getSO ();
}
}
SapphireObject oldSO = Sapphire.copy (so); Sapphire.invoke (assim, rpc);
SOStream diff = Sapphire.diff (oldSO, portanto); if (diff) Sapphire.getReplica () update (diff).;
}
}
classe pblica LCReplica estende InstanceManager {public sincronizado Lease getLease (); atualizao pblica sincronizado void (SOStream);

// Cdigo para mtodos de instncia do gerenciador

}
}

Figura 5: Gerente Exemplo de implantao com argumentos.

acreditamos que o programador DM deve ser envolvido para garantir que o composto DM implementa exatamente o
comportamento que o programador espera. A nossa experincia com Mestres compem mostrou que o uso de herana para a
composio DM simples e intuitiva.
6.3

Exemplo de cdigo DM

A Figura 5 mostra uma definio simplificada do DM LeasedCaching que ns fornecemos na Biblioteca Sapphire. Ns
incluir o cdigo para o componente Proxy e as declaraes de funo do Gerenciador de Instncia. Este DM no tem um
coordenador, porque ele no precisa de gerenciamento centralizado.
O DM LeasedCaching no replicado, por isso DK s ir criar um Gestor Instncia. O gerente Instncia mos para fora
locaes mutuamente exclusivas aos representantes (que residem com a referncia remota ao SO) e usa o tempo limite para
lidar com proxies falhou. O Proxy com um contrato de arrendamento vlido pode ler ou gravar em uma cpia local. Readonly operaes no incorrer em comunicaes, o que economiza latncia sobre uma rede lenta, mas as atualizaes so
sincronicamente pro- pogated ao Gerente Instncia em caso de falha Proxy.

Quando o aplicativo chama um mtodo em um SO com este DM anexado, Proxy do chamador: (1) verifica que detm um
contrato de arrendamento, (2) executa a chamada de mtodo na sua cpia local, (3) verifica se o objeto foi modificado
(usando diff ()), e (4) sincroniza o objeto remoto com a sua cpia em cache se o objeto mudou, usando uma atualizao ()
para o Gerenciador de Instncia.
Cada Proxy armazena o contrato de arrendamento no objeto de arrendamento (linha 3) e uma cpia local do objeto
Sapphire (linha 4). Se o Proxy no detm um contrato de arrendamento vlido, ele deve obter um da Instncia Manager
(linha 8) antes de invocar o seu local para cpia. Se o proxy no capaz de obter o contrato de arrendamento, o DM joga
um SONotAvailableException (linha 10). O aplicativo est preparado para qualquer RPC para um SO de falhar, por isso vai
capturar a exceo e lidar com ele. O aplicativo tambm sabe que o SO usa o LeasedCaching SOM, por isso compreende a
cadeia de erro (linha 11).
Se o Proxy capaz de obter um contrato de arrendamento a partir do Gerenciador Instncia, o contrato de arrendamento
ir conter uma cpia up-to-date do SO (linha 13). O Proxy vai fazer uma cpia limpa do SO (linha 17), chamar o mtodo na
sua cpia local (linha 18) e, em seguida, diff a cpia local com a cpia limpa para verificar se h atualizaes (linha 19). Se
o to mudado, o Proxy ir atualizar cpia do Gestor de Instncia do SO (linha 20). A cpia e diff necessrio porque o
proxy no sabe qual SO mtodos podem escrever para o SO, exigindo, portanto, uma atualizao para o Gerenciador de
Instncia. Se o DM tinha mais conhecimento sobre o SO (ou seja, o SO permite que o DM saber quais mtodos so somente
leitura), poderamos ignorar esta etapa.
O exemplo ilustra algumas propriedades interessantes de DMS. Primeiro, o cdigo DM a aplicao agnstica e pode
executar apenas um conjunto limitado de operaes no SO que gerencia. Em particular, pode interpor apenas em chamadas
de mtodo para o seu SO, e manipula a gesto SO como uma caixa preta. Por exemplo, h DMs que cache automaticamente
um SO, mas no DMs que cache uma parte de um SO. Isso garante uma clara separao de cdigo de gerenciamento de
objetos de lgica de aplicao e permite que o DM para ser reutilizado em diferentes aplicaes e objetos.
Em segundo lugar, a DM no pode abranger mais de um objeto Sapphire: ele executa operaes somente no objeto que
gerencia. Ns no escolheu para apoiar a gesto cross-SO porque exigiria o DM para entender melhor a aplicao; bem, ele
pode causar conflitos entre as DMs de diferentes SOs. Como resultado, h DMs que fornecem operaes multi-RPC em um
nico SO, mas no suportar transaes cross-lo. No entanto, o programador pode combinar vrios objetos Sapphire em um
SO ou implementar suporte a concorrncia ao nvel da aplicao para alcanar o mesmo efeito.
6.4

Exemplos DM Projeto

Esta seo discute a concepo e implementao de vrias classes de DMs da Biblioteca Sapphire, listadas na Tabela 1.
Nosso objetivo mostrar como a API DM pode ser usado para estender o DK para uma ampla gama de funcionalidades de
gesto distribudos.
Code-descarregamento. As DMs-descarregamento de cdigo so teis para aplicaes de computao intensiva. o
CodeOffloading DM suporta a migrao objeto transparente com base no trade-off entre o desempenho localizar um objeto
em um dispositivo ou na nuvem, enquanto o DM ExplicitCodeOffloading permite que o aplicativo para decidir quando
mover computao. O DM ExplicitCodeOffloading d
a aplicao mais controle do que o CodeO automatizadoffloading DM, mas menos transparente porque o SO deve
interagir com o DM.
Uma vez que o DK cria o objeto Sapphire em um dispositivo mvel, o DM CodeOffloading automatizado replica o
objeto na nuvem. O dispositivo do lado do DM Instance Manager, em seguida, executa vrios RPCs localmente e pergunta
o lado em nuvem Instance Manager para fazer o mesmo, calculando o custo de funcionamento de cada lado. Um algoritmo
adaptativo, baseado em Q-Learning [70], escolhe gradualmente a opo de menor custo para cada RPC. Periodicamente, o
DM retestes as alternativas para se adaptar dinamicamente s mudanas de comportamento, pois o custo de
descarregamento depende do tipo de computao e a conexo de rede, o que pode mudar ao longo do tempo.
Pessoa para pessoa. Ns construmos DMs peer-to-peer para suportar o compartilhamento direto da SOS atravs de
dispositivos mveis de cliente sem necessidade de ir atravs da nuvem. Estes DMs colocar dinamicamente rplicas em ns
que contm referncias para o SO. Implantamos o DM usando um coordenador centralizado que tenta colocar rplicas to
perto para os chamadores possvel, sem exceder um nmero mximo especificado pelo aplicativo de rplicas. Ns
mostramos o impacto no desempenho deste esquema P2P na seo 8.
Replicao. A Biblioteca Sapphire contm trs DMs replicao que replicam um objeto Sapphire em vrios servidores para
tolerncia a falhas. Eles oferecem garantias de seriao e semntica exatamente-uma vez, juntamente com tolerncia a
falhas. Eles exigem que o SO determinista e s faz idempotent chamadas para outros SOs.
modelo DMs replicao da Biblioteca como uma mquina de estado replicado (RSM) que executa operaes em um SO
rplica master. Estes DMs todos herdar de uma DM comum que implementa o RSM, em seguida, estender o DM comum a
implementar polticas diferentes para a colocao de rplicas (por exemplo, Geo-replicado, P2P).

O RSM DM usa um coordenador para instanciar o nmero desejado de rplicas, designar um lder, e manter informaes
sobre membros do grupo de rplica. O Coordenador associa um nmero poca com esta informao, que ele atualiza
quando alteraes de membros.
Para cada RPC, instncia Gestores de encaminhar o pedido para o Gestor de Instncia da rplica master, que registra a
RPC e atribui a ele um ID. O mestre, em seguida, envia o nmero de ID e poca para os outros gestores de ocorrncia que
aceit-lo se eles no tm outra RPC com o mesmo ID. Se o mestre recebe uma resposta de pelo menosfoutros gerentes
exemplo, ele executa o RPC e sincroniza o estado do SO nas outras rplicas. Se uma das rplicas falhar, o DK notifica o
coordenador, que aloca uma nova rplica, designa um lder, comea uma nova poca, e informa outras rplicas da mudana.
Escalabilidade. Para dimensionar Sapphire Objetos que lidar com um grande nmero de pedidos, a Biblioteca Sapphire
inclui ambas as DMs escalabilidade aptridas e stateful. O DM LoadBalancedFrontEnd fornece carga simples equilbrio
entre um determinado nmero de rplicas. Este DM suporta apenas objetos Sapphire que so aptridas (ou seja, no exigem
coerncia entre rplicas); no entanto, o SO livre para acessar estado em outros objetos safira ou no disco. O DM
ScaleUpFrontEnd estende o DM LoadBalancedFrontEnd com scale-up automtico, o DM monitora a latncia de
solicitaes e cria novas rplicas quando a carga sobre o SO e a latncia aumenta. Finalmente, o LoadBalancedMasterSlave
oferece escalabilidade para cargas de trabalho de leitura pesadas por alocar dinamicamente uma srie de somente leitura
rplicas que recebem actualizaes a partir a rplica master. Este DM usa o coordenador para organizar rplicas e selecione
o mestre. Ns mostrar a utilidade dos nossos Mestres de escalabilidade no ponto 8.
Discusso. API upcall do DM e sua API DK associados so relativamente pequeno (apenas 8 upcalls e 27 chamadas DK),
mas poderoso o suficiente para cobrir uma ampla gama de tarefas de implantao sofisticados. A maioria dos nossos DMs
esto sob uma centena de linhas de cdigo. H trs razes para este eficincia da expresso. A primeira a diviso do
trabalho entre o DMs ea DK. A DK suporta mecanismos fundamentais como a RPC, a criao do objeto e mobilidade e
gerenciamento de rplicas. Portanto, a DK executa a maioria do trabalho em operaes de implantao, enquanto o DMS
simplesmente dizer ao DK o trabalho a realizar.
O segundo a disponibilidade de um Coordenador centralizado, tolerante a falhas no ambiente de DM. Isto reduz a
complexidade de muitos protocolos distribudos; por exemplo, na ConsensusRSM DMs, o Coordenador simplifica consenso
determinando a associao lder e grupo. Nossos trs DMs replicao compartilhar esse cdigo, mas tomar decises
diferentes de colocao de rplicas, o cumprimento das metas e propriedades diferentes com o mesmo mecanismo. Herana
facilita a composio de novos DMs partir dos j existentes; por exemplo, o DurableTransactions DM se baseia no DM
OptimisticTransactions, acrescentando tolerncia a falhas com apenas mais 20 linhas de cdigo.
Finalmente, a decomposio de aplicativos em Sapphire objetos simplifica muito a implementao DM. Implantamos o
DM-descarregando o cdigo em apenas 95 LoC porque no temos para determinar a unidade de cdigo para descarregar de
forma dinmica, e porque o aplicativo fornece um indcio de que o SO computao intensiva, escolhendo o DM. Em
contraste, sistemas de descarregamento de cdigo atual [19, 30, 14] so muito mais complexos porque faltam informaes
sobre o comportamento da aplicao e porque as aplicaes no so facilmente compostos em unidades de localidade, como
objetos.

Implementao

Nosso prottipo DK foi construdo usando Java para acomodar dispositivos mveis Android. Ao todo, a DK composto por
12.735 linhas de cdigo Java, incluindo 10.912 linhas de
MobileCloud

Figura 6: aplicao Sapphire e sistema de tempo de execuo.

cdigo RMI Apache Harmony, que tivemos para a porta para Dalvik. Dalvik foi desenvolvida com base no Apache
Harmony, mas no inclui uma implementao para Java RMI.
A Figura 6 mostra a arquitetura do prottipo. Usamos Java 1.6.0_38 JVM da Sun para executar Sapphire no cluster,
enquanto os comprimidos e telefones correu Sapphire no Android

4.2 Dalvik VM. Usamos Java RMI para RPCs de baixo nvel entre os ns DK. Usamos Voldemort [69] como o
armazenamento de back-end para os nossos DMs checkpointing.
Java RMI fornece apenas a comunicao ponto-a-ponto e s suporta chamadas para objetos Java que possuem uma
interface especial Java RMI-fornecidos. Assim, s poderia usar Java RMI para comunicao de baixo nvel entre os
servidores DK ea OTS. Para conseguir uma comunicao transparente entre organizaes de apoio e entre os componentes
do DM, foi construdo um compilador (862 LoC), que cria tocos para organizaes de apoio e para DM Instncia gerentes e
coordenadores. Ter um esboo para cada SO permite que o servidor DK para rotear chamadas de procedimento remoto e
invocar componentes do DM no lado do receptor e chamador. DM Instncia gerentes e coordenadores tambm exigem tocos
porque o DK tem de ser capaz de suportar RPC transparente de Gestores Instncia e proxies. O compilador gera stubs como
classes Java que estendem a classe do objeto de destino, substituindo todos os contedos mtodo com funes de
encaminhamento para o DK. Um esboo , por conseguinte, uma referncia que pode ser usado para a comunicao
transparente com o objecto remoto atravs da DK.
Contamos tambm com a implementao do Apache Harmony da RMI serializao - com reflexo Java para Marshall e
objetos desempacotar - para o envio, diffing e copiar objetos. Ns fizemos nenhuma otimizao do Java RMI em todo este
prottipo. Poderamos ter aplicado tcnicas bem conhecidas [44, 54, 50] para melhorar o desempenho RPC e esperar para
faz-lo no futuro; no entanto, como mostramos na nossa avaliao, o nosso desempenho competitivo com os mecanismos
de cliente-servidor amplamente utilizados, tais como REST. Para atingir este desempenho em dispositivos mveis, tivemos
que corrigir vrios bugs que causaram problemas de desempenho na Harmonia cdigo RMI Apache que portado para
Android.
Nosso prottipo no inclui atualmente uma comunicao segura entre servidores DK. suportes Java RMI
SSL / TLS, ento o nosso prottipo poderia facilmente suportar a comunicao criptografada entre servidores DK. Tambm
seria necessrio um mecanismo de autenticao para registrar servidores DK em dispositivos mveis, como o Google SSO
[28].
Em aplicaes de hoje, mecanismos tais como cheques de controle de acesso so normalmente fornecidos pelo
aplicativo. Com uma plataforma de programao unificado como safira, torna-se possvel mover mecanismos de segurana
na prpria plataforma. Enquanto essa discusso est fora do escopo do papel, estamos a explorar o uso de proteo baseada
em controle de fluxo de informaes para aplicaes mveis / nuvem no contexto do objeto da Sapphire e da estrutura / DM
DK.

Experincia e Avaliao

Esta seo apresenta avaliaes qualitativas e quantitativas de Sapphire. Em primeiro lugar, descrever a nossa experincia
na construo de novas aplicaes e portar aplicaes de safira. Em segundo lugar, ns fornecemos as medies de baixo
nvel de desempenho DK, e uma avaliao de vrios Mestres e suas caractersticas de desempenho. A nossa experincia
demonstra que: (1) Os pedidos de safira so fceis de construir, (2) a separao de cdigo de aplicativo e cdigo de
implementao, juntamente com o uso de simtrica (ou seja, o servidor no-client) comunicao, maximiza a flexibilidade e
escolha de implantao para programadores, e (3) gerentes de implantao pode ser utilizada de forma eficaz para melhorar
o desempenho e escalabilidade em um ambiente distribudo dinmico.
8.1 Aplicaes
Ns consideramos a concepo e implementao de vrias aplicaes de safira com relao a trs objectivos:

Facilidade de desenvolvimento: Deve ser fcil para desenvolver aplicaes mveis / nuvem desde o
incio ou por portar aplicativos do dispositivo no distribudos mveis para Sapphire. Alm disso, deve ser
possvel escrever o cdigo do aplicativo sem abordar explicitamente gesto de distribuio.

Flexibilidade de implantao: O programador deve ser capaz de escolher a partir de esquemas

alternativos de gesto de distribuio e alterar as decises de implantao sem reescrever o cdigo do
aplicativo.

Cdigo de Gesto Generalidade: Deve ser possvel construir componentes de gerenciamento de

distribuio de genricos que podem ser usados amplamente, tanto dentro de um aplicativo e em diferentes
aplicaes.
A Tabela 4 lista vrias aplicaes que construmos ou portados, juntamente com a sua loc. Ns construmos trs
aplicaes a partir do zero: uma lista online de tarefas, um editor de texto e mesa de colaborao, e um jogo multi-player.
Tambm construmos um clone Twitter cheio de recursos, chamado Azulo, e emparelhado com a interface do usurio frontend de Twimight [68], um cliente Android Twitter open-source. A tabela tambm lista seis aplicativos no-distribudos, de
computao intensiva que
Tabela 4: Sapphire aplicaes. Dividimos cada aplicao em cdigo front-end (UI) e cdigo de back-end (lgica da aplicao). A coluna
de origem indica se ns desenvolvemos um novo cdigo Sapphire nativa ou portado cdigo-fonte aberto a safira.

Back-endFront-end
Aplicao

Fonte

LoC

Fonte

LoC

Lista de afazeres
Editor de Texto /
Tabela
Multi-jogador do
jogo

Nativo

48

Nativo

132

Nativo

409

Nativo

533

Nativo

588

Nativo

Pssaro azul
Sudoku Solver
Regresso
reconhecimento de
imagem
motor de fsica
Clculo
xadrez AI

Nativo
portado
portado
portado

783
76
348

portado
-

1186
13.00
9
-

portado
portado
portado

102
108
818
427

temos portado para Sapphire.

Facilidade de desenvolvimento. Levou relativamente pouco tempo e experincia de programao para desenvolver
aplicativos de safira. Em particular, a existncia de uma biblioteca de DM permite que os programadores escrever a lgica
da aplicao sem necessidade de gerir a distribuio explicitamente. Duas aplicaes - o jogo multi-jogador e editor
colaborativo - foram escritos por alunos de graduao que nunca haviam construdo aplicativos do dispositivo ou da web
mvel e tinha pouca experincia distribudos sistemas. Em menos de uma semana, cada aluno escreveu uma aplicao
mvel / nuvem de trabalho de entre 1000 e 1500 linhas de cdigo que consiste em cinco ou seis objetos Sapphire
abrangendo a interface do usurio e Sapphire back-end.
Portar aplicaes existentes para Sapphire foi fcil tambm. Para as aplicaes de computao intensiva, uma nica
mudana de linha foi suficiente para transformar um objeto Java em um distribudos de modo que poderia de forma
adaptativa executar ou na nuvem ou no dispositivo mvel. Ns no tm de lidar com falhas porque o CodeOffload DM
esconde-los, de forma transparente re-executar o clculo localmente quando o site remoto no est disponvel. Uma
graduao portado todas as seis aplicaes - e implementou o CodeOffload DM, bem como - em menos de uma semana.
Nosso maior aplicao era Azulo, um clone de Twitter que foi organizado como dez objetos Sapphire: Tweet, Tag,
TagManager, Timeline, UserTimeline, HomeTimeline, MentionsTimeline, FavoritesTimeline, Usurio e UserManager.
Implementamos todas as funes do Twitter, exceto para mensagens e pesquisa em menos de 800 linhas. Em comparao,
bigbird [22], um Twitter clone de cdigo aberto, 2563 linhas de cdigo, e Retwis-J [38], que depende fortemente de
funcionalidade de pesquisa Redis, de 932 linhas de cdigo.
aplicaes mobile / nuvem distribudos devem lidar com os desafios da executados em dispositivos com recursos
limitados mveis, servidores de nuvem no confiveis, e links de alta latncia, de toda a rea. Usando Sapphire, esses
desafios so tratados pelo selecionando DMs da biblioteca DM, o que simplifica a tarefa do programador e torna mais fcil
para desenvolver e testar implementaes alternativas.
Flexibilidade de implantao. Mudando DM de um SO, que muda suas propriedades de distribuio, exige apenas uma
alterao de cdigo de uma linha. Temos feito uso da propriedade ao longo do desenvolvimento das nossas aplicaes como
ns experimentamos com nossas decises iniciais de distribuio e tentou otimizar-los.
Em Azulo, por exemplo, inicialmente escolheu no tornar Tweet e Tag em SOs; uma vez que estes objetos so pequenos
e imutvel, ns pensamos que eles no precisam ser objetos independentes, globalmente compartilhados. Mais tarde,
percebemos que seria til para se referir diretamente aos Tweets e tags de Timeline objetos em vez de acess-los atravs de
outro SO. Por isso, mudou-los para SOS - uma mudana trivial - e ento utilizado ExplicitCaching para ambos para reduzir
o atraso de rede para leituras do seu tweet ou tag strings.

Como outro exemplo, encontramos uma deciso implantao no desenvolvimento do nosso jogo multi-player. O objeto
do jogo dura apenas para a durao de um jogo e s pode ser acessado a partir de dois dispositivos utilizados para jogar.
Uma vez que o objecto no necessita de uma elevada fiabilidade e disponibilidade, pode ser implantado em qualquer
nmero de maneiras: por um servidor, em um dos dispositivos, ou em ambos os dispositivos. Ns primeiro implantado o
objeto do jogo em um servidor de nuvem e, em seguida, decidiu experimentar com alternativas peer-to-peer. Alterando a
partir da implementao de nuvem para peer-to-peer usando os gestores KeepOnDevice e ConsensusRSM-P2P em nossa
biblioteca DM necessrios apenas umamudana de linha nica,e melhor desempenho (ver Seco 8.4) e permitiu jogos para
continuar quando o servidor est indisponvel. Em contraste, mudando um pedido de um dos sistemas de hoje de uma
implantao de nuvem para uma implantao de dispositivos mveis peer-to-peer iria exigir a aplicao significativa
reescrevendo (e pode at mesmo ser impossvel sem um componente nuvem intermedirio devido natureza clienteservidor de existir Systems).
Cdigo de Gesto generalidade. Aplicamos vrias DMs a mltiplos SOs dentro das aplicaes individuais e atravs de
aplicaes. Por exemplo, muitos de nossos aplicativos tem um objeto que compartilhado entre um pequeno nmero de
usurios ou dispositivos (por exemplo, ToDoList, documento, etc.). Para tornar a leitura mais rpida, assegurando que os
usurios ver as atualizaes imediatas, foi utilizado o DM ConsistentCaching para todas estas aplicaes. Sem a estrutura
DM, os programadores teria que escrever o cdigo de cache e sincronizao explicitamente para cada caso.
Mesmo dentro Azulo, que tem 10 tipos de objetos Sapphire, poderamos reutilizar vrios DMs. Se o cdigo de
implementao para cada Azulo por isso teve de ser implementado no aplicativo, o aplicativo deve crescer pelo menos 800
LoC, mais do que dobrando de tamanho! Este nmero conservador: ele assume a disponibilidade da API DM ea DK para a
sustentao. Sem esses mecanismos, seria necessria ainda mais cdigo.
8.2 Configurao experimental
Nossos experimentos foram realizados em um cluster homogneo de mquinas de servidor e vrios tipos de dispositivos
(tablets e telefones). Cada servidor continha 2 quad-core Intel Xeon E5335 CPUs 2.00GHz com 8 GB de DRAM rodando
Ubuntu 12.04 com o kernel Linux verso 3.2.026. Os dispositivos foram Nexus 7 comprimidos, que so executados em um
1.3 GHz quad-core Cortex A9 com 1 GB de DRAM, e os telefones Nexus S com um processador Hummingbird
single-core de 1 GHz e 512 MB de DRAM. Os servidores foram todos ligados a um switch top-of-rack. Os dispositivos
foram localizados na mesma rede local que os servidores, e se comunicava com o servidor atravs de uma conexo sem fios
ou ligaes 3G T-Mobile.
8.3 microbenchmarks
Ns medimos a DK para a latncia e taxa de transferncia usando RPCs de circuito fechado. Latncias foram medidos no
cliente. Antes de tomar medidas, enviamos primeira vrios milhares de pedidos para aquecer a JVM para evitar os efeitos do
JIT e tamponantes otimizaes.
RPC Latncia Comparao. Ns comparamos o desempenho da Sapphire RPC para Java RMI e dois modelos de
comunicao amplamente utilizados: Thrift e REST. Apache Thrift [3] uma biblioteca RPC open-source utilizado pelo
Facebook, Cloudera e Evernote. RESTO [25] um protocolo de comunicao de baixo nvel popular para a Web; muitos
sites tm uma API REST pblica, incluindo Facebook e Twitter. Medimos REST usando um cliente Java em execuo a
classe HttpURLConnection padro e um script PHP em execuo no Apache 2.2 para expedio mtodo.
Tabela pedido 5 mostra / latncias de resposta para intra-n (locais), de servidor para servidor, tablet-a-servidor, servidor
para tablet e comunicao tablet-a-tablet em pedidos nulos para todos os quatro sistemas. Enquanto Thrift foi ligeiramente
mais rpido em todos os casos, Java RMI e Sapphire foram comparveis e foram ambos mais rpido do que a biblioteca
Java REST.
Sapphire usa Java RMI para comunicao entre servidores DK; no entanto, eu despacho chamadas de mtodo para SOs
atravs da DK. Este envio adicional causado a diferena de latncia entre Java RMI e Sapphire RPC. O custo adicional foi
devido principalmente ao instanciar e serializao de objeto de dados RPC de Sapphire (que no necessrio para um nulo
Java RMI RPC). Ns poderamos reduzir esse custo, utilizando uma infra-estrutura RPC e serializao mais eficiente, como
Thrift.
Note-se que, mesmo sem otimizao, Sapphire foi mais rpido do REST, que provavelmente o quadro de comunicao
mais utilizado hoje. Alm disso, poderamos
Tabela 5: latncias solicitao (MS) para local, de servidor para servidor, tablet-a-servidor, servidor para tablet e tablet-to-tablet. Observe
que o descanso no suporta comunicao para tablets.

Protocolo
RPC
Sapphire
Java RMI
parcimnia
DESCANSA
R

Local

S^S

T^S

S^T

T^
T

0,08
0,05
0,04
0,49

0,16
0,12
0,11
0,64

5.9
4.6
2.0
7.9

3.4
2.0
2.0
-

12.0
7.2
3.6
-

no mostrar desempenho REST para servidor para tablet e tablet-to-tablet porque arquitetura cliente-servidor de descanso
no pode aceitar solicitaes HTTP no tablet. Assim, REST pode ser usado apenas para comunicao tablet-a-servidor,
exigindo a aplicao para gerenciar explicitamente formas de comunicao como o servidor-cliente ou cliente-a-cliente.
Taxa de transferncia de comparao. Medimos pedido de transferncia para o Sapphire DK e Java RMI. Os resultados
(Figura 7) mostrou curvas de rendimento semelhantes, com Java RMI objecto de transferncia de aproximadamente 15%
maior do que para Sapphire Objects. Isso ocorre porque Sapphire RPCs nulos no so verdadeiramente vazio: eles carregam
uma estrutura serializada dizendo a DK como direcionar a chamada. Para quebrar o custo mais baixo, medida que a taxa de
transferncia de um Java RMI transporte de uma carga idntica do nulo RPC safira. Isso reduziu a diferena de
rendimento para 3,6%; esta de 3,6% o custo adicional de expedio RPC de safira na DK, sendo o restante devido ao
custo de serializao para a estrutura de expedio. Novamente, existem muitas maneiras de reduzir o custo da presente
comunicao no Sapphire, mas deixamos os otimizao para o trabalho futuro.

clientes

Figura 7: Taxa de transferncia de um objeto Sapphire versus um objeto RMI.

Sapphire Custo DK Operao. Ns medimos a latncia de vrios servios DK. DK chamar latncia depende do tamanho e
da complexidade do objeto, uma vez que usar a serializao Java. A Tabela 6 mostra resultados de latncia para criar,
replicar e SOs movendo em servidores e tablets. latncias de operao foram baixas quando executado em servidores em
nuvem. Os comprimidos foram consideravelmente mais lento do que os servidores em nuvem. No entanto, esperamos que a
maioria das operaes de gesto tais como estes a serem executadas na nuvem (ou seja, no esperamos comprimidos para
criar um grande nmero de SOS). O processo de instanciao SO pode ser caro, porque

DK deve criar vrios objetos localmente: o SO, o stub SO, o Proxy DM eo Gerente DM Instncia. A DK tambm deve criar
o Coordenador DM remotamente em um n DK-FT e registrar o SO com o OTS. A comunicao com o n de DK-FT ea
OTS
foi
responsvel
por
quase
metade
da
latncia
instanciao.
50
0

Tabela 6: Sapphire DK latncias API (MS).

Execuo Rede

Telefone

IQ

BaseWiFi BaseWiFi 3G 3G

PhysicsSudoku

40
0

30
0

20
0

0
0

I..I

BaseWiFi 3G

BaseWiFi 3G

BaseWiFi 3GBaseWiFi 3G

Clculo

ChessAI

RegressionOCR

8.4 Performance Manager Implantao

Ns medimos o desempenho de cinco categorias de DMs: caching, replicao peer-to-peer, mobilidade e escalabilidade.
Nosso objetivo foi examinar sua eficcia como extenses para o DK e os custos e os trade-offs de empregar diferentes DMs.
Cache. Foram avaliados dois DMs cache: LeaseCaching e ConsistentCaching. Como esperado, o cache melhorou
significativamente a latncia de leituras em ambos os casos. Para o TodoList SO, que usa o DM LeaseCaching, caching
reduzida latncia de leitura a partir de 6 ms para 0,5 ms, enquanto a latncia de gravao aumentou de 6,1 ms para 7,5 ms.
Para o jogo, ento, que usa o DM ConsistentCaching, todos ler latncias diminuiu, de 7-13 ms para 2-3 ms. Com o cache
consistente, o custo de gravao para manter a caches e cloud sincronizada foi significativa, passando de 29 ms a 77 ms.
Overhead introduzido pelo DM foi devido ao uso de serializao para determinar leitura vs. operaes de gravao. Para as
gravaes, todo o objecto foi enviada para ser sincronizada com a nuvem, em vez de um adesivo compacto.
descarregamento de cdigo. Medimos nossas, aplicaes computeintensive portados com a CodeOffloading DM para o
tablet Nexus 7 eo smartphone Galaxy S. A figura 8 mostra as latncias para a execuo de cada aplicativo localmente no
dispositivo (como base), descarregados para a nuvem atravs de WiFi, e descarregados atravs de 3G. As descargas tradeoffs variaram amplamente entre as duas plataformas devido a diferenas na velocidade da CPU, sem fio, e o desempenho da
placa de rede celular. Por exemplo, para a aplicao do clculo, o descarregamento de nuvem era melhor para o telefone
sobre ambos sem fio e 3G; no entanto, para o tablet era melhor somente sobre wireless. Para o motor de fsica, o
descarregamento foi universalmente melhor, mas foi particularmente significativo para o dispositivo mvel, o que no foi
capaz de fornecer simulao em tempo real, sem descarregamento de cdigo.
Estas diferenas de plataforma cruzada no desempenho mostrar a importncia da flexibilidade. Um algoritmo
automatizado nem sempre pode prever quando se descarregar e pode ser caro. Portanto, importante para o programador de
ser capaz de alterar facilmente a implantao de se adaptar a novas tecnologias.
500

Comprimido
400

PhysicsSudokuCalculusChessAIRegressionOCR

Figura 8: Cdigo de desempenho descarregamento.

clientes

Figura 9: Efeito da aplicao do LoadBalancedFrontEnd DM.

Escalabilidade. Ns construmos a DM LoadBalancedFrontEnd para escalar um aptrida SO sob carga pesada. O DM

cria um determinado nmero de rplicas no consistentes de um SO e atribui clientes para as rplicas de uma forma roundrobin. A Figura 9 mostra a taxa de transferncia dos SO que servem RPCs nulos quando o DM cria at 3 rplicas.
Rendimento dimensionado de forma linear com o nmero de rplicas at que a rede saturada a 257,365 solicitaes /
segundo.
Peer-to-Peer implementaes. Sapphire permite que programadores mover objetos facilmente entre clientes e
servidores, permitindo implementaes P2P que seria difcil ou impossvel em sistemas existentes. Ns medimos trs
implementaes para o jogo assim do nosso jogo multi-jogador: (1) sem DM, o que causou Sapphire para implantar o SO
no servidor onde ele criado; (2) com o KeepOnDevice DM, que se mudou dinamicamente o objeto do jogo a um
dispositivo que acessaram; e (3) com o DM ConsensusRSM-P2P, que criou sincronizado rplicas do jogo para nos
dispositivos dos chamadores.
Para cada implantao, a Figura 10 mostra a latncia dos mtodos de leitura do jogo (getScrambleLetters (), getPlayerTurn
() e getLastRoundStats ()) e escrever mtodos (play () e passar ()). Com o jogo assim na nuvem, ler e escrever latncias
foram elevadas para ambos os jogadores. Com o DM KeepOnDevice, a leitura e gravao latncias eram extremamente
baixos para o dispositivo que hospeda o SO, mas um pouco maior para o outro jogador, em comparao com a verso em
nuvem. Finalmente, com o DM ConsensusRSM-P2P, leia latncias eram muito

20

Hospedar GuestHost GuestHost Guest

5
29

f 26

2830

^^

62

H getPlayerTurn | getScrambleLetters [J] getLastRoundStats

passe jogo

Figura 10: Multi-jogador do jogo: esquemas de implantao

diferentes.
inferior em ambos os dispositivos, enquanto as latncias
de gravao foram maiores. No nosso cenrio, os dois
comprimidos e o servidor estavam na mesma rede. Nos casos em que os dois jogadores esto prximos na rede e longe do
servidor, as DMs peer-to-peer iria fornecer uma opo de implantao valioso.
Com as DMs, h servidores de nuvem foram necessrios para suportar o jogo to; isso reduziu a carga do servidor, mas
Jogo SOs j no estavam disponveis se o dispositivo que hospeda foram desconectados. Esta experincia mostra o impacto
das diferentes opes de implantao e o benefcio de ser capaz de escolher de forma flexvel implementaes alternativas
para a troca o desempenho do aplicativo, disponibilidade e carga do servidor.

Trabalho relatado

Os pesquisadores construram muitos sistemas para ajudar a aplicaes de lidar com problemas de implantao. sistemas de
descarga de cdigo, como COMET [30], Maui [19], e CloneCloud [14], descarregar automaticamente as tarefas de
computao intensiva a partir de dispositivos mveis em nuvem servidores. sistemas de armazenamento distribudos
[21,12,16] so uma soluo popular para escalabilidade do lado do servidor, durabilidade e tolerncia a falhas. Sistemas
como PADS [7], Practi [6] e WheelFS [65] explorado implantao configurvel de dados de aplicativos, mas no tempo de
execuo gesto de toda a aplicao. Sistemas como Bayou [67], Cimbiosys [55] e Simba [2] oferecem o cache do cliente e
acesso offline para ambientes fracamente ligados. Cada um destes sistemas s resolve um subconjunto da implantao
desafios que as aplicaes mveis / nuvem enfrentar. Sapphire o primeiro sistema distribudo para fornecer uma soluo
unificada para a implantao de aplicativos mobile / nuvem.
Quando a construo de biblioteca DM da Sapphire, que se inspirou em sistemas de implantao mvel / nuvem
existentes, incluindo aqueles que fornecem: comunicao [34], protocolos de consenso [31, 72] de balanceamento de carga,
replicao geogrfica [43, 63], em toda a rea [37 , 52], andDHTs [64, 57,45].
Semelhante ao nosso objetivo com Sapphire, sistemas de linguagem e do compilador anteriores tentaram unificar o
ambiente distribudo. No entanto, ao contrrio de Sapphire, estas solues no tm flexibilidade. Eles quer tomar todas as
decises de implementao do aplicativo - uma abordagem que no funciona para a ampla gama de requisitos de mobile /
nuvem - ou deixar tudo implantao at o programador.

Compiladores como Coign [32], links [15], Swift [13] e Hop [60] particionar automaticamente aplicaes, mas dar aos
programadores nenhum controle sobre desempenho trade-offs. domnios de idiomas individuais como Node.js [51] e
Google Web Toolkit [29] criar uma linguagem de programao uniforme em todos os navegadores e servidores, mas deixe a
implantao at a aplicao. Para dispositivos mveis, MobileHTML5 [47], MobiRuby [48] e Corona [17] apoiar um nico
idioma crossplatform. Sapphire suporta um ambiente mais completa multi-plataforma, mas os programadores pode
selecionar as implantaes de uma extensa (e extensvel) biblioteca.
espao de endereo nico da DK e modelo de objetos distribudos esto relacionados com a distribuio antecipada
sistemas de programao, como Argus [41], Amoeba [66] e Emerald [35]. Os sistemas modernos como Orleans [10] e
Tango [4] prestao de servios em nuvem ou do lado do servidor. Tecido [42] estende o trabalho neste espao com
abstraes de idiomas que oferecem garantias de segurana. Estes sistemas foram destinados para homogneos, redes de
rea local, por isso no tem a personalizao e extensibilidade da Sapphire DK.
No geral, existente ou sistemas de programao incio distribudos no so de uso geral, flexvel ou extensible o
suficiente para suportar os requisitos de aplicativos mveis / nuvem. Portanto, na concepo de safira, que se inspirou na
obra que tem explorado customizability e extensibilidade em outros contextos: sistemas operacionais [24, 8, 26, 59, 40],
armazenamento distribudo [7, 20, 65, 61, 27], bases de dados [11, 5], e roteadores e switches [36,46].

10 Concluso
Este artigo apresentou Sapphire, um sistema que simplifica o desenvolvimento de aplicaes mobile / nuvem. Implantao
Kernel do Sapphire cria um ambiente integrado com a comunicao independente de localizao em dispositivos mveis e
nuvens. Sua camada de implantao romance contm uma biblioteca de gerentes de implantao que lidam com questes de
distribuio aplicao- especficos, tais como carga-scaling, replicao e caching. Nossa experincia mostra que Sapphire:
(1) facilita enormemente a programao da, nuvem distribudos aplicaes heterogneas / mveis, (2) oferece uma grande
flexibilidade na escolha e mudando decises de implementao, e (3) d aos programadores controle refinado sobre o
desempenho, disponibilidade, e escalabilidade.

Agradecimentos
Este trabalho foi financiado pela National Science Foundation (concede CNS-0963754, CNS-101647, CSR 1.217.597), um
NSF Graduate Fellowship, a Fundao ARCS, uma bolsa de estudo IBM PhD, Google, eo presidente Wissner-Slivka em
Cincia da Computao & Engenharia. Agradecemos ao nosso pastor Doug Terry e os clientes por seus comentrios teis
sobre o papel. Finalmente, gostaramos de agradecer o laboratrio de Sistemas UW por seu apoio e feedback durante todo o
projeto.

Referncias
[1]
A. Adya, G. Cooper, D. Myers, e M. Piatek. Thialfi: Um servio de notificao de cliente para aplicaes em escala
internet. DentroProc.ofSOSP, 2011.
[2]
N. Agrawal, A. Aranya, e C. Ungureanu. sincronizao de dados mveis em um piscar de olhos. Dentro Proc.
ofHotStorage, 2013.
[3]
Apache. Apache Thrift, 2013.http://thrift.apache.org.
[4]
M. Balakrishnan, D. Malkhi, T. Wobber, M. Wu, V. Prab- hakaran, M. Wei, JD Davis, S. Rao, T. Zou, e A. Zuck.
Tango: Distribudo estruturas de dados ao longo de um log compartilhado. DentroProc. ofSOSP, 2013.
[5]
D. Batoory, J. Barnett, JF Garza, KP Smith, K. Tsukuda, B. Twichell, e T. sbio. Genesis: Um sistema de
gerenciamento de banco de dados extensvel.IEEE Transactions on Software Engineering, De 1988.
[6]
N. Belaramani, M. Dahlin, L. Gao, A. Nayate, A. Venkataramani, P. Yalagandula, e J. Zheng. replicao Practi.
DentroProc. ofNSDI, De 2006.
[7]
NM Belaramani, J. Zheng, A. Nayate, R. Soule, M. Dahlin, e R. Grimm. PADS: Uma arquitetura de poltica para
sistemas de armazenamento distribudo. DentroProc. ofNSDI, 2009.
[8]
BN Bershad, S. Savage, P. Pardyak, EG Sirer, ME Fiuczynski, D. Becker, C. Chambers, e S. Eggers. segurana
extensibilidade e desempenho no sistema operacional SPIN. DentroProc. ofSOSP, 1995.
[9]
2006.

M. Burrows. O servio de bloqueio Chubby para sistemas distribudos fracamente acoplados. Dentro Proc. ofOSDI,

[10]
S. Bykov, A. Geller, G. Kliot, JR Larus, R. Pandya, e J. Thelin. Orleans: computao em nuvem para todos.
DentroProc. de SOCC, 2011.
[11]
MJ Carey, DJ DeWitt, JE Richardson, e EJ Shekita. Objeto e gerenciamento de arquivos no sistema de banco de
dados extensvel EXODUS. Departamento de Cincias da Computao da Universidade de Wisconsin, de 1986.
[12]
F. Chang, J. Dean, S. Ghemawat, WC Hsieh, DA Wal- lach, M. Burrows, T. Chandra, A. Fikes e RE Gruber. Bigtable:
Um sistema de armazenamento distribudo para dados estruturados.ACM Transactions em sistemas de computadores, 2008.
[13]
S. Chong, J. Liu, AC Myers, X. Qi, K. Vikram, L. Zheng, e X. Zheng. aplicaes web seguras atravs de
particionamento automtico. DentroProc. ofSOSP, 2007.
[14]
B.-G. Chun, S. Ihm, P. Maniatis, M. Naik, e A. Patti. CloneCloud: execuo Elastic entre o dispositivo mvel e em
nuvem. DentroProc. ofEuroSys, 2011.
[15]

E. Cooper, S. Lindley, P. Wadler, e J. Yallop. Links: Programao Web sem camadas. DentroProc. ofFMCO, De 2006.

[16]
JC Corbett, J. Dean, M. Epstein, A. Fikes, C. Geada, JJ Furman, S. Ghemawat, A. Gubarev, C. Heiser, P. Hochschild,
W. Hsieh, S. Kanthak, E. Kogan, H. Li, A. Lloyd, S. Melnik, D. Mwaura, D. Nagle, S. Quinlan,
R.Rao, L. Rolig, Y. Saito, M. Szymaniak, C. Taylor, R. Wang e D. Woodford. Spanner: banco de dados distribudo-global do
Google. Dentro
Proc. ofOSDIDe 2012.
[17]
Corona SDK, 2013. http://www.coronalabs.com/.
[18]
J. Cowling, Portas DR, B. Liskov, RA Popa, e A. Gaikwad. Censo: gesto de adeso Location-aware para sistemas
distribudos de larga escala.Proc. de USENIX ATC, 2009.
[19]
E. Cuervo, A. Balasubramanian, D.-k. Cho, A. Wolman,
S.Saroiu, R. Chandra e P. Bahl. MAUI: fazer smartphones durar mais tempo com offload cdigo. Dentro
2010.

Proc. de MobiSys, De

[20]
M. Dahlin, L. Gao, A. Nayate, A. Venkataramana, P. Yala- gandula, e J. Zheng. replicao Practi. Dentro Proc. da
INDE, 2006.
[21]
G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian, P. Vosshall e
W. Vogels. Dynamo: altamente disponvel armazenamento de valores-chave da Amazon. DentroProc. ofSOSP, 2007.
[22]
D. Diephouse e P. um Brown.Building
altamente escalvel, de cdigo aberto clone Twitter de 2009.
http://fr.slideshare.net/multifariousprb/
edifcio-a-altamente escalvel-open-source-twitter-clone.
[23]
Dropbox, 2013. http://dropbox.com.
[24]
DR Engler, MF Kaashoek, et ai. Exokernel: Uma arquitetura de sistema operacional para a gesto dos recursos em
nvel de aplicativo. DentroProc. ofSOSP, 1995.
[25]
RT Fielding. Estilos arquitectnicos e do Projeto de
Arquitecturas de Software baseados em rede.Tese de doutorado,
Universidade da Califrnia, Irvine, de 2000.

[26]
B. Ford, G. Voltar, G. Benson, J. Lepreau, A. Lin, e O. Shivers. O Flux OSKit: Um substrato para o kernel e pesquisa
de linguagem. DentroProc. ofSOSP, 1997.
[27]
R. Geambasu, AA Levy, T. Kohno, A. Krishnamurthy, e HM Levy. Comet: Uma loja de valores-chave distribudos
ativa. DentroProc. ofOSDI, De 2010.
[28]
2013.
marketplace / sso.
[29]

https://developers.google.com/google-apps/

Google Web Toolkit. https://developers.google.com/ web-toolkit /, Outubro de 2012.

[30]
MS Gordon, DA Jamshidi, S. Mahlke, ZM Mao, e X. Chen. COMET: Cdigo de descarregar atravs da migrao de
execuo transparente. DentroProc. ofOSDIDe 2012.
[31]

HAProxy: A, de alto desempenho balanceador de carga / HTTP TCP confivel, 2013. http://haproxy.1wt.eu/.

[32]

GC Hunt e ML Scott. O sistema distribudo automtica coign particionamento. DentroProc. ofOSDI, De 1999.

[33]
P. Hunt, M. Konar, FP Junqueira e B. Reed. ZooKeeper: coordenao dos sistemas de escala internet Espera-free.
DentroProc. de USENIXATC, De 2010.
[34]
AD Joseph, AF de Lespinasse, JA Tauber, DK Gifford, e MF Kaashoek. Rover: um kit de ferramentas para acesso
informao mvel. DentroProc. ofSOSP, 1995.
[35]
1987.
[36]
[37]

E. Jul H. Levy, N. Hutchinson, e A. Black. mobilidade de gro fino no sistema de Emerald. Dentro Proc. ofSOSP,
E. Kohler, R. Morris, B. Chen, J. Jannotti, e MF Kaashoek. The Click router modular. DentroProc.ofSOSP, De 1999.
L. Lamport. Paxos feito simples.ACMSigactNews, De 2001.

[38]
C. Leau. Redis dados da Primavera - Retwis-J, 2013.http://docs.spring.io/spring-data/data-keyvalue/ examples /
retwisj / / corrente.
[39]
JB Leners, H. Wu, W.-L. Hung, MK Aguilera, e M. Walfish. Deteco de falhas em sistemas distribudos com a rede
falcon espio. DentroProc. ofSOSP, 2011.
[40]
R. Levin, E. Cohen, W. Corwin, F. Pollack, e W. Wulf. separao Poltica / mecanismo em Hydra. Dentro Proc.
ofSOSP, 1975.
[41]

B. Liskov, D. Curtis, P. Johnson, e R. Scheifler. Implementao do Argus. DentroProc. ofSOSP, 1987.

[42]
J. Liu, MD George, K. Vikram, X. Qi, L. Waye, e AC Myers. Tecido: Uma plataforma de computao distribuda
segura e armazenamento. DentroProc. ofSOSP, 2009.
[43]
W. Lloyd, MJ Freedman, M. Kaminsky e DG Andersen. No se contente com eventual: consistncia causal Scalable
para armazenamento de rea ampla com COPS. DentroProc. ofSOSP, 2011.
[44]
J. Maassen, R. Van Nieuwpoort, R. Veldema, H. Bal,
T.Kielmann, C. Jacobs e R. Hofman. Efficient Java RMI para programao paralela.
de programao, De 2001.

ACM Transactions em Lnguas e sistemas

[45]
P. Maymounkov e D. Mazieres. Kademlia: Um sistema de informao ponto a ponto com base na mtrica XOR.
DentroProc. ofIPTPS, 2002.
[46]
N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar,
L.
Peterson, J. Rexford, S. Shenker, e J. Turner. Abertura de fluxo: Ativando a inovao em redes de campus.ACM
SIGCOMM Comunicao comentrio Computador, 2008.
[47]
[48]
[49]
[50]

MoblieHTML5 de 2013. http://mobilehtml5.org.

MobiRuby de 2013. http://mobiruby.org/.
MySQL, 2013. http://www.mysql.com/.
C. Nester, M. Philippsen e B. Haumacher. A RMI mais eficiente para Java. DentroProc. do Java Grande, De 1999.

[51]

Node.js, 2013. http://nodejs.org/.

[52]
BM Oki e BH Liskov. replicao Viewstamped: Um novo mtodo de cpia primria para apoiar sistemas distribudos
altamente disponveis. DentroProc. ofPODC, 1988.
[53]

Analisar, 2013. http://parse.com.

[54]
M. Philippsen, B. Haumacher e C. Nester. serializao mais eficiente e RMI para Java.Concorrncia: Practice and
Experience, 2000.
[55]
V. Ramasubramanian, TL Rodeheffer, DB Terry,
M.Walraed-Sullivan, T. Wobber, CC Marshall, e A. Vahdat. Cimbiosys: Uma plataforma para a replicao parcial baseada em
contedo. Dentro
Proc. ofNSDI, 2009.
[56]

Redis: servidor estrutura de dados Open Source, 2013. http://redis.io/.

[57]
A. Rowstron e P. Druschel. Pastelaria: Scalable, localizao do objeto descentralizada e encaminhamento para
sistemas peer-to-peer em larga escala. DentroProc. de Middleware, De 2001.
[58]
Amazon S3, 2013. http://aws.amazon.com/s3/.
[59]
MI Seltzer, Y. Endo, C. Pequeno, e KA Smith. Lidando com o desastre: Sobrevivendo extenses de kernel
misbehaved. DentroProc. ofOSDI, 1996.
[60]
De 2006.

M. Serrano, E. Gallesio e F. Loitsch. Hop: uma linguagem de programao da web 2.0. DentroOOPSLA Companion,

[61]
A. Siegel, K. Birman, e K. Marzullo. Engano: Um sistema de arquivos distribudo flexvel. DentroProc. do Workshop
sobre a ofReplicated Data Management, 1990.
[62]

Simple Object Access Protocol. http://www.w3.org/TR/ Sabonete/.

[63]
Y. Sovran, R. Energia, MK Aguilera, e J. Li. armazenamento transacional para sistemas replicados-geo. Dentro Proc.
doSOSP de 2011.
[64]
I. Stoica, R. Morris, D. Karger, MF Kaashoek e H. Balakrishnan. Chord: Um servio escalvel peer-to-peer de
pesquisa para aplicaes de internet. DentroProc. de SIGCOMM, 2001.
[65]
J. Stribling, Y. Sovran, I. Zhang, X. Pretzer, J. Li, MF Kaashoek, e R. Morris. armazenamento, de rea ampla flexvel
para sistemas distribudos com WheelFS. DentroProc. ofNSDI, De 2009.
[66]
AS Tanenbaum, R. Van Renesse, H. Van Staveren, GJ Sharp e SJ Mullender. Experincias com o sistema operacional
Amoeba distribudos.Comum. ACM, 1990.
[67]
DB Terry, MM Theimer, K. Petersen, AJ Demers, MJ Spreitzer e CH Hauser. Gerir conflitos de atualizao em
albufeira, um sistema de armazenamento replicado fracamente ligados. DentroProc. ofSOSP, 1995.
[68]

Twimight cliente Twitter open-source para Android, 2013. http://code.google.com/p/twimight/.

[69]

Voldemort: Um banco de dados distribudo, 2013. http: //www.project-voldemort.com/voldemort/.

[70]

C. Watkins e P. Dayan. Q-learning.Machine Learning, De 1992.

[71]

DA Wheeler. SLOCCount de 2013. http: //www.dwheeler.com/sloccount/.

[72]

balanceador de carga Zen, 2013. http: //www.zenloadbalancer. com /.