![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Às vezes, os usuários do WebSphere Business Monitor (Monitor) nos dizem que o algoritmo de processamento de eventos do programa é difícil de compreender. Em sua maioria, eles parecem confusos com o objetivo das expressões de filtro e dos predicados de correlação, pelas várias opções de entrega de evento e pela maneira como as atualizações são conduzidas em um contexto de monitoramento.
Neste artigo, ofereceremos um olhar sobre os bastidores desses conceitos. Não trataremos de pontos mais complexos do modelo de programação do Monitor, como, acionadores, cronômetros e contextos de monitoramento aninhados, mas iremos nos concentrar simplesmente nos fundamentos básicos do processamento de eventos.
Também forneceremos uma apresentação de slides para download que mostra, através de uma sequência simples, o caminho que um evento faz quando é processado pelo Monitor.
Conceitos de processamento de eventos
No núcleo do Monitor estão os objetos do observador. Um objeto do observador é criado para cada entidade que você deseja monitorar. As entidades monitoradas podem ser tangíveis, como um dispositivo, servidor ou veículo e podem ser abstratas como uma execução de processo, uma entrega de pacote ou um ciclo de vendas. O objeto do observador acompanha os eventos que relatam quaisquer alterações de estado na entidade monitorada e atualiza seu próprio estado baseado nas informações desses eventos.
Um objeto de observador usado pelo Monitor é chamado de um contexto de monitoramento ou MC porque as informações que ele coleta fornecem o contexto para monitorar uma entidade observada. Os campos de dados em um MC são chamados de métricas porque são tipicamente representados por medidas das informações sobre essa entidade que são relevantes para os negócios.
Por exemplo, vamos dizer que uma empresa de limusines queira monitorar sua frota de carros. É recomendável que a empresa use o Monitor para criar um contexto de monitoramento para cada viagem, quando iniciada. Esse contexto pode ser atualizado com informações sobre a viagem, por exemplo, o horário de entrada do passageiro, engarrafamentos e o horário de saída do passageiro, baseado em eventos recebidos das limusines na estrada. Ele pode conter métricas para a duração da viagem, atrasos ao buscar e deixar o passageiro, um índice de satisfação do cliente derivado dessas métricas, velocidade média etc.
Para estender os recursos de monitoramento, a empresa de limusines pode definir MCs para seus motoristas, com métricas de pontualidade, viagens por mês, média de satisfação do cliente etc. A empresa poderia defini-las também para os carros, com métricas como quilometragem por uso de combustível, próximo serviço planejado e mais. Esses MCs seriam objetos do observador para os motoristas e os veículos.
As métricas e inscrições de eventos de um MC são definidas pelas definições de contexto de monitoramento. Assim como um MC é um objeto de objetivo especial, sua definição é uma classe de objetivo especial que define a estrutura e o comportamento de suas instâncias.
Agora que você entende os conceitos básicos e a terminologia, vamos ver como tudo isso funciona.
Processamento de eventos por etapa
Existem três etapas para processar um evento:
- Filtragem - Que tipo de evento é esse?
- Correlação - Quais MCs estão interessados nesse evento?
- Atualização de MC - Quais métricas são atualizadas pelo evento e como?
Cada MC acompanha somente os tipos de eventos que pertencem à entidade que monitoram.
No exemplo da empresa de limusines, os MCs de viagem acompanhavam eventos que relatam despacho de viagens, entrada e saída de passageiros, trânsito carregado e acidentes de carro. A definição do MC de viagem teria cinco inscrições de eventos, uma para cada evento.
Uma inscrição de evento contém um filtro, que é uma expressão booleana que avalia como verdadeiros os eventos que acompanha e como falsos os eventos restantes. A única regra para definir um filtro é que ele precisa permitir que os eventos do tipo desejado passem e bloqueiem todos os outros. Por motivos de desempenho, os filtros devem ser o menor possível, em outras palavras, eles devem ser apenas complexos o suficiente para identificar um tipo de evento entre a variedade de eventos esperados.
Por exemplo, se um evento contém um atributo xsi:type
que identifica sua carga útil, e diferentes tipos de eventos têm
diferentes tipos, pode ser necessário apenas testar esse atributo. Mas, se
um tipo único genérico de evento é usado para relatar as ocorrências de
diferentes tipos (o que pode ser determinado apenas pelo exame do conteúdo do
evento), o filtro precisa testar os campos adicionais.
No exemplo da limusine, se os carros sempre relataram o status da viagem usando um evento
cujo tipo de carga útil é limo:TripStatus (em que
limo representa um namespace) eventos de despacho,
entrada e saída são distinguidos através de um campo
event nature, o campo
event nature terá de ser testado junto
com o atributo xsi:type para determinar o tipo dos
eventos que foram recebidos.
Depois de um evento ter passado por um filtro de inscrição, seu predicado de correlação é avaliado para verificar se há um MC. Os predicados de correlação tipicamente comparam um valor da chave no evento, como um identificador exclusivo de viagem, com uma métrica que contenha a mesma chave. Se um MC correspondente for localizado, esse MC pode receber um evento para processamento adicional. Se não, um novo contexto de MC pode ser criado.
Mas e se isso não for o desejado? Digamos, por exemplo, que um evento de entrada de passageiro chega e nenhum MC correspondente é localizado. Neste caso, não é recomendável a criação de um novo MC, mas, em vez disso, a criação de uma condição de erro que indique que o evento de "carro despachado" (que deveria ter ocorrido primeiro e criado o MC) não foi recebido. Da mesma maneira, se um evento de "carro despachado" chegar e um MC para a mesma viagem for localizado, isso seria inesperado e indicaria um erro. Novamente, seria recomendável a criação de um erro e não a entrega de um evento de despacho duplicado no contexto já existente.
Como se pode ver, é importante ser capaz de controlar o algoritmo de correlação de evento. É possível fazer isso definindo as configurações de entrega de evento. Cada inscrição de evento tem três configurações, que cobrem os casos de nenhum, um e vários MCs preenchendo o predicado de correlação. A tabela a seguir mostra essas configurações.
Configurações de entrega de evento
| Nenhuma correspondência | Uma correspondência | Múltiplas correspondências |
|---|---|---|
| Ignorar | Ignorar | Ignorar |
| Tratar como erro | Tratar como erro | Tratar como erro |
| Criar novo MC | Entregar para o (único) MC correspondente | Entregar para qualquer MC correspondente |
| Retroceder todas as mudanças e tentar processar este evento novamente mais tarde | Entregar todos os MCs correspondentes |
Depois do processamento de correlação ter identificado MCs para a entrega de eventos, o estado do processamento é atualizado de acordo com o conteúdo do evento.
Para entender como isso funciona, pense em um MC como uma planilha, cujas células são métricas. Para cada métrica, a definição do MC estabelece um ou mais mapas que configuram seus valores. Os mapas são como fórmulas de planilhas. Um mapa pode depender de uma inscrição de evento.
Quando um evento é entregue para um MC, todos os mapas que dependem do recebimento da inscrição são executados e suas métricas de destino são atualizadas com os resultados. As atualizações adicionais são, então, processadas em cascata, como em uma planilha: mapas que dependem das métricas atualizadas atualizam seus destinos e assim por diante. A cascata sempre terminará porque o gráfico de dependência definido pelos mapas não pode ter ciclos. Por exemplo, se a métrica B depende da métrica A, então a métrica A não pode depende da métrica B.
Se o ensaio que fizemos aqui parecer sem graça ou se desejar simplesmente obter uma revisão visual e interessante do que aprendeu, dê uma olhada na apresentação de slides "Processamento de Eventos" fornecida com este artigo. Ela mostra as etapas do processo que descrevemos neste artigo usando gráficos simples e uma sequência fácil de entender.
Espero que este artigo e os slides que o acompanham ajudem a compreender melhor os conceitos por trás do processamento de eventos no WebSphere Business Monitor.
| Descrição | Nome | Tamanho | Método de download |
|---|---|---|---|
| Slide show demo | epdemo.pdf | 299KB | HTTP |
Informações sobre métodos de download Obtenha o Adobe® Reader®
-
Informações do produto WebSphere Business Monitor: Obtenha todas
as informações do produto, incluindo recursos e benefícios, requisitos do sistema
e mais.
-
Centro de Informações do WebSphere Business Monitor: Obtenha a documentação
completa do produto.
-
zona do BPM do developerWorks: Obtenha os recursos mais recentes sobre as
soluções IBM BPM, incluindo downloads, demos, artigos, tutoriais,
eventos, webcasts e mais.
Joachim (Jim) H. Frank é um Arquiteto de Software Senior da IBM. Ele foi líder técnico de design e desenvolvimento do WebSphere Business Modeler e do WebSphere Business Monitor. É possível entrar em contato com Jim pelo jhfrank@us.ibm.com.
