Segundo o framework Cosmos, um processo de adaptação dinâmica deve considerar os requisitos de QoS e as políticas de adaptação descritas na especificação da aplicação, de acordo com o modelo de gerenciamento de QoS introduzido na Seção 2.3. Neste modelo, monitores (Figura 3.1) iniciam o processo de adaptação ao detectarem parâmetros de QoS definidos na especificação fora da faixa de valores aceitáveis especificados. Ou seja, caso algum monitor detecte uma situação de anomalia que requeira algum tipo de adaptação, um evento é indicado ao gerente do sistema, QoSManager, que se encarrega de interagir com o Configurator, (componente central da arquitetura Cosmos) de modo que ele possa decidir o que fazer.
Para decidir o que fazer, o Configurator precisa adotar critérios. Por sua vez, a defi- nição de critérios requer o conhecimento do comportamento do sistema, como também, das atividades do processo nas mais diferentes situações; como este trabalho está inserido no contexto do Cosmos reforçamos a necessidade de se realizar um estudo aprofundado destas situações.
O modelo de QoS originalmente proposto para Cosmos é limitado no sentido de não permitir a especificação de uma aplicação com dois ou mais componentes que realizem a mesma tarefa. Outra limitação se dá na descrição de requisitos para a aplicação, que não permite estabelecer indicadores do melhor nível no contexto atual para o correto funcionamento da aplicação. No decorrer deste trabalho realizamos vários testes para identificar alguns critérios-chaves de modo a estender a ADL estrutural do Cosmos com o objetivo de incluir estes critérios na gerência da QoS do sistema.
3.2.1
Arquitetura Geral da Abordagem Inicial
Na abordagem inicial proposta por [3], a adaptação dinâmica se concentrou no escopo da conexão virtual, sendo realizada duplicando os canais de comunicação envolvidos,
conforme ilustrado na Figura 3.1. Para esse caso, as atividades do processo de adaptação são descritas no Diagrama de Atividades da Figura 3.2.
Figura 3.1: Arquitetura para Adaptação dinâmica no Cosmos com duplicação de canais de comunicação.
Ao iniciar um processo de adaptação, o configurador (elemento principal do Cosmos) precisa analisar a solicitação de forma a não deixar o sistema em um estado inconsis- tente. Após essa verificação, o configurador efetivamente inicia o processo de adaptação notificando os componentes envolvidos para que estes realizem uma etapa de reserva de recursos e se preparem para a reconfiguração. O Configurator notifica então o correspon- dente componente VirtualConnection, informando-o que um processo de adaptação foi iniciado. A conexão virtual realiza a mesma operação de alocação de recursos e prepara- ção para a reconfiguração nas portas associadas (denominadas Output Port e Input Port), para em seguida realizar a duplicação do canal de comunicação. Após a configuração do canal secundário e das portas de comunicação envolvidas, a conexão virtual notifica o Configurator, informando-o que o processo de preparação e alocação de recursos para
a reconfiguração foi concluído com sucesso e que a reconfiguração pode continuar. O configurador, após receber a notificação da conexão virtual, identifica os componentes transmissores, para em seguida notificá-los, de modo que estes possam ativar a adapta- ção previamente preparada. Neste ponto, o componente transmissor interrompe a sua transmissão e altera seus parâmetros operacionais. O componente realiza então uma no- tificação à sua correspondente porta de saída e recomeça a transmissão. A porta de saída (Output Port), por sua vez, realiza a troca do canal de comunicação, marcando o ca- nal primário como livre e continua a operar normalmente enviando dados, agora, pelo canal secundário. Caso ainda tenham dados do fluxo em trânsito no canal de comunica- ção primário, até esses eventuais dados chegarem à porta de entrada, o sistema realizará, paralelamente, a transmissão dos novos dados (fluxo adaptado), saindo do componente transmissor através do canal secundário.
Figura 3.2: Diagrama de atividades relativo a um processo de adaptação no framework Cosmos
O componente receptor continua sua operação solicitando dados à porta de entrada (Input Port). A porta de entrada, por sua vez, continua entregando os dados do buffer correspondente ao canal primário, até que o mesmo se esvazie. Quando o buffer primário da porta de entrada não contiver mais dados, assume-se que o fluxo de dados do canal de
comunicação primário terminou, e que este canal não irá entregar mais nenhum dado para a porta de entrada.
Neste momento, esta porta notifica o componente associado e inicia o processo de troca dos canais de comunicação e de seus buffers de recepção. Após a notificação, o componente receptor realiza os procedimentos necessários à reconfiguração dinâmica, trocando seus parâmetros de operação e retornando ao seu funcionamento normal.
No final da troca dos canais, a porta de entrada notifica ao canal primário que ele não é mais necessário. O canal primário, com as notificações de suas duas portas envolvidas realiza uma chamada callback à conexão virtual correspondente, informando que o canal primário não está mais sendo utilizado e que o mesmo pode ser desalocado. A conexão virtual realiza a troca dos canais de comunicação, fazendo com que o canal de comunica- ção secundário passe a ser o canal primário da interconexão. Uma visão geral do processo de adaptação pode ser vista na Figura 3.2 por meio de diagrama da UML 2.0.
3.2.2
Arquitetura Geral da Abordagem Proposta
O processo para realizar trocas dinâmicas de componentes em sistemas, sem afetar o funcionamento da aplicação, e, principalmente, mantendo os critérios de qualidade espe- cificados previamente, envolve várias atividades; o gerenciamento da sincronização entre estas atividades requer um esforço de grande dimensão.
Para que a troca de um componente seja realizada é necessário que exista um me- canismo para selecionar um componente que melhor se adeque dentro da necessidade gerada pelo novo contexto de execução, denotado pelos novos parâmetros necessários para se manter a aplicação funcionando. Portanto a abordagem proposta no presente tra- balho se utiliza de um mecanismo para a seleção de componentes, que foi introduzido na arquitetura como um novo serviço para o Cosmos e definido através de um componente denominado ComponentChooserService.
A Figura 3.3 apresenta uma arquitetura simplificada para o Cosmos prover suporte à adaptação dinâmica com troca de componentes. Nesta arquitetura, novos serviços foram adicionados ao Cosmos: o ComponentChangeService, que engloba toda a parte relacio- nada com as conexões e os demais componentes da aplicação, e, o ComponentChooser- Service que é responsável por selecionar componentes substitutos.
Dado que a arquitetura é uma evolução da arquitetura proposta originalmente pelo Cosmos, a simplificação tem como objetivo direcionar o foco da apresentação para os
Figura 3.3: Relacionamento entre os Elementos.
elementos principais da proposta, e, ao mesmo tempo, ocultar detalhes que não fazem parte do presente trabalho. Considerando que o modelo originalmente proposto encontra- se descrito em [2] e [3], descrições mais detalhadas dos demais componentes envolvidos na arquitetura podem ser obtidas nas respectivas referências.