Sistemas Distribuídos e Ubíqua

Prévia do material em texto

Aula 1 
https://www.youtube.com/watch?v=34RvRBXzvMo
Ler a apresentação 
”Um sistema distribuído é aquele no qual os componentes localizados em computadores interligados em rede se comunicam e coordenam suas ações apenas passando mensagens” Coulouris et al. 2007
Desta definição, surgem 3 propriedades dos Sistemas Distribuídos:
· Concorrência de componentes 
· Falta de um relógio global 
· Falhas de componentes independentes 
A implementação com sucesso de aplicações para Sistemas Distribuídos deve levar em consideração os itens acima
Os sistemas distribuídos foram inicialmente propostos para o compartilhamento de recursos (arquivos, impressoras, etc) A lista destes recursos foi amplamente estendida ao longo do tempo 
· Serviços
· Componentes
· Processamento
· Comunicação
· Heterogeneidade
· Escalabilidade
· Segurança
· Tratamento de Falhas
· Concorrência
· Transparência
Diferentes tipos de entidades computacionais, controladas por diferentes S.O. e conectadas por diferentes tipos de rede podem compor um sistema distribuído. Os protocolos de rede são usados para tornar a comunicação entre essas entidades transparente. No entanto, algumas aplicações requerem o uso de um Middleware para assegurar a coerência na comunicação
Middleware é um conjunto de funcionalidades e padronizações que atua entre a aplicação e a plataforma (S.O.), oferecendo uma abstração para a comunicação e representação dos dados, permitindo que diferentes aplicações rodando em diferentes plataformas se comuniquem de forma transparente em um SD.
Suponha que diferentes aplicações, escritas em diferentes LP, executando em diferentes S.O. precisem comunicar. Como cada LP oferece a sua própria representação dos dados e meios de comunicação, o Middleware atuaria como uma camada intermediária, para permitir a comunicação corretamente.
Escalabilidade 
Um SD é um sistema aberto. Isto significa que está sujeito a modificações ao longo do tempo. Desta forma, a qualquer momento novas entidades podem ser incorporadas ao sistema, assim como outras entidades podem deixar de existir. O mesmo vale para usuários do sistema e suas requisições. Toda essa dinamicidade deve ser considerada ao implementar um SD. 
Segurança 
Esta certamente é uma das propriedades que mais causam preocupações aos usuários de SD. O compartilhamento de recursos faz com que estes sejam visíveis a outros usuários do sistema, no entanto, eles devem ser protegidos de acessos indevidos. Mecanismos de privilégios de usuário e criptografia são os modos mais usados para garantir a segurança nos SD. Tratamento de falhas
 Os elementos de um SD estão sujeitos a falhas (como qualquer outra entidade computacional). Quando tais falhas forem identificadas, elas devem ser reportadas ao usuário e tratadas, a fim de manter o sistema coerente e confiável
Concorrência
Por existirem diversos elementos em um SD, é possível que múltiplas requisições ou múltiplos acessos sejam realizados ao mesmo recurso, no mesmo instante de tempo. A implementação do sistema deve garantir que todas os acessos/ requisições sejam respondidos (mesmo que a resposta seja negativa) 
Transparência 
Principal objetivo de um SD: acessar recursos ao longo do sistema, como se fossem locais. Essa característica torna os SD acessíveis a todos os tipos de usuários (dos avançados aos leigos) e deve ser preservada
2 - Ler o tópico 
Computação ubíqua (em inglês: Ubiquitous Computing ou ubicomp) ou computação pervasiva é um termo usado para descrever a onipresença da informática no cotidiano das pessoas.[1]
Termo
O termo foi usado pela primeira vez pelo cientista de informática norte americano Mark Weiser (1952 — 1999) em 1988 e publicado em 1991 no seu artigo The Computer for the 21st Century.[2][1]
Também é conhecida pelos termos em língua inglesa de pervasive computing, calm technology, things that think is everywhere, e denomina-se alternativamente de inteligência ambiental. [3][4]
Conceito
Computação ubíqua tem como objetivo tornar a interação humano computador invisível, ou seja, integrar a informática com as ações e comportamentos naturais das pessoas. Não invisível como se não pudesse ver, mas, sim de uma forma que as pessoas nem percebam que estão dando comandos a um computador, mas como se tivessem conversando com alguém. Além disso, os computadores teriam sistemas inteligentes que estariam conectados ou procurando conexão o tempo todo, dessa forma tornando-se assim onipresente.[1][5]
O primeiro passo para conseguir chegar a essa interação mais fácil ou invisível, é a utilização de interfaces naturais, a forma mais primitiva que temos de interagir com algum ser humano, que é a utilização da fala, gestos, presença no ambiente ou até mesmo a movimentação dos olhos, deixando dessa forma o teclado e mouse sem nenhuma utilização.
O segundo passo seria a geração de uma computação sensível a contexto, essa tecnologia torna possível que os dispositivos possam capturar o contexto automaticamente. O contexto nesse caso é a presença de uma pessoa ao espaço ou qualquer tipo de movimento corporal, movimentação dos braços, dedos, cabeça, olhos e até movimentos faciais.
A computação ubíqua requer computadores pequenos, baratos e tecnologias de ligação com ou sem fios a computadores de maior dimensão. Por exemplo, uma casa controlada por dispositivos de computação ubíqua deverá ter controle remoto da iluminação da casa, sistema de extinção de incêndios, sistemas de entretenimento integrados, sistemas para monitorizar a saúde dos ocupantes da casa, uma geladeira que avise aos ocupantes da casa sobre produtos estragados ou fora da validade, etc.
A computação ubíqua apresenta desafios em toda a ciência da computação: no projeto e engenharia de sistemas, na modelagem de sistemas e no design da interface do usuário. Os modelos contemporâneos de interação humano-computador, sejam eles de linha de comando , de menu ou baseados em interface gráfica , são inadequados e inadequados para o caso onipresente. Isso sugere que o paradigma de interação "natural" apropriado a uma computação ubíqua totalmente robusta ainda precisa emergir - embora também haja reconhecimento no campo de que, em muitos aspectos, já estamos vivendo em um mundo ubicomp (veja também o artigo principal sobre Natural user interfaces ). Dispositivos contemporâneos que dão algum suporte a esta última ideia incluem telefones celulares, aparelhos de áudio digital, etiquetas de identificação por rádio frequência, GPS e quadros interativos .
Mark Weiser propôs três formas básicas para dispositivos de sistema onipresentes: guias, blocos e placas.
· Guias: dispositivos portáteis com centímetro
· Pads : dispositivos portáteis de tamanho dissimétrico
· Placas: dispositivos de exibição interativos de tamanho de medidor.
Estas três formas propostas por Weiser são caracterizadas por serem de tamanho macro, tendo uma forma planar e incorporando displays de saída visual. Se relaxarmos cada uma dessas três características, poderemos expandir esse intervalo para uma faixa muito mais diversificada e potencialmente mais útil de dispositivos de computação onipresentes. Assim, três formas adicionais para sistemas onipresentes foram propostas: [5]
· Poeira : os dispositivos miniaturizados podem ser sem displays de saída visual, por exemplo, micro sistemas eletromecânicos ( MEMS ), variando de nanômetros através de micrômetros a milímetros. Veja também Poeira Inteligente .
· Pele : tecidos baseados em polímeros emissores de luz e condutores, dispositivos de computador orgânico, podem ser formados em superfícies de exibição não planas mais flexíveis e produtos como roupas e cortinas, ver display OLED . O dispositivo MEMS também pode ser pintado em várias superfícies, de modo que umas variedades de estruturas físicas do mundo possam atuar como superfícies em rede de MEMS.
· Argila : conjuntos de MEMS podem ser formados em formas tridimensionais arbitrárias como artefatos que se assemelham a muitos tipos diferentes de objetosfísicos (veja também Interface tangível ).
Interoperabilidade com Computação Móvel e Vestível
A computação Ubíqua é um campo de pesquisas em rápido desenvolvimento e graças as tecnologias de computação móvel e vestível. A tecnologia de computação móvel está evoluindo para além de dispositivos celulares, como sistemas de navegação para automóveis interconectados a sistemas de gestão de tráfego, monitoramento e assistência de condutores. Os campos de aplicação da computação móvel ainda não tem seus limites estabelecidos, mas é certa sua interoperabilidade com a computação vestível. A computação vestível é caracterizada principalmente pelos modelos de computação que são desenvolvidos para interagir com o ser humano de maneira natural e independente de interfaces de acionamento comuns aos equipamentos de computação tradicionais. Em teoria, não precisam do constante acionamento de interfaces liga-desliga ou ações similares. Como, por exemplo, um tênis com sensoriamento capaz de enviar para outros sistemas informações como inclinação ou velocidade durante sua utilização. A interoperabilidade permitiria que um tênis com tecnologia de sensor, indicasse para o veiculo do usuário quais os percursos recentes que apresentaram obstáculos nas vias ou outro tipo de informação que seria enviada ao sistema de gestão de tráfego e compartilhadas com outros veículos.
Questões
A privacidade é facilmente a crítica mais citada da computação onipresente (ubicomp) e pode ser a maior barreira para seu sucesso a longo prazo[6].
Um artigo de Linda Little e Pam Briggs sobre esta questão de privacidade, afirma que: "Estes são os tipos de princípios de privacidade que foram estabelecidos pela indústria - mas nos últimos dois anos, temos tentado entender se tais princípios refletem a Algumas das principais questões de pesquisa que estamos abordando são: Quais são as principais preocupações dos usuários em relação à gestão da privacidade em um contexto onipresente e elas refletem os princípios de privacidade 'especialistas'? Essas preocupações variam em função do contexto “Os usuários terão confiança suficiente nos procedimentos de gerenciamento de privacidade para administrar e administrar suas preferências de privacidade? ” Motahari, et al., (2007) argumentam que as pessoas não têm um entendimento completo das ameaças à sua privacidade. Os sistemas estão cientes do uso inadequado de suas informações pessoais, obrigações legais e segurança inadequada, eles estão menos cientes de estabelecer preferências para quem tem acesso e de alguma forma inferências indiretas que podem ser feitas por observações de outras pessoas. Eles argumentam ainda que é necessária uma abordagem holística, já que as abordagens tradicionais e as investigações atuais não são suficientes para abordar as ameaças à privacidade em computação onipresente. Reconhecendo - em consonância com uma série de outros pesquisadores (Harper & Singleton, 2001; Paine, et al., 2007) - que as preocupações com a privacidade tendem a ser altamente dependentes da situação, desenvolvemos um método de pesquisa que exibe um contexto rico para o usuário, a fim de obter informações mais detalhadas sobre os fatores de privacidade que sustentam nossa aceitação da computação onipresente ".
Os problemas de política pública são frequentemente "precedidos por longas sombras, longos trens de atividade", surgindo lentamente, ao longo de décadas ou mesmo ao longo de um século. Há uma necessidade de uma visão de longo prazo para orientar a tomada de decisões políticas, pois isso ajudará a identificar problemas ou oportunidades de longo prazo relacionados ao ambiente de computação onipresente. Essa informação pode reduzir a incerteza e orientar as decisões tanto dos formuladores de políticas quanto daqueles diretamente envolvidos no desenvolvimento do sistema (Wedemeyer et al., 2001). Uma consideração importante é o grau em que diferentes opiniões se formam em torno de um único problema. Algumas questões podem ter um forte consenso sobre sua importância, mesmo que haja grandes diferenças de opinião em relação à causa ou solução. Por exemplo, poucas pessoas vão diferir em sua avaliação de um problema altamente tangível com impacto físico, como terroristas usando novas armas de destruição em massa para destruir a vida humana. As declarações de problemas descritas acima, que abordam a evolução futura da espécie humana ou os desafios à identidade, têm claras implicações culturais ou religiosas e tendem a ter maior variação na opinião sobre elas.
3 - Ler o tópico
Sincronização é o gerenciamento adequado de múltiplas linhas de execução ou processos concorrentes que acedem um mesmo recurso limitado ou uma porção de dados, situação conhecida como condição de corrida.
Este gerenciamento em geral deve prover acesso a todas as linhas de execução dentro dos limites do recurso limitado, de modo que todas tenham tempo finito de espera (não ficarão em espera infinita). No caso de acesso a uma porção de dados, as leituras e escritas realizadas devem ocorrer de modo a preservar a consistência.
Entre os mecanismos que provém sincronização podemos citar os semáforos e exclusão mútua que definem regiões críticas.
Sincronização é útil em programas multitarefa para manter a consistência de dados usados por diversas linhas de execução, em sistemas distribuídos para controlar o acesso de diversos nós a um recurso limitado e bancos de dados para escalonar adequadamente acessos concorrentes à base.
3 -Ler o tópico
Desenvolver sistemas distribuídos confiáveis em uma escala mundial exige uma troca entre consistência e disponibilidade. No mês passado, O CTO da Amazon, Werner Vogels, postou um artigo descrevendo abordagens para tolerar eventuais consistências de dados em sistemas distribuídos de grande escala.
Conforme discutido neste post da InfoQ:
Um dos aspectos chave do papel da arquitetura de sistemas é o de pesar os requisitos conflitantes e decidir por uma solução, freqüentemente pela negociação de um aspecto contra outro.
Um novo post de Werner Vogels, discutiu como estes requisitos fundamentais influenciam os serviços de infra estrutura, fornecendo recursos para a construção de plataformas computacionais em escala de internet.
Dado o escopo mundial destes sistemas, nós usamos técnicas de replicação de forma ubiquita para garantir performance e alta escalabilidade consistente . Embora a replicação nos aproxime de nossos objetivos, não se pode alcançá-la de uma forma perfeitamente transparente, sob uma série de condições os clientes desses serviços serão confrontados com as conseqüências da utilização de técnicas de replicação no interior dos serviços. Uma das formas em que isto se manifesta é no tipo de consistência de dados que é fornecida, particularmente quando o sistema distribuído base fornece um modelo de consistência eventual para a replicação dos dados. Quando desenhando estes sistemas de larga escala na Amazon, nós utilizamos um conjunto dos princípios orientados e abstrações relacionadas à replicação de dados em larga escala e focamos na troca entre a alta disponibilidade e a consistência de dados.
De acordo com Werner, existem duas formas de olhar para a consistência: a partir do ponto de vista do desenvolvedor/cliente - como eles observam a atualização dos dados e a partir do ponto de vista do servidor - como é o fluxo das atualizações através do sistema e que garantias o sistema pode dar no que diz respeito às atualizações.
Os seguintes elementos devem ser considerados quando se define um modelo de consistência no lado do cliente:
Sistema de armazenamento... Alguém deve assumir que por baixo do pano isso é algo de grande escala e altamente distribuído, que é construído para garantir a durabilidade e a disponibilidade...
Processo A. Este é um processo que escreve e lê a partir do sistema de armazenamento.
Processos B e C. Estes dois processos são independentes do processo A e escrevem e lêem a partir do sistema de armazenamento... Consistência no lado do cliente tem a ver com o como equando os observadores (neste caso os processos A, B ou C) vêem as atualizações feitas para um objeto de dados em sistemas de armazenamento.
Consistência forte. Depois de completar as atualizações, qualquer acesso subseqüente (pelo A, B ou C) irá retornar o valor atualizado.
Consistência fraca. O sistema não garante que acessos subseqüentes retornarão o valor atualizado. Uma série de condições precisa ser conhecida antes que o valor seja retornado. O período entre a atualização e o momento em que é garantido que qualquer observador sempre vai olhar o valor atualizado o qual é apelidado como janela de inconsistência.
Consistência eventual. Este é uma forma específica de consistência fraca, o sistema de armazenamento garante que se nenhumas atualizações novas sejam feitas para o objeto, eventualmente todos os acessos retornarão o ultimo valor atualizado. Se não ocorrer falhas, o tamanho máximo da janela de inconsistência pode ser determinado baseado nos fatores tais como os atrasos de comunicação, a carga no sistema e o número de réplicas envolvidas no esquema de replicações.
As variações do modelo de consistência no lado do cliente:são:
Consistência casual. Se o processo A tem comunicado ao processo B que tem atualizado um item de dado, um acesso subseqüente pelo processo B retornará o valor atualizado, e uma escrita é garantida para substituir a escrita anterior. Acesso pelo processo C que não tem relacionamento casual com processo A está sujeito às normais regras da consistência eventual.
Consistência de leitura-da-sua-escrita. Esta é um modelo importante onde o processo A, depois de ter atualizado um item de dados, sempre acessa o valor atualizado e nunca verá o valor antigo. Este é um caso especial do modelo de consistência casual.
Consistência de sessão. Esta é uma versão prática do modelo anterior, onde um processo acessa o sistema de armazenamento no contexto de uma sessão. Enquanto a sessão existir, o sistema garante a consistência da leitura-da-sua-escrita... a garantia não sobrepõem as sessões.
Consistência de leitura monótona. Se um processo tem visto um valor particular para o objeto, qualquer acesso subseqüente nunca retornará quaisquer valores anteriores.
Consistência de escrita monótona . Neste caso o sistema garante serializar a escrita pelo mesmo processo. Sistemas que não garantem este nível de consistência são notoriamente difíceis para programar.
O nível de consistência em um lado do servidor depende de como as atualizações são propagadas entre a réplica de dados (que é uma forma típica de melhorar a taxa de transferência e fornecer a escalabilidade). Consistência fraca/eventual acontece quando nem todas as réplicas de dados participam da operação de atualização e/ou contatado como parte da operação de leitura. Os dois cenários comuns onde esta situação ocorre são replicações sólidas para o escalonamento da leitura e casos com o acesso de dados complicado. Na maioria destes sistemas as atualizações são propagadas de uma maneira lenta para os restantes nodes no conjunto de réplicas. O período até que todas as réplicas tenham sido atualizadas é a janela de inconsistência e todo o sistema é vulnerável para leitura a partir de nodes que ainda não tenham[= recebido as atualizações. O nível de consistência fornecida por um servidor pode ser melhorada através de implementações específicas de comunicação com cliente/servidor ou pelo próprio cliente:
Quer ou não leitura-da-sua-escrita, sessão e consistência monótona podem ser alcançados depende em geral da "rigidez" dos clientes para o servidor que executa o protocolo distribuído para eles. Se este for o mesmo servidor de cada vez, então é relativamente fácil garantir a leitura-da-sua-escrita e as leituras monótonas. Este se torna um pouco mais difícil de controlar o balanceamento de carga e a tolerância de culpa, mas isto é uma solução simples... Às vezes o cliente implementa a leitura-da-sua-escrita e leituras monótonas.. Adicionando versões nas escritas, o cliente descarta os valores de leituras com versões que precedem da última versão vista.
Cada aplicação cliente tem sua própria tolerância à inconsistência fornecida pelo servidor, mas em todos os casos devem estar cientes do nível de consistência que a aplicação do servidor fornece. Há uma série de melhorias práticas para modelo de consistência eventual, como consistência de sessão de nível e leituras monótonas, que fornecem melhores ferramentas para o desenvolvedor.
image1.png