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. Escalabilidade: 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. Manutenibilidade: facilidade de realizar manutenes e expanses em um
sistema. Fatores que facilitam a obteno desta qualidade so: interface bem
definidas e documentadas e adoo de padres abertos e bem aceitos, de forma
que componentes do sistema possam ser atualizados e trocados facilmente e que
no haja dependncia de fornecedores.
3. Heterogeneidade: comumente novos sistemas precisam se integrar a
componentes ou sistemas existentes, desenvolvidos com tecnologias diferentes,
como linguagem e protocolos. Muitas vezes os sistemas legados so, inclusive,
dependentes de plataformas de hardware, impedindo que os diferentes
componentes sejam executados num mesmo host e conseqentemente precisam se
comunicar atravs da rede.
4. Acesso e compartilhamento de recursos: recursos podem ser equipamentos
(hardware, como impressoras e scanners), software (aplicativos) e dados (banco de
dados, arquivos, etc). Para uma utilizao eficiente (principalmente em termos de
custos) necessrio compartilhar os recursos com os diversos usurios, sejam eles
pessoas ou outros componentes e sistemas de software que fazem uso dos
recursos. Arquiteturas cliente/servidor centralizadas provem mtodos eficientes de
compartilhamento de recursos, porm em arquiteturas distribudas os recursos
podem ser encapsulados e representados atravs de objetos, criando modelos mais
sofisticados para distribuio e controle de acesso ao recursos.
5. Tolerncia a falhas: um sistema tolerante a falhas deve ser capaz de continuar
provendo seus servios mesmo na presena de falhas e erros em seus
componentes. Falhas incluem erros de software, falhas de infra-estrutura (rede,
energia, etc), m utilizao entre outras. Arquiteturas distribudas provem mtodos
eficazes de tolerncia a falhas atravs de conceitos como replicao de dados e
servios e redundncia de servidores.
2. Qual a diferena
distribudo?

entre

um

sistema

Sistemas Cliente/Servidor
No h autonomia entre os
componentes que formam o
sistema pois todos so controlados
de forma centralizada e nica.

Componentes
homogneos: mesma
linguagem, compilador e
representao de dados.

cliente-servidor

um

sistema

Sistemas Distribudos
Cada componente do sistema
autnomo em relao aos
demais. Cada um cuida de
seus prprios recursos e
utilizam interfaces bem
definidas para comunicaremse entre si.
Componentes heterogneos:
comumente as diferentes
partes de um sistema
distribudo so desenvolvidas
utilizando linguagens
diferentes e executando em

plataformas diferentes. Basta

que o protocolo de
comunicao (e/ou interface)
entre os componentes sejam
comuns para que haja a
comunicao necessria
entre eles.
Ponto nico de controle:
estado, memria e
recursos so gerenciados e
controlados no servidor.
Sistemas cliente/servidor
podem ser desenvolvidos
para serem executados em
um nico processador, at
mesmo em uma nica
thread.

Pela natureza autnoma dos

componentes, o controle
distribudo e concorrente.
Geralmente os componentes
so executados em
processadores e mquinas
diferentes, e precisam
utilizam mtodos de
comunicao entre processos
para se comunicarem
localmente ou atravs de
redes.

Ponto nico de falha:

geralmente o sistema ou
est funcionando ou no.
Como o processamento e
controle esto
centralizados no servidor,
se este falhar todo o
sistema para. Situaes
em que parte do sistema
funciona e outra no so
incomuns.

Mltiplos pontos de falha: em

sistemas distribudos
componentes podem falhar
isoladamente causando
falhas em partes especficas
do sistema enquanto outras
funcionam normalmente.
Mtodos de replicao e
redundncia podem ser
utilizados para amenizar os
problemas.

3. Qual a diferena entre transparncia de localizao e transparncia de

acesso?
1. Transparncia de Acesso significa que a interface para comunicao local e remota
so iguais.
2. Transparncia de Localizao significa que para utilizar um servio a localizao
fsica do componente que prov tal servio no precisa ser conhecida.
4. Conceitue e exemplifique
1. Objeto
Objetos so instncias de tipos de objeto que possuem um conjunto de atributos
que representam o estado interno do objeto e mtodos que podem expor e
alterar seus atributos ou realizar computaes, inclusive utilizando outros
objetos. Um objeto pode apenas representar um conjunto de dados (um paralelo
seriam os POJOs da linguagem Java) como tambm servios que podem ser
utilizados por outros objetos.
2. Tipo objeto

Tipos de objeto so as especificaes das caractersticas de objetos similares,

basicamente os mtodos e atributos pblicos que sero expostos por esses
objetos. Essas caractersticas so especificadas atravs das chamadas interfaces
e definem um contrato para as interaes entre os objetos cliente e servidor.
3. Requisio de Objeto
Requisio de objetos so chamadas de mtodos que um objeto cliente faz a um
objeto servidor. Porm em sistemas distribudos os objetos cliente e servidor
podem estar em hosts diferentes, o que leva a uma srie de etapas adicionais
em relao a chamadas de mtodos simples existentes em linguagens de
programao orientadas a objetos. Essas etapas podem incluir a transmisso de
parmetros atravs da rede, traduo da forma de representao dos dados em
diferentes plataformas de hardware, sincronizao entre os objetos cliente e
servidor dentre outras.
5. Diferena entre objeto e tipo objeto
Tipos de Objeto so especificaes do comportamento (mtodos) que Objetos daquele
tipo (instncias) apresentam.
6. Como os servios so modelados em um meta-modelo orientados a objetos?
1. Em um meta-modelo orientado a objetos os servios so modelados como mtodos
disponibilizados pelos objetos. Na nomenclatura de objetos distribudos a utilizao
dos servios se d atravs de Requests de objetos, que so chamadas remotas aos
mtodos disponibilizados pelos objetos.
7. D exemplo de quando se deveria utilizar polimorfismo no projeto de objetos
distribudos.
Quando desejamos que um servio (mtodo) seja realizado de forma diferente
dependendo do tipo de objeto que foi instanciado para uma determinada interface.
8. Qual a diferena entre as declaraes
diagramas de classes da UML?

private, protected and public em

Um mtodo ou atributo declado private pode ser acessado somente pela prpria classe
e representado no diagrama UML com um sinal -.
O tipo protected permite que objetos que tenham relacionamento de herana possam
acessar tambm.
Atributos e mtodos public podem ser acessados por qualquer outro objeto e so
representados no diagrama UML com um sinal +.
9. Quais relacionamentos de consistncia tm que haver entre diagrama de
seqncia e diagrama de classes?
Todos os mtodos utilizados no diagrama de sequncia devem estar modelados no
diagrama de classes e as chamadas de mtodos devem obedecer as definies de
controle de acesso (public, protected e private)
10.Explique as razes porque a distribuio deve ser considerada durante o
projeto de objetos distribudos.
A distribuio define fatores como confiabilidade, escalabilidade e integrao de
servios.

11.O que um middleware? Como o middleware auxilia no desenvolvimento de

sistemas distribudos?
Middleware uma camada de software que abstrai os servios de comunicao em
rede disponibilizados pelo Sistema Operacional de Rede, tornando transparente para o
programador a complexidade desta comunicao, incluindo particularidades de
hardware e linguagens de programao. Os Middlewares fornecem um modelo
computacional uniforme para o desenvolvimento de aplicaes distribudas,
disponibilizando servios de invocao remota de objetos, troca de mensagens e
controle de transaes.
12.Comparando com o modelo OSI da ISO, em que nvel ocorre as interaes do
modelo cliente-servidor (requisio/resposta) ? Quais as camadas que fazem
interface com a aplicao?
Em aplicaes cliente/servidor desenvolvidas diretamente sobre as primitivas de rede
do Sistema Operacional de Rede, ou seja, sem a utilizao de frameworks de
comunicao, as interaes iro ocorrer na camada de Transporte, por exemplo
utilizando sockets TCP orientados a conexo ou datagramas UDP. Independente do
protocolo de transporte utilizado a aplicao dever implementar um controle de
sesses na camada de Sesso, lidando diretamente com endereamento de rede e
portas de comunicao. Dependendo da forma em que os dados so transmitidos pela
rede a aplicao ainda ter que lidar com as representaes dos dados na camada de
Apresentao, para ento finalmente trabalhar com os dados na camada de Aplicao.
13.Considerando o exemplo de Cliente/Servidor usando a API Java para socket
em comunicao UDP, apresentado em aula:
1. Descreva como o cliente recupera o endereo do servidor, que tipo de
mecanismo e que servio de nomes so utilizados?
O endereo IP do servidor recuperado atravs do nomes utilizando o
mecanismo de DNS (Domain Name System). No caso da linguagem Java o
mtodo InetAddress.getByName(NOME_SERVIDOR") pode ser utilizado.
2. Como o servidor identifica o cliente que est se comunicando com o
mesmo?
Em uma conexo TCP/IP, independente do protocolo de transporte, cada cliente
possui um identificador nico formado pelo endereo IP e porta de origem.
14.Considerando o exemplo apresentado em aula sobre a API Java para servios
de stream baseado no TCP, olhando o cdigo do servidor explique como se d
o mecanismo de aceitao de conexo?
Primeiro um objeto do tipo ServerSocket criado especificando uma porta local para
receber as solicitaes. Em seguida o mtodo accept() do objeto ServerSocket
executado e a thread bloqueada at que uma conexo seja estabelecida.
15.Discuta as diferenas da abordagem RPC da abordagem de troca de
mensagens (e.g. que utiliza sockets) em uma comunicao cliente-servidor.
Na troca de mensagens cliente-servidor simplesmente aberto um canal de
comunicao (e.g. Socket) onde dados so transmitidos. J na abordagem RPC temos o
conceito de invocao de procedimentos (ou mtodos) remotamente, mas da mesma
forma que faramos localmente. Nesse processo esto envolvidos mecanismos de
sincronizao de estados, traduo de representao de dados etc.

16.Comente as similaridades e diferenas entre chamada de procedimento

remoto, arquitetura cliente-servidor e objetos distribudos.
Na arquitetura cliente-servidor temos basicamente o conceito de requisio-resposta.
No h uma abstrao em relao a localizao e acesso aos dados nem um padro
definido para a troca de informaes, o programador quem define o protocolo
utilizado entre o cliente e servidor.
O RPC introduz uma padronizao em relao a forma em que os dados so enviados e
recebidos: um mtodo remoto chamado passando-se seus argumentos e um valor
retornado. Toda a complexidade inerente a comunicao atravs de uma rede
abstrada pela camada de RPC.
Por fim o conceito de Objetos Distribudos estende a tecnologia RPC adicionando
sincronizao de estado (atributos) dos objetos e transparncia de localizao e acesso.
A sintaxe utilizada para trabalhar com Objetos Distribudos muito parecida com a
utilizada ao se trabalhar com objetos locais, diferenciando apenas em particularidades
relacionadas a tratamento de erros e excees.
17.A linguagem Java possui um mecanismo nativo de distribuio de objetos: RMI
(Remote Method Invocation). Pesquise como este mecanismo funciona.
1. Java RMI uma API que permite que objetos instanciados em uma mquina virtual
Java (JVM) possa invocar mtodos de objetos instanciados em uma JVM remota,
geralmente rodando em outra mquina. O Java RMI pode ser considerado um
Middleware Orientado a Objetos.
2. A arquitetura bsica do Java RMI envolve o uso de classes Stub no lado cliente, que
implementa a interface do objeto remoto e responsveis pela comunicao via
rede com um objeto Skeleton no lado servidor. Para o programador as classes Stub
se apresentam como objetos normais, com a mesma interface de programao
utilizada se os objetos estivessem instanciados na JVM local.
3. O servidor registra os objetos remotos disponveis atravs de um sistema de registro
de interfaces, geralmente um daemon rodando na mquina servidora. Por sua vez o
cliente solicita uma intncia do objeto remoto para o servio de registro que
responsvel por ativar o objeto, caso necessrio, no lado servidor e controlar a
sincronizao de estados e invocao dos mtodos.
18. Explique como os papis das stubs do cliente e do servidor no modelo RPC e
como so geradas e mapeadas numa linguagem especfica.
Stubs so responsveis por converter a chamada em uma transmisso de uma
mensagem destinada para a mquina onde se encontra o servidor com as seguintes
informaes: nome do procedimento e parmetros para o procedimento. Na mquina
servidora deve existir tambm o stub do servidor que ser responsvel em receber a
mensagem e convert-la em uma chamada do procedimento requisitado. Para que haja
compatibilidade entre os stubs em ambos os lados de um RPC devem seguir o mesmo
protocolo, ou seja, o mesmo formato das mensagens e mesmo formato dos dados e de
estruturas de dados.