Você está na página 1de 34

Prof.

Luiz Fernando Bi1encourt IC - UNICAMP

MC714
Sistemas Distribuídos
1° semestre, 2017
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Tipos de sistemas distribuídos


Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Tipos de SDs
• Sistemas de computação distribuídos
• Sistemas de informação distribuídos
• Sistemas embuJdos (embarcados)
distribuídos
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas de informação distribuídos


Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas de Informação
distribuídos
•  Organizações se defrontaram com uma profusão
de aplicações em rede.
•  Interoperabilidade complicada.
•  Algumas soluções de middleware existentes são
resultado da integração de tais aplicações em um
sistema empresarial
•  Mais fácil que desenvolver todas novamente.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas de Informação
distribuídos
•  Integração em vários níveis.
•  Aplicação (servidor + banco de dados) disponibilizada a
clientes remotos.
•  Cliente envia requisição, recebe resposta.
•  Integração em nível mais baixo: clientes poderiam empacotar
várias requisições para diferentes servidores em uma única
requisição maior.
•  Envio para execução em forma de transação distribuída.
•  Idéia fundamental: ou todas ou nenhuma seria executada.

•  Ex.: reserva passagem, hotel, aluguel de automóvel,


restaurante (groupon), passagem de trem.
•  Com e sem sistema computacional
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas de Informação
distribuídos
•  Aplicações tornaram-se gradualmente separadas em
componentes independentes
•  Componentes de banco de dados e de processamento
•  Integração deveria ocorrer em nível mais alto
•  Comunicação também entre aplicações
•  Indústria de integração de aplicações empresariais
(Enterprise ApplicaJon IntegraJon – EAI).
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Transações
•  Aplicações de bancos de dados costumam ser
realizadas sob a forma de transações.
•  Programá-las requer primiJvas especiais que devem ser
fornecidas pelo sistema distribuído ou pela linguagem
em tempo de execução.
•  Lista de primiJvas depende dos Jpos de objetos que
estão sendo usados na transação.
•  Read e write são primiJvas _picas.
•  Chamadas de procedimento remoto (RPC – remote
procedure calls) costumam ser encapsuladas em
transações – RPC transacional.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Transações
•  BEGIN_TRANSACTION: marca o início de uma transação.
•  END_TRANSACTION: finaliza transação e tenta commit.
•  ABORT_TRANSACTION: mata a transação e restaura
valores anteriores.
•  READ: lê dados de um arquivo, tabela, etc.
•  WRITE: escreve dados em um arquivo, tabela, etc.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Transações
•  Propriedades (ACID):
•  Atomicidade: (para o mundo externo) transação
ocorre de forma indivisível.
•  Consistência: transação não viola invariantes do
sistema.
•  Isolamento: transações concorrentes não interferem
uma na outra.
•  Durabilidade: uma vez dado commit
(“compromeJmento”), as mudanças são
permanentes.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Transações aninhadas
•  Transações aninhadas.
•  Subtransações.
•  1 transação pode gerar subtransações paralelas e distribuídas,
que podem gerar subtransações ...
•  Fig. 25.
•  Problema:
•  Transações em paralelo, uma se compromete, tornando
resultados visíveis à transação-pai.
•  Transação-pai é abortada, restaurando o sistema ao estado
anterior ao início da transação de nível mais alto.
•  Resultados da subtransação compromeJda devem ser anulados –
“permanência” (durabilidade) se aplica somente às transações de
nível mais alto.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Transações aninhadas
•  Profundidade arbitrária.
•  Considerável trabalho administraJvo para conseguir que tudo
esteja correto.
•  SemânJca é:
•  Transação ou subtransação inicia, recebe uma cópia privada de
todos os dados presentes no sistema inteiro, manipulando como
desejar.
•  Se abortar, seu universo privado some.
•  Se comprometer, seu universo privado subsJtui o do pai.
•  Dessa forma, se uma subtransação é compromeJda e mais tarde
uma nova é iniciada, a segunda vê os resultados da primeira.
•  Se uma transação do nível mais alto abortar, todas as subjacentes
também têm de ser abortadas.
•  Fig 26
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Transações aninhadas
•  Importantes em sistemas distribuídos.
•  Modo natural de distribuir uma transação em
várias máquinas.
•  Divisão lógica do trabalho da transação original.
•  Ex: reserva de diversos trechos de vôo.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Transações
•  No início dos middlewares empresariais, componente
que manipulava transações formava o núcleo para
integração de aplicações no nível do servidor ou do
banco de dados.
•  Componente denominado monitor de processamento de
transações (monitor TP).
•  PermiJr modelo de programação transacional para
aplicações.
•  Fig. 27.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Integração de aplicações
empresariais
•  Aplicações passaram a se desvincular dos bancos de
dados sobre os quais eram construídas.
•  Necessidade de integrar aplicações
independentemente de seus bancos de dados.
•  Componentes de aplicação deveriam comunicar-se
diretamente uns com os outros.

•  Integração de aplicações via middleware


•  Fig 28.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Integração de aplicações
empresariais
•  Vários Jpos de middleware de comunicação

•  RPC – remote procedure call: componente de


aplicação pode enviar efeJvamente uma requisição a
outro componente de aplicação executando uma
chamada de procedimento local
•  Empacotamento da requisição como uma mensagem e envio.

•  Orientação a objetos: invocação de método remoto


(remote method invocaJon – RMI). Em essência o
mesmo que RPC, mas funciona com objetos ao invés
de aplicações.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Integração de aplicações
empresariais
•  RPC e RMI: ambos precisam estar ligados (chamador e
chamado) e precisam saber como se referir um ao outro
– esse acoplamento pode ser desvantagem.
•  Middleware orientado a mensagem (MOM)
•  Aplicações enviam mensagem a pontos lógicos de
contato.
•  Aplicações podem indicar interesse por um Jpo
específico de mensagem que o middleware cuidará
para que sejam entregues a essas aplicações.
•  Sistemas publicar/inscrever (publish/subscribe).
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


• SDs até agora: estáveis / nós fixos e
conexões, até certo ponto, permanentes.
•  Alcançado através de diversas técnicas (p.ex. mascarar
falhas, esconder localização, etc)
•  DisposiJvos móveis e embarcados: instabilidade é o
comportamento esperado.
•  Sistemas distribuídos pervasivos (espalhado; difuso...)
•  CaracterísJcas: equipamentos pequenos, bateria,
mobilidade.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


•  Inerentemente distribuído.
•  Configurados pelos proprietários.
•  Descobrir ambiente automaJcamente é desejável.
•  Encaixar-se no ambiente onde está.

•  Requisitos:
•  Aceitar/adotar mudanças de contexto.
•  Encorajar composição ad hoc.
•  Reconhecer comparJlhamento como comportamento
padrão.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


•  Adotar mudanças de contexto:
•  DisposiJvo ciente de que seu ambiente pode mudar conJnuamente.
•  Ex.: descobrir que rede não está disponível porque usuário está se
movimentando. Conectar-se a outra rede ou tomar providências
adequadas.
•  IncenJvar composição ad-hoc
•  DisposiJvos uJlizados de formas diferentes por usuários diferentes
•  Configuração, automáJca ou não, de aplicações tem que ser fácil
•  ComparJlhamento como padrão
•  DisposiJvos se comunicam para trocar informações.
•  Meios para ler, armazenar, gerenciar e comparJlhar informações.
•  ConecJvidade intermitente e dinamicidade de disposiJvos
conectados: espaço de informações muda o tempo todo.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


•  Mobilidade necessita de suporte a adaptação fácil e
dependente de aplicação a seu ambiente local.
•  Descobrir serviços eficientemente e agir de acordo.
•  Existe transparência de distribuição em sistemas
pervasivos?
•  Distribuição de dados e controle é inerente a tais
sistemas.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


Sistemas domésticos

•  1 ou mais computadores pessoais, televisão, backup,
celulares, geladeira, câmeras de vigilância, relógios,
iluminação...
•  Necessidade de autoconfiguração e autogerência
•  Não assumir que usuários finais são capazes ou têm
disposição para configurar e manter em
funcionamento, além de corrigir falhas
•  Primeiro passo: universal plug and play
•  Gerenciamento do espaço pessoal
•  O que comparJlhar, com qual disposiJvo, sob quais
circunstâncias, por quanto tempo, etc
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


Sistemas domésticos

•  Haverá uma máquina que gerencia sistema domésJco?
•  Outros disposiJvos só fornecem interface.
•  Sistemas de recomendação.
•  Dedução do que deve ser colocado no espaço pessoal
de alguém.
•  Metadados para sistemas de recomendação.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


Sistemas de saúde distribuídos

• DisposiJvos de monitoramento de saúde


• Contato automáJco com o médico
• Evitar hospitalização
• Vários sensores em uma rede de área
corporal (body-area network – BAN)
• Preferencialmente sem fio
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


Sistemas de saúde distribuídos

•  Monitoramento de pessoas em um serviço de saúde


pervasivo.
•  (a) concentrador local; ou
•  (b) conexão sem fio con_nua.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


Sistemas de saúde distribuídos

• Questões a serem tratadas:


•  Onde e como dados comparJlhados devem ser
armazenados?
•  Como prevenir perda de dados cruciais?
•  Que infraestrutura é necessária para gerar e propagar
alertas?
•  Como médicos podem fornecer feedback online?
•  Como robustez extrema de sistema de monitoramento
pode ser alcançada?
•  Quais as políJcas de segurança e como políJcas
podem ser impostas?
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


Redes de sensores

•  Redes também usadas para processar


informações, não apenas transmiJ-las.
•  Comunicação sem fio e nós alimentados por bateria.
•  Capacidade restrita de comunicação.
•  Eficiência é importante.
•  Relação com bancos de dados distribuídos
•  “Qual tráfego senJdo norte na rodovia X”.
•  Resposta dada por colaboração entre vários sensores
ao longo da rodovia.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


Redes de sensores

• Dois extremos:
•  Fig 29: armazenamento e processamento somente no
servidor do operador da rede.
•  Fig 30: armazenamento e processamento somente nos
sensores.
• Ambas tem problemas.
•  29: Enviar todos os dados medidos pode ser
desperdício de recursos.
•  30: Despreza capacidade de agregação, o que
retornaria menos dados ao operador.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


Redes de sensores

•  Necessário processamento de dados na rede


•  Árvore com todos os nós, e agregação de
resultados propagados de volta à raiz.
•  Questões:
•  Como configurar uma árvore eficiente em redes
de sensores?
•  Como agregação de resultados acontece? Pode
ser controlada?
•  O que acontece se enlaces falham?
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Sistemas distribuídos pervasivos


Redes de sensores

•  TinyDB: interface de banco de dados em redes sensores


•  Pode usar qualquer algoritmo de roteamento em árvore.
•  Nós intermediários colhem e agregam resultados de seus
filhos.

•  Problema: árvore de uma única raiz pode não ser tão


eficiente se consultas podem parJr de qualquer ponto.
•  Nós especiais que concentram resultados e consultas
relacionadas
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Resumo
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Resumo
•  SDs: computadores autônomos que trabalham juntos
para dar a aparência de um único sistema.
•  Facilita integração de diferentes aplicações que
executam em computadores diferentes.
•  Ampliação fácil.
•  Custo: so{ware mais complexo, menos segurança,
menor desempenho
•  Meta: ocultar parte da complexidade relacionada à
distribuição de processos.
•  Premissas erradas dificultam desenvolvimento. Ex:
latência é baixa.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP

Resumo
•  Tipos diferentes de SDs:
•  Computação: derivado da computação
paralela.
•  Informação: sistemas empresariais, bancos de
dados, intergração de aplicações.
•  Pervasivos: ubiquidade do sistema,
administração distribuída.

Você também pode gostar