Serviço de Monitoração

Com os agentes posicionados e em execução, cabe ao serviço de monitoração escutar os eventos complexos e traduzir as informações neles contidas para valores de métricas de qualidade, as quais são utilizadas para atualizar os modelos de execução. Para entendermos como isso é realizado, devemos compreender o contexto no qual o serviço de monitoração é normalmente utilizado.

Em geral, esse serviço é acionado por um gerente de adaptação quando este conecta um meta-objeto que representa uma ligação a outro que representa uma instância de

serviço em execução. Neste contexto, o gerente responsável pela ligação aciona o serviço de monitoração, informando ambos os meta-objetos, e solicita que ele mantenha os meta- objetos atualizados com as informações de qualidade.

Para isso, o serviço de monitoração identifica as restrições associadas aos meta-objetos e seleciona as métricas que fazem parte dessas restrições. A cada uma dessas métricas corresponde um tipo de evento complexo produzido por um agente de processamento. Esse tipo de evento é identificado a partir das diretivas de monitoração mantidas pelo próprio serviço de monitoração.

Uma vez identificados os tipos de eventos complexos, o serviço de monitoração re- gistra consumidores de eventos junto ao serviço de processamento. Esses consumidores são responsáveis por ouvir os eventos complexos, extrair deles os valores das métricas de qualidade, e atualizar os meta-objetos.

Quando os valores obtidos para as métricas violam as restrições estabelecidas na li- gação, o meta-objeto que a representa é notificado. Neste momento, esse meta-objeto armazena internamente a violação e a comunica ao gerente, que deve decidir se a ligação com a instância de serviço deve ou não ser mantida.

Para que todo esse fluxo possa funcionar, é necessário que os agentes recebam os even- tos primitivos utilizados como entrada. Para que esses eventos primitivos sejam gerados e encaminhados, o serviço de monitoração utiliza proxies.

Como vimos, quando o serviço de monitoração é acionado para monitorar uma ligação, ele recebe os meta-objetos que representam a ligação e a instância de serviço selecionada. Nesse momento, o serviço de monitoração gera um proxy para a instância de serviço. É este

proxy, contendo uma referência para instância de serviço, que é efetivamente conectado

ao meta-objeto que representa a ligação. Na prática, os acessos às operações da instância passam pelo proxy, que deve notificar essa invocação.

Neste ponto, cabe explicar como a invocação de um serviço no plano base chega até o

proxy. Para compreendermos esse mecanismo, é necessário entendermos como funcionam

os contêineres de componentes na plataforma iPojo.

A plataforma iPojo possui um modelo de programação no qual os componentes são definidos através de classes Java “puras”, nas quais não aparece nenhum código referente ao modelo de componentes. Um exemplo de código de aplicação que requer um serviço é apresentado na Figura 38. Como podemos observar, o serviço é utilizado diretamente, sem ser descoberto pela própria aplicação. De fato, cabe ao contêiner injetar o serviço selecionado no atributo correspondente da classe, não sendo necessário que o desenvolvedor da aplicação tenha ciência acerca do registro de serviços.

Ainda durante o desenvolvimento, a classe que realiza o código de negócio passa por um processo de manipulação, utilizando-se uma ferramenta da plataforma. Essa ferramenta modifica os bytecodes da classe, injetando neles código próprio da plataforma iPojo. Uma parte do código manipulado é apresentado na Figura 39.

Figura 38 – Código de aplicação utilizando serviço

Fonte: o autor

Figura 39 – Código manipulado

Fonte: o autor

Como podemos observar, o método usarServico original foi modificado. Esse método agora se inicia com uma chamada ao contêiner (InstanceManager) para informar a ele que o método de negócio está sendo iniciado (linha 17). Após essa chamada, ocorre uma chamada a um novo método criado no processo de manipulação, o método __usarServico. Ao final do método, em caso de sucesso ou de erro, o contêiner é novamente acionado (linhas 19 e 21).

O novo método criado corresponde ao método de negócio original, sendo que o serviço é requisitado ao contêiner através da chamada do método onGet (linha 12). Assim, cabe ao contêiner retornar o serviço a ser utilizado. Internamente, esse contêiner mantém uma lista de objetos que possuem interesse em indicar o serviço que deve ser utilizado. Na plataforma iPojo original, o tratador de dependências cria, para cada dependência de

serviço, um objeto que deve responder qual serviço que deve ser utilizado. Esse objeto é registrado junto ao contêiner e acionado quando o serviço é requisitado.

Na plataforma DSOA, substituímos o tratador de dependências por um tratador de ligação próprio. Esse tratador registra o meta-objeto que representa uma ligação junto ao contêiner, fazendo com que o serviço a ser utilizado seja requisitado ao modelo de execução. Neste ponto, o meta-objeto que representa a ligação retorna o proxy, que foi injetado nele pelo serviço de monitoração.

Quando uma operação é requisitada no proxy, este a encaminha à instância de ser- viço correspondente, e gera um evento primitivo de invocação que é encaminhado para processamento via serviço de distribuição. Como mencionamos anteriormente, consumi- dores ligados ao serviço de processamento de eventos recebem esse evento primitivo e o encaminham para os agentes em execução no motor de processamento. Por fim, eventos complexos computados a partir dos eventos primitivos são produzidos pelos agentes e en- caminhados para o serviço de monitoração. De forma resumida, é assim que o nível meta da arquitetura reflexiva da plataforma DSOA conduz o processo de adaptação.

Apresentados os elementos estruturais que compõem a plataforma, passamos a discutir como as aplicações são instaladas e configuradas para que possam entrar em execução.