Primeira Lista Objetos Distribudos

1. Quais so os requisitos no funcionais que tipicamente conduzem a adoo da

arquitetura de um sistema distribudo? Discuta o conceito de cada uma destes
requisitos.
1. sca!abi!idade: capacidade de suportar o crescimento, esperado ou no, de carga
sobre o sistema. Em sistemas distribudos isso pode ser alcanado adicionando
novos hosts para atender o servio e dividir a carga.
2. "anutenibi!idade: facilidade de realizar manutenes e epanses em um
sistema. !atores "ue facilitam a obteno desta "ualidade so: interface bem
de#nidas e documentadas e adoo de padres abertos e bem aceitos, de forma
"ue componentes do sistema possam ser atualizados e trocados facilmente e "ue
no ha$a depend%ncia de fornecedores.
&. #etero$eneidade% comumente novos sistemas precisam se integrar a
componentes ou sistemas eistentes, desenvolvidos com tecnologias diferentes,
como linguagem e protocolos. 'uitas vezes os sistemas legados so, inclusive,
dependentes de plataformas de hard(are, impedindo "ue os diferentes
componentes se$am eecutados num mesmo host e conse")entemente precisam se
comunicar atrav*s da rede.
+. &cesso e comparti!'amento de recursos% recursos podem ser e"uipamentos
,hardware, como impressoras e scanners-, soft(are ,aplicativos- e dados ,banco de
dados, ar"uivos, etc-. .ara uma utilizao e#ciente ,principalmente em termos de
custos- * necess/rio compartilhar os recursos com os diversos usu/rios, se$am eles
pessoas ou outros componentes e sistemas de soft(are "ue fazem uso dos
recursos. 0r"uiteturas cliente1servidor centralizadas prov%em m*todos e#cientes de
compartilhamento de recursos, por*m em ar"uiteturas distribudas os recursos
podem ser encapsulados e representados atrav*s de ob$etos, criando modelos mais
so#sticados para distribuio e controle de acesso ao recursos.
2. (o!er)ncia a fa!'as% um sistema tolerante a falhas deve ser capaz de continuar
provendo seus servios mesmo na presena de falhas e erros em seus
componentes. !alhas incluem erros de soft(are, falhas de infra3estrutura ,rede,
energia, etc-, m/ utilizao entre outras. 0r"uiteturas distribudas prov%em m*todos
e#cazes de toler4ncia a falhas atrav*s de conceitos como replicao de dados e
servios e redund4ncia de servidores.
*. Qua! + a diferena entre um sistema c!iente,ser-idor e um sistema
distribudo?
5istemas 6liente15ervidor 5istemas 7istribudos
8o h/ autonomia entre os
componentes "ue formam o
sistema pois todos so controlados
de forma centralizada e 9nica.
6ada componente do sistema
* aut:nomo em relao aos
demais. 6ada um cuida de
seus pr;prios recursos e
utilizam interfaces bem
de#nidas para comunicarem3
se entre si.
6omponentes
homog%neos: mesma
linguagem, compilador e
representao de dados.
6omponentes heterog%neos:
comumente as diferentes
partes de um sistema
distribudo so desenvolvidas
utilizando linguagens
diferentes e eecutando em
plataformas diferentes. <asta
"ue o protocolo de
comunicao ,e1ou interface-
entre os componentes se$am
comuns para "ue ha$a a
comunicao necess/ria
entre eles.
.onto 9nico de controle:
estado, mem;ria e
recursos so gerenciados e
controlados no servidor.
5istemas cliente1servidor
podem ser desenvolvidos
para serem eecutados em
um 9nico processador, at*
mesmo em uma 9nica
thread.
.ela natureza aut:noma dos
componentes, o controle *
distribudo e concorrente.
=eralmente os componentes
so eecutados em
processadores e m/"uinas
diferentes, e precisam
utilizam m*todos de
comunicao entre processos
para se comunicarem
localmente ou atrav*s de
redes.
.onto 9nico de falha:
geralmente o sistema ou
est/ funcionando ou no.
6omo o processamento e
controle esto
centralizados no servidor,
se este falhar todo o
sistema para. 5ituaes
em "ue parte do sistema
funciona e outra no so
incomuns.
'9ltiplos pontos de falha: em
sistemas distribudos
componentes podem falhar
isoladamente causando
falhas em partes espec#cas
do sistema en"uanto outras
funcionam normalmente.
'*todos de replicao e
redund4ncia podem ser
utilizados para amenizar os
problemas.
.. Qua! + a diferena entre transpar/ncia de !oca!izao e transpar/ncia de
acesso?
1. >ranspar%ncia de 0cesso signi#ca "ue a interface para comunicao local e remota
so iguais.
2. >ranspar%ncia de ?ocalizao signi#ca "ue para utilizar um servio a localizao
fsica do componente "ue prov% tal servio no precisa ser conhecida.
0. 1onceitue e e2emp!i3que
1. Objeto
@b$etos so inst4ncias de tipos de ob$eto "ue possuem um con$unto de atributos
"ue representam o estado interno do ob$eto e m*todos "ue podem epor e
alterar seus atributos ou realizar computaes, inclusive utilizando outros
ob$etos. Am ob$eto pode apenas representar um con$unto de dados ,um paralelo
seriam os POJOs da linguagem Bava- como tamb*m servios "ue podem ser
utilizados por outros ob$etos.
*. (ipo objeto
>ipos de ob$eto so as especi#caes das caractersticas de ob$etos similares,
basicamente os m*todos e atributos p9blicos "ue sero epostos por esses
ob$etos. Essas caractersticas so especi#cadas atrav*s das chamadas interfaces
e de#nem um contrato para as interaes entre os ob$etos cliente e servidor.
.. 4equisio de Objeto
Ce"uisio de ob$etos so chamadas de m*todos "ue um ob$eto cliente faz a um
ob$eto servidor. .or*m em sistemas distribudos os ob$etos cliente e servidor
podem estar em hosts diferentes, o "ue leva a uma s*rie de etapas adicionais
em relao a chamadas de m*todos simples eistentes em linguagens de
programao orientadas a ob$etos. Essas etapas podem incluir a transmisso de
par4metros atrav*s da rede, traduo da forma de representao dos dados em
diferentes plataformas de hard(are, sincronizao entre os ob$etos cliente e
servidor dentre outras.
5. Diferena entre objeto e tipo objeto
>ipos de @b$eto so especi#caes do comportamento ,m*todos- "ue @b$etos da"uele
tipo ,inst4ncias- apresentam.
6. 1omo os ser-ios so mode!ados em um meta,mode!o orientados a objetos?
1. Em um meta3modelo orientado a ob$etos os servios so modelados como m*todos
disponibilizados pelos ob$etos. 8a nomenclatura de ob$etos distribudos a utilizao
dos servios se d/ atrav*s de Requests de ob$etos, "ue so chamadas remotas aos
m*todos disponibilizados pelos ob$etos.
7. D/ e2emp!o de quando se de-eria uti!izar po!imor3smo no projeto de objetos
distribudos.
Duando dese$amos "ue um servio ,m*todo- se$a realizado de forma diferente
dependendo do tipo de ob$eto "ue foi instanciado para uma determinada interface.
8. Qua! a diferena entre as dec!ara9es private, protected and public em
dia$ramas de c!asses da :"L?
Am m*todo ou atributo declado private pode ser acessado somente pela pr;pria classe
e * representado no diagrama A'? com um sinal E3F.
@ tipo protected permite "ue ob$etos "ue tenham relacionamento de herana possam
acessar tamb*m.
0tributos e m*todos public podem ser acessados por "ual"uer outro ob$eto e so
representados no diagrama A'? com um sinal EGF.
;. Quais re!acionamentos de consist/ncia t/m que 'a-er entre dia$rama de
seq</ncia e dia$rama de c!asses?
>odos os m*todos utilizados no diagrama de se"u%ncia devem estar modelados no
diagrama de classes e as chamadas de m*todos devem obedecer as de#nies de
controle de acesso ,public, protected e private-
1=.2p!ique as raz9es porque a distribuio de-e ser considerada durante o
projeto de objetos distribudos.
0 distribuio de#ne fatores como con#abilidade, escalabilidade e integrao de
servios.
11.O que + um midd!e>are? 1omo o midd!e>are au2i!ia no desen-o!-imento de
sistemas distribudos?
'iddle(are * uma camada de soft(are "ue abstrai os servios de comunicao em
rede disponibilizados pelo 5istema @peracional de Cede, tornando transparente para o
programador a compleidade desta comunicao, incluindo particularidades de
hard(are e linguagens de programao. @s 'iddle(ares fornecem um modelo
computacional uniforme para o desenvolvimento de aplicaes distribudas,
disponibilizando servios de invocao remota de ob$etos, troca de mensagens e
controle de transaes.
1*.1omparando com o mode!o O?@ da @?OA em que n-e! ocorre as intera9es do
mode!o c!iente,ser-idor BrequisioCrespostaD ? Quais as camadas que fazem
interface com a ap!icao?
Em aplicaes cliente1servidor desenvolvidas diretamente sobre as primitivas de rede
do 5istema @peracional de Cede, ou se$a, sem a utilizao de frameworks de
comunicao, as interaes iro ocorrer na camada de >ransporte, por eemplo
utilizando sockets >6. orientados a coneo ou datagramas A7.. Hndependente do
protocolo de transporte utilizado a aplicao dever/ implementar um controle de
sesses na camada de 5esso, lidando diretamente com endereamento de rede e
portas de comunicao. 7ependendo da forma em "ue os dados so transmitidos pela
rede a aplicao ainda ter/ "ue lidar com as representaes dos dados na camada de
0presentao, para ento #nalmente trabalhar com os dados na camada de 0plicao.
1..1onsiderando o e2emp!o de 1!ienteC?er-idor usando a &P@ Ea-a para socFet
em comunicao :DPA apresentado em au!a%
1. Descre-a como o c!iente recupera o endereo do ser-idorA que tipo de
mecanismo e que ser-io de nomes so uti!izados?
@ endereo H. do servidor * recuperado atrav*s do nomes utilizando o
mecanismo de 785 ,Domain Name System-. 8o caso da linguagem Bava o
m*todo net!ddress"#et$yName%&NO'()S(R*DOR+, pode ser utilizado.
*. 1omo o ser-idor identi3ca o c!iente que estG se comunicando com o
mesmo?
Em uma coneo >6.1H., independente do protocolo de transporte, cada cliente
possui um identi#cador 9nico formado pelo endereo H. e porta de origem.
10.1onsiderando o e2emp!o apresentado em au!a sobre a &P@ Ea-a para ser-ios
de stream baseado no (1PA o!'ando o cHdi$o do ser-idor e2p!ique como se dG
o mecanismo de aceitao de cone2o?
.rimeiro um ob$eto do tipo ServerSocket * criado especi#cando uma porta local para
receber as solicitaes. Em seguida o m*todo accept%, do ob$eto ServerSocket *
eecutado e a thread * blo"ueada at* "ue uma coneo se$a estabelecida.
15.Discuta as diferenas da aborda$em 4P1 da aborda$em de troca de
mensa$ens Be.$. que uti!iza socFetsD em uma comunicao c!iente,ser-idor.
8a troca de mensagens cliente3servidor simplesmente * aberto um canal de comunicao ,e.g.
5ocIet- onde dados so transmitidos. B/ na abordagem C.6 temos o conceito de invocao de
procedimentos ,ou m*todos- remotamente, mas da mesma forma "ue faramos localmente.
8esse processo esto envolvidos mecanismos de sincronizao de estados, traduo de
representao de dados etc.
16.1omente as simi!aridades e diferenas entre c'amada de procedimento
remotoA arquitetura c!iente,ser-idor e objetos distribudos.
8a ar"uitetura cliente-servidor temos basicamente o conceito de re"uisio3resposta.
8o h/ uma abstrao em relao a localizao e acesso aos dados nem um padro
de#nido para a troca de informaes, o programador * "uem de#ne o protocolo
utilizado entre o cliente e servidor.
@ C.6 introduz uma padronizao em relao a forma em "ue os dados so enviados e
recebidos: um m*todo remoto * chamado passando3se seus argumentos e um valor *
retornado. >oda a compleidade inerente a comunicao atrav*s de uma rede *
abstrada pela camada de C.6.
.or #m o conceito de @b$etos 7istribudos estende a tecnologia C.6 adicionando
sincronizao de estado ,atributos- dos ob$etos e transpar%ncia de localizao e acesso.
0 sintae utilizada para trabalhar com @b$etos 7istribudos * muito parecida com a
utilizada ao se trabalhar com ob$etos locais, diferenciando apenas em particularidades
relacionadas a tratamento de erros e ecees.
17.& !in$ua$em Ea-a possui um mecanismo nati-o de distribuio de objetos% 4"@
B4emote "et'od @n-ocationD. Pesquise como este mecanismo funciona.
1. Bava C'H * uma 0.H "ue permite "ue ob$etos instanciados em uma m/"uina virtual
Bava ,BJ'- possa invocar m*todos de ob$etos instanciados em uma BJ' remota,
geralmente rodando em outra m/"uina. @ Bava C'H pode ser considerado um
'iddleware @rientado a @b$etos.
2. 0 ar"uitetura b/sica do Bava C'H envolve o uso de classes Stub no lado cliente, "ue
implementa a interface do ob$eto remoto e * respons/veis pela comunicao via
rede com um ob$eto Skeleton no lado servidor. .ara o programador as classes Stub
se apresentam como ob$etos EnormaisF, com a mesma interface de programao
utilizada se os ob$etos estivessem instanciados na BJ' local.
&. @ servidor registra os ob$etos remotos disponveis atrav*s de um sistema de registro
de interfaces, geralmente um daemon rodando na m/"uina servidora. .or sua vez o
cliente solicita uma int4ncia do ob$eto remoto para o servio de registro "ue *
respons/vel por ativar o ob$eto, caso necess/rio, no lado servidor e controlar a
sincronizao de estados e invocao dos m*todos.
18. 2p!ique como os pap+is das stubs do c!iente e do ser-idor no mode!o 4P1 e
como so $eradas e mapeadas numa !in$ua$em espec3ca.
5tubs so respons/veis por converter a chamada em uma transmisso de uma
mensagem destinada para a m/"uina onde se encontra o servidor com as seguintes
informaes: nome do procedimento e par4metros para o procedimento. 8a m/"uina
servidora deve eistir tamb*m o stub do servidor "ue ser/ respons/vel em receber a
mensagem e convert%3la em uma chamada do procedimento re"uisitado. .ara "ue ha$a
compatibilidade entre os stubs em ambos os lados de um C.6 devem seguir o mesmo
protocolo, ou se$a, o mesmo formato das mensagens e mesmo formato dos dados e de
estruturas de dados.