1
INTRODUÇÃO RPC x RMI 2
INTRODUÇÃO RPC Remote procedure call Este termo é utilizado para aplicativos clientes que fazem normalmente chamadas a procedimentos remotos que estão em outro processo e hosts. RMI Remote method invocation O modelo baseado orientado a objeto utiliza este termo para definir uma chamada a um método. Eventos distribuídos É capacidade de notificação que os SD tem de avisar a um outro processo que um evento ocorreu. 3
INTRODUÇÃO Middleware 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 4
INTRODUÇÃO Características Transparência de locação 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 Protocolo de Comunicação Um middleware deve ser capaz de implementar o processo de comunicação solicitação e resposta, em qualquer protocolo existente. Ex: TCP ou UDP 5
INTRODUÇÃO Hardware O middleware implementa mecanismo para troca de dados entre diferentes plataforma de hardware existentes. Ex: IDL Sistema Operacional 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 Alguns middlewares podem permitir transparência quanto ao uso de diferentes linguagens de programação em seus processos. Ex: Corba, IDL 6
INTRODUÇÃO Applications RMI, RPC and events Request reply protocol Middleware layers External data representation Operating System 7
INTERFACES Interfaces 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 8
INTERFACES Service interfaces 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. Define: tipos de entrada e saída de cada objeto Passa também objetos como argumento ou resultado 9
INTERFACES Interface Definition Languages IDL Permite criar uma notação universal para interface de métodos e variáveis para serem utilizados entre diversas linguagem de programação. 10
IDL Corba IDL // In file Person.idl struct Person { string name; string place; long year; } ; interface PersonList { readonly attribute string listname; void addperson(in Person p) ; void getperson(in string name, out Person p); long number(); }; 11
IDL Outras Além do Corba IDL, temos: OSF - C IDL DCOM - CDE IDL etc 12
O MODELO DE OBJETO Referência de objetos Usado para fazer referencia para qualquer chamada a um método Interfaces Define os métodos, tipos dos argumentos, tipos de retornos e exceções, sem especificar sua implementação Ações É a ação existente necessária para providenciar a invocação do objeto, sua execução, devolvendo algum resultado ao cliente Exceções Permite definir as regras para tratamento de erros que podem ocorrer nos processo Coleção de lixos Controle para liberação de espaços para os objetos não mais usados. Ex: Java Outras linguagens não fazem esse controle 13
OBJETOS DISTRIBUÍDOS Cada processo contém objetos, alguns na qual podem receber chamadas remotas, outras somente local 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 A remote invocation B local C invocation local E invocation local invocation D remote invocation F 14
O MODELO DE OBJETO DISTRIBUÍDO Existe dois conceitos fundamentais para um modelo de objetos distribuídos: Referência de Objeto Remoto É um identificador único que pode ser usado em um sistema distribuído para fazer referência a um particular objeto remoto Interface 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. 15
O MODELO DE OBJETO DISTRIBUÍDO Objeto Remoto e Interface Remoto remote object Data remote interface m1 { implementation m2 m3 of methods m4 m5 m6 16
DESAFIOS PARA PROJETOS DE RMI Apesar de em Java a chamada remota ser uma questão de uma extensão a uma chamada local, ela ainda apresenta desafios: 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 17
DESAFIOS PARA PROJETOS DE RMI Diferentes formas de invocação Retry request message Duplicate filtering Retransmission od results Os problemas acima afetam na confiabilidade do método de convocação de um objeto remoto 18
O MODELO DE OBJETO DISTRIBUÍDO Semântica de Invocação Fault tolerance measures Invocation semantics Retransmit request message Duplicate filtering Re-execute procedure or retransmit reply No Not applicable Not applicable Maybe Yes No Re-execute procedure At-least-once Yes Yes Retransmit reply At-most-once 19
O MODELO DE OBJETO DISTRIBUÍDO Maybe invocation semantics Pode ocorrer quando o cliente invoca um objeto remoto, mas sabe realmente se foi executado ou não Falha por omissão ( ex: perda de msg) Crash (Ex: o objeto presente no servidor falha) A falha pode ocorrer antes de executar o objeto, ou depois de ser executado Perda da msg antes Perda da msg depois Time out 20
O MODELO DE OBJETO DISTRIBUÍDO 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: Crash Falhas arbitrárias (erros podem ocorrer se a retransmissão executar o objeto novamente) 21
O MODELO DE OBJETO DISTRIBUÍDO At-most-once semantics: 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 Corba aceita At-least-once para chamadas a objetos que não retornem resultado 22
O MODELO DE OBJETO DISTRIBUÍDO Métodos de Chamada Remota object A client proxy for B Request server skeleton & dispatcher for B s class remote object B Reply Remote Communication reference module module Communication module Remote reference module 23
O MODELO DE OBJETO DISTRIBUÍDO Implementação do RMI Proxy Bindind name Objects references Comunications 24
O MODELO DE OBJETO DISTRIBUÍDO Módulo de comunicação Implementa um protocolo solicitação e resposta Usa os 3 primeiros itens da estrutura de msg messagetype requestid objectreference methodid arguments int (0=Request, 1= Reply) int RemoteObjectRef int or Method array of bytes 25
O MODELO DE OBJETO DISTRIBUÍDO Módulo Referência Remota É 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 26
O MODELO DE OBJETO DISTRIBUÍDO Módulo Referência Remota Tabela de referência de objetos 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 27
O MODELO DE OBJETO DISTRIBUÍDO Acões do Módulo de Referência Remota 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. 28
O MODELO DE OBJETO DISTRIBUÍDO 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 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
O MODELO DE OBJETO DISTRIBUÍDO 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 MethodId para selecionar o apropriado método no Skeleton O Dispatcher e proxy usam a mesma alocação de methodid para os métodos de interface remota 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
O MODELO DE OBJETO DISTRIBUÍDO Geração de classes para proxies, dispatchers e skeleton 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 31
O MODELO DE OBJETO DISTRIBUÍDO Factory method 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 32
O MODELO DE OBJETO DISTRIBUÍDO O factory method É usado para criar objetos remotos O factory object É o objeto criado pelo método factory (factory method) Binders É 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 33
O MODELO DE OBJETO DISTRIBUÍDO Server Threads É a capacidade de executar concorrência aos objetos remotos Ativação de objetos remotos 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 São geralmente providenciado pelo servidor e dão a capacidade ao objeto remoto de manter seus estados mesmo após diversas ativações 34
MODELO RPC 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: At-least-once At-most-once Usa também um protocolo de solicitação e resposta 35
MODELO RPC O RPC não utiliza módulos de referência remota, uma vez que não trabalha com objetos e métodos O cliente utiliza um stub procedure, similar ao uso do proxy para as chamadas das procedures remotas 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 36
MODELO RPC Ex: client process server process Request client program client stub procedure Communication module Reply server stub procedure Communication module dispatcher service procedure 37
MODELO RPC No servidor 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. 38
MODELO DE OBJETO DISTRIBUÍDO Ex: SUN RPC JAVA RMI 39