Padrões-04 - Padrões Arquiteturais - Broker

Padrões Arquiteturais

Sistemas Distribuídos:
Broker

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
2 Livro Texto: Pattern Oriented Software Eduardo N. F. Zagari
Architecture - Buschmann

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

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Padrões-04 - Padrões Arquiteturais - Broker

Mais de Eduardo Nicola F. Zagari

Padrões-04 - Padrões Arquiteturais - Broker