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 Middlewarelocalizados 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 ProcedureCall (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 programasRPC.

• 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) daOpen 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 portmapdaemon 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 portmapdaemons de uma rede • os portmap daemons nos quais o respectivo programa

está registrado irá responder.