Programação de Sistemas

Distribuídos
Middleware

Prof(a): Marília Freire

@IFRN
 Roteiro da Aula
• Middleware
• Por que Middleware?
• Categorias de Middleware
• Middleware procedural (RPC)
Middleware
O que são aplicações distribuídas?
• Aplicações formadas por módulos que se
espalham por diversas máquinas

Internet
Como desenvolver aplicações distribuídas?

• Desenvolver
componentes
diretamente no topo
das primitivas do
sistema operacional é
extremamente
complexo para muitos
desenvolvedores de
aplicações.
 Como desenvolvê-las de forma
mais amigável?
• Usar suporte de Sistemas de Middleware
localizados entre componentes do sistema
distribuído e componentes do sistema
operacional
– tarefa de facilitar as interações entre esses
componentes
 Middleware
• Software que reside entre o sistema
operacional e a aplicação a fim de facilitar o
desenvolvimento de aplicações
• Camada de software que permite a
comunicação entre aplicações (distribuídas)
 Middleware (cont.)
• 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.
POR QUE USAR MIDDLEWARE?
 Por que Middleware?
• Construir aplicações distribuídas 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
 Por que Middleware?
• Desenvolvedores e administradores teriam
que implementar a ativação de componentes
• Implementar sincronização é extremamente
tedioso e propenso a erros
 Por que Middleware?
• Middleware simplifica a construção de
Aplicações Distribuídass implementando as
camadas de apresentação e sessão
 Middleware ou o que????
• Denominações Equivalentes:
– Modelos de Integração de Objetos
– Plataformas de Distribuição de Objetos
Categorias de Middleware
 Categorias de Middleware
• Middleware procedural / Remote Procedure
Call (RPC)
• Middleware orientado a
transação/transacional
• Middleware orientado a mensagem (MOM)
• Middleware orientado a objetos (MOO)
MIDDLEWARE PROCEDURAL
 Chamadas Remotas de
Procedimentos (RPC)
• É uma chamada de procedimento que cruza as
fronteiras dos componentes locais (hosts)
• Idéia básica
– Não há diferença lógica, para o cliente, entre chamar um procedimento
local ou um remoto
• Uma chamada remota de procedimento usa
comunicação direta, orientada a conexão e
síncrona para permitir a um processo cliente
chamar um procedimento remoto.
– Paradigma originalmente criado pela Sun Microsystems como parte de sua
plataforma Open Network Computing (ONC)
 Estrutura RPC
• Os componentes do lado servidor que
executam RPCs são chamados programas
RPC.
• Um programa RPC tem uma interface que
define os procedimentos que podem ser
chamados remotamente
– Define também os tipos de dados dos argumentos
que podem ser passados para procedimentos
remotos
Interface Definition Language - IDL
• Linguagem definida pelo middleware que é
independente de linguagem de programação
e responsável por descrever todos os serviços
disponibilizados por uma aplicação.
 Stub
• Código gerado por sistemas de chamadas
remotas de procedimentos
– contêm o código de chamadas à rede
– protege os programadores de aplicações de
detalhes de comunicação de baixo nível, como
sockets
– gerados automaticamente por algum compilador
– ex RPCgen
 Serviços
– comunicação
síncrona
(request/wait-for-
reply)
– Vários problemas
devem ser tratados
pelo programador
– Ex. Falhas na
comunicação
 Como habilitar uma chamada?
• Passos necessários para habilitar uma chamada
remota de procedimento:
1. Codificar o nome e os parâmetros do procedimento
usando a sintaxe da Interface Definition Language
(IDL) fornecida pelo middleware.
2. Gerar o código fonte para um stub cliente e para um
skeleton servidor (uso de compilador, ex RPCgen).
3. Compilar e linkar o stub no processo cliente.
4. Compilar e linkar o skeleton no processo servidor.
 Para realizar uma chamada
• Para fazer uma chamada (invocação) remota de
procedimento:
1. O processo cliente chama o stub do cliente como se fosse um
procedimento local.
2. O stub do cliente converte os parâmetros em uma cadeia de bits
(marshalling) e envia os bits na rede para o skeleton do servidor.
3. O skeleton do servidor converte os bits de volta para parâmetros
(unmarshalling) e chama o procedimento no servidor.
4. O skeleton do servidor converte a resposta do procedimento em uma
cadeia de bits e envia pela rede para o stub do cliente.
5. O stub do cliente converte os bits para a resposta e a retorna para o
procedimento chamador.
 Mecanismos de RPC conhecidos
• Distributed Computing Environment (DCE) da
Open Software Foundation (OSF).
• Open Network Computing (ONC) da SUN.
 RPC: Camada de Apresentação
• Responsável por mapear estruturas de dados
das aplicações para uma forma transmissível e
homogênea.
 RPC: Camada de Apresentação
• Os mapeamentos entre representações de
dados de aplicação para transporte são
chamados marshalling e unmarshalling.
– Marshalling pode ser implementado
estaticamente em tempo de compilação ou
dinamicamente em tempo de execução.
– Stubs dos lados cliente e servidor são
implementações estáticas de marshalling e
unmarshalling.
 RPC: Camada de Sessão
• A implementação da camada de sessão deve
habilitar clientes a localizar um servidor RPC
(estática ou dinamicamente)
Exemplo do Unix (Dynamic Binding):
1. Cada host de uma rede Unix que suporta RPCs roda
um daemon chamado portmap.
2. Todo servidor RPC registra seus programas no
portmap daemon que roda no host.
3. Clientes podem contactar um único portmap
daemon para obter uma lista de todos os programas
que residem no servidor.
4. Clientes podem também enviar por broadcast uma
busca por um programa para todos os portmap
daemons de uma rede
• os portmap daemons nos quais o respectivo programa
está registrado irá responder.