Diferença entre RPC e RMI
Contente
- Gráfico de comparação
- Definição de RPC
- Vamos entender como a RPC é implementada através das etapas fornecidas:
- Definição de RMI
- Conclusão
RPC e RMI são os mecanismos que permitem ao cliente invocar o procedimento ou método do servidor através do estabelecimento de comunicação entre cliente e servidor. A diferença comum entre RPC e RMI é que o RPC suporta apenas programação processual considerando que o RMI suporta programação orientada a objetos.
Outra grande diferença entre os dois é que os parâmetros passados para a chamada de procedimentos remotos consistem em estruturas de dados comuns. Por outro lado, os parâmetros passados para o método remoto consistem em objetos.
- Gráfico de comparação
- Definição
- Principais diferenças
- Conclusão
Gráfico de comparação
Base para comparação | RPC | RMI |
---|---|---|
Suporta | Programação processual | Programação orientada a objetos |
Parâmetros | Estruturas de dados comuns são passadas para procedimentos remotos. | Os objetos são passados para métodos remotos. |
Eficiência | Menor que o RMI | Mais do que RPC e suportado pela moderna abordagem de programação (ou seja, paradigmas orientados a objetos) |
Despesas gerais | Mais | Menos comparativamente |
Parâmetros de entrada e saída são obrigatórios. | sim | Não necessariamente |
Provisão de facilidade de programação | Alto | baixo |
Definição de RPC
Chamada de procedimento remoto (RPC) é um recurso da linguagem de programação desenvolvido para a computação distribuída e baseado na semântica de procedimento local chamadas. São as formas mais comuns de serviço remoto e foram projetadas como uma maneira de abstrair o mecanismo de chamada de procedimento a ser usado entre sistemas conectados através de uma rede. É semelhante ao mecanismo IPC, em que o sistema operacional permite que os processos gerenciem dados compartilhados e lidem com um ambiente em que diferentes processos estão sendo executados em sistemas separados e requerem necessariamente comunicação baseada em.
Vamos entender como a RPC é implementada através das etapas fornecidas:
- O processo do cliente chama o stub do cliente com parâmetros e sua execução é suspensa até que a chamada seja concluída.
- Os parâmetros são convertidos em um formato independente de máquina, organizando o stub do cliente. Em seguida, é preparado o que contém a representação dos parâmetros.
- Para encontrar a identidade do site, o stub do cliente intercomunicará com o servidor de nomes no qual existe um procedimento remoto.
- Usando o protocolo de bloqueio, o cliente envia stub para o site em que existe a chamada de procedimento remoto. Esta etapa interrompe o stub do cliente até receber uma resposta.
- O site do servidor recebe os enviados do lado do cliente e os converte em formato específico da máquina.
- Agora, o stub do servidor executa uma chamada no procedimento do servidor, juntamente com os parâmetros, e o stub do servidor é interrompido até que o procedimento seja concluído.
- O procedimento do servidor retorna os resultados gerados para o stub do servidor e os resultados são convertidos em formato independente da máquina no stub do servidor e criam um contendo os resultados.
- O resultado é enviado ao stub do cliente, que é convertido novamente em formato específico da máquina, adequado para o stub do cliente.
- No último cliente, o stub retorna os resultados ao processo do cliente.
Definição de RMI
Invocação de método remoto (RMI) é semelhante ao RPC, mas é específico do idioma e um recurso do java. É permitido que um thread chame o método em um objeto remoto. Para manter a transparência no lado do cliente e do servidor, ele implementa objetos remotos usando stubs e esqueletos. O stub reside no cliente e, para o objeto remoto, ele se comporta como um proxy.
Quando um cliente chama um método remoto, o stub do método remoto é chamado. O stub do cliente é responsável pela criação e ing do pacote que contém o nome de um método e os parâmetros do empacotamento, e o esqueleto é responsável por receber o pacote.
O esqueleto desmarca os parâmetros e chama o método desejado no servidor. O esqueleto organiza o valor fornecido (ou exceções) com a parcela e o envia para o esboço do cliente. O esboço remonta a parcela de devolução e a envia ao cliente.Em Java, os parâmetros são passados para métodos e retornados na forma de referência. Isso pode ser problemático para o serviço RMI, pois nem todos os objetos são métodos remotos. Portanto, ele deve determinar quais poderiam ser passadas como referência e quais não.
Java usa o processo nomeado como serialização onde os objetos são passados como valor. O objeto remoto é localizado por passagem por valor. Também pode transmitir um objeto por referência, passando uma referência remota ao objeto junto com a URL da classe stub. A passagem por referência restringe um esboço para o objeto remoto.
- O RPC suporta paradigmas de programação procedural, portanto, é baseado em C, enquanto o RMI suporta paradigmas de programação orientados a objetos e é baseado em java.
- Os parâmetros passados para procedimentos remotos no RPC são as estruturas de dados comuns. Pelo contrário, o RMI transita objetos como um parâmetro para o método remoto.
- O RPC pode ser considerado como a versão mais antiga do RMI, e é usado nas linguagens de programação que suportam a programação procedural e só pode usar o método de passagem por valor. Por outro lado, o recurso RMI é desenvolvido com base na abordagem de programação moderna, que pode usar passagem por valor ou referência. Outra vantagem do RMI é que os parâmetros passados por referência podem ser alterados.
- O protocolo RPC gera mais despesas gerais que o RMI.
- Os parâmetros passados no RPC devem ser "in-out”, O que significa que o valor passado para o procedimento e o valor de saída devem ter os mesmos tipos de dados. Por outro lado, não há compulsão em passar "in-out”No RMI.
- No RPC, as referências não podem ser prováveis porque os dois processos têm o espaço de endereço distinto, mas é possível no caso de RMI.
Conclusão
O RPC e o RMI têm o mesmo objetivo, mas são usados em linguagens que suportam diferentes paradigmas de programação, portanto, possuem recursos distintos.