Event Channel Service

Em CORBA, a comunicação síncrona é naturalmente definida no modelo de invocação de métodos. De uso frequente em aplicações de tempo real, a comunicação assíncrona, no entanto, se ressente de uma definição robusta neste padrão. As opções definidas no CORBA que se aproximam de tal semântica são as chamadas oneway e deferred synchronous: (i) a primeira, pela falta de definição no padrão, pode não implementar uma entrega confiável; (ii) a segunda requer interfaces dinâmicas, que apresentam características de imprevisilibilidade não compatíveis com requisitos de tempo real.

Para atender a este tipo de demanda o CORBA define um serviço de eventos, a saber, Event Channel service, que desacopla a invocação do método da sua execução através de um objeto intermediário, o ``canal'' de eventos, que define um modelo de comunicação produtor-consumidor, no qual os participantes das pontas não necessitam ter conhecimento explícito uns dos outros. Existem dois modos de comunicação através do canal de eventos: push e pull. A ponta ativa no modelo pull puro é o consumidor, que traciona eventos do canal. Já no modelo push, a atividade é disparada pelo produtor que impele eventos ao canal, que por sua vez os impele aos consumidores.

No TAO, este serviço foi adotado como solução básica para a comunicação assíncrona, tendo sido extendido com algumas características que visam o atendimento de requisitos de tempo real. Como apenas o modo push esta implementado, somente os objetos relacionados com este modelo estão descritos abaixo:

EventChannel:

A interface do EC provê dois métodos fábrica , pelos quais as aplicações obtêm objetos de gerenciamento de produtores ou consumidores, conforme a demanda, através dos quais se obtêm os outros objetos, descritos a seguir, que estabelecem a conexão com o canal.

SupplierAdmin:

A interface do SA provê métodos fábrica com os quais são criados os objetos proxy apropriados ao produtor.

ConsumerAdmin:

Para a interface CA provê métodos fábrica com quais são criados os objetos proxy apropriados ao consumidor.

ProxyPushSupplier:

A interface PPS é usada por consumidores no modelo push para conectar e desconectar do canal. Esta interface herda de PushSupplier e age como um proxy para os produtores que impelirem eventos ao canal.

ProxyPushConsumer:

A interface PPC é usada por produtores no model o push para conectar e desconectar do canal. Esta interface herda de PushConsumer e age como um proxy para os consumidores aos quais o canal impele eventos.

PushSupplier:

A interface PS provê os métodos necessários a um produtor de eventos no modelo push.

PushConsumer:

A interface PC provê os métodos necessários a um consumidor de eventos no modelo push.

Figura 2: Funcionalidades RT do Event Channel.

Como foi comentado e pode ser observado na figura 2, uma série de elementos foram acrescentados ao Common Object Service Event Channel, visando ao atendimento de requisitos de sistemas de tempo real:

Imposição de prioridades no despacho de eventos:

A atual implementação pode despachar eventos na mesma fila pela sua ordem de importância, o que é necessário para suportar prioridades dentro de um grupo de periódicos.

suspend/resume:

Se as dependências de um consumidor mudam no run-time, ele pode utilizar as primitivas suspend/resume. Quando um consumidor invoca ProxyPushSupplier::suspend as dependências registradas com aquele proxy são desabilitadas até que o método resume seja chamado. I isto mantém o determinismo requerido pela política de escalonamento, i.e., consumidores não podem acrescentar nem remover dependências em tempo de execução, apenas suspender e reativar.

Dados:

Os dados podem ser unions, buffers não tipados e any.

Filtragem de eventos:

Consumidores podem se registrar para eventos com base em tipos de eventos ou no identificador do produtor. O Event Channel filtra a entrega de eventos baseado nesses registros.

Correlação de Eventos:

Consumidores podem registrar para a entrega de eventos baseados em grupos conjuntivos ou disjuntivos de eventos. Registros de grupos conjuntivos compelem o canal a notificar o consumidor somente quando todos os eventos do grupo foram recebidos. Grupos disjuntivos fazem com que o canal dispare a notificação quando qualquer dos eventos tenham sido recebidos.

Processamento periódico de eventos:

consumidores podem se registrar com base em eventos temporizados. Produtores periódicos impelem eventos para o canal a intervalos bem definidos.