sd-comunicacao-indireta-sergiotcarvalho

Prévia do material em texto

UNIVERSIDADE FEDERAL DE GOIÁSUNIVERSIDADE FEDERAL DE GOIÁS
INSTITUTO DE INFORMÁTICAINSTITUTO DE INFORMÁTICA
Sistemas DistribuídosSistemas Distribuídos
Prof. Sérgio T. Carvalho
sergio@inf.ufg.br
Comunicação Indireta
2
Comunicação IndiretaComunicação Indireta
● Comunicação entre entidades em um SD por 
meio de um intermediário, sem que haja 
qualquer acoplamento entre o sender e o(s) 
receiver(s)
● IPC, RPC: comunicação direta com alto 
acoplamento entre um sender e um receiver
● space and time uncoupling
– space: sender não conhece a identidade do(s) 
receiver(s)
– time: sender e receiver(s) possuem tempos 
de vida independentes
3
Space and Time couplingSpace and Time coupling
Há desvantagem na comunicação indireta?
4
● Diferença entre Comunicação Assíncrona e 
time uncoupling?
5
Comunicação Assíncrona e IndiretaComunicação Assíncrona e Indireta
6
Modelos (Paradigmas) de Modelos (Paradigmas) de 
Comunicação IndiretaComunicação Indireta
● Comunicação de Grupo
● Sistema publish/subscribe
● Filas de Mensagens
● Memória Compartilhada Distribuída
● Espaços de Tuplas
7
Comunicação em GrupoComunicação em Grupo
8
Comunicação em GrupoComunicação em Grupo
● Disseminação confiável de informações entre 
muitos clientes
● Suporte a aplicações colaborativas
● Implementação de estratégias de tolerância a 
falhas
● Suporte a monitoramento e gerenciamento 
(por exemplo, balanceamento de carga)
9
Comunicação em GrupoComunicação em Grupo
10
ImplementaçãoImplementação
● Semântica de entrega de mensagens em 
grupos:
– Ordem FIFO: considera ordenação das 
mensagens no remetente
– Ordem causal: considera a causalidade entre 
os eventos
– Ordem total: considera a ordem total dos 
eventos → todos recebem na mesma ordem 
(balanceamento de carga)
11
Sistemas Sistemas Publish-Subscribe Publish-Subscribe (P/S)(P/S)
((ouou distributed event-based systems) distributed event-based systems)
12
Sistemas Sistemas Publish-Subscribe Publish-Subscribe (P/S)(P/S)
((ouou distributed event-based systems) distributed event-based systems)
● Sistema baseado em eventos distribuídos
● Sistema distribuído composto de
– Publishers: processos que publicam eventos 
no sistema P/S
– Subscribers: processos de consomem 
eventos no sistema P/S
● Subscription indica eventos em que um subscriber 
está interessado
● Entrega de evento: event notification
13
Sistemas Sistemas Publish-SubscribePublish-Subscribe
((ouou distributed event-based systems) distributed event-based systems)
● Modelo de comunicação assíncrona entre
● gerador de eventos (objetos de interesse) e
● consumidores de eventos (assinantes)
● Eventos são comunicados via notificações
● Completo desacoplamento entre geradores e 
consumidores de eventos
● um gerador de eventos não sabe quais 
consumidores recebem suas notificações
● Tipos de eventos
● tipos de dados envolvidos em um evento
14
Sistemas Sistemas Publish-SubscribePublish-Subscribe
((ouou distributed event-based systems) distributed event-based systems)
● Mais amplamente usado
● Publicadores (publishers) publicam eventos 
estruturados em um serviço de eventos e 
assinantes (subscribers) expressam 
interesse em eventos particulares
Estilos de Arquitetura
16
Sistemas Sistemas Publish-SubscribePublish-Subscribe
((ouou distributed event-based systems) distributed event-based systems)
● Examples of Application domains
– Areas with live feeds of real-time data
– Support for cooperative working
● Participants need to be informed of events of 
shared interest
– Support for ubiquitous computing
● Management of events emanating from the 
ubiquitous infrastructure
– Monitoring applications 
Homecare system: an overview
18
Eventos e notificações: ExemploEventos e notificações: Exemplo
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
19
Arquitetura distribuída para notificação de Arquitetura distribuída para notificação de 
eventoseventos
subscriberobserverobject of interest
Event service
object of interest
object of interest observer
subscriber
subscriber
3.
1.
2. notification
notification
notification
notification
20
Papéis dos componentes de uma Papéis dos componentes de uma 
arquitetura de eventosarquitetura de eventos
Objeto de interesse
gerador de eventos de algum tipo especificado
Evento
ocorrência em um objeto de interesse
Notificação
objeto que contém informação sobre um evento, 
utilizado para comunicá-lo aos interessados
Assinante
objeto que registra interesse por notificações de certo 
tipo de evento
21
Papéis dos componentes de uma Papéis dos componentes de uma 
arquitetura de eventos (2)arquitetura de eventos (2)
Objeto observador
intermediador entre objetos de interesse e assinantes
implementa a lógica de notificação
encaminhamento, filtragem, correlação de eventos para 
detectar padrões, caixa postal de eventos
seu uso é opcional
Publicador
torna tipos de eventos conhecidos do público
pode ser o objeto observador ou o próprio objeto de 
interesse que gera o evento
22
23
Characteristics of Characteristics of Publish-Subscribe Publish-Subscribe 
SystemsSystems
● Heterogeneity
– Components that were not designed to 
interoperate can be work together
● Asynchronicity
– Notifications are sent asynchronously by 
event-generating publishers to all subscribers 
that have expressed an interest in them to 
prevent publishers needing to synchronize 
with subscribers. 
– Publishers and subscribers need to be 
decoupled
24
The programming modelThe programming model
25
The programming modelThe programming model
● publish(e) → publica um evento no sistema
● subscribe(f) → indica o interesse por um tópico 
que atenda a certos critérios
● unsubscribe(f) → indica não ter interesse por 
um tópico
● notify(e) → entrega evento a subscriber
● advertise(f) → tipos de tópicos a serem publi- 
cados no futuro
26
The programming modelThe programming model
● Tipos de assinaturas
– Channel-based → subscription indica o 
interesse em todos os eventos de um canal
– Topic-based → (ou assunto/subject) 
subscription indica um tópico de interesse, 
entre vários associados aos eventos do 
sistema
– Content-based → subscription indica 
restrições quanto ao conteúdo dos eventos
– Type-based → eventos são tipados, e 
subscription indica tipos ou subtipos de 
interesse
27
The programming modelThe programming model
28
The programming modelThe programming model
29
Implementation issuesImplementation issues
● Central task: to ensure that events are 
delivered efficiently to all subscribers that 
have filters defined that match the event.
● Additional requirements: security, scalability, 
failure handling, concurrency and quality of 
service
● Implementation has been an area of intense 
investigation
30
Implementation issuesImplementation issues
Centralized
– A single node with a server on that node 
acting as an event broker
– Publishers publish events to this broker
– Subscribers send subscriptions to the broker 
and receive notifications in return
– Interaction with the broker through point-to-
point messages (message passing or remote 
invocation)
● What is the problem?
31
Implementation issuesImplementation issues
Problems...
– The design lacks resilience and scalability– The centralized broker represents
● a single point for system failure and a 
● a performance bottleneck
● Solution...?
32
Implementation issuesImplementation issues
33
Implementation issuesImplementation issues
● Network of brokers
34
Broker OverlayBroker Overlay
35
Flat-hierarchyFlat-hierarchy
36
The architecture of publish-subscribe The architecture of publish-subscribe 
systemssystems
37
Event FloodingEvent Flooding
38
Subscription FloodingSubscription Flooding
39
Filtering-based FloodingFiltering-based Flooding
40
Filtering-based routingFiltering-based routing
41
Rendezvous-based routingRendezvous-based routing
42
Modelo Filas de MensagensModelo Filas de Mensagens
(message queues)(message queues)
● Message-queues provide a point-to-point service
– Sender places the message into a queue, and 
it is then removed by a single process
● Also reffered to as Message-Oriented Middleware
● Commercial implementations
– WebSphere MQ (IBM), MSMQ (Microsoft), 
JMS
● Support for transactions 
43
Message QueuesMessage Queues
44
Programming modelProgramming model
● Producer processes can send messages to a specific 
queue and consumer processes can then receive 
messages from this queue
● Three styles of receive
– Blocking receive
– Non-blocking receive (polling)
– Notify 
45
Programming modelProgramming model
● Properties of the message queue systems
– Messages are persistent until they are consumed
– Reliable delivery
● Messages are commited to disk
● Any message sent is eventually received 
and the message received is identical to the 
one sent
● No messages are delivered twice
● Message queues versus message-passing
– Queues are explicit and third-party entities
46
Implementation issuesImplementation issues
● Centralized versus distributed
47
A simple networked topology in WebSphere MQA simple networked topology in WebSphere MQ
48
The programming model offered by JMSThe programming model offered by JMS
49
The programming model offered by JMSThe programming model offered by JMS
50
The programming model offered by JMSThe programming model offered by JMS
51
The programming model offered by JMSThe programming model offered by JMS
52
The programming model offered by JMSThe programming model offered by JMS
53
The programming model offered by JMSThe programming model offered by JMS
54
The programming model offered by JMSThe programming model offered by JMS
55
Distributed Shared MemoryDistributed Shared Memory
● DSM is a abstraction used for sharing data between 
computers that do not share physical memory
56
Distributed Shared MemoryDistributed Shared Memory
● Problems of implementing DSM are related to the 
replication issues and caching of shared files
● The significance of DSM
– Development of shared-memory multiprocessors
– Algorithms for parallel computation
– Caching strategies, fast processor-memory 
interconnections
● Number of processors
57
Tuple SpaceTuple Space
58
CréditosCréditos
Prof. Sérgio T. Carvalho
sergio@inf.ufg.br
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Figure 5.10 Dealing room system
	Figure 5.11 Architecture for distributed event notification
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46
	Slide 47
	Slide 48
	Slide 49
	Slide 50
	Slide 51
	Slide 52
	Slide 53
	Slide 54
	Slide 55
	Slide 56
	Slide 57
	Slide 58