redes de computadores ii

Redes de computadores II

Comunicação entre processosChamada de procedimento remoto (RPC)

Prof : Diovani Milhorim

Chamada de procedimento RemotoDefinição

Permite que um programa procedural chame uma função que reside em outro computador tão convenientemente como se esta função fosse parte do mesmo programa que executa, no mesmo computador.

Chamada de procedimento Remoto

Chamada de procedimento RemotoDefinição

RPC foi desenvolvida para permitir aos programadores se concentrar nas tarefas exigidas de um programa chamando funções e, tornando transparente ao programador o mecanismo que permite que as partes do aplicativo se comuniquem através de uma rede.

Chamada de procedimento RemotoHistória:

A idéia de RPC data de 1976, quando foi descrito no RFC 707. Um dos primeiros usos comerciais da tecnologia foi feita pela Xerox no "Courier", de 1981. A primeira implementação popular para Unix foi o Sun RPC (atualmente chamado ONC RPC), usado como base do Network File System e que ainda é usada em diversas plataformas.


Outra implementação pioneira em Unix foi o Network Computing System (NCS) da Apollo Computer, que posteriormente foi usada como fundação do DCE/RPC no Distributed Computing Environment (DCE).

Uma década depois a Microsoft adotou o DCE/RPC como base para a sua própria implementação de RPC, MSRPC, a DCOM foi implementada com base nesse sistema. Ainda no mesmo período da década de 1990, o ILU da Xerox PARC e o CORBA ofereciam outro paradigma de RPC baseado em objetos distribuídos, com mecanismos de herança.


De forma análoga, atualmente utiliza-se XML como linguagem de descrição de interface e HTTP como protocolo de rede para formar serviços web, cujas implementações incluem SOAP e XML-RPC.

Chamada de procedimento Remoto Características:

a definição de um procedimento remoto especifica parâmetros de entrada e de saída. Parâmetros de entrada são passados para o servidor enviando os valores dos argumentos na mensagem (request message). Parâmetros de saída são retornados para o cliente na mensagem de resposta (reply message).

Um procedimento remoto é executado em um ambiente diferente do seu chamador e não pode acessar variáveis do ambiente do chamador, como variáveis globais por exemplo

Chamada de procedimento remoto

Chamada de procedimento RemotoFuncionamento:

O cliente na inicialização localiza o servidor. O cliente invoca um procedimento local (stub), que serializa os

parâmetros (marshalling), constrói uma mensagem, invoca a camada de comunicação e bloqueia.

O servidor recebe a mensagem e:-faz o despacho para o stub apropriado.-este recupera os parâmetros (unmarshalling), e chama o procedimento escrito pelo programador.-o resultado é serializado e uma mensagem é enviada de volta.

O stub do cliente recebe a mensagem, faz o unmarshalling e devolve a resposta ao código cliente.


Stubs:

Escondem os códigos de chamada à rede. Protege as aplicações (cliente e servidor) dos

detalhes referentes à comunicação pela rede. Cabe ao stub a passagem de parâmetros entre os

procedimentos.

Chamada de procedimento RemotoSistemas RPC divididos em duas classes:

A) mecanismos RPC integrados a uma linguagem de programação particular que inclui uma notação para definir as interfaces

o cliente utiliza-se de bibliotecas de procedimentos convencionais para realizar as tarefas, como por exemplo a localização de um servidor que possa tratar seus requisitos. Tais bibliotecas são chamadas de user package. A figura abaixo mostra os níveis de um programa cliente:


B) Uso de de uma linguagem de definição de interface (IDL) para descrever as interfaces entre clientes e servidores. Sun RPC está incluída na segunda classe. Uma interface especifica as características dos procedimentos fornecidos por um servidor que são visíveis aos clientes do servidor. Estas características incluem: nomes dos procedimentos e os tipos de seus parâmetros (assinatura).

Uma interface possui uma lista de assinaturas. Os compiladores de interfaces podem ser projetados para processar interfaces a serem utilizadas com diferentes linguagens de programação.

Chamada de procedimento RemotoIDL – interface definition language

As interfaces são especificadas num formato independente de linguagem: as IDL.

Isto permite que muitos detalhes de implementação sejam escondidos da especificação da interface.

Chamada de procedimento RemotoIDL

Especifica características dos procedimentos fornecidos por um servidor que são visíveis aos clientes do servidor: assinaturas dos procedimentos, ou seja, seus nomes, junto com os tipos de seus argumentos de entrada e saída.

Exemplo de IDL

Chamada de procedimento remotoImplementação:

O software que suporta RPC tem três tarefas: a) Processar a interface: integrar mecanismos RPC com os

programas cliente e servidor em uma linguagem de programação convencional. Isto inclui o marshalling e unmarshalling de argumentos no cliente e no servidor e o despacho das mensagens de request para o procedimento apropriado no servidor.

b) Tratar a comunicação: transmitir e receber mensagens de request e reply

c) Ligar (binding): localizar o servidor apropriado para um serviço particular

Chamada de procedimento remotoProcessar a interface:

Construindo o programa cliente: Antes que um programa cliente possa executar, chamando os procedimentos remotos, é preciso que o stub seja gerado. O stub tem o propósito de converter uma chamada a um procedimento para uma chamada remota ao mesmo procedimento. Os tipos dos argumentos e os resultados no stub do cliente devem conferir com aqueles esperados pelo procedimento remoto. Isto é alcançado através da utilização de uma linguagem comum de definição de interface, por exemplo a IDL, mostrada anteriormente.

Chamada de procedimento remotoSTUB

A tarefa do stub do cliente é fazer o marshalling, isto é, empacotar os argumentos do procedimento, os valores de tipos de dados simples e o identificador do procedimento em uma mensagem. O cliente deve enviar a mensagem ao servidor e esperar pela resposta. Quando a resposta retorna, o cliente deve fazer o unmarshalling (processo inverso ao marshalling) e retornar os resultados.

Chamada de procedimento remotoPrograma servidor:

Um sistema RPC fornecerá um despachador e um conjunto de stubs para os procedimentos. O despachador usa o identificador do procedimento na mensagem enviada pelo cliente para selecionar um dos stubs e passar os argumentos. A tarefa de um stub no servidor é fazer o unmarshalling dos argumentos, chamar o procedimento apropriado, e quanto retornar, fazer o marshalling dos argumentos de saída.


Existe um compilador de interfaces para processar as definições de uma interface escritas em uma linguagem de definição de interface (IDL). Tais compiladores são projetados para produzir componentes que podem ser combinados com programas clientes e programas servidores, sem quaisquer modificações nos compiladores originais.

Chamada de procedimento remotoUm compilador de interface normalmente realiza as seguintes tarefas:

Gera um stub-cliente para cada assinatura de procedimento na interface. Os stubs serão compilados e ligados com o programa cliente

Gera um stub-servidor para cada assinatura de procedimento na interface. O despachador e os stubs serão compilados e ligados com o programa servidor.

Usa as assinaturas dos procedimentos na interface – que definem os argumentos e os tipos resultantes – para gerar as operações de marshalling e unmarshalling apropriadas em cada stub.

Gera os cabeçalhos para cada procedimento no serviço de definição da interface. O programador do serviço fornece o corpo (implementação) destes procedimentos.

Chamada de procedimento remotoRPC-sun e rpcgen

RPC-sun : criado orginalmente para máquinas sun. Hoje disponível em vários sistemas.

Constitui-se de: Uma linguagem de definição de interfaces (RPCL). Aplicativo rpcgen, que cria os stub de comunicação Biblioteca RPC Protocolo de comunicação para as aplicações.

Chamada de procedimento remotoRpc-gen – criação dos arquivos

Chamada de procedimento remotoLigar (binding):

Um cliente para enviar uma mensagem a um servidor, deve utilizar um serviço de nomes disponível no sistema distribuído. O cliente procura neste serviço de nomes por um servidor que possa atender à sua chamada de procedimento.

Em geral o serviço é executado por servidores portmmap.

Chamada de procedimento remotoPortmapper: O portmapper RPC é um servidor que converte

números de processos RPC em números no protocolo TCP/IP (ou UDP/IP).

Ele deve estar executando para que seja possível realizar chamadas RPC para servidores RPC em determinada máquina.

Quando um servidor RPC é iniciado, ele irá dizer ao portmap qual número de porta ele está ouvindo, e quais programas RPC ele está preparado para atender.

Quando um cliente deseja realizar uma chamada RPC para um determinado número de processo, ele deve primeiro contatar o portmap no servidor, para determinar o número da porta a qual os pacotes RPC devem ser enviados.

Chamada de procedimento remotoPortmapper:

Chamada de procedimento remotoJava RMI

Java RMI permite que objetos Java executando no mesmo computador ou em computadores separados se comuniquem entre si via chamadas de métodos remotos. Essas chamadas são muito semelhantes àquelas que operam em objetos no mesmo programa.

Java RMI é uma implementação da RPC por Java para comunicação distribuída de um objeto Java com outro. Um vez que um método (ou serviço) de um objeto Java é registrado como sendo remotamente acessível, um cliente pode pesquisar (lookup) esse serviço e receber uma referência que permita ao cliente utilizar esse serviço (isto é,

chamar o método).

Chamada de procedimento remotoIntrodução

CORBA (Common Object Request Broker Architecture) é uma tecnologia padronizada pela OMG (Object Management Group) para oferecer uma arquitetura de computação distribuída. Componentes são construídos em uma das linguagens permitidas (C, C++, Java, dentre outras) e têm suas interfaces exportadas e disponibilizadas através de suas descrições em uma linguagem padrão denominada IDL (Interface Definition Language). Neste contexto, componentes podem se comunicar, invocando e/ou oferecendo serviços, independentemente da linguagem de programação na qual foram escritos e da localização dos mesmos no sistema distribuído.

Chamada de procedimento remotoPrincípios de Projeto do CORBA

Separação de interface e implementação: clientes dependem de interfaces e não de implementações;

Transparência de localização: uso do serviço é ortogonal à localização do serviço;

Transparência de acesso: invocação de operações em objetos;

Interfaces com tipos: referências aos objetos são tipadas pelas interfaces;

Suporte de herança múltipla de interfaces

.

Chamada de procedimento remotoCORBA IDL (OMG IDL):

Linguagem de definição de interfaces orientada a objetos Usada para especificar interfaces contendo atributos e operações Suporta herança de interfaces (herança múltipla e simples), atributos e

operações, tipos básicos (e.g., double, char, long, etc.), arrays e seqüências

Projetada para ser mapeada para múltiplas linguagens (e.g., C, C++, COBOL, Java, etc.)

Similar às interfaces Java e classes abstratas C++ Não é uma linguagem de programação completa, pois define somente

interfaces

Chamada de procedimento remotoSOAP

SOAP é um protocolo baseado em XML para troca de informações em um ambiente distribuído.

Os Web services são componentes que permitem às aplicações enviar e receber dados em formato XML Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML.


SOAP é um procolo projetado para invocar aplicações remotas através de RPC ou trocas de mensagens, em um ambiente independente de plataforma e linguagem de programação. SOAP é, portanto, um padrão normalmente aceito para utilizar-se com Web Services. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização de uma linguagem (XML) e mecanismo de transporte (HTTP) padrões.

Chamada de procedimento remotoSOAPSOAP sobre HTTP (POST) (Pedido)

POST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn

SOAPAction: "Some-URI"

<SOAP-ENV:Envelope

xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/“

SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetLastTradePrice xmlns:m="Some-URI">

<symbol>DIS</symbol>

</m:GetLastTradePrice>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>


SOAP sobre HTTP (Resposta)

HTTP/1.1 200 OK

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn

<SOAP-ENV:Envelope

xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/“

SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

<SOAP-ENV:Body>

<m:GetLastTradePriceResponse xmlns:m="Some-URI">

<Price>34.5</Price>

</m:GetLastTradePriceResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

redes de computadores ii

Documents