Escolar Documentos
Profissional Documentos
Cultura Documentos
MC714
Sistemas Distribuídos
1° semestre, 2017
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
• 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.
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
empresariais
• Vários Jpos de middleware de comunicação
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
• Requisitos:
• Aceitar/adotar mudanças de contexto.
• Encorajar composição ad hoc.
• Reconhecer comparJlhamento como comportamento
padrão.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
• 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
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.