padrões-04 - padrões arquiteturais - broker

Padrões Arquiteturais

Sistemas Distribuídos: Broker

2 Livro Texto: Pattern Oriented Software Architecture - Buschmann

Eduardo N. F. Zagari

Sistemas Distribuídos

• Tendências: – Sistemas Comp. com múltiplas CPUs – Redes locais com centenas de hospedeiros

• Benefícios – Economia – Desempenho e escalabilidade – Distribuição intrínseca – Confiabilidade

• Desvantagem: hw e sw overhead



Padrões em S.D.

• Pipes e Filtros – Embora possa ser usado na distribuição é mais

freqüentemente empregado na estruturação do núcleo da aplicação

• Microkernel – Aplica-se a sistemas de software que devem ser

aptos a se adaptarem a mudanças nos requisitos do sistema

– Emprega a arquitetura Cliente-Servidor – Mais adequado a sistemas adaptáveis

• Broker



Broker

• Permite estruturar aplicações distribuídas através de componentes desacoplados, que interagem via invocações remotas

• Coordena toda a comunicação • Encaminhamento de requisições • Resultados • Exceções



Exemplo



Contexto

• Ambiente distribuído • Possivelmente heterogêneo • Com componentes cooperantes

independentes



Problema

• Construir um sistema de software complexo como um conjunto de componentes desacoplados e interoperantes – Grande flexibilidade, manutenabilidade,

“alterabilidade” – Potencialmente distribuíveis e escaláveis

• Entretanto... 1. Problemas com a forma de comunicação

(dependência do mecanismo de IPC, localização, linguagem de programação etc)

2. Problemas com a gerência dos serviços



Problema

• A distribuição deve ser transparente • Componentes deve ser aptos a acessar

serviços providos por terceiros através de invocações remotas com transparência de localização

• Pode-se precisar trocar, adicionar ou remover componentes em tempo de execução

• A arquitetura deve esconder detalhes específicos do sistema e da implementação do usuário



Solução

• Introduzir um componente broker para obter melhor desacoplamento entre clientes e servidores. – Servidores se registram no broker e exportam seus

serviços via interface dos métodos – Clientes acessam os serviços via broker – Broker localiza servidor apropriado, encaminha

requisições e transmite os resultados e exceções de volta ao cliente

• Broker provê a integração de duas tecnologias: a de distribuição e a de objetos



Estrutura

1. Servidor – Implementa objetos que expõem suas

funcionalidades via interfaces – Interfaces podem ser disponibilizadas através de

IDL ou de um padrão binário 2. Clientes

– Aplicações que acessam o serviço de pelo menos um servidor

– Para tanto, encaminham requisições ao broker e recebem dele as respostas ou exceções



Estrutura

3. Broker – Mensageiro responsável pela transmissão

das requisições, respostas e exceções – Deve prover algum mecanismo de

localização (identificador) – Oferece APIs aos clientes e servidores

(registro, invocação de métodos etc) – Pode prover serviços adicionais (serviço de

nomes, suporte a serialização/marshaling etc)



Estrutura

4. Proxy do lado do Cliente – Camada adicional entre cliente e broker – Provê transparência (objeto remoto aparece como se

fosse local). Esconde: • O mecanismo de IPC entre cliente e broker • A criação/remoção de blocos de memória • O marshaling de parâmetros e resultados

5. Proxy do lado do Servidor – Análogo ao anterior (recebem requisições,

desempacotam as mensagens, “de-serializam” os parâmetros, chamam os serviços apropriados e retornam resultados/exceções serializados ao cliente



Estrutura

6. Pontes – Componentes opcionais – Escondem detalhes de implementação

quando dois brokers interoperam em redes heterogêneas (diferentes redes, S.O.s etc)



Estrutura



Dinâmica – Cenário 1 Servidor se registra



Cenário 2 - Cliente envia requisição a servidor local (síncrona)



Cenário 3 – Interação de diferentes brokers via pontes



Implementação

1. Definir um modelo de objetos ou usar um modelo existente (nomes, objetos, requisições, valores, exceções, tipos suportados, extensões de tipos, interfaces e operações)

2. Decidir qual tipo de interoperabilidade de componentes o sistema deve oferecer (especificar um padrão binário ou introduzir uma IDL de alto nível)

• Vantagem/desvantagem 3. Especificar as APIs que o broker provê para

colaborar com clientes e servidores • Decidir também se invocações estáticas ou dinâmicas



Implementação

4. Usar objetos proxy para esconder detalhes de implementação dos clientes e servidores

5. Projetar o broker (como ele deve agir): • Protocolo on-the-wire detalhado • Broker local em toda máquina • Mecanismo de identificação do cliente para retorno

de resultados • Mecanismo de (un)marshaling de parâmetros



Implementação

• Prover buffers (se suportar comunicação assíncrona)

• Prover Diretório de Serviços • Serviço de Nomes • Informação de tipos dos servidores (se

suportar invocação de métodos dinâmica) • Planejar ação (semântica de erro) do broker

em caso de erros (de componentes e/ou da comunicação)

6. Desenvolver compiladores de IDL



Usos conhecidos

• CORBA • IBM SOM/DSOM • Microsoft OLE 2.x • WWW



Benefícios

• Transparência de localização • Mudança e extensão de componentes • Portabilidade de um sistema de Broker • Interoperabilidade entre diferentes

sistemas de Broker • Reusabilidade



Desvantagens

• Eficiência limitada • Baixa tolerância a falta (do broker)

• Teste e Debug - apresentam vantagem e desvantagem ao mesmo tempo: – Ex. vantagem: desenvolver cliente com

servidor já testado – Ex. desvantagem: testar um sistema de

broker inteiro...

padrões-04 - padrões arquiteturais - broker

Technology