Esse capítulo tem como objetivo discutir alguns trabalhos relacionados ao uso de adaptação aberta no contexto de sistemas autoadaptativos. Os trabalhos utilizam gera- dores de planos como meio de alcançar as mudanças necessárias durante o processo de adaptação.
Em (SOARES; LOPES; SILVA, 2013) Soares apresenta a instanciação do framework de geração de processos (SILVA, 2011) sobre a plataforma OSGi. Essa instanciação foi reali-
zada para verificar a viabilidade do uso do framework de geração de processo nesse novo ambiente de execução. A instanciação apresentada na Figura 33, define um componente (ModelManager) para realizar o monitoramento da aplicação que está em execução na pla- taforma OSGi. O estado atual dos componentes da aplicação é refletido noModelManager, como também dos componentes disponíveis através doBundle Repository.
Figura 33: Visão Geral da Solução (SOARES; LOPES; SILVA, 2013).
A necessidade de adaptação é detectada pelo Configurator, através do ModelManager. Com isso o Configurator que passa ao framework de geração de processos o modelo da aplicação atual e a configuração desejada. O gerador de processos gera o plano de adap- tação, que são as ações necessárias para realizar as mudanças na aplicação, e o executa na plataforma através do bundle WSDL Management. O bundle WSDL Management é
responsável pelo gerenciamento de bundles da plataforma OSGi. A comunicação entre o framework de geração de processos e o bundle WSDL Management é realizada através de uma interface WSDL.
O uso do framework de geração de processos para alcançar adaptação em aplicações também é utilizada em nosso trabalho, no entanto, a integração utilizada nos trabalhos são distintas. A integração sugerida por Soares é direta na plataforma OSGi enquanto a nossa integração visa a utilização do framework de geração de processos no Cosmos. É importante enfatizar que mesmo com a integração do Cosmos com a plataforma OSGi, não implica na integração do framework de processos com o ambiente, outro ponto é que o controle dos componentes Cosmos é realizado pelo próprio Cosmos.
Em (FONSECA F. L.; BENEDITTO, 2012) Fonseca apresenta um mecanismo para exe-
cução de planos de reconfiguração arquitetural. Para demonstrar o uso do mecanismo, foi criada uma infraestrutura que utiliza a plataforma OSGi, como ambiente de execução, e o modelo de componentes iPOJO. A Figura 34, apresentada no trabalho, mostra a visão geral da infraestrutura criada que contem dois componentes principais, o Controlador e o Planejador. O Controlador é composto por quatro componentes que são utilizados durante o processo de adaptação. O Receptor é responsável por obter um plano de adap- tação, do componente Planejador, e transformá-lo em uma representação canônica das ações de adaptação. Esse plano é formado por um conjunto de operações que seguem o formato LISP. Uma vez que o plano seja traduzido em ações de adaptação, ele é passado ao componente Executor que tem a responsabilidade de executá-las. A execução do plano é realizada em duas etapas: validação - onde é verificado as precondições e se o efeito desejado é atingido; e adaptação - onde a execução é realizada de fato. O componente Sincronizador é necessário por conta do comportamento assíncrono do modelo de compo- nentes iPOJO. Por fim, caso ocorra algum erro durante o processo, o Controlador desfaz as operações que foram realizadas. O processo de geração dos planos pelo Planejador é iniciado pelo componente Sensor, e a partir do estado inicial e descrição do sistema ele gera um plano que é utilizado pelo Controlador na adaptação. A comunicação entre o Controlador e Planejador é realizada por meio de arquivos.
Essa abordagem oferece um mecanismo para suporte a adaptação e reconfiguração di- nâmica de componentes sobre a plataforma OSGi. Também apresenta uma infraestrutura que utiliza o mecanismo pra realizar adaptações por meio de planejadores. A integração da infraestrutura com o planejador é realizada por meio de arquivos, que são gerados pelo Planejador e lidos pelo Controlador. Na ocorrência de erros, o Controlador desfaz as ações
Figura 34: Detalhamento da infraestrutura.
que foram executadas, porém, não é definida a geração de um novo plano. Em nossa abor- dagem, também utilizamos um gerador de planos de adaptação que além de gerar o plano de adaptação, também o executa no Cosmos, com isso, não é necessário procedimentos extras de tradução dos planos de adaptação. A comunicação entre o Cosmos e o gerador de planos é realizada através do uso de webservices.
Em (TAJALLI et al., 2010) Tajallo apresenta uma abordagem para adaptação dinâ- mica de sistemas através do uso de planejamento e mecanismos arquiteturais. Para tal é utilizado dois tipos de modelos de domínio: modelo de domínio da aplicação e modelo de domínio de adaptação. O modelo de domínio de aplicação capta os possíveis estados dos componentes da aplicação e ações que esses componentes podem executar. O modelo de domínio de adaptação capta ações e estados da arquitetura, cada ação estado nesse modelo corresponde a uma configuração da arquitetura em particular.
Nessa abordagem é utilizado o estilo arquitetural de adaptação em camadas (EDWARDS et al., 2009), onde são criadas três camadas: camada da aplicação, que contem os compo-
nentes; camada de adaptação, que monitora, gerencia e realiza as adaptações; e camada de planejamento, que gera os planos de acordo com requisitos do usuário e na especificação dos componentes. O plano gerado pela camada de planejamento define a nova arquitetura para a camada de aplicação e as ações para alcançar a nova arquitetura.
Em nossa abordagem, o processo de adaptação é dividido em componentes especiali- zados, com isso, as atividades que envolvem a adaptação são desacopladas. No processo de geração de planos de adaptação é definida uma nova arquitetura e as ações para alcançar essa arquitetura são executadas diretamente no Cosmos pelo Planejador.
Em (MORIN et al., 2008) Morin apresenta uma abordagem que combina técnicas de orientação a aspectos e a modelos para executar adaptações em sistemas de software. Em tempo de desenvolvimento são elaborados a base da aplicação, variações de modelos
arquiteturais e o modelo de adaptação. Em tempo de execução o modelo da aplicação é processado para produzir uma configuração da aplicação que deve ser executada. O processo de adaptação é realizado com base no modelo da aplicação em execução e as variações dos modelos. Uma variante deve ser selecionada de acordo com o contexto da aplicação em execução. Uma vez que uma configuração é escolhida o framework realiza a validação da configuração. Uma vez validada a configuração, ele é implantada.
Em nossa abordagem os planos de adaptação são gerados dinamicamente sem a neces- sidade de se definir em tempo de desenvolvimento variantes do modelo da aplicação. Em nosso modelo de adaptação, a geração do plano e execução é realizada por um framework de geração de processos, que utiliza técnicas de inteligencia artificial para gerar as ações necessárias para realizar a adaptação.
Em (ANDRZEJAK; HERMANN; SAHAI, 2005) Andrzejak et al tenta automatizar a cri- ação e execução de workflows para gerenciar adaptações. Para tal, são utilizadas como entradas a declaração de um conjunto de ações atômicas, a descrição do sistema em execu- ção e a descrição a ser alcançada do sistema. A partir dessa entrada é gerado um workflow para as ações atômicas, iniciada sua execução desse workflow resultando na atualização do estado do sistema. Para a execução desse procedimento foi proposta uma arquitetura que consiste de um controlador, um planejador, um mecanismo de execução de workflow e um deamon para executar as as ações atômicas.
A interação entre esses componentes é realizada por documentos intermediários que devem ser fornecidos pelo usuário. Esses conjunto de documentos é formado pela espe- cificação das ações atômicas, em PDDL, a especificação do estado da aplicação e uma coleção de classes java e scripts ant que implementem as diferentes ações atômicas. Esses documentos são utilizados no uso do planejador.
Em nossa abordagem, mesmo tendo que definir o modelo PDDL, regras de transfor- mação e ações templates, é utilizado um modelo definido por (SILVA, 2011) que utiliza
arquivos XMI em sua elaboração. Na geração dos planos, a abordagem de (SILVA, 2011) não precisa utilizar todos os recursos disponíveis na geração, para tal, é gerado workflows abstratos que são utilizados na geração dos workflows concretos. A partir dos workflows concretos são utilizados os recursos necessários para sua execução.