DADist_Tema_02_Texto de apoio

Prévia do material em texto

CURSO DE CIÊNCIA DA COMPUTAÇÃO 
DISCIPLINA: DESENVOLVIMENTO DE APLICAÇÕES DISTRIBUÍDAS 
TEMA 02 – CONCEITOS E ASPECTOS DE PROJETO 
 
TEXTO PARA APOIO AO ESTUDO 
 
1) Contextualização 
 Podemos pensar em computação distribuída como sendo a divisão das aplicações em 
agentes computacionais individuais, que podem ser distribuídos inclusive por uma rede de 
computadores, mas, mesmo assim, ainda trabalham em conjunto para a realização de tarefas 
cooperativas. Há várias razões para se utilizar computação distribuída, dentre algumas delas, 
podemos citar: 
• A solução de um problema, especialmente grande e complexo, dividindo-o em partes 
menores e processá-las por meio de computação paralela pode se tornar possível com 
computadores menores. Ou seja, muitas vezes, não é necessário ter que recorrer a um 
super computador, reduzindo, inclusive os custos. 
• Aplicações que envolvem grandes quantidades de dados podem ser de difícil alocação 
e processamento se não forem utilizados recursos de computação distribuída. 
• A questão de aplicações que demandem maior atenção às falhas pode ser mais 
facilmente atendida por meio do uso de múltiplos agentes conectados em rede de 
computadores, de modo que, se uma máquina tiver algum problema, o trabalho pode 
ser realizado por outra. 
 
2) Conceitos importantes sobre aplicações distribuídas 
 Uma aplicação distribuída é constituída por diferentes camadas. No nível mais baixo, 
uma rede conecta os computadores de modo que seja possível estabelecer a comunicação entre 
eles. Protocolos de rede como TCP/IP possibilitam que os computadores enviem mensagens 
entre si pela rede, de modo que eles possam empacotar e endereçar os dados que serão 
entregues em outra máquina. Serviços de mais alto nível estão no topo dos protocolos de rede. 
Portanto, a aplicação distribuída roda no topo destas camadas, utilizando certos serviços e 
protocolos, objetivando realizar as tarefas de modo coordenado através da rede de 
computadores. 
 Alguns conceitos importantes estão mostrados a seguir. 
2.1) Processos 
Um sistema operacional típico de um computador pode executar vários processos de uma 
vez. Um processo é criado descrevendo uma sequência de passos em uma linguagem de 
programação, compilando o programa para uma forma que permita sua execução em um 
sistema operacional. 
 
2.2) Threads 
Cada processo tem, pelo menos, uma thread de controle. Há sistemas operacionais que 
suportam a criação de múltiplas threads de controle dentro de um único processo. Cada thread 
em um processo pode executar de forma independente das outras threads, embora exista 
alguma sincronização entre elas. Uma thread pode monitorar a conexão de um socket, por 
exemplo, enquanto outra thread pode monitorar eventos provenientes do uso do teclado, etc. 
 
2.3) Objetos 
Programas escritos sob o paradigma de orientação a objetos consideram a cooperação entre 
objetos. E os objetos podem ser definidos como sendo um agrupamento de dados relacionados, 
com métodos disponíveis para realizar alguma ação como a escrita ou leitura dos atributos, etc. 
Um processo pode ser composto por um ou mais objetos e estes objetos podem ser acessados 
por uma ou mais threads dentro de um processo. Além disso, um objeto pode ser distribuído 
através de múltiplos processos em múltiplos computadores. 
 
2.4) Agentes 
O termo “agente” é utilizado para significar, de forma geral, algum elemento que tenha 
alguma função significativa e uma aplicação distribuída. Enquanto uma thread, um processo e 
um objeto são entidades bem definidas, um “agente” é um componente de mais alto nível, 
definido em torno de uma função particular ou papel sobre o sistema. Em uma aplicação remota 
de bankline, por exemplo, pode-se considerar um agente de cliente, agente de transação, etc. 
Os agentes podem ser distribuídos em múltiplos processos, podem ser compostos de múltiplos 
objetos e threads nestes processos. O agente de cliente pode ser composto de um objeto em 
um processo sendo executado no computador do cliente, que está aguardando pela atualização 
das informações solicitadas, juntamente com um processo sendo executado no servidor do 
banco, que processa as requisições do cliente e envia os dados processados para ele. Neste 
exemplo, há dois objetos sendo executados em processos distintos em máquinas separadas, 
mas pode-se considerar que eles se complementam e formam o agente de cliente, com 
elementos do lado do cliente e do lado do servidor. 
As aplicações distribuídas podem ser pensadas como um grupo coordenado de agentes 
trabalhando para realizar alguma tarefa. Cada um destes agentes pode estar distribuído através 
de múltiplos processos em máquinas remotas e podem consistir de múltiplos objetos e threads 
de controle. 
 
2.5) Particionamento e distribuição 
Se pensarmos em computadores e as conexões de rede disponíveis para uma aplicação 
distribuída como sendo uma “máquina virtual”, então, inicialmente, deve-se projetar um 
mapeamento de processos, objetos, threads a agentes para as várias partes da máquina virtual. 
Há situações em que o particionamento cliente/servidor baseado no requerimento dos dados 
pode ser usado. As tarefas computacionais podem ser distribuídas baseadas nas necessidades 
das aplicações: minimizar a transferência de dados na rede, maximizar a quantidade de dados 
para processamento, etc. Por outro lado, em aplicações que demandem processamento mais 
intensivo, pode-se particionar o sistema baseando-se nos requisitos funcionais, com dados 
mapeados para a máquina com maior poder computacional. Este método de particionamento é 
especialmente útil quando a sobrecarga associada à transferência dos dados é insignificante se 
comparada com o tempo de processamento gasto por várias máquinas. 
Portanto, podemos desenvolver módulos baseados no particionamento dos dados e 
funcionalidades. E estes módulos podem ser distribuídos de acordo com a necessidade em 
alguma máquina e conectar estes módulos para estabelecer o fluxo de dados requeridos pela 
aplicação. Estas interconexões entre os módulos devem ser o mais flexível e transparentes 
possível, tendo em vista que podem ser necessários ajustes durante o desenvolvimento ou 
implantação do sistema distribuído. 
 
2.6) Flexibilidade e protocolos de comunicação 
O tipo e o formato das informações enviadas entre agentes em um sistema distribuído estão 
sujeitos a vários requisitos. Alguns deles são o resultado do particionamento dos dados/funções 
descritos no item anterior. A alocação de tarefas e dados para os agentes em um sistema 
distribuído tem uma influência direta no tipo de dados envolvidos na comunicação entre os 
agentes, a quantidade de dados que será transferida, e quão complicado serão os protocolos de 
comunicação entre os agentes. Se a maior parte dos dados está localizada na máquina em que 
eles são necessários, então a comunicação será majoritariamente curta e simples, objetivando 
informar o status e instruir outros agentes a iniciar o processamento, etc. Por outro lado, se 
servidores estão disponibilizando grande quantidade de dados para agentes remotos, então o 
protocolo de comunicação será mais complexo e as conexões entre os nós no sistema 
permanecerão abertas por mais tempo. É importante implementar várias possibilidades de 
comunicação a adaptá-las quando necessário. Os protocolos de comunicação que um dado 
agente precisa entender pode ser proveniente de um sistema legado que, desse modo, precisa 
ser incorporado ao sistema. O suporte a estes protocolos deveria ser, de certa forma, facilmente 
acessível, mas, eventualmente, isso pode não acontecer por diferentes razões. Neste caso, uma 
possibilidade seria desenvolver os protocolos, mas isso depende dos custos envolvidos. 
 
2.7) Multithreading 
Os agentes, frequentemente, lidam com a execução de várias threads de controle de uma 
vez, seja relacionadas à requisição de serviçosde múltiplos agentes remotos, ou por 
processamento de dados, ou por várias outras possíveis causas. Multithreading é comumente 
uma maneira eficiente de otimizar o uso de vários recursos como o tempo de CPU, dispositivos 
de armazenamento local, etc. A habilidade de criar e controlar múltiplas threads de controle é 
especialmente importante no desenvolvimento de sistemas distribuídos, tendo em vista que os 
agentes distribuídos são tipicamente mais assíncronos que os agentes dentro de um processo 
em uma única máquina. O ambiente no qual os agentes estão sendo executados pode ser muito 
heterogêneo e não se quer que os agentes em uma aplicação distribuída sejam escravos ou 
reféns daqueles mais lentos. Seria um desperdício de recursos se um computador servidor com 
multiprocessador ficasse ocioso esperando por um cliente de um desktop leia os resultados da 
resposta de uma requisição. Seria interessante considerar uma única thread no servidor 
destinada a atender ao cliente e enquanto ele estiver lendo os dados ou estiver compondo uma 
requisição como a escrita em um formulário de login e senha. Enquanto isso, outras threads do 
servidor podem realizar outros trabalhos como analisar e processar as requisições de outros 
clientes. 
 
2.8) Segurança 
Os dados transmitidos entre os agentes frequentemente precisam estar seguros de 
observações externas e indesejáveis. Em situações em que um agente externo, que não está sob 
o controle da máquina host, é autorizado a interagir com agentes locais, é altamente 
recomendável ter medidas de segurança disponíveis para autenticar o agente externo, 
objetivando evitar que problemas aconteçam pelo fato dele ter acesos a recursos locais. Então, 
é importante que sistemas distribuídos tenham, pelo menos, alguma forma de autenticar a 
identidade dos agentes, definir níveis de acesso dos agentes, e possibilitar a criptografia dos 
dados transmitidos. 
 
2.9) Transparência 
Os sistemas distribuídos devem ser percebidos como sendo uma entidade pelos usuários ou 
mesmo os desenvolvedores de software. Os usuários e desenvolvedores de software não devem 
ver os sistemas distribuídos como sendo uma coleção de sistemas autônomos, que estão 
cooperando. Ou seja, os sistemas distribuídos devem ser transparentes para eles. 
Existem diferentes tipos de transparências e algumas delas são: 
2.9.1) Transparência de acesso 
Os clientes não devem estar cientes da distribuição de arquivos. Os arquivos podem estar 
presentes em diferentes servidores que estão distantes e o acesso aos arquivos deve ocorrer 
tão bem quanto se acessa arquivos locais. 
2.9.2) Transparência de localização 
Os arquivos podem ser realocados sem alterar o caminho de localização. A transparência do 
nome do local se refere ao fato de que o cliente não tem o nome do local físico onde o arquivo 
está. Esta propriedade é especialmente importante quando for necessário fazer alguma 
alteração de recursos e na disponibilidade de recursos. 
2.9.3) Transparência de falhas 
Como o próprio nome indica, possibilita que os usuários e aplicações completem suas 
tarefas, mesmo quando ocorre alguma falha no sistema. A tolerância de acesso desempenha 
um importante papel na tolerância de falhas porque, se eventualmente ocorre alguma falha em 
alguma máquina, o trabalho pode ser realizado por outra e isso não é percebido pelo cliente. 
 
2.10) Escalabilidade 
A escalabilidade pode ser definida como sendo a habilidade de lidar com o aumento da carga 
de trabalho sem o aumento dos recursos do sistema. Ou seja, a escalabilidade é a habilidade de 
lidar com o aumento da carga por meio de estratégias que permitam ampliar a capacidade do 
sistema. 
Alguns tipos de escalabilidade são: 
2.10.1) Escalabilidade de carga 
Um sistema tem escalabilidade de carga se ele tem a habilidade de funcionar 
normalmente, sem atrasos ou consumo indevido de recursos, mesmo com diferentes gamas de 
cargas de trabalho. 
 
2.10.2) Escalabilidade de espaço 
Um sistema tem escalabilidade de espaço se os requisitos de memória não crescerem a 
limites intoleráveis mesmo quando o número de itens suportados aumentar. 
 
 
2.11) Performance 
Qualquer desenvolvimento de sistemas deve buscar a máxima performance. Mas, no caso 
de sistemas distribuídos, isto é particularmente desafiador, tendo em vista que existem outras 
características que precisam ser observadas (transparência, segurança, escalabilidade, etc) e 
que podem comprometer o desempenho. 
 
2.12) Extensibilidade 
Um sistema distribuído extensível é aquele que permite adicionar ou substituir componentes do 
sistema, objetivando estender ou modificar a funcionalidade do sistema. 
 
2.13) Confiabilidade 
Embora os sistemas distribuídos tenham o potencial para alta disponibilidade devido a 
replicação, a natureza distribuída dos serviços significa que mais componentes tenham que 
trabalhar adequadamente para que um serviço funcione apropriadamente. Portanto, há mais 
potencial de falhas e se a arquitetura do sistema não levar em consideração alguma medida para 
aumentar a confiabilidade, pode ocorrer uma degradação da disponibilidade. Sendo assim, a 
confiabilidade requer consistência, segurança e tolerância a falhas. 
 
2.14) Abertura 
Um sistema distribuído aberto fornece seus serviços de acordo com regras padronizadas e 
permite que múltiplas implementações de componentes padronizados sejam desenvolvidas. 
 
2.15) Interoperabilidade 
Um sistema distribuído que foi desenvolvido pensando na interoperabilidade garante que 
os sistemas implementados sob os mesmo padrões (e possivelmente aqueles que não o foram) 
possam operar entre eles. 
 
 
3) Erros comuns cometidos no desenvolvimento de sistemas distribuídos 
O desenvolvimento de sistemas distribuídos é diferente de sistemas que não são 
distribuídos. Desenvolvedores sem experiência frequentemente fazem considerações 
equivocadas quando desenvolvem sistemas distribuídos pela primeira vez, embora estas 
considerações possam ser válidas para alguns sistemas não distribuídos. Algumas das 
considerações equivocadas são: 
• A conexão é confiável; 
• A latência é zero ou pode ser desprezada; 
• Largura de banda infinita; 
• A rede é segura; 
• A topologia não muda; 
• Custo de transporte é insignificante; 
• Tudo é homogêneo. 
Se estas considerações forem feitas, podem ocorrer dificuldades para se alcançar os 
objetivos do sistema distribuído. Por exemplo, considerando que a rede é confiável pode 
resultar em problema quando houver alguma falha na conectividade. Considerando que a 
latência é zero ou desprezível, pode haver problema de escalabilidade. 
 
4) Paradigmas 
Grande parte dos sistemas distribuídos são baseados em algum paradigma particular 
para descrever a distribuição e comunicação. Alguns destes paradigmas são: 
• Memória compartilhada; 
• Objetos distribuídos; 
• Sistema de arquivos distribuídos; 
• Coordenação distribuída; 
• Arquitetura orientada a serviços e Web Services; 
• Bancos de dados distribuídos; 
• Documentos compartilhados.