



Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Exercicio resolvidos de middleware
Tipologia: Exercícios
1 / 6
Esta página não é visível na pré-visualização
Não perca as partes importantes!




1.. O que é um middleware? Software que fornece um modelo de programação, e que é situado entre camadas de software (no nosso caso, o Java RMI, entre as camadas de aplicação e transporte), que usa um protocolo baseado em mensagens entre objetos (locais e remotos), no sentido de fornecer abstrações de mais alto nível, como as invocações e eventos remotos, proporcionando transparência de localização nas invocações remotas. 2. Quando um cliente invoca um método num objecto servidor quais os principais com ponentes de software que podem falhar? (Dar um exemplo de uma falha para cada caso)
O processo cliente (terminar de forma anormal - crash) O processo servidor (terminar de forma anormal – crash) O software de comunicação (uma mensagem pode não ser chegar ao destino) Em que medida as falhas são independentes?
Para que servem os stubs? (Considere o stub do cliente e o stub do servidor.)
Qual a diferença principal entre RPC (Remote Procedure Call) e RMI (Remote Method Invocation)? RPC implementa processos: cliente e servidor, como seria para uam linguagem procedural, como a linguagem C, que não suporta classes nem objetos.RMI implementa objetos ao invés de processos, com nas linguagens C++ e Java.
que são os stubs e os skeletons e como os mesmos são gerados?
Os stubs e os skeletons são componentes intermediários, entre um cliente e o objeto. O stub é um componente do lado do cliente, que contém uma referência para o objeto
remoto. A partir desta referência, chamamos o método do objeto remoto, via ORB. O skeleton é um componente do lado do servidor, e o ORB o usa para gerar a chamada de método remota em uma chamada local no objeto. O skeleton traduz a chamada e os parâmetros para a implementação específica do objeto. No retorno, o skeleton novamente traduz os resultados e erros gerados e os envia de volta para o cliente via ORBs.
13. Como um cliente acha o serviço remoto RMI?
Os clientes acham os serviços remotos usando o serviço de nomeação ou directório
(naming or directory), o serviço de nomeação ou directório roda como um endereço bem formado (host:port).
O RMI pode usar diferentes tipos de serviços de directório, incluindo o JNDI. O próprio
RMI inclue um simples serviço, chamado de RMI Registry. O RMI Registry roda em cada
maquina que hospeda o serviço remoto, por definição na porta 1099.
Numa máquina host, um programa servidor cria um serviço remoto, primeiramente criando o objecto que implemente aquele serviço. Em seguida ele exporta aquele
objecto para o RMI. Quando o objecto é exportado o RMI cria um serviço que aguarda
as conexões do cliente. O servidor registra o objecto no RMI Registry, com um nome público.
No lado do cliente o RMI Registry é acedido através da classe estática Naming. Ela
provém o método lookup( ), que o cliente usa para requisitar o registro. Esse método
aceita a URL que especifica o nome do servidor e o nome do serviço desejado. O
método retorna uma referência remota para o objecto do serviço. A URL é formada, como seguinte:
rmi://<host_name>[:port_number]/<service_name>
15. Pra que serve Servidor RMI Registry?
Após a execução deste comando, você deveria ver no seu diretório os arquivos
Mensageiro_Stub.class, Mensageiro_Skeleton.class.
a) RMI permite que o código que defineo comportamento e o código que implementa o comportamento permanecer em separados e rodar em em JVMs separadas. (V). b) Em RMI, a definição do serviço remoto não é codificada usando uma interface Java. (F) justificacao: e falso porque RMI permite que o código que defineo comportamento e o código que implementa o comportamento permanecer em separados e rodar em em JVMs separadas, logo a interface e no java virtual machine. . c) A classe que implementa o comportamento roda do lado do servidor RMI. (V). d) IDL são desenhados para permitir que objectos implementados em diferentes linguagens possam se invocar. (V) e) Garbage collection: é necessário providenciar mecanismos para libertar o espaço ocupado por objectos que são mais necessários. (V) f) Uma acção num programa orientado a objectos é iniciada por um objecto invocando um método de um outro objecto. ( V). g) Uma interface define o tipo que pode ser usado para declarar o tipo de variaves ou dos parâmetros e valores de retorno dos métodos e ela não são usadas os construtores. (V)
A implementação do RMI é essencialmente feita de três camadas de abstracção. A camada Stub e Skeleton está abaixo dos olhos do desenvolvedor. Esta camada intercepta as chamadas de métodos feitas pelo cliente para que a variável de referência da interface redirecione essas chamadas para o serviço RMI remoto.
A camada de Remote Reference Layer. Esta camada sabe como interpretar e gerir referências feitas dos clientes para os objectos do serviço remoto. A conexão do Cliente ao servidor é Unicast (uma-para-um).
A camada de transporte é baseada nas conexões TCP/IP entre as maquinas em uma rede.
rmi://<host_name>[:port_number]/<service_name>
Escrever e compilar o código Java da interface
Escrever e compilar o código Java das implementações das classes
Gerar as classes Stub e Skeleton das classes de implementação
Crie um directório para salvar todos os seus arquivos de projecto
A camada mais próxima do programador, ou seja da aplicação cliente e do objecto remoto, é a camada Stubs/Skeletons. Os Stubs são classes usadas do lado da aplicação cliente e funcionam como Proxies entre a aplicação cliente e o objecto remoto. Os Stubs recebem os parâmetros dos métodos exportados pelo objecto remota (definidas pela interface da classe remota) e reencaminham-nos para o lado do servidor onde serão interpretados por uma instância de uma classe Skeleton. O Skeleton recebe os parâmetros enviados pelo Stub e executa as respectivas chamadas no objecto remoto. Em sentido inverso, os Skeletons são também responsáveis por receber o valor de