Comunicação indireta em sistemas distribuídos

COMUNICAÇÃO INDIRETA
VICTOR HAZIN DA ROCHA

É DEFINIDA COMO A COMUNICAÇÃO ENTRE
ENTIDADES DE UM SISTEMA DISTRIBUÍDO
POR MEIO DE UM INTERMEDIÁRIO, SEM
NENHUM ACOPLAMENTO DIRETO ENTRE O
REMETENTE E O DESTINATÁRIO (OU
DESTINATÁRIOS).

O REMETENTE NÃO SABE OU NÃO PRECISA
SABER A IDENTIDADE DO DESTINATÁRIO
(OU DESTINATÁRIOS) E VICE-VERSA.
DESACOPLAMENTO ESPACIAL

DESACOPLAMENTO ESPACIAL
▸ Por causa do desacoplamento espacial, o desenvolvedor
de sistema tem muitos graus de liberdade para lidar com
alterações.
▸ Os participantes podem ser substituídos, atualizados,
duplicados ou migrados.

REMETENTE E O DESTINATÁRIO (OU
DESTINATÁRIOS) PODEM TER TEMPOS DE
VIDA INDEPENDENTES.  
EM OUTRAS PALAVRAS, O REMETENTE E O
DESTINATÁRIO (OU DESTINATÁRIOS) NÃO
PRECISAM EXISTIR AO MESMO TEMPO
PARA SE COMUNICAR.
DESACOPLAMENTO TEMPORAL

ACOPLAMENTO TEMPORAL DESACOPLAMENTO TEMPORAL
ACOPLAMENTO
ESPACIAL
Comunicação direcionada para
determinado destinatário (ou
destinatários);
 
O destinatário (ou destinatários) deve
existir nesse momento no tempo.
Propriedades: comunicação direcionada
para determinado destinatário (ou
destinatários);
O remetente (ou remetentes) e o
destinatário (ou destinatários) podem ter
tempos de vida independentes.
DESACOPLAMENTO
ESPACIAL
Propriedades: o remetente não precisa
conhecer a identidade do destinatário
(ou destinatários);
O destinatário (ou destinatá- rios) deve
existir nesse momento no tempo.
O remetente não precisa conhecer a
identidade do destinatário (ou
destinatários); 
O remetente (ou remetentes) e o
destinatário 
(ou destinatários) podem ter tempos de
vida independentes.

▸ Frequentemente usada em sistemas distribuídos em que são
previstas alterações;
▸ Ex: Ambientes moveis, onde os usuários podem se conectar e
desconectar rapidamente da rede global – e devem ser
gerenciadas para fornecer serviços mais conﬁáveis.
▸ Muito usada para disseminação de eventos em sistemas
distribuídos, em que os destinatários podem ser desconhecidos e
estar propensos à mudança;
▸ Ex:no gerenciamento da disseminação de eventos (feeds) em
sistemas ﬁnanceiros.

COMUNICAÇÃO EM INDIRETA X COMUNICAÇÃO ASSÍNCRONA
▸ Na comunicação assíncrona, um remetente envia uma
mensagem e, então, continua (sem bloquear);
▸ Não há necessidade de esperar o destinatário para se
comunicar;
▸ O desacoplamento temporal adiciona a dimensão extra de que
o remetente e o destinatário (ou destinatários) podem ter
existências independentes;
▸ O destinatário pode não existir no momento em que a
comunicação é iniciada.

COMUNICAÇÃO EM GRUPO
PUBLISH-SUBSCRIBER
FILAS DE MENSAGENS
MEMÓRIA COMPARTILHADA

A COMUNICAÇÃO EM GRUPO OFERECE UM SERVIÇO
POR MEIO DO QUAL UMA MENSAGEM É ENVIADA
PARA UM GRUPO E, ENTÃO, ENTREGUE A TODOS OS
MEMBROS DO GRUPO. NESSA AÇÃO, O REMETENTE
NÃO CONHECE A IDENTIDADE DOS DESTINATÁRIOS.

▸ A comunicação em grupo representa uma abstração em
relação à comunicação por multicast;
▸ Pode ser implementada sobre multicast IP ou sobre uma rede
de sobreposição equivalente, melhorando signiﬁcativamente
o gerenciamento de participantes do grupo e a detecção de
falhas e fornecendo garantias de conﬁabilidade e ordenação;
▸ Com as garantias reforçadas, a comunicação em grupo está
para o multicast IP assim como o TCP está para o serviço
ponto a ponto em IP.

▸ Na comunicação em grupo, o conceito central é o de um
grupo com atribuições de membros associadas por meio
das quais os processos podem ingressar no grupo ou sair
dele.
▸ Os processos podem enviar uma mensagem para esse
grupo e, então, ela é propagada para todos os seus
membros, com certas garantias em termos de
conﬁabilidade e ordenação.

▸ Assim, a comunicação em grupo implementa
comunicação por multicast, na qual uma mensagem é
enviada para todos os membros do grupo por meio de
uma única operação.
▸ A comunicação para todos os processos no sistema, em
contraste com o envio para um subgrupo deles, é
conhecida como broadcast, enquanto a comunicação para
um único processo é conhecida como unicast.

▸ A característica fundamental da comunicação em grupo é
que um processo executa somente uma operação de
multicast para enviar uma mensagem para cada processo
de um grupo de processos, em vez de executar várias
operações de envio para processos individuais.
▸ Em Java, essa operação é:
aGroup.send(aMessage)

GRUPOS DE PROCESSOS
▸ São grupos em que as entidades que se comunicam são
processos;
▸ Esses serviços são de nível relativamente baixo;
▸ As mensagens são entregues para processos e nenhum
outro suporte para entrega é fornecido;
▸ Normalmente, as mensagens são vetores de byte não
estruturados, sem suporte para empacotamento de
tipos de dados complexos.

GRUPOS DE OBJETOS
▸ Um grupo de objetos é um conjunto de objetos que
processam o mesmo conjunto de invocações
concorrentemente, com cada um retornando respostas.
▸ Fornecem uma estratégia de nível mais alto para a
computação em grupo.
▸ Os objetos clientes não precisam estar cientes da
replicação.

GRUPOS DE OBJETOS
▸ Eles ativam operações em um único objeto local, o qual
atua como proxy para o grupo.
▸ O proxy usa um sistema de comunicação em grupo para
enviar as invocações para os membros do grupo de
objetos.
▸ Os parâmetros e resultados do objeto são empacotados
como na RMI e as chamadas associadas são entregues
automaticamente para os objetos/métodos de destino
corretos.

GRUPOS DE OBJETOS
▸ O Electra [Maffeis 1995] é um sistema compatível com
CORBA que suporta grupos de objetos;
▸ Um grupo do Electra pode fazer interface com qualquer
aplicativo compatível com CORBA;
▸ O Electra foi construído originalmente sobre o sistema de
comunicação em grupo Horus para gerenciar a
participação como membro do grupo e para fazer
multicast das invocações.

GRUPOS FECHADOS
▸ Um grupo é fechado se
somente membros do
grupo podem enviar
mensagem para ele;
▸ Um processo em um grupo
fechado entrega para si
mesmo qualquer
mensagem que envie para
o grupo;
Closed group

GRUPOS ABERTOS
▸ Um grupo é aberto se
processos de fora do
grupo podem enviar
mensagens para ele.
Closed group Open group

GRUPOS FECHADOS E ABERTOS
▸ As categorias “aberto” e “fechado” também se aplicam,
com signiﬁcados similares, às listas de correio.

▸ Os grupos fechados de processos são úteis, por
exemplo, para servidores em cooperação enviarem, uns
para os outros, mensagens que somente eles devem
receber.

▸ Os grupos abertos são úteis, por exemplo, para entregar
eventos para grupos de processos interessados.

GRUPOS SOBREPOSTOS E NÃO SOBREPOSTOS
▸ Nos grupos sobrepostos,as entidades (processos ou
objetos) podem ser membros de vários grupos;
▸ Nos grupos não sobrepostos a participação como
membro não deve se sobrepor (isto é, qualquer processo
pertence, no máximo, a um grupo).

GRUPOS SOBREPOSTOS E NÃO SOBREPOSTOS
▸ Em sistemas reais, pode-se esperar que a participação
como membro do grupo se sobreponha;
▸ A comunicação para todos os processos no sistema, em
contraste com o envio para um subgrupo deles, é
conhecida como broadcast, enquanto a comunicação para
um único processo é conhecida como unicast.

PROBLEMAS DE
IMPLEMENTAÇÃO

CONFIABILIDADE E ORDENAÇÃO
▸ Todos os membros de um grupo devem receber cópias
das mensagens enviadas para o grupo, geralmente com
garantias de entrega;
▸ As garantias incluem acordo sobre o conjunto de
mensagens que todo processo do grupo deve receber e
sobre a ordem de entrega para os membros do grupo.

▸ Integridade:
▸ A mensagem recebida é a mesma que foi enviada e
nenhuma mensagem é entregue duas vezes;
▸ Validade:
▸ Qualquer mensagem enviada é entregue;
▸ Acordo:
▸ Se a mensagem é entregue para um processo, então ela é
entregue para todos os processos do grupo.

▸ A comunicação em grupo exige garantias extras em
termos da ordem relativa das mensagens entregues para
vários destinos;
▸ A ordem não é garantida pelas primitivas de comunicação
entre processos;
▸ Por exemplo, se o multicast é implementado por uma
série de mensagens de um para um, elas podem ﬁcar
sujeitas a atrasos arbitrários.

▸ Os serviços de comunicação em grupo oferecem multicast
ordenado, com a opção de uma ou mais das propriedades
a seguir:
▸ Ordem FIFO:
▸ O primeiro a entrar é o primeiro a sair;

ordenado, com a opção de uma ou mais das propriedades a seguir:
▸ Ordem causal:
▸ A ordem causal leva em conta as relações causais entre as
mensagens;
▸ Se uma mensagem acontece antes de outra no sistema
distribuído, essa assim chamada relação causal vai ser
preservada na entrega das mensagens associadas em todos
os processos

ordenado, com a opção de uma ou mais das propriedades
a seguir:
▸ Ordem total:
▸ Se uma mensagem for entregue antes de outra em
um processo, então a mesma ordem vai ser
preservada em todos os processos.

GERENCIAMENTO DA PARTICIPAÇÃO NO GRUPO
▸ Um serviço de gerenciamento de participação de um grupo
tem quatro tarefas principais:
▸ Fornecer uma interface para mudanças de participação
como membro do grupo;
▸ Detecção de falha;
▸ Notiﬁcar os membros sobre mudanças de participação
no grupo;
▸ Realizar expansão de endereço de grupo.

▸ Fornecer uma interface para mudanças de participação
como membro do grupo:
▸ O serviço de participação no grupo fornece operações
para criar e destruir grupos de processos e para
adicionar ou retirar um processo de um grupo;
▸ Na maioria dos sistemas, um único processo pode
pertencer a vários grupos ao mesmo tempo (grupos
sobrepostos, conforme deﬁnido anteriormente).

▸ Detecção de falha:
▸ Esse serviço monitora os membros do grupo não somente para o
caso de falha por colapso, mas também para o caso de se
tornarem inacessíveis devido a uma falha de comunicação;
▸ O detector marca os processos como Suspeitos ou Não suspeitos;
▸ O serviço usa o detector de falha para chegar a uma decisão
sobre a participação como membro do grupo:
▸ Ele exclui um processo como membro se houver suspeita de
que ele falhou ou se tornou inacessível.

▸ Notiﬁcar os membros sobre mudanças de participação no
grupo:
▸ O serviço notiﬁca os membros do grupo quando um
processo é adicionado ou quando um processo é
excluído (devido a uma falha ou quando é
deliberadamente retirado do grupo).

▸ Realizar expansão de endereço de grupo:
▸ Quando um processo envia uma mensagem ao grupo, ele o faz através de
um identiﬁcador de grupo, em vez de uma lista dos processos no grupo;
▸ O serviço de gerenciamento de participação de membros expande o
identiﬁcador para os membros que pertencem ao grupo;
▸ O serviço pode coordenar a entrega mesmo com mudanças na
participação de membros no grupo;
▸ Isto é, ele pode decidir coerentemente onde vai entregar determinada
mensagem, mesmo que a participação como membro tenha mudado
durante a entrega.

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5  
© Pearson Education 2012
Join
Group
address
expansion
Multicast
communication
Group
send
Fail
Group membership
management
Leave
Process group

▸ Em geral, a necessidade de manter a participação como
membro do grupo tem um impacto signiﬁcativo sobre a
utilidade das estratégias baseadas em grupo.
▸ Em particular, a comunicação em grupo é mais eﬁciente
em sistemas de pequena escala e estáticos e não funciona
tão bem em ambientes de escala maior ou em ambientes
com alto grau de volatilidade.

PUBLISH-SUBSCRIBER
▸ Também referidos como sistemas baseados em eventos
distribuídos [Muhl et al. 2006];
▸ Essas são as mais amplamente utilizadas de todas as
técnicas de comunicação indireta apresentadas nessa
aula.

É UM SISTEMA EM QUE PUBLICADORES
DIVULGAM EVENTOS ESTRUTURADOS PARA
UM SERVIÇO DE EVENTO E ASSINANTES
EXPRESSAM INTERESSE EM EVENTOS
ESPECÍFICOS POR MEIO DE ASSINATURAS, AS
QUAIS PODEM SER PADRÕES ARBITRÁRIOS
SOBRE OS EVENTOS ESTRUTURADOS.
SISTEMAS PUBLICAR-ASSINAR

PUBLISH-SUBSCRIBER
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4  

PUBLISH-SUBSCRIBER
▸ Um assinante poderia expressar interesse em todos os eventos
relacionados a esta aula sobre sistemas distribuídos, como a
disponibilidade de uma nova aula ou atualizações no seu site.
▸ A tarefa do sistema publicar-assinar é combinar as assinaturas
com os eventos publicados e garantir a entrega correta de
notiﬁcações de evento.
▸ Determinado evento vai ser entregue possivelmente para
muitos assinantes e, assim, o publicar-assinar é,
fundamentalmente, um paradigma de comunicação de um
para muitos.

APLICAÇÕES DE SISTEMAS PUBLICAR-ASSINAR
▸ Sistemas de informação ﬁnanceira;
▸ Outras áreas com divulgação ao vivo de dados em tempo real
(incluindo feeds RSS);
▸ Suporte para trabalho cooperativo, em que vários participantes
precisam ser informados sobre eventos de interesse compartilhado;
▸ Suporte para computação ubíqua, incluindo o gerenciamento de
eventos provenientes de infraestrutura ubíqua (por exemplo, eventos
de localização);
▸ Um grande conjunto de aplicativos de monitoramento, incluindo
monitoramento de rede na Internet.

SISTEMA DE SALA DE NEGOCIAÇÕES
Dealer’s computer
Information
provider
Dealer
External
source
External
source
Information
provider
Dealer
Dealer
Dealer
Notification
Notification
Notification
Notification
Notification
Notification
Notification
Notification
Dealer’s computer
Dealer’s computerDealer’s computer
Notification
Notification

CARACTERÍSTICAS
▸ Um sistemas publisher-subscriber têm duas características
principais:
▸ Heterogeneidade;
▸ Assincronismo.

PUBLISH-SUBSCRIBER: HETEROGENEIDADE
▸ Quando notiﬁcações de evento são usadas como meio de
comunicação, pode-se fazer com que componentes de um
sistema distribuído que não foram projetados para
operação conjunta funcionem juntos;
▸ Basta os objetos que geram eventos publicarem os tipos
de eventos que oferecem e outros objetos assinarem os
padrões de eventos e fornecerem uma interface para
receber e lidar com as notiﬁcações resultantes.

PUBLISH-SUBSCRIBER: HETEROGENEIDADE
▸ Bates et al. [1996] descrevem como os sistemas publicar-assinar
podem ser usados para conectar componentes heterogêneos
na Internet:
▸ Eles descrevem um sistema no qual os aplicativos podem
reconhecer as localizações e atividades dos usuários, como o
uso de computadores, impressoras ou livros etiquetados
eletronicamente;
▸ Eles imaginam seu uso futuro no contexto de uma rede
doméstica suportando comandos como: “se as crianças
chegarem, ligue o aquecimento central”.

PUBLISH-SUBSCRIBER: ASSINCRONISMO
▸ As notiﬁcações são enviadas de forma assíncrona,pelos
publicadores que geram eventos, a todos os assinantes
que expressaram interesse neles;
▸ Para evitar que os publicadores precisem estar
sincronizados com os assinantes – os publicadores e os
assinantes

▸ O Mushroom [Kindberg et al. 1996] é um sistema publicar-
assinar baseado em objetos projetado para suportar trabalho
colaborativo, no qual a interface exibe objetos que representam
usuários e objetos informação, como documentos e blocos de
anotações dentro de espaços de trabalho compartilhados,
chamados de lugares da rede.
▸ O estado de cada lugar é replicado nos computadores dos
usuários que estão nesse lugar.
▸ Eventos são usados para descrever mudanças nos objetos e no
foco de interesse de um usuário.

▸ Um evento poderia especificar que um usuário em particular
entrou ou saiu de um lugar ou executou determinada ação em
um objeto.
▸ Cada réplica de qualquer objeto, para o qual tipos de eventos
específicos são relevantes, expressa interesse neles por meio
de uma assinatura e recebe notificações quando elas ocorrem.
▸ No entanto, os assinantes de eventos são desacoplados dos
objetos que recebem eventos, pois diferentes usuários estão
ativos em diferentes momentos.

PUBLISH-SUBSCRIBER
▸ Os publicadores disseminam um evento por meio de uma
operação publish(e) e os assinantes expressam interesse
em um conjunto de eventos por meio de assinaturas.

PUBLISH-SUBSCRIBER
▸ Eles conseguem isso por meio de uma operação
subscribe(f), onde f se refere a um ﬁltro.

PUBLISH-SUBSCRIBER
▸ Posteriormente, os assinantes podem revogar esse
interesse por meio de uma operação unsubscribe(f)
correspondente.

PUBLISH-SUBSCRIBER
▸ Quando chegam eventos para um assinante, eles são
entregues usando uma operação notify(e).

PUBLISH-SUBSCRIBER
▸ Alguns sistemas complementam o conjunto de operações
anteriores, introduzindo o conceito de anúncios.

PUBLISH-SUBSCRIBER
▸ Com os anúncios, os publicadores têm a opção de
declarar a natureza de futuros eventos por meio de uma
operação advertise(f).

PUBLISH-SUBSCRIBER
▸ Os anúncios são deﬁnidos em termos dos tipos de
eventos de interesse (que assumem a mesma forma dos
ﬁltros);
▸ Em outras palavras, os assinantes declaram seu interesse
em termos de assinaturas e, opcionalmente, os
publicadores declaram os estilos de eventos que vão
gerar por meio de anúncios;
▸ Os anúncios podem ser revogados com uma chamada de
unadvertise(f).

PUBLISH-SUBSCRIBER
▸ A expressividade dos sistemas publicar-assinar é
determinada pelo modelo de assinatura (ﬁltro), com vários
esquemas possíveis:
▸ Baseado em canal;
▸ Baseado em tópico;
▸ Baseado em conteúdo;
▸ Baseado em tipo.

PUBLISH-SUBSCRIBER: BASEADO EM CANAL
▸ Os publicadores divulgam eventos para canais nomeados e,
então, os assinantes se inscrevem em um deles para receber
todos os eventos enviados para esse canal;
▸ Esse é um esquema bastante primitivo e o único que define um
canal fí sico;
▸ Todos os outros esquemas empregam alguma forma de filtragem
no conteúdo de um evento, conforme veremos a seguir;
▸ Embora simples, esse esquema tem sido usado com sucesso no
Event Service do CORBA.

PUBLISH-SUBSCRIBER: BASEADO EM TÓPICO
▸ Também chamado de baseado em assunto;
▸ Nesta estratégia, supomos que cada notiﬁcação é
expressa em termos de vários campos, com um deles
denotando o tópico;
▸ Então, as assinaturas são deﬁnidas em termos do tópico
de interesse.

▸ Esta estratégia é equivalente às estratégias baseadas em
canal, sendo que a diferença é que os tópicos são
deﬁnidos implicitamente no caso dos canais, mas
declarados explicitamente como um dos campos nas
estratégias baseadas em tópico;
▸ A expressividade das estratégias baseadas em tópico
também pode ser melhorada pela introdução de uma
organização hierárquica de tópicos.

▸ EX:
▸ Consideraremos um sistema publicar-assinar para um livro;
▸ As assinaturas poderiam ser deﬁnidas em termos de
comunicação_indireta ou comunicação_indireta/publicar-assinar;
▸ Os assinantes que expressem interesse no primeiro receberão
todos os eventos relacionados a este capítulo;
▸ Enquanto, no segundo caso, os assinantes podem expressar
interesse no tópico mais especíﬁco da publicar-assinar.

PUBLISH-SUBSCRIBER: BASEADO EM CONTEÚDO
▸ As estratégias baseadas em conteúdo são uma
generalização das baseadas em tópico, permitindo a
expressão de assinaturas sobre diversos campos em uma
notificação de evento.
▸ Mais especificamente, um filtro baseado em conteúdo é
uma consulta definida em termos de composições de
restrições sobre os valores de atributos de evento.

PUBLISH-SUBSCRIBER: BASEADO EM CONTEÚDO
▸ Ex:
▸ Um assinante poderia expressar interesse nos eventos
relacionados ao tópico dos sistemas publicar-assinar, onde
o sistema em questão é o “Event Service do CORBA” e
onde o autor é “Tim Kin- dberg” ou “Gordon Blair”.
▸ A soﬁsticação das linguagens de consulta associadas varia
de um sistema para outro, mas em geral essa estratégia é
signiﬁcativamente mais expressiva do que as estratégias
baseadas em canal ou em tópico,

PUBLISH-SUBSCRIBER: BASEADO EM TIPO
▸ Estas estratégias estão intrinsecamente ligadas às
estratégias baseadas em objeto, em que os objetos têm
um tipo específico.
▸ Nas estratégias baseadas em tipo, as assinaturas são
definidas em termos de tipos de eventos e a combinação
é definida em termos de tipos ou subtipos do filtro dado.

PUBLISH-SUBSCRIBER: BASEADO EM TIPO
▸ Esta estratégia pode expressar diversos filtros, desde filtragem
mais grossa, baseada em nomes de tipo globais, até consultas
mais refinadas, definindo atributos e métodos de determinado
objeto.
▸ Esses filtros refinados têm expressividade semelhante às
estratégias baseadas em conteúdo.
▸ As vantagens das estratégias baseadas em tipo é que elas
podem ser elegantemente integradas às linguagens de
programação e podem verificar a exatidão do tipo das
assinaturas, eliminando alguns tipos de erros de assinatura.

A ARQUITETURA DE SISTEMAS PUBLISH-SUBSCRIBE

PROBLEMAS DE
IMPLEMENTAÇÃO
PUBLISH-SUBSCRIBER

IMPLEMENTAÇÕES CENTRALIZADAS VERSUS DISTRIBUÍDAS
▸ Foram identiﬁcadas várias arquiteturas para a
implementação de sistemas publicar-assinar;
▸ A estratégia mais simples é centralizar a implementação
em um único nó, com um servidor nesse nó atuando como
intermediário de evento;
▸ Os publicadores divulgam eventos para esse
intermediário, e os assinantes enviam assinaturas para ele
e recebem notiﬁcações em resposta.

▸ Assim, a interação com o intermediário é por meio de uma
série de mensagens ponto a ponto;
▸ Isso pode ser implementado usando-se passagem de
mensagens ou invocação remota;
▸ Essa estratégia é simples de ser implementada, mas o
projeto não mostra ﬂexibilidade e escalabilidade;
▸ Pois o intermediário centralizado representa um ponto
único de falha e é um gargalo para o desempenho.

▸ Consequentemente, também estão disponíveis
implementações distribuídas de sistemas publicar-assinar;
▸ Nesses esquemas, o intermediário centralizado é
substituído por uma rede de intermediários, que coopera
para oferecer a funcionalidade desejada;
▸ Essas estratégias têm o potencial de sobreviver à falha do
nó e têm-se mostrado capazes de funcionar bem em
implantações na Internet.

75Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4  
IMPLEMENTAÇÕES CENTRALIZADAS VERSUS DISTRIBUÍDAS:
A REDE DE INTERMEDIÁRIOS

▸ Levando isso um passo adiante, é possível ter uma
implementação totalmente P2P de um sistema publicar-
assinar;
▸ Essa é uma estratégia de implementação muito popular
nos sistemas recentes, e não há distinção entre
publicadores, assinantes e intermediários;
▸ Todos os nós atuam como intermediários, implementando
cooperativamente a funcionalidade de roteamento de
evento exigida.

ARQUITETURA DE SISTEMAS PUBLISH-SUBSCRIBE

▸ A implementação distribuída das estratégias baseadas em
conteúdo ou, baseadas em tipo) é mais complexa e
merece mais considerações.

▸ Na camada inferior, os sistemas publicar-assinar fazem uso
de diversos serviços de comunicação entre processos,
como TCP/IP, multicast IP.

▸ A parte principal da arquitetura é fornecida pela camada
de roteamento de eventos suportada pela infraestrutura
de sobreposição de rede.

▸ O roteamento de eventos executa a tarefa de garantir que
as notiﬁcações de evento sejam roteadas da forma mais
eﬁciente possível para os assinantes apropriados.

▸ Para estratégias baseadas em conteúdo, esse problema é referido
como roteamento baseado em conteúdo (CBR, Content-Based
Routing), com o objetivo de explorar as informações do conteúdo
para rotear os eventos eﬁcientemente para seus destinos.

▸ A camada superior implementa a correspondência, isto é, garante que os
eventos correspondam a determinada assinatura;
▸ Embora isso possa ser implementado como uma camada separada, a
correspondência é rebaixada para os mecanismos de roteamento de evento.

▸ Enquanto a infraestrutura de sobreposição suporta isso
conﬁgurando redes de intermediários ou estruturas P2P
adequadas.

▸ Dentro dessa arquitetura global, há uma grande variedade
de estratégias de implementação:
▸ Inundação, Filtragem, Rendez-vous…

ARQUITETURA DE SISTEMAS PUBLISH-SUBSCRIBE:
INUNDAÇÃO
▸ A estratégia mais simples é baseada na “inundação";
▸ É enviada uma notiﬁcação de evento para todos os nós da
rede e, então, realizada a correspondência apropriada na
extremidade assinante.
▸ Essa estratégia tem a vantagem da simplicidade;
▸ Pode resultar em muito tráfego de rede desnecessário;

FILTRAGEM
▸ Um princípio que serve de base para muitas estratégias é
aplicar ﬁltragem na rede de intermediários;
▸ Os intermediários encaminham as notiﬁcações pela rede
somente onde há um caminho para um assinante válido;
▸ Isso é obtido pela propagação, pela rede, de informações
de assinatura para os publicadores em potencial, seguido
do armazenamento do estado associado em cada
intermediário.

FILTRAGEM
▸ Cada nó deve manter:
▸ Uma lista de vizinhos contendo uma relação de todos os
vizinhos conectados à rede de intermediários;
▸ Uma lista de assinaturas contendo uma relação de todos os
assinantes conectados diretamente e servidos por esse nó;
▸ Uma tabela de roteamento;
▸ A tabela de roteamento mantém uma lista de vizinhos e
assinaturas válidas para esse caminho.

EXEMPLOS DE SISTEMAS PUBLISH-SUBSCRIBE

FILAS DE MENSAGENS
▸ Estratégia para comunicação em sistemas distribuídos por
meio de filas;
▸ Processos produtores podem enviar mensagens para uma
fila específica e outros processos (consumidores) podem
receber mensagens dessa fila;
▸ Possui desacoplamento temporal e espacial.

FILAS DE MENSAGENS
▸ Enquanto os grupos e os sistemas publicar-assinar
fornecem um estilo de comunicação de um para muitos, as
ﬁlas de mensagem fornecem um serviço ponto a ponto;
▸ Elas são ponto a ponto no sentido de que o remetente
coloca a mensagem em uma ﬁla e isso, então, é removido
por um único processo.

FILAS DE MENSAGENS
▸ As ﬁlas de mensagem também são referidas como
middleware orientado a mensagens;
▸ É um tipo importante de middleware comercial;
▸ Ex: Websphere MQ (IBM), MSMQ (Microsoft) e Streams
Advanced Queuing (Oracle);
▸ São amplamente usadas como a base de sistemas de
processamento de transações comerciais, em razão de seu
suporte intrínseco para transações

FILAS DE MENSAGENS
▸ São suportados três estilos de recepção:
▸ Recepção com bloqueio:
▸ Bloqueará até que uma mensagem apropriada esteja disponível;
▸ Recepção sem bloqueio (uma operação de consulta):
▸ Verifica o status da fila e retornar uma mensagem, se estiver
disponível; caso contrário, retornará uma indicação de não disponível;
▸ Operação de notificação:
▸ Emite uma notificação de evento quando uma mensagem estiver
disponível na fila associada.

FILAS DE MENSAGENS

FILAS DE MENSAGENS
▸ O principal problema de implementação para sistemas de
enfileiramento de mensagem é a escolha entre implementações
centralizadas ou distribuídas;
▸ Algumas implementações são centralizadas, com uma ou mais filas
de mensagem controladas por um gerenciador de fila localizado em
determinado nó;
▸ A vantagem desse esquema é a simplicidade;
▸ gerenciadores podem se tornar componentes bastante pesados e
têm o potencial de se tornar um gargalo ou um único ponto de
falha.

FILAS DE MENSAGENS: WEBSPHERE MQ
▸ É um middleware desenvolvido pela IBM com base no conceito
de filas de mensagem, oferecendo uma indireção entre
remetentes e destinatários de mensagens ;
▸ As filas são controladas por gerenciadores de fila, os quais as
hospedam e comandam, e permitem que os aplicativos as
acessem por meio da MQI (Message Queue Interface);
▸ A MQI é uma interface relativamente simples que permite aos
aplicativos executar operações como conectar ou desconectar
de uma fila (MQCONN e MQDISC) ou enviar/receber
mensagens para/de uma fila (MQPUT e MQGET).

▸ Os aplicativos clientes que acessam um gerenciador de
fila podem residir no mesmo servidor fí sico.
▸ Geralmente, contudo, eles ficam em máquinas diferentes e
precisam se comunicar com o gerenciador de fila por
meio do que é conhecido como canal cliente.

▸ Os comandos MQI são executados no proxy e, então,
enviados de forma transparente para o gerenciador de ﬁla
para execução usando RPC.

FILAS DE MENSAGENS: JMS
▸ É uma especificação padronizada para programas Java
distribuídos, para comunicação indireta;
▸ A especificação unifica os paradigmas de sistemas
publicar-assinar e fila de mensagens pelo menos
superficialmente,;
▸ Suporta tópicos e filas como destinos de mensagens
alternativos.

▸ Um cliente JMS é um programa ou componente Java que produz ou
consome mensagens;
▸ Um produtor JMS é um programa que cria e produz mensagens;
▸ Um consumidor JMS é um programa que recebe e consome mensagens;
▸ Um provedor JMS é qualquer um dos vários sistemas que implementam a
especiﬁcação JMS;
▸ Uma mensagem JMS é um objeto usado para comunicar informações entre
clientes JMS (dos produtores para os consumidores);
▸ Um destino JMS é um objeto que suporta a comunicação indireta no JMS
(ou é um tópico JMS ou uma ﬁla JMS).

ESTRATÉGIAS DE MEMÓRIA COMPARTILHADA
▸ As duas estratégias mais utilizadas de compartilhamento
de memória em sistemas distribuídos são:
▸ Memória Compartilhada Distribuída (DSM, distributed
shared memory);
▸ Comunicação via espaço de tuplas.

DMS
▸ É uma abstração usada para compartilhar dados entre computadores
que não compartilham memória ﬁ́ sica;
▸ Os processos acessam a DSM por meio de leituras e atualizações no
que parece ser memória normal dentro de seus espaços de
endereçamento;
▸ Contudo, um suporte de execução runtime subjacente garante, de
forma transparente, que os processos sendo executados em diferentes
computadores observem as atualizações feitas pelos outros;
▸ É como se os processos acessassem uma única memória
compartilhada, mas na verdade a memória ﬁ́ sica é distribuída.

DMS
▸ A principal vantagem da DSM é que ela dispensa o
programador das preocupações com passagem de
mensagens ao escrever aplicativos;
▸ É uma ferramenta para aplicativos paralelos ou para qualquer
aplicativo distribuído no qual itens de dados compartilhados
individuais podem ser acessados diretamente;
▸ A DSM é menos adequada em sistemas cliente-servidor, em
que os clientes normalmente veem os recursos mantidos no
servidor como dados abstratos e os acessam por requisição;

COMUNICAÇÃO VIA ESPAÇO DE TUPLAS
▸ Os espaços de tuplas foram apresentados pela primeira
vez por David Gelernter;
▸ Os processos se comunicam indiretamente, colocando
tuplas em um espaço de tuplas, enquanto outros
processos podem ler ou remover tuplas desse espaço;
▸ As tuplas não têm endereço, mas são acessadas por
casamento de padrões no conteúdo .

COMUNICAÇÃO VIA ESPAÇO DE TUPLAS

REFERÊNCIAS
▸ Cap 06 - Sistemas Distribuídos -
Conceitos e Projeto - 5ª Ed. 2013 -
George Coulouris, Tim Kindberg, Jean
Dollimore

Comunicação indireta em sistemas distribuídos

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Comunicação indireta em sistemas distribuídos