Objetos Distribudos e Invocao Remota Introduo 1 Introduo

Objetos Distribuídos e Invocação Remota Introdução 1

Introdução l 2 RPC x RMI Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Introdução l RPC – Remote procedure call – l RMI – Remote method invocation – l O modelo baseado orientado a objeto utiliza este termo para definir uma chamada a um método. Eventos distribuídos – 3 Este termo é utilizado para aplicativos clientes que fazem normalmente chamadas a procedimentos remotos que estão em outro processo e hosts. É capacidade de notificação que os SD tem de avisar a um outro processo que um evento ocorreu. Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Introdução l Middleware – – 4 Software que providencia um modelo de programação por blocos de processos pela passagem de mensagem Alguns middleware permitem que os processos sejam implementados em diferentes linguagem de programação Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Introdução l Características – Transparência de locação l – Protocolo de Comunicação l 5 o cliente não sabe se o procedimento ou método chamado está no mesmo processo ou num processo diferentes rodando em outra máquina. Ex: RPC, RMI, etc Um middleware deve ser capaz de implementar o processo de comunicação solicitação e resposta, em qualquer protocolo existente. Ex: TCP ou UDP Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Introdução – Hardware l – Sistema Operacional l – O middleware deve ser capaz de oferecer alto nível de abstração do S. O. que está sendo utilizado Independência de Linguagem de programação l 6 O middleware implementa mecanismo para troca de dados entre diferentes plataforma de hardware existentes. Ex: IDL Alguns middlewares podem permitir transparência quanto ao uso de diferentes linguagens de programação em seus processos. Ex: Corba, IDL Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Introdução Applications RMI, RPC and events Request reply protocol Middleware layers External data representation Operating System 7 Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Interfaces l Interfaces – – 8 Define como e quais objetos e variáveis estão presentes na comunicação entre processos. Não tem acesso direto as variáveis ou método Define parâmetros de inputs e outputs Não trabalha com ponteiros Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Interfaces l Service interfaces – l Termo utilizado para definir as procedures ou serviços oferecidos pelo servidor. Ex: FTP, procedimento de escrita e leitura de arquivo Remote Interface – Especifica os métodos de um objeto que estão disponíveis para inovocação por outros objetos de outros processos. l l 9 Define: tipos de entrada e saída de cada objeto Passa também objetos como argumento ou resultado Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Interfaces l Interface Definition Languages – IDL – 10 Permite criar uma notação universal para interface de métodos e variáveis para serem utilizados entre diversas linguagem de programação. Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

IDL l 11 Corba IDL // In file Person. idl struct Person { string name; string place; long year; }; interface Person. List { readonly attribute string listname; void add. Person(in Person p) ; void get. Person(in string name, out Person p); long number(); }; Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

IDL l Outras – Além do Corba IDL, temos: l l l 12 OSF - C IDL DCOM - CDE IDL etc Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto l Referência de objetos – l Interfaces – l Permite definir as regras para tratamento de erros que podem ocorrer nos processo Coleção de lixos – – 13 É a ação existente necessária para providenciar a invocação do objeto, sua execução, devolvendo algum resultado ao cliente Exceções – l Define os métodos, tipos dos argumentos, tipos de retornos e exceções, sem especificar sua implementação Ações – l Usado para fazer referencia para qualquer chamada a um método Controle para liberação de espaços para os objetos não mais usados. Ex: Java Outras linguagens não fazem esse controle Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Objetos distribuídos l Cada processo contém objetos, alguns na qual podem receber chamadas remotas, outras somente local – l l Objetos Remotos x Objetos Locais Objetos precisam conhecer a referência de objeto remoto de um objeto em outro processo para poder invocar seus serviços. Como ele faz isso? A interface Remota especifica como os métodos são acessados remotamente remote invocation A 14 Professor: Arlindo Tadayuki Noji B local C E invocation local invocation D remote invocation Instituto de Ensino Superior F

O Modelo de Objeto Distribuído l Existe dois conceitos fundamentais para um modelo de objetos distribuídos: – Referência de Objeto Remoto l – Interface Remoto l 15 É um identificador único que pode ser usado em um sistema distribuído para fazer referência a um particular objeto remoto Define como os objetos remotos podem ser invocados, contém a definição das estruturas de dados e métodos. Ex: Corba IDL e Java RMI. Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Objeto Remoto e Interface Remoto remoteobject remote interface { 16 Professor: Arlindo Tadayuki Noji Data m 1 m 2 m 3 implementation of methods m 4 m 5 m 6 Instituto de Ensino Superior

Desafios para projetos de RMI l Apesar de em Java a chamada remota ser uma questão de uma extensão a uma chamada local, ela ainda apresenta desafios: – – 17 Numa chamada local, o método é executado apenas uma vez. No RMI nem sempre é verdade Nível de transparência nem sempre atinge o desejável Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Desafios para projetos de RMI l Diferentes formas de invocação – – – l 18 Retry request message Duplicate filtering Retransmission od results Os problemas acima afetam na confiabilidade do método de convocação de um objeto remoto Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Semântica de Invocação Invocation semantics Fault tolerance measures Retransmit request message 19 Duplicate filtering Re-execute procedure or retransmit reply No Not applicable Yes No Re-execute procedure At-least-once Yes Retransmit reply At-most-once Professor: Arlindo Tadayuki Noji Maybe Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Maybe invocation semantics – Pode ocorrer quando o cliente invoca um objeto remoto, mas sabe realmente se foi executado ou não l l – A falha pode ocorrer antes de executar o objeto, ou depois de ser executado l l l 20 Falha por omissão ( ex: perda de msg) Crash (Ex: o objeto presente no servidor falha) Perda da msg antes Perda da msg depois Time out Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l At-least-once invocation semantics: – – Neste caso, o cliente que invoca conhece que um determinado objeto foi executado pelo menos uma vez ou pelo menos é avisado que houve um erro Neste categoria os problemas podem advir de: l l 21 Crash Falhas arbitrárias (erros podem ocorrer se a retransmissão executar o objeto novamente) Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l At-most-once semantics: – – 22 O cliente que invoca sabe exatamente que o método remoto foi chamado apenas uma vez ou não. Aplica e trata todas os tipos de falhas que podem ocorrer Ex: Java RMI, Corba aceita At-least-once para chamadas a objetos que não retornem resultado Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Métodos de Chamada Remota server client object A proxy for B Request skeleton & dispatcher for B’s class remote object B Reply 23 Communication Remote reference module Professor: Arlindo Tadayuki Noji Communication module Remote reference module Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Implementação do RMI – – 24 Proxy Bindind name Objects references Comunications Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Módulo de comunicação – – 25 Implementa um protocolo solicitação e resposta Usa os 3 primeiros itens da estrutura de msg message. Type request. Id object. Reference method. Id arguments Professor: Arlindo Tadayuki Noji int (0=Request, 1= Reply) int Remote. Object. Ref int or Method array of bytes Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Módulo Referência Remota – – – 26 É responsável entre a tradução da referência local e a referência remota dos objetos Cria o referência de objetos remotos Cada processo possui uma tabela de referência de objetos, que faz correspondência entre as informações dos objetos existentes nos processos locais e não locais Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Módulo Referência Remota – Tabela de referência de objetos l l 27 Mantêm todas as referências de objetos locais usadas pelo processo Mantêm as referências para cada proxy local, correspondentes dos objetos remotos Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Acões do Módulo de Referência Remota – – – 28 Quando um objeto remoto é passado como argumento ou como resultado pela primeira vez, o módulo de referência remota é incentivado a criar uma referência de objeto remoto, na qual é adicionado a uma tabela Quando uma referência de objeto remoto chega em uma solicitação ou numa resposta de mensagem, o módulo de referência remota faz uma consulta para encontrar uma referência do objeto localmente, na qual pode referir-se para um proxy ou para um objeto remoto Caso a referência de objeto remoto não seja encontrado na tabela, o RMI cria um novo proxy e insere na tabela através do módulo de referência remota. Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l O software RMI – Consiste em uma camada de software entre a aplicação baseada em objetos e a comunicação e o módulo de referência remota l Proxy – a função do proxy é providenciar um método transparente de invocação para o cliente, fazendo parecer que está invocando um objeto local. Mas em vez de executar alguma tarefa, ele transfere na forma de msg para o objeto remoto Esconde os detalhes de uma referência a objetos remotos, marshalling, unmarshalling e os processos de comunicações existentes – Existe um proxy para cada Objeto remoto – 29 Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Dispatcher - Um servidor tem um dispatcher e um skeleton para cada representação de classe de objetos. O Dispatcher é responsável por receber as requisições vindas do módulo de comunicações. – Usa o Method. Id para selecionar o apropriado método no Skeleton – O Dispatcher e proxy usam a mesma alocação de method. Id para os métodos de interface remota – l Skeleton – A classe de um objeto remoto possui um skeleton, onde é implementado os métodos dentro de uma interface remota É implementado um pouco diferente da interface original do objeto remoto – Passa pelo processo de marshalling antes de invocar o objeto remoto e unmashalling para devolver a informação como resultado – 30 Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Geração de classes para proxies, dispatchers e skeleton – – – 31 São gerados automaticamente pela interface do compilador Corba São gerado a partir do arquivo IDL Para o Servidor é gerado os proxys, dispatches e skeleton de cada objeto remoto Para o Cliente, os aplicativos deverão conter as classes dos proxys de todos os objetos remotos Exemplo de compiladores: Orbix (C++); Delphi Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Factory method – – 32 Interface de objetos remotos não possuem construtores, portanto, os objetos remotos não podem ser construídos pela invocação remota de construtores Objetos remotos são construídos através de uma sessão de inicialização ou por um método remoto projetado para este propósito Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l O factory method – l O factory object – l É o objeto criado pelo método factory (factory method) Binders – 33 É usado para criar objetos remotos É um serviço separado que mantém uma tabela contendo uma mapeamento dos nomes textual sobre as referências de objetos remotos e é usado pelo servidor para registrar identificar os seus objetos remotos por nome e os seus clientes Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

O Modelo de Objeto Distribuído l Server Threads – l Ativação de objetos remotos – – l Este processo permite controlar quando um determinado objeto remoto está ativo ou disponível para ser invocado. Isto é feito porque não é pratico manter todos objetos remotos funcionando e disponíveis em dado tempo, além de não ser realmente necessário Este controle é feito pelo servidor que gerencia este processo automaticamente (ex: iniciado quando for envolvido no processo de marshalling) Persistência de objetos – 34 É a capacidade de executar concorrência aos objetos remotos São geralmente providenciado pelo servidor e dão a capacidade ao objeto remoto de manter seus estados mesmo após diversas ativações Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Modelo RPC l Remote Procedure Call – – – É similar ao RMI, mas neste caso, se refere a capacidade de fazer chamadas a procedures que estão em outros processos Servidores podem ser clientes de outros processo servidores Possui como semântica de invocação: l l – 35 At-least-once At-most-once Usa também um protocolo de solicitação e resposta Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Modelo RPC l O RPC não utiliza módulos de referência remota, uma vez que não trabalha com objetos e métodos l O cliente utiliza um stub procedure, similar ao uso do proxy para as chamadas procedures remotas – – 36 Um stub procedure recebe a chamada, mas ao invés de executar algo, ele executa o processo de marshalling e transmite via msg a solicitação ao servidor com a procedure remota para a execução No recebimento da resposta, executa o processo de unmarshalling e apresenta o resultado para o invocador dentro do processo local Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Modelo RPC l Ex: client process server process Request client program 37 client stub procedure Communication module Professor: Arlindo Tadayuki Noji Reply server stub procedure Communication dispatcher module service procedure Instituto de Ensino Superior

Modelo RPC l No servidor – – – 38 Contém um dispatcher que trabalha junto com um stub procedure servidor e que liga a um serviço (procedure) existente para cada procedure existente na interface de serviços O dispatcher seleciona a procedure de acordo com identificação da procedure vinda da msg de solicitação O Server stub procedure funciona parecido com um skeleton, onde executa o processo de unmarshalling dos argumentos de entrada, executa a procedure implementada e faz o marshalling dos resultados para serem devolvidos através de uma msg. Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior

Modelo de Objeto Distribuído l Ex: – – 39 SUN RPC JAVA RMI Professor: Arlindo Tadayuki Noji Instituto de Ensino Superior