jpalmeida-pp-2016-01-aula14[eventos]

17/5/16
Observer ou Listener
Processamento Paralelo
Middleware Orientado a
Mensagens
Prof. João Paulo A. Almeida
([email protected])
2015/01 - INF02799
Publisher-Subscriber
Publisher-Subscriber (Push-Push)
Desacoplar productores (publishers) & consumidores
(subscribers) de eventos:
• Um canal de eventos (Event Channel) armazena/
encaminha eventos
• Produtores ou fornecedores (publishers) criam eventos e
colocam no event channel
Publisher
Event Channel
attachPublisher
detachPublisher
attachSubscriber
detachSubscriber
pushEvent
Subscriber
pushEvent
• Consumidores (subscribers) registram-se com o canal de
eventos
• Events são como mensagens
• Suporta modelos de push e pull
• Pode haver filtros de eventos
Dinâmica do Publisher-Subscriber Pattern
: Publisher
: Event Channel
: Subscriber
attachSubscriber
• Um publisher notifica
qualquer número de
subscribers através de um
evento
produce
pushEvent
event
pushEvent
event
detachSubscriber
Decisões de projeto mais importantes:
• Modelo de interação: push vs. pull
• Tipos de evento: controle ou dados
• Ponto-a-ponto, ponto-a-multiponto, ou multiponto (grupos)
• Filas de eventos persistentes ou transientes
Vantagens e Desvantagens do
Publisher-Subscriber Pattern
Vantagens:
• Desacoplar consumidores e
produtores de notificações de
eventos
• O canal de eventos conhece a lista de
produtores
• O canal de eventos conhece a lista de
consumidores, que implementam a
mesma interface (Subscriber)
• O acoplamento é anônimo
• Quem produz eventos não precisa ficar
bloqueado aguardando a recepção do
evento
• Consumidores e produtores não
precisam estar ativos simultaneamente
Desvantagens:
• Projeto deve evitar cascatas de
eventos desnecessários
• Há perda de desempenho se for
usado apenas para
comunicação ponto a ponto
• Modelo de comunicação n:m é
suportado
• O “evento” não é enviado para um
receptor específico, permitindo
“multicast” ou “broadcast”
1
17/5/16
Middleware Orientado a Mensagens
Event service
  Java oferece um serviço de nomes que
implementa o “publish-subscriber” design
pattern com esse fim → Java Message Service
(JMS)
Várias plataformas de middleware oferecem
funcionalidades similares
  CORBA Event Service, CORBA Notification Service
  Oracle Advanced Queueing
  TIBCO Enterprise Message Service
  Apache ActiveMQ
 Apart from Java, ActiveMQ can be also used from .NET,
C/C++ or Delphi or from scripting languages like Perl,
Python, PHP and Ruby via various "Cross Language
Clients”
•  Definições
  Um objeto pode desempenhar dois papéis:
provedor ou consumidor de informação (informação é
passada através de “eventos”)
Há dois estilos de comunicação de eventos entre objetos
distribuídos:
–  Push model → fornecedor invoca operação no consumidor
•  (exemplo: o Observer/Listener pattern)
–  Pull model → consumidor invoca operação no fornecedor
  O Event channel (canal de eventos) permite que
múltiplos fornecedores e consumidores troquem
informação
  É um intermediador
  JBOSS Messaging
Pull model
Push model
Fornecedor oferece a
interface PushSupplier
Permite registro do
consumidor
supplier
PushSupplier
Consumidor suporta a
interface
PushConsumer
Fornecedor faz
‘push’ (empurra) o
evento (dados) para o
consumidor
push()
consumer
PushConsumer
Introduzindo o intermediário
supplier
try_pull()
pull()
PullSupplier
Event
channel
supplier
PullSupplier
try_pull()
pull()
consumer
PullConsumer
Event channel
•  Exemplo: modelo pull, push
ProxyPullConsumer
Fornecedor
(supplier) oferece
a interface
PullSupplier
  O consumidor
puxa (‘pulls’) o
evento do
fornecedor
try_pull()
  pull()
PushConsumer
push()
  Objeto intermediário entre consumidores e
fornecedores
  Opera como um proxy supplier e proxy
consumer
  Suporta diferentes combinações de modelos
(push-push, push-pull, pull-pull, pull-push)
  Suporta múltiplos fornecedores e consumidores
consumer
ProxyPushSupplier
2
17/5/16
Modelo pull-push
Modelo push-pull
•  Toda a iniciativa é do event channel
•  Supplier e consumer são passivos, e
implementam objetos remotos
•  Event channel é completamente passivo
•  Toda a iniciativa é dos objetos supplier e
consumer
•  Supplier e consumer não precisam implementar
objetos remotos ProxyPushConsumer
ProxyPullConsumer
supplier
try_pull()
pull()
PullSupplier
Event
channel
PushConsumer
push()
consumer
ProxyPushSupplier
PullConsumer
supplier
push()
PushSupplier
Event
channel
try_pull()
pull()
consumer
ProxyPullSupplier
Modelo push-push
Modelo pull-pull
•  Eliminação de pull, comunicação apenas sob
demanda (quando realmente vai resultar no
envio de mensagem)
•  Eliminação de push, comunicação apenas
quando mensagem pode ser processada
ProxyPushConsumer
push()
supplier
PushSupplier
Event
channel
ProxyPullConsumer
PushConsumer
push()
consumer
ProxyPushSupplier
supplier
try_pull()
pull()
PullSupplier
Event
channel
PullConsumer
try_pull()
pull()
consumer
ProxyPullSupplier
Patterns combinados
•  Factory
•  Listener (Push)
–  Caso especial de callback distribuído
•  Polling (Pull)
3