Notas de Aula - MAC 5759 - Sistemas de Objetos Distribuídos

Aula 14 - 25/4/2002

Eventos e Notificações

• Um evento é a ocorrência de alguma coisa. É algo atômico.
• Não confundir o evento com a notificação da ocorrência do evento.
• Hoje em dia, há bastante pesquisa em sistemas de publicação/assinatura (publish/subscribe systems).
• CORBA define dois serviços:
• mais antigo: Serviço de Eventos
• mais recente e sofisticado: Serviço de Notificação
• Eventos também são chamados de chamadas implícitas ( implicit invocation)
• Origem dos sistemas distribuídos:
• uma série de nós distribuídos trocando mensagens
• caso particular mais explorado posteriormente:
• sistema cliente/servidor; comunicação de 1 para 1; invocation-based communication; RMI
• (a rigor, mesmo usando RMI, poder-se-ia ter um modelo genérico peer-to-peer ao invés de cliente/servidor)
• Características básicas da comunicação baseada em eventos:
1. event-driven communication; muitos para muitos
• 1 objeto gerador de eventos pode mandar esse evento para muitos outros objetos
• 1 objeto pode receber eventos de muitos outros objetos
2. os geradores de eventos não guarda referências/ponteiros para os consumidores e vice-versa
3. o envio de notificações não bloqueia o emissor; mensagens assíncronas
• em geral, o recebimento dos eventos é feito de forma implícita (callbacks)
• obs.: esse não é único meio de enviar mensagens assíncronas em CORBA, CORBA Messaging também permite
4. notificações precisam ser auto-explicativas
• o ponto de entrada de diferentes tipos de eventos é normalmente um só
• ao contrário de RMI, não há checagem de tipos estática via IDL
• Aspecto mais importante de sistemas baseados em eventos:
• O desacoplamento entre emissor e receptor de eventos é muito maior do que entre cliente/servidor em RMI.
• tipos de desacoplamento
1. espacial - emissores não conhecem emissores e sua localização e vice-versa
2. temporal - completamente assíncrono (e.g., 1 mês). emissor não deve assumir nada sobre recebimento
3. sintático - a interface é sempre a mesma; não há necessidade de recompilar todo o código quando a "interface" muda.
4. semântico - o evento é interpretado com um certo significado no receptor; mas o emissor não precisa conhecer ou concordar com esse significado.
• o resultado normalmente é que o código é mais simples pois não precisa se preocupar com várias coisas
• por outro lado, perdemos coisas como verificação de tipos, sincronia, etc.

 O Serviço de Eventos de CORBA

• define 3 elementos:
• canal de eventos (event channel)
• produtor (supplier)
• consumidor (consumer)
• o canal oferece uma interface de administração que permite definir o tipo de canal e registrar e desregistrar produtores e consumidores
• Modelo Push operação push()
• Modelo Pull operações pull() ou try_pull()
• Pode-se misturar os dois modelos. Cada produtor e cada consumidor de cada canal podem adotar um modelo diferente
• Pode-se criar Federações de Canais de Eventos conectando-se a saída de um na entrada do outro
• O serviço lida com eventos genéricos e por isso envia e recebe objetos do tipo Any (um container p/ objetos de qq. tipo).
• Outra opção oferecida é o envio de eventos de tipos especificos. A aplicação deve verificar o tipo do evento e fazer o narrow antes de usá-lo. Essa interface lida com objetos do tipo Object (o super-tipo de todos os tipos)
• Pode-se implementar um serviço de eventos com tipos específicos mas o padrão é o mais genérico possível.
• Interfaces:
• o canal de eventos possui um proxy supplier interface e um proxy consumer interface
• module CosEventComm (M&H pag. 937) define interfaces push do consumidor e produtor
• module CosEventComm (M&H pag. 938) define interfaces pull do consumidor e produtor
• module CosEventComm {

exception Disconnected{};
        interface PushConsumer {
                void push (in any data) raises(Disconnected);
                void disconnect_push_consumer();
        };
        interface PushSupplier {
                void disconnect_push_supplier();
        };
        interface PullSupplier {
                any pull () raises(Disconnected);
                any try_pull (out boolean has_event)
                        raises(Disconnected);
                void     disconnect_pull_supplier();
        };
        interface PullConsumer {
                void disconnect_pull_consumer();
        };
};
• module CosEventChannelAdmin (M&H pag. 939-40)
• module CosEventChannelAdmin {

        exception AlreadyConnected {};
        exception TypeError {};
        interface ProxyPushConsumer: CosEventComm::PushConsumer {
                void connect_push_supplier(
                                in CosEventComm::PushSupplier push_supplier)
                        raises(AlreadyConnected);
        };
        interface ProxyPullSupplier: CosEventComm::PullSupplier {
                void connect_pull_consumer(
                                in CosEventComm::PullConsumer pull_consumer)
                        raises(AlreadyConnected);
        };
        interface ProxyPullConsumer: CosEventComm::PullConsumer {
                void connect_pull_supplier(
                                in CosEventComm::PullSupplier pull_supplier)
                        raises(AlreadyConnected,TypeError);
        };
        interface ProxyPushSupplier: CosEventComm::PushSupplier {
                void connect_push_consumer(
                                in CosEventComm::PushConsumer push_consumer)
                        raises(AlreadyConnected, TypeError);
        };
        interface ConsumerAdmin {
                ProxyPushSupplier obtain_push_supplier();
                ProxyPullSupplier obtain_pull_supplier();
        };
        interface SupplierAdmin {
                ProxyPushConsumer obtain_push_consumer();
                ProxyPullConsumer obtain_pull_consumer();
        };
        interface EventChannel {
                ConsumerAdmin for_consumers();
                SupplierAdmin for_suppliers();
                void destroy();
        };
};
• o destroy(), destroi o canal imediatamente sem entregar os eventos não entregues, os clientes são avisados.
• estabelecendo conexões: (M&H pag. 940-1) interfaces ProxyPushSupplier e ProxyPushConsumer
• ProxyPullSupplier e ProxuPullConsumer é análogo
• Canais de Eventos são registrados no servidor de nomes como objetos comuns
• Exemplo de uso em computação ubíqua: canais de eventos em cada espaço físico.
• Importante definir para cada aplicação o modelo de transmissão de eventos:
• push canônico
• pull canônico
• híbrido push/pull
• híbrido pull/push
• TAO implementou um Serviço de Eventos com suporte para tempo-real. Parte desse trabalho levou ao serviço de notificações

Serviço de Notificações CORBA

• Acrescenta uma série de funcionalidades ao Serviço de Eventos
• Define novos módulos estendendo as interfaces do Serviço de Eventos
• Melhorias:
• filtragem de eventos
• Qualidade de Serviço
• suporte não só para Any mas também para StructuredEvent e sequence
• suporte para descobrir quais são os produtores e consumidores para cada tipo de evento
• Características
• define um interface EventChannelFactory (livro BVD, pag. 501)
• EventChannel

  create_channel (in CosNotification::QoSProperties initial_qos, 
                  in CosNotification::AdminProperties initial_admin, 
                  out ChannelID id) 
     raises (CosNotification::UnsupportedQoS, 
             CosNotification::UnsupportedAdmin);
ChannelIDSeq get_all_channels ();
EventChannel get_event_channel (in ChannelID id) raises (ChannelNotFound);
• para cada canal pode-se obter vários admins diferentes
• para diferentes tipos de eventos
• utilizando diferentes filtros de eventos
• StructuredEvent contém, entre outras coisas, propriedades de QoS
• EventReliability = 0 ou 1
• Prioridade
• StartTime (hora a partir da qual o evento deve ser enviado)
• StopTime (hora a partir da qual o evento deve ser descartado)
• Timeout (no canal de eventos)
• Filtragem de Eventos
• cria-se um filtro manualmente ou através de fábricas
• filtros contém restrições (constraints )
• restrições são definidas através de linguagens diferente. Uma linguagem é sempre oferecida: EXTENDED_TCL onde TCL é a Trader Constraint Language
• exemplos de restrições: que especifíca quais tipos de eventos podem passar ou $.priority > 3
• Qualidade de Serviço
• Confiabilidade do Evento (0 = best effort ou 1 = persistente)
• Confiabiliadade da Conexão (0 ou 1) caso seja 1, as conexões são persistentes. Se clientes morrem, as conexões a eles são re-estabelecidas quando eles voltam
• Prioridade (eventos com maior prioridade são entregues antes)
• StartTime, StopTime e TimeOut como descrito acima
• MaxEventsPerConsumer: quantos eventos podem ser enfileirados p/ cada consumidor
• OrderPolicy: AnyOrder, FifoOrder, PriorityOrder, DeadlineOrder (baseado no timeout; é o default)
• DiscardPolicy: o que descartar quando o canal enche: AnyOrder, FifoOrder, LifoOrder, PriorityOrder, DeadlineOrder
• MaximumBatchSize: para seqüências de eventos estruturados, quantos podem vir por vez
• PacingInterval: o tempo máximo no qual o canal vai coletar eventos e colocar dentro de uma seqüência

Referências:

• O Eider sugeriu essa página bem interessante.
• Henning e Vinoski capítulo 20 (só o Event Service).
• Brose, Vogel e Duddy capítulo 11.