Sistemas Operativos II

1 - Characterization of Distributed Systems

definio:
um SD um sistema em que os componentes situados na rede de computadores
comunicam e coordenam as suas aces apenas por passagem de mensagens.

caractersticas dos SDs:

concorrncia dos componentes;
inexistncia de um relgio global;
falhas independentes dos seus componentes.

recursos:
geridos pelo servidor e acedidos por clientes;
ou encapsulados como objectos e acedidos por outros clientes objectos.

desafios ao construir SDs:

heterogeneidade dos seus componentes;
abertura (permite adio ou substituio de componentes);
segurana;
escalabilidade (habilidade de trabalhar quando a carga ou o nmero de users
aumenta);
tratamento de falhas;
concorrncia dos componentes;
transparncia;
qualidade do servio.
1.1 - Introduction

espao fsico:
os computadores conectados numa rede podem estar, espacialmente, separados por
qualquer distncia (continentes diferentes, mesma sala, mesmo edifcio, etc);

concorrncia:
numa rede de computadores, a execuo de programas concorrentes a norma;
eu num computador, tu noutro e partilhamos ficheiros, etc;
a capacidade do sistema para tratar a partilha de recursos pode ser aumentada
adicionando mais recursos rede (mais computadores, por exemplo).

inexistncia de relgio global:

quando os programas precisam de cooperar, coordenam as suas aces trocando
mensagens;
existem limites para a eficcia com que os computadores numa rede conseguem
sincronizar os seus relgios (no existe uma noo nica do tempo correcto);
pelo que factual que a nica forma de comunicao o envio de mensagens
atravs de uma rede.

falhas independentes:
todos os sistemas de computadores podem falhar e cabe aos system designers
planear as consequncias de possveis falhas;
falhas numa rede resultam no isolamento dos computadores nessa rede (mas no
significa que deixem de estar operacionais);
cada componente do sistema pode falhar individualmente, sendo que as outras
continuam a funcionar.
1.2 - Examples of distributed systems

os SD so utilizados em reas diversas:

finanas e comrcio (e-Commerce, Amazon, eBay, Paypal);
sociedade da informao (World Wide Web como fonte de informao e
conhecimento);
indstrias criativas e entretenimento (jogos, filmes, msicas, youtube);
cuidar da sade (telemedicina, diagnsticos remotos);
educao (e-learning, comunidades);
transporte e logstica (GPS, Google Maps, MapQuest);
cincia (e-Science, anlise e processamento de grandes quantidades de dados);
gesto do ambiente (aviso prvio de catstrofes naturais).

12.1 - Web search

trata-se de uma indstria em crescendo;

a funo de um motor de pesquisa indexar todos os contedos da World Wide Web;
a Google (lder do mercado de web search) tem um design bastante sofistficado do
SD que suporta a pesquisa (tal como de outras aplicaes e servios, como o Google
Earth);

Google:
possui um dos maiores e mais complexos SDs da histria;
infraestrutura fsica subjacente que consiste numa grande quantidade de
computadores em rede situados em data centres por todo o mundo;
um sistema de ficheiros distribudos para suportar ficheiros pesados;
um sistema de armazenamento estruturado associado que oferece acesso
rpido a grandes datasets;
um modelo de programao que suporta a gesto de grandes computaes em
paralelo e distribudas por toda a infraestrutura fsica.
12.2 - Massively multiplayer online games (MMOGs)

milhares de utilizadores interagem atravs na Internet em mundos virtuais;

o desafio dos SDs, deve-se propagao em tempo real de servios e fast response.

12.3 - Financial trading

necessrio existir acesso, em tempo real, a vrias informaes (como preos,

tendncias, evolues econmicas, etc);
aqui so utilizados distributed event-based systems;
eventos porque a informao precisa de ser fivel e rpida.
1.3 - Trends in distributed systems

os SDs passam por mudanas constantes e isso pode ser visto atravs das diversas
tendncias:
a emergncia de tecnologias de rede;
a emergncia de computao ubqua acoplada com o desejo de suportar mobilidade
do user nos SDs;
aumento da procura de servios multimdia;
os SDs como utilidade.

1.3.1 - Pervasive networking and the modern Internet

a Internet moderna uma coleco de redes de computadores interconectadas de

diferentes tipos (WiFi, WiMAX, Bluetooth, redes de telemveis, etc);
os programas a correr nos computadores ligados Internet interagem trocando
mensagens atravs de meios comuns de comunicao;
mecanismos de comunicao da internet (protocolos) fazem com que um programa
em qualquer lugar possa trocar mensagens com outro programa em outro qualquer
lugar, abstraindo-se da tecnologia utilizada;
a Internet , ela mesma, um grande SD uma vez que permite ao uso da WWW, email
e transferncia de ficheiros, independentemente da localizao (WWW diferente de
Internet!);
a firewall tem por objectivo proteger uma intranet prevenindo mensagens no
autorizadas de sair ou entrar.

1.3.2 - Mobile and ubiquitous computing

a portabilidade de muitos dispositivos (telemveis, GPSs, pagers, etc),

juntamente com a sua capacidade de se conectarem a redes, torna o mobile
computing (sendo isto a capacidade de executar tarefas computacionais
enquanto nos movemos) possvel;
ubiquitous computing o aproveitamento de pequenos dispositivos
computacionais que se encontram presentes em ambientes frequentados pelo
utilizador (casa, trabalho, etc).
1.3.3 - Distributed multimedia systems

um SD multimdia deve desempenhar funes como udio, vdeo, transmisses, etc.

1.3.4 - Distributed computing as a utility

surgimento de variadssimos servios medida que os SD amadurecem.

1.4 - Focus on resource sharing

partilha de dispositivos como impressoras, discos, etc, de forma a reduzir custos;

servidor (programa em execuo, um processo, num computador ligado a uma rede
que aceita pedidos de programas em execuo noutros computadores para executar
um servio a responder apropriadamente);
cliente (pedidos);
uma interaco completa entre cliente e servidor, desde o ponto em que o cliente
envia o pedido at receber a resposta do servidor, chamada de invocao remota;
o mesmo processo pode ser ambos cliente e servidor, uma vez que os servidores, s
vezes, invocam operaes noutros servidores;
os clientes so activos (fazem pedidos), enquanto que os servidores so passivos (s
acordam quando recebem pedidos);
os clientes duram tanto quanto as aplicaes das quais eles fazem parte, enquanto em
que os servidores esto em execuo contnua.
1.5 - Challenges

os exemplos na seco 1.2 tm como objectivo ilustrar o que so SDs, a respectiva

scope e os problemas que surgem no design de SDs;
para a maior parte dos desafios, foi encontrada a soluo, no entanto, outros desafios
vo ser encontrados (nesta seco, falamos sobre esses desafios).

1.5.1 - Heterogeneidade

a Internet permite aos seus users aceder a vrios aceder a servios e executar
aplicaes atravs de uma coleco de computadores e redes;

a heterogeneidade a variedade de recursos e um conceito que se aplica seguinte

lista:
redes;
hardware de computadores;
sistemas operativos;
linguagens de programao;
implementaes por parte de developers diferentes.

apesar da Internet consistir de vrios tipos de redes, as suas diferenas assentam no

facto de todos os computadores ligados a essas redes utilizarem os protocolos da
Internet para comunicarem entre si;

alguns exemplos:
data types como inteiros podem ser representados de formas diferentes em diferentes
tipos de hardware (deve-se lidar com isto se se forem trocar mensagens entre
programas a correrem em diferentes hardwares);
os SOs de todos os computadores precisam de ter uma implementao dos
protocolos da Internet (e nem todos os protocolos precisam ter a mesma interface, por
exemplo, a troca de mensagens diferente em UNIX e Windows);
as diferentes linguagens de programao utilizam representaes diferentes para chars
e EDs (tais como arrays e records);
programas escritos por developers diferentes no conseguem comunicar entre si a
menos que utilizem standards comuns (por exemplo, para a representao de tipos
primitivos de data e EDs nas mensagens - para tal, temos os protocolos da Internet);
 Middleware:

middleware o termo que se aplica camada de software que providencia uma

abstraco de programao tal como uma mscara da heterogeneidade das redes
subjacentes, do hardware, dos SOs e das linguagens de programao ( um exemplo
comum o CORBA (Common Object Request Broker) que descrito mais frente);
outro middleware como o RMI (Java Remote Invocation) suporta apenas uma
linguagem de programao (mais sobre isto no Captulo 5);
maior parte do middleware implementado em cima dos protocolos da Internet
(protocolos estes que, por sua vez, tapam as diferenas das redes subjacentes);
todo o middleware lida com as diferenas nos SOs e no hardware (mais sobre isto no
Captulo 4);
mais que resolver os problemas relacionados com a heterogeneidade, o middleware
providencia um modelo computacional uniforme para ser utilizado pelos
programadores de servidores e de aplicaes distribudas;
possveis modelos incluem invocao remota de objectos, notificaes de eventos
remotos, acesso remoto ao SQL e processamento de transaces distribudas (por
exemplo, o CORBA oferece invocao remota de objectos o que permite a um
objecto num programa que est em execuo num computador invocar um mtodo de
um objecto de um programa que est em execuo num outro computador (a sua
implementao esconde o facto das mensagens so passadas por uma rede de modo a
enviar o pedido de invocao e a sua resposta))

Heterogeneidade e mobile code:

o termos mobile code refere-se ao ao program code que pode ser transferido de um
computador para outro e ser executado no seu destino (Java applets, por exemplo);
a abordagem da virtual machine uma forma de tornar o cdigo executvel numa
variedade de computadores host (isto , um compilador para uma linguagem em
particular gera cdigo para a virtual machine em vez de cdigo para um hardware em
particular (por exemplo, o compilador do Java produz cdigo para a JVM que o
executa por interpretao (a JVM precisa de ser implementada uma vez para cada tipo
de computador para permitir que os programas Java corram);
a forma mais usada de mobile code a incluso de programas Javascript em algumas
pginas web carregadas para client browsers (mais sobre isto em 1.6).
1.5.2 - Openness

a abertura de um sistema de computador a caracterstica que determina se um

sistema pode ser estendido e re-implementado de vrias formas;
a abertura dos SDs determinada, primeiramente, pelo grau no a que novos servios
resource-sharing podem ser adicionados e tornados disponveis para serem
utilizados por uma variedade de programas cliente;
a abertura no pode ser alcanada a no ser que a especificao e a documentao das
interfaces de key software dos componentes de um sistema sejam tornadas
disponveis para os software developers (isto , as key interface so publicadas);
a publicao de interfaces apenas o starting point para adicionar e estender
servios num SD;
o desafio dos designers abordar a complexidade dos SDs (que, por sua vez,
consistem de variadssimos componentes projectados por pessoas diferentes);
os designers dos protocolos da Internet introduziram uma srie de documentos
chamados RFCs (Request For Comments) cada um deles conhecido por um
nmero;
os RFCs no so o nico meio de publicao, por exemplo, o W3C (World Wide
Web Consortium) desenvolve e publica standards relacionados com o
funcionamento da Web;
os sistemas desenhados para suportar partilha de recursos desta forma, so
denominados open distributed systems para enfatizar o facto de serem extensveis;
eles podem ser extensveis ao nvel do hardware adicionando computadores rede ao
nvel de software introduzindo novos servios e a re-implementando os antigos,
fazendo com que as aplicaes possam partilhar recursos;
outra vantagem dos open systems a sua independncia de fornecedores individuais;

sumarizando:
open systems so caracterizados pelos facto de os seus key interfaces serem
publicados;
open distributed systems so baseados num mecanismo uniforme de comunicao e
interfaces publicadas para acesso de recursos partilhados;
open distributed systems podem ser construdos a partir de hardware e software
heterogneos (possivelmente de diferentes fornecedores), no entanto, a conformidade
de cada componente deve ser cuidadosamente testada e verificada para o sistema
funcionar correctamente.
1.5.3 - Security

maior parte da informao que est disponvel nos SDs tem um enorme valor para os
seus users, pelo que a sua segurana de extrema importncia;

a segurana para recursos de informao tem trs componentes:

confidencialidade (proteco contra a divulgao a indivduos no autorizados);
integridade (proteco contra alterao ou corrupo);
disponibilidade (proteco contra a interferncia com meios de acesso a recursos).

o facto de existir comunicao seja qual for a localizao, traz riscos ao nvel da
segurana associados ao facto de existir acesso livre a recursos da intranet (no
entanto, pode-se usar uma firewall para formar uma barreira volta da intranet,
restringindo o trfego que pode entrar e sair apesar de isto no garantir o uso
apropriado de recursos pelos users na intra net ou o uso de recursos na Internet (que,
neste caso, no esto protegidos por uma firewall));
num SD, os clientes enviam pedidos de acesso para aceder a dados geridos pelos
servidores o que envolve enviar informao em mensagens atravs de uma rede (por
exemplo, um Dr. pedir acesso aos dados de um paciente ou adicionar dados ficha
desse paciente, entre outros);
a segurana no se trata s de esconder o contedo das mensagens, tambm
envolve ter a certeza da identidade do user ou do agente em nome de quem a
mensagem foi enviada (no exemplo anterior, o servidor precisa de saber que o user
mesmo um Dr.);
para resolver este tipo de problema, existe o uso de tcnicas de encriptao
desenvolvidas para este propsito (mais sobre isto no Captulo 11);

apesar de tudo isto, existem ainda dois desafios ao nvel da segurana que ainda no
tm uma soluo universal:
denial of service attack, que consiste em bombardear o servio com um nmero
anormal de pedidos inteis de forma a que os users a srio, reais sejam incapazes
de utilizar o servio (mais sobre isto no Captulo 3);
security of mobile code, considerando que algum recebe um executvel de um
programa como anexo de um mail, os possveis efeitos de executar tal programa so
imprevisveis (mais sobre isto no Captulo 11).
1.5.4 - Scalability

os SDs operam de maneira efectiva e eficiente a diferentes escalas, desde uma

pequena intranet at Internet;
um sistema considera-se escalvel se continua efectivo quando existe um aumento
significativo no nmero de recursos e no nmero de users;
o nmero de computadores e de servidores na Internet tem vindo a aumentar
drasticamente;

o design de SDs escalveis apresenta alguns desafios:

controlar os custos de recursos fsicos, com o aumento da procura de recursos, deve
ser possvel estender um sistema a um custo razovel (por exemplo, a frequncia com
que ficheiros so acedidos numa intranet cresce medida que o nmero de users e de
computadores cresce, pelo que deve ser possvel adicionar computadores servidor
para evitar problemas de desempenho (em geral, num sistema com n users, para ser
escalvel, a quantidade de recursos fsicos para suportar esses users deve ser de O(n)
(mais sobre isto no Captulo 12)));
controlar a perda de desempenho, considerando a gesto de um conjunto de dados
cujo tamanho proporcional ao nmero de users ou recursos no sistema (por
exemplo, uma tabela com a correspondncia entre os nomes do domnio dos
computadores e os seus endereos de Internet mantidos no DNS (Domain Name
System) que utilizado principalmente para procurar nomes DNS (tais como
www.amazon.com) os algoritmos que utilizam estruturas hierrquicas escalam
melhor do que aqueles que utilizam estruturas lineares (mas, mesmo com estruturas
hierrquicas, um aumento do tamanho resulta em perda de desempenho, sendo O(log
n) o tempo que leva a aceder a uma estruturas hierrquica (onde n o tamanho de um
conjunto de dados)), ou seja, para um sistema ser escalvel, a perda de desempenho
mximo no deve exceder este limite;
evitar que os recursos de software esgotem, um exemplo de falta de escalabilidade
so os nmeros utilizados como endereos de IP da Internet que seriam de 32 bits
mas, como seria de esperar, a disponibilidade de endereos da Internet est a esgotar
(mais sobre isto no Captulo 3) pelo que um novo protocolo que prev endereos de
128 bits est a ser adoptado (o que vai fazer com que hajam modificaes em vrios
componentes de software);
evitar bottlenecks de desempenho, em geral, os algoritmos devem ser
descentralizados para evitar bottlenecks de desempenho (por exemplo, o
predecessor do DNS (Domain Name System), no qual o nome da tabela era mantido
num nico master file que podia ser downloaded por qualquer computador que
precisasse dele, tornou-se uma bottleneck quando deixaram de haver apenas
algumas centenas de computadores na Internet, ou seja, rapidamente se tornou numa
bottleneck sria de desempenho e administrativa (mais sobre isto nos Captulos 3 e
13);

seria ideal o sistema e o software no mudarem quando a escala do sistema aumenta.

1.5.5 - Failure handling

os sistemas de computador tambm falham e, quando ocorrem falhas no hardware ou

no software, os programas podem produzir resultados incorrectos ou podem deixar de
funcionar antes de ter conseguido completar a computao pretendida (mais sobre isto
no Captulo 2);
as falhas no SD so parciais, isto , alguns componentes podem falhar enquanto que
outros continuam a funcionar, pelo que o tratamento de falhas particularmente
difcil;

no entanto, existem algumas tcnicas para lidar com falhas, tais como:
deteco de falhas, algumas falhas podem ser detectadas, por exemplo, checksums
podem ser utilizadas para detectar dados corrompidos numa mensagem ou num
ficheiro (no Captulo 2 explicado que muito difcil ou mesmo impossvel de
detectar algumas outras falhas, tal como um servidor remoto na Internet que tenha
crashado, ou seja, o desafio a gesto de falhas que no possam ser detectadas
mas que possam ser suspeitadas;
esconder as falhas, algumas falhas podem ser escondidas ou tornadas menos notrias
(por exemplo, mensagens podem ser retransmitidas quando no chegam ao
destinatrio ou um ficheiro pode ser escrito em dois discos para que, caso um esteja
corrompido, o outro ainda possa estar correcto);
tolerncia a falhas, muitos servios da Internet exibem falhas (no seria prtico
tentar detectar e esconder todas as falhas que possam ocorrer numa rede to grande
com tantos componentes, por exemplo, quando um web browser no consegue
contactar com um web server, no faz o user esperar, informa-o do problema);
recuperar de falhas, envolve que o design do software seja tal que permita que o
estado permanente dos dados possa ser recuperado (ou rolled back) aps um
servidor ter crashado (mais sobre isto no Captulo 17);
redundncia, os servios podem ser feitos de modo a tolerar falhas utilizando
componentes redundantes (por exemplo, deve existir sempre (no mnimo) duas rotas
diferentes entre quaisquer dois routers na Internet ou, outro exemplo, no DNS cada
nome de tabela replicado em, pelo menos, dois servidores diferentes, etc);

os SDs providenciam um elevado grau de disponibilidade no que toca s falhas do

hardware (a disponibilidade de um sistema uma medida da proporo de tempo que
est disponvel para uso).
1.5.6 - Concurrency

tanto os servidores como as aplicaes fornecem recursos que podem ser partilhados
pelos clientes num SD, pelo que existe a possibilidade de vrios clientes tentarem
aceder a um recurso partilhado ao mesmo tempo (por exemplo, uma ED que grava
lances para um leilo pode ser acedida vrias vezes medida que se aproxima o fim
do leilo);
os servios e aplicaes, geralmente, permitem que mltiplos pedidos de clientes
possam ser processados concorrentemente (supondo que cada recurso est
encapsulado como um objecto e as suas invocaes so executadas em threads
concorrentes, neste caso, possvel que vrias threads possam estar a executar
concorrentemente dentro de um objecto, o que faria com que houvesse conflito de
ambas as operaes e houvesse uma produo inconsistente de resultados);
ou seja, qualquer objecto que represente um recurso partilhado num SD deve ser
responsvel por assegurar que funciona correctamente num ambiente concorrente
(isto aplica-se tanto a servidores como a objecto em aplicaes) pelo que a
implementao de um objecto cujo o objectivo no era ser usado num SD deve fazer o
que for necessrio para que o objecto seja seguro num ambiente concorrent;
para um objecto ser seguro num ambiente concorrente, as suas operaes devem ser
sincronizadas de tal modo que os seus dados se mantenham consistentes (isto pode ser
alcanado atravs de tcnicas standard, tais como semforos, que so utilizados na
maior parte dos SOs (mais sobre isto nos Captulos 7 e 17)).
1.5.7 - Transparency

a transparncia define-se por ocultar do user e do programador da app as

componentes num SD para que o sistema seja visto como um todo e no como uma
coleco de componentes independentes;
o ANSA Reference Manual (ANSA 1989) e o International Organization for
Standardizations Reference Model for Open Distributed Processing (RM-ODP [ISO
1992]) identificam oito formas de transparncia;

formas de transparncia:
transparncia de acesso, possibilita que recursos locais e remotos sejam acedidos
utilizando operaes idnticas;
transparncia de localizao, possibilita que os recursos sejam acedidos sem ser
conhecida a sua localizao fsica ou de rede (por exemplo, o edifcio (fsica) ou o IP
(rede));
transparncia da concorrncia, possibilita que vrios processos operem de forma
concorrente utilizando recursos partilhados sem que haja interferncia entre eles;
transparncia da replicao, possibilita que mltiplas instncias de recursos serem
utilizadas para aumentar a confiabilidade e o desempenho sem que os users e os
programadores das aplicaes tenham conhecimento das rplicas;
transparncia de falhas, possibilita ocultar falhas permitindo aos users e aos
programadores das aplicaes completarem as suas tarefas independentemente das
falhas ocorrerem ao nvel do hardware ou do software;
transparncia da mobilidade, permite o movimento de recursos e clientes dentro de
um sistema sem afectar as operaes de users ou programas;
transparncia de desempenho, permite ao sistema ser reconfigurado para melhorar o
desempenho medida que a carga varia;
transparncia da escalabilidade, permite ao sistema e aplicaes expandirem em
escala sem modificar a estrutura do sistema ou os algoritmos das aplicaes.

as transparncias mais importantes so as duas primeiras (acesso e localizao) uma

vez que a sua presena ou ausncia afecta a utilizao de recursos distribudos (pelo
que, em conjunto, so definidas como transparncia da rede);
como exemplo de transparncia, temos uma API para ficheiros que utiliza as mesmas
operaes para a aceder a ficheiros locais ou remotos (mais sobre isto no Captulo
12);
como exemplo de falta de transparncia de acesso, consideramos um SD que no
permita o acesso a ficheiros num computador remoto a menos que faamos uso de um
programa ftp para ter acesso a eles;
 os URLs so transparentes quanto localizao porque a parte do URL que
identifica o domnio do web server refere-se a um nome de um computador num
domnio (em vez de a um um endereo da Internet);
os URLs no so transparentes quanto mobilidade porque uma pgina de web
pessoal no se poder mover para o novo posto de trabalho num domnio diferente
(todos os links noutras pginas continuam a apontar para a pgina original);
no geral, identificadores como os URLs (que incluem o nome dos domnios dos
computadores, previnem a transparncia quanto replicao;
para ilustrar a transparncia quantos s falhas (utilizando o contexto dos mails
electrnicos), pois os mails sero entregues (eventualmente) mesmo quando os
servidores ou as ligaes de comunicao falham (as falhas so masked pela
tentativa de retransmisso das mensagens at serem entregues, mesmo que demore
vrios dias (normalmente, o middleware converte as falhas das redes e dos processos
em excepes ao nvel da programao (mais sobre isto no Captulo 5);
para ilustrar a transparncia quanto mobilidade, supomos que dois users esto em
partes diferentes de um pas, a viajar, e fazem uma chamada (esses users
desconhecem a mobilidade dos telemveis).

1.5.8 - Quality of service

uma vez que os users obtenham as funcionalidades que pretendiam, tal como um
servio de ficheiros num SD, podemos perguntar sobre a qualidade do servio;
as principais propriedades dos sistemas que afectam a qualidade do servio
experienciada pelos clientes e pelos users so a confiabilidade, segurana e o
desempenho (pelo que a adaptabilidade para mudar as configuraes do sistema e a
disponibilidade de recursos reconhecido como um aspecto importante da qualidade
do servio;
a confiabilidade e a segurana so crticos no design da maior parte dos sistemas de
computadores.
1.6 - Case study: The World Wide Web

a World Wide Web [www.w3.org I, Berners-Lee 1991] um sistema envolvente para

publicar e aceder a recursos e servios por toda a Internet ( atravs dos browsers
comuns que os users vm documentos, ouvem streams, interagem com um conjunto
ilimitado de servios, etc);
a vida da Web comeou no European centre for nuclear research (CERN), na Suia,
em 1989, como um veculo de troca de documentos entre uma comunidade de fsicos
conectados pela Internet;
a Web um sistema aberto, isto , pode ser estendido e implementado de novas
formas sem perturbar as suas funcionalidades j existentes (ver Seco 1.5.2);
a Web baseada em trs principais componentes tecnolgicos padro:
a HyperText Markup Language (HTML), uma linguagem para especificar os
contedos e layouts das pginas tal como eles nos so mostrados pelos web browsers;
Uniform Resource Locators (URLs), tambm conhecidos como Uniform Resource
Identifiers (URIs), que identificam documentos e outros recursos guardados como
parte da Web;
uma arquitectura de sistema client-server com regras padro para interaco (o
HyperText Transfer (HTTP)) pelo qual os browsers e outros clientes fazem fetch
(tiram) documentos e outros recursos dos web servers (uma caracterstica importante
que os users possam localizar e gerir o seu prprio web server em qualquer stio da
Internet);

HTML:
utilizado para especificar o texto e as imagens que fazem o contedo de uma pgina
web e para especificar como so apresentados ao user
os users conseguem produzir HTML mo, utilizando um editor de texto.

URLs:
o propsito de um Uniform Resource Locator (URL) identificar um recurso;
os browsers examinam os URLs para aceder aos recursos correspondentes, isto ,
normalmente, o browser procura o URL correspondente quando o user clica num link
ou quando o browser faz fetchde um recurso embebido numa pgina web (como
uma imagem);
um URL HTTP tem dois objectivos principais (identificar em que web server se
encontram os recursos e identificar qual dos recursos do web server se pretende).

Publicar um recurso:
enquanto que tem um modelo bem definido para aceder a recursos atravs do seu
URL, publicar recursos vai depender da implementao do web server.
 HTTP:
define de que maneiras os browsers e outros clientes interagem com os web servers
(mais sobre isto no Captulo 5);
Request-reply interactions, o HTTP um protocolo request-reply em que o cliente
envia um pedido de mensagem ao servidor que contm o URL do recurso pretendido,
depois o servidor procura o nome do caminho e, caso exista, envia de volta o
contedo pretendido como mensagem de resposta ao cliente (caso contrrio, envia
uma resposta como 404 Not Found);
Content types, os browsers no necessariamente capazes de tratar todo o tipo de
contedos;
One resource per request, os clientes especificam um recursos por pedido HTTP (por
exemplo, se uma pgina web tem nove imagens o web browser ir tratar dez pedidos
separados para obter a totalidade dos contedos da pgina (os browsers, tipicamente,
fazem vrios pedidos concorrentemente para reduzir o delay geral para o user);
Simple access control, regra geral, qualquer user com uma ligao rede a um web
server consegue aceder a qualquer dos seus recursos publicados.

Dynamic pages:
a maior das experincias dos users com a Web interagir com servios em vez de
recuperar dados;
por exemplo, o preenchimento de um formulrio est sujeito ao input do user, pelo
que o servidor tem de processar esse input, portanto, o URL designa um programa no
servidor (e no um ficheiro);
caso o input do user seja um conjunto razoavelmente pequeno de parmetro,
comummente enviado como o componente query do URL, utilizando o mtodo GET,
alternativamente, enviado como data adicional no pedido utilizando o mtodo
POST;
um programa que os web servers executam para gerar contedo para os seus clientes
referido como Common Gateway Interface (CGI), um programa CGI deve
conseguir analisar os argumentos que o cliente fornecer e produzir o contedo
pretendido (normalmente texto HTML), sendo que o programa vai, com frequncia,
consultar ou actualizar a base de dados ao processar o pedido.
 Download Code:
um programa CGI executado no servidor;
s vezes, os designers dos servios web precisam de cdigo service-related para
executar dentro do browser, no computador do user (em particular, cdigo escrito em
Javascript [www.netscape.com] downloaded com frequncia com a pgina web,
contendo um formulrio de maneira a fornecer melhor qualidade na interaco com o
user do que aquela que os widgets padro do HTML permitem;
uma pgina Javascript melhorada pode dar ao user feedback instantneo de entradas
invlidas em vez de forar o user a verificar os valores no servidor o que iria demorar
muito mais;
o Javascript pode tambm ser utilizado para actualizar partes do contedo de uma
pgina web sem fazer fetch de uma verso completamente nova da pgina e
proceder sua re-renderizao (estes updates dinmicos ocorrem devido a aces do
user (clicar num link ou num radio button) ou quando o browser receber nova data
do servidor (neste caso, uma vez que o tempo de chegada da data no est
relacionada com nenhuma aco do user, denominada assncrona (uma tcnina
conhecida como AJAX (Asynchronous Javascript And XML) utilizada nestes casos
(mais sobre isto na Seco 2.3.2)));
uma alternativa a uma programa Javascript uma applet (uma app escrita na
linguagem Java [Flanagan 2002]) que o browser downloads automaticamente e
executa quando faz fetch da pgina web correspondente (mais sobre applets na
Seco 2.3.1).

Web services:
at agora, discutimos a Web, quase na totalidade, do ponto de vista do browser do
user;
no entanto, outros programas alm dos browsers, podem, tambm, ser clientes da
Web (...).

Discussion of the Web:

o sucesso da Web tem por base a facilidade com que fontes individuais ou
organizacionais podem publicar recursos, a aptido da sua estrutura hypertext para
organizar vrios tipos de informao e a abertura da arquitectura do seu sistema;
os motores de pesquisa so uma alternativa popular como modo de encontrar
informao na Web mas so imperfeitos a produzir o que o user quer especificamente
(uma soluo para este problema, exemplificada no Resource Description Framework
[www.w3.org V], produzir vocabulrios padro, sintaxe e semntica para exprimir
metadata sobre as coisas no nosso mundo e encapsular essa metadata em
recursos web correspondentes para acesso programtico);
ou seja, em vez de procurar palavras que ocorrem em pginas Web, os programa
podem procurar com a metadata para compilar listas de links relacionados
baseados na correspondncia por semntica (colectivamente, os recursos da web de
linked metadata so conhecidos por semantic web);
como arquitectura de sistema, a Web, enfrenta um problema de escala devido aos
hits por segundo em servidores populares (possveis solues no Captulo 2).
1.7 - Summary

os SDs esto por toda a parte;

a Internet permite aos users (que esto em todas as partes do mundo) aceder a
servios, seja qual for a sua localizao;
cada organizao gere uma intranet que, por sua vez, fornece servios locais a
servios de Internet aos users locais e, geralmente, fornece servios a outros users da
Internet;
pequenos SDs podem ser construdos a partir de mobile computers e de outros
pequenos dispositivos computacionais que estejam ligados a uma rede wireless;
a partilha de recursos o maior factor de motivao na construco de SDs;
recursos como impressoras, ficheiros, pginas web ou registos de bases de dados so
geridos por servidores de tipo apropriado;
os clientes acedem a recursos (por exemplo, os clientes dos servidores web so,
geralmente, chamados browsers);

a construco de SDs produzem muitos desafios:

Heterogeneidade, os SDs devem ser construdos de uma variedade de diferentes
redes, SOs, hardware e LPs (os protocolos de comunicao da Internet mascaram
a diferenas nas redes, e o middleware lida com as outras diferenas;
Abertura, SDs devem ser extensveis, isto , o primeiro passo publicar as interfaces
dos componentes, mas a integrao dos componentes escritos por diferentes
programadores um grande desafio;
Segurana, a encriptao pode ser usada para fornecer uma proteco adequada dos
recursos partilhados e manter a informao sensvel secreta quando esta transmitida
em mensagens atravs da rede (no entanto, os ataques Denial of service continuam a
ser um problema);
Resoluo de falhas, qualquer processo, computador ou rede pode falhar
independentemente dos outros, pelo que cada componente deve estar ciente das
possibilidades em que outras componentes das quais dependem podem falhar e o seu
design deve lidar com cada uma dessas falhas apropriadamente;
Concorrncia, a presena de mltiplos users num SD a fonte de pedidos
concorrentes aos recursos desse SD, pelo que o design de cada recurso deve visar a
segurana no ambiente concorrente;
Transparncia, tem por objectivo tornar certos aspectos da distribuio invisveis ao
programador da app para que ele s se preocupe com o design da sua app em
particular (por exemplo, no devem estar preocupados com a sua localizao, com ir
ser replicada ou migrada, at mesmo as falhas das redes e dos processos podem ser
apresentadas aos programadores das app na forma de excepes (mas tm de ser
tratadas);
os detalhes de como as suas operaes so acedidas por outros componentes ou se
Qualidade do servio, no suficiente fornecer acesso aos servios nos SDs, devem
existir, tambm, garantias tendo em conta as qualidades associadas com o acesso a
esse servio, tais como: desempenho, segurana, e confiabilidade.
Exercises

1.1 Give five types of hardware resource and five types of data or software resource that can
usefully be shared. Give examples of their sharing as it occurs in practice in distributed
systems. (pages 2, 14)

1.2 How might the clocks in two computers that are linked by a local network be
synchronized without reference to an external time source? What factors limit the
accuracy of the procedure you have described? How could the clocks in a large number
of computers connected by the Internet be synchronized? Discuss the accuracy of that
procedure. (page 2)

1.3 Consider the implementation strategies for massively multiplayer online games as
discussed in Section 1.2.2. In particular, what advantages do you see in adopting a single
server approach for representing the state of the multiplayer game? What problems can
you identify and how might they be resolved? (page 5)

1.4 A user arrives at a railway station that they has never visited before, carrying a PDA that
is capable of wireless networking. Suggest how the user could be provided with
information about the local services and amenities at that station, without entering the
stations name or attributes. What technical challenges must be overcome? (page 13)

1.5 Compare and contrast cloud computing with more traditional client-server computing?
What is novel about cloud computing as a concept? (pages 13, 14)

1.6 Use the World Wide Web as an example to illustrate the concept of resource sharing,
client and server. What are the advantages and disadvantages of HTML, URLs and
HTTP as core technologies for information browsing? Are any of these technologies
suitable as a basis for client-server computing in general? (pages 14, 26)

1.7 A server program written in one language (for example, C++) provides the
implementation of a BLOB object that is intended to be accessed by clients that may be
written in a different language (for example, Java). The client and server computers may
have different hardware, but all of them are attached to an internet. Describe the
problems due to each of the five aspects of heterogeneity that need to be solved to make
it possible for a client object to invoke a method on the server object. (page 16)
1.8 An open distributed system allows new resource-sharing services such as the BLOB
object in Exercise 1.7 to be added and accessed by a variety of client programs. Discuss
in the context of this example, to what extent the needs of openness differ from those of
heterogeneity. (page 17)

1.9 Suppose that the operations of the BLOB object are separated into two categories
public operations that are available to all users and protected operations that are
available only to certain named users. State all of the problems involved in ensuring that
only the named users can use a protected operation. Supposing that access to a protected
operation provides information that should not be revealed to all users, what further
problems arise? (page 18)

1.10 The INFO service manages a potentially very large set of resources, each of which can
be accessed by users throughout the Internet by means of a key (a string name). Discuss
an approach to the design of the names of the resources that achieves the minimum loss
of performance as the number of resources in the service increases. Suggest how the
INFO service can be implemented so as to avoid performance bottlenecks when the
number of users becomes very large. (page 19)

1.11 List the three main software components that may fail when a client process invokes a
method in a server object, giving an example of a failure in each case. Suggest how the
components can be made to tolerate one anothers failures. (page 21)

1.12 A server process maintains a shared information object such as the BLOB object of
Exercise 1.7. Give arguments for and against allowing the client requests to be executed
concurrently by the server. In the case that they are executed concurrently, give an
example of possible interference that can occur between the operations of different
clients. Suggest how such interference may be prevented. (page 22)

1.13 A service is implemented by several servers. Explain why resources might be

transferred between them. Would it be satisfactory for clients to multicast all requests to
the group of servers as a way of achieving mobility transparency for clients? (page 23)

1.14 Resources in the World Wide Web and other services are named by URLs. What do the
initials URL denote? Give examples of three different sorts of web resources that can be
named by URLs. (page 26)

1.15 Give an example of an HTTP URL. List the main components of an HTTP URL, stating
how their boundaries are denoted and illustrating each one from your example. To what
extent is an HTTP URL location-transparent? (page 26)