RPC
e Middleware
Visão Geral:
O RPC (Remote Procedure Call ou Chamada Remota de Procedimento) foi encomendado pela OSF (Open Software Foundation) para definir um fornecedor de tecnologia neutra e utilizador de padrão aberto, data sua criação em 1976, tendo em seus primeiros usos comerciais pela Xerox em 1981 e no Unix com o Sun RPC que usa como base NFS (Network File System) que é utilizado até hoje em diversas plataformas.
Como funciona:
Esse tipo de modelo permite que um programa procedural, ou seja, que apresente os procedimentos (passo-a-passo), chame uma função que reside em outro computador tão convenientemente como se essa função fosse parte do mesmo programa que executa no mesmo computador. O objetivo do RPC foi permitir aos programadores se concentrar nas tarefas exigidas de um aplicativo, e ao mesmo tempo, tornando transparente para o programador o mecanismo que permite que as partes do aplicativo se comuniquem através de uma rede.
O RPC trabalha de forma semelhante ao de chamada de procedimento local onde de forma simples o procedimento chamado por uma rotina separa os argumentos em uma área de memória comum e transfere o controle para execução que irá ler os argumentos e processar, após isso a rotina reassume o controle, recolhe o resultado na área de memória comum e segue a execução.
Nele temos uma Thread para controlar o processo invocador e servidor, onde o processo invocador envia mensagem para o processo servidor e aguarda o retorno, essa mensagem informa ao servidor os parâmetros do procedimento, o processo servidor trata esses parâmetros e responde com o resultado.
A maior vantagem do RPC é a chamada de métodos em outras linguagens, pois ele não é focado em uma linguagem específica, o que resulta em uma maior flexibilidade.
Chamada Local e Remota de Procedimento:
Dentre uma série de variáveis uma chamada remota de procedimento difere das chamadas locais em alguns pontos:
*Tratamento de erros: Deve-se tratar falhas do servidor ou da rede.
*Variáveis globais e efeitos colaterais: Uma vez que o servidor não possui acesso ao espaço de endereços do cliente, argumentos protegidos não podem ser passados como variáveis globais ou retornados.
*Desempenho: chamadas remotas geralmente operam a velocidades inferiores em uma ou mais ordens de grandeza em relação às chamadas locais.
*Autenticação: uma vez que chamadas remotas de procedimento podem ser transportadas em redes sem segurança, autenticação pode ser necessária. Dessa forma, mesmo havendo a possibilidade de se criar de forma automática o cliente e o servidor, os protocolos precisam ser desenvolvidos e configurados cuidadosamente.
Transporte:
O RPC pode trabalhar em cima de diferentes tipos de protocolos de transporte. Uma vez que a maneira como a mensagem é transmitida é indiferente entre processos, se faz necessário cuidado em relação a confiabilidade, uma vez que tal função não é desempenhada pelo RPC fica a cargo do protocolo sua execução, dessa forma o uso de protocolo não confiáveis como UDP precisam de implementações de confiabilidade. Já no TCP que trabalha a confiabilidade, a necessidade fica apenas quanto a verificação de timeouts pela aplicação para identificar falhas do servidor.
Atualmente:
Visando a utilização por diversos tipos de servidores e clientes foram criados e padronizados vários RPC’s, em sua maioria utilizam IDL (Interface Description Language = Linguagem de Descrição de Interface) para que diferentes plataformas possam utliza-lo para chamar procedimentos. Com esse formato, é possível gerar interfaces entre cliente/servidor que são chamadas de stubs, esses por sua vez vão embarcados na aplicação cliente e servidor, provendo a comunicação entre si, tal procedimento não pode, nem deve ser considerado uma camada de middleware.
Atualmente uma grande utilização do RPC está sendo feita junto ao XML, onde temos a tecnologia XML-RPC utilizada nos processos de NF-e. A ferramenta consegue trabalhar em implementações cliente/servidor de múltiplas plataformas e com um baixo tamanho de arquivo, o que possibilita boa navegação sem o consumo de grandes tamanhos de banda.
Criação do modelo RMI (RPC para Java), linguagens orientadas a objeto usam o termo método, em lugar de procedimento. Então, o dispositivo RPC que a Sun Microsystems criou para o java é chamado de Método de Invocação Remota do Java ( Java Remote Method Invocation, Java RIM).
Middleware
Visão Geral:
Um middleware ou mediador no campo da computação distribuída é um software que reside entre o sistema operacional e a aplicação a fim de facilitar o desenvolvimento de aplicações. É uma camada de software que permite a comunicação entre aplicações (distribuídas) agregando um conjunto de serviços que fornece comunicação e distribuição de forma transparente à aplicação. Middleware permite que processos em diferentes espaços de endereçamento consigam se comunicar.
Construir SDs diretamente no topo de uma camada de transporte é muito difícil, comunicação em geral precisa manipular o envio de parâmetros complexos, diferentes codificações de tipos de dados. Desenvolvedores e administradores teriam que implementar a ativação de componentes e implementar sincronização o que seria extremamente tedioso e propenso a erros.
Recursos e Vantagens:
Middleware simplifica a construção de SDs implementando as camadas de apresentação e sessão ou seja, o middleware está localizado entre as camadas de aplicação e transporte.
Imagem inserida (
http://faptech.wordpress.com/iptv/software-iptv/
)
Interface (API) única.
Interoperabilidade (de aplicações distribuídas).
Facilidade de Uso: Middleware deve ser mais fácil de usar do que escrever uma interface de comunicação de baixo nível usando sockets.
Transparência de Localização: Deve ser possível mover uma aplicação para um endereço de rede diferente sem a necessidade de recompilar qualquer software.
Transparência de Linguagem (e plataforma): Um processo usando o middleware deve ser capaz
de se comunicar com um processo que foi escrito em uma linguagem diferente.
Esconde do programador diferenças entre:
*Plataformas de hardware
*Sistemas operacionais
*Bibliotecas e protocolos de comunicação
