3 Instanciação do Framework de Geração de Processos
3.5 Integrando o Framework de Geração de Processos com o ambiente OSG
Para instanciar o framework de geração dinâmica de processos sobre o ambiente OSGi é necessário definir uma arquitetura de integração entre o framework e o ambiente OSGi. Esta subseção apresenta e discute os componente presentes em nossa solução assim como as suas respectivas funcionalidades, relacionando cada componente com as atividades do processo de reconfiguração que eles suportam. A arquitetura de integração apresentada nesta Seção é uma evolução da nossa primeira arquitetura de integração apresentada em (SOARES; LOPES; SILVA, 2013), o qual é baseada na infraestrutura oferecida pelo fra-
mework.
Para se utilizar o framework de geração dinâmica de processos é necessário definir uma interface de comunicação para que os planos gerados possam ser executados sobre o ambiente em que ele está instanciado. O uso de tecnologias de gerenciamento de workflows para representação e execução de planos de adaptação nos levou a decisão de utilizar uma interface WSDL (Web Services Description Language) para executar as tarefas do workflow gerado sobre o ambiente. Entretanto, não encontramos em nossas pesquisas, uma abordagem de gerenciamento remoto que defina uma forma de gerenciar o ambiente OSGi através de uma interface WSDL. Existem algumas abordagens que fornecem uma interface
de gerência sobre o ambiente OSGi, tais como: Sheel Console2; Remote Shell Console3; e
Web Console4; mas nenhuma dessas abordagens oferecem uma interface WSDL.
Desse modo, para prover ao framework de geração dinâmica de processos uma interface de comunicação com o ambiente OSGi, propomos um componente chamado Configurator, que fornece uma interface WSDL com os serviços que podem ser utilizados pelo framework de geração dinâmica de processos durante a geração e execução dos planos de adaptação. Para executar as tarefas que apresentamos na Seção 3.4 sobre o ambiente, o Configurator utiliza a API disponibilizada pelo próprio ambiente (BundleContext e SystemBundle que foram discutidas na Seção 2.3.1).
A Figura 10 mostra nossa solução para integração do framework de geração dinâ- mica de processos ao ambiente OSGi. O framework de geração dinâmica de processos, que é representado na parte superior da figura pelo componente Workflow Generator, é responsável por gerar um plano de adaptação para o sistema. Como mencionamos an-
2 http://felix.apache.org/site/apache-felix-shell.html 3 http://felix.apache.org/site/apache-felix-remote-shell.html 4 http://felix.apache.org/site/apache-felix-web-console.html
teriormente, o framework oferece diversos componentes. Componentes independentes de domínio (cinza-escuro) são aqueles que podem ser reutilizados sem nenhuma alteração e componentes customizáveis (cinza-médio) são aqueles que precisam ser, de alguma ma- neira, modificados. Na parte inferior da figura apresentamos o ambiente OSGi através de um retângulo com cantos arredondados. Os componentes que são específicos da nossa instanciação foram implementados na forma de bundles (representados por elipses com preenchimento cinza-claro) que executam dentro do ambiente OSGi juntamente com a aplicação (representados por elipses com preenchimento cinza-médio).
Figura 10: Arquitetura da Solução
O componente WfMS representa o sistema de gerenciamento de workflows, que é responsável por gerenciar todo o processo de geração e execução do plano de adaptação sobre o ambiente. Para executar o plano de adaptação sobre o ambiente, o WfMS utiliza a interface WSDL disponibilizada pelo componente Configurator (não exibida na figura). O Configurator gerencia a aplicação (App Bundles), que está executando sobre o ambi- ente OSGi, através da API (BundleContext e SystemBundle) disponibilizada pelo próprio ambiente.
O componente Model Manager é responsável por manter um modelo atualizado dos componentes da aplicação que estão executando no ambiente OSGi, e para isso utiliza probes (não mostrados na Figura), que são implementados através de threads que rodam
dentro do ModelManager e ficam consultando os componentes em um certo intervalo de tempo. Nós assumimos que quaisquer mudanças que ocorram no ambiente devem ser refletidas no Model Manager. O componente Repository é responsável por manter uma representação dos componentes que estão disponíveis para serem utilizados pela aplicação. O Configurator consulta o Model Manager e compara os valores das propriedades dos componentes que estão sendo monitoradas e compara com limites definidos pelo usuário. Ao perceber a necessidade de uma adaptação, o Configurator inicia o processo de geração de um plano de adaptação, passando para o framework de geração de processos um modelo com a configuração atual da aplicação e a nova configuração que deve ser alcançada (configuração abstrata). Vale ressaltar que apesar dos limites serem definidos pelo usuário, o plano de adaptação da aplicação é gerado dinamicamente. O Configurator dá suporte as atividades: Obtain Current Configuration e Obtain Selected Configuration da Figura 3; Obtain Concrete Configuration da Figura 4; e Execute Concrete Workflow da Figura 5.
O componente Model Translator utiliza as regras de transformação apresentadas na Seção 2.2.1 para dar suporte à atividade Translate into pre/post da Figura 3, traduzindo os modelos de configuração atual e desejada em uma especificação de problema PDDL.
O componente Planner é responsável por gerar o plano de adaptação (corresponde a atividade Run Planner da Figura 3) a partir de uma especificação de problema PDDL e dos templates de tarefa disponíveis em um repositório (Task Template Repository). Este componente armazena o modelo de domínio PDDL, que fornece ao planejador as informações necessárias para que o plano seja gerado.
Uma vez que o plano tenha sido gerado, o componente Workflow Translator é res- ponsável por traduzir o plano gerado em um workflow abstrato (atividade Translate Into Workflow da Figura 3). Para isso, o componente Workflow Translator utiliza os templates de tarefas que estão disponíveis em um repositório (Task Template Repository).
Após o workflow ter sido gerado, o componente Workflow Model Handler é responsável por extrair as tarefas abstratas do workflow abstrato e substituí-las por tarefas concretas de acordo com os recursos que estão disponíveis no ambiente, que corresponde as ativi- dades: Extract Abstract Tasks, Replace Task Parameters, e Associate Concrete Tasks da Figura 4. Para descobrir quais recursos podem compor o workflow concreto, o WfMS se comunica com o Configurator, que por sua vez recupera os componente disponíveis no Repository.
Configurator. No caso de ocorrer algum erro durante a execução do workflow gerado, o componente Recovery Handler é responsável por gerar um workflow que desfaça as tarefas que já foram executadas com sucesso sobre o ambiente, levando o sistema à configuração inicial. Esses componentes estão associados a fase operacional do processo apresentado na Seção 2.2.1.3.
Embora todos os componentes da infraestrutura de suporte possam ser tratados como bundles e rodarem a partir de um container OSGi, nossa implementação não seguiu este caminho. Isso se deu devido a reutilização de componentes fornecidos pelo framework de geração dinâmica de processo. Dessa maneira, os componentes do framework (Model Translator, Planner, Workflow Translator, Workflow Model Handler e Recovery Handler ) rodam em um servidor de aplicação Glassfish v3.1, enquanto que os componentes Confi- gurator, Model Manager e Repository são executados a partir do container OSGi Equinox v3.7.2, juntamente com os componentes que compõem a aplicação, e o sistema de geren- ciamento de workflow corresponde ao YAWL que roda no Tomcat v6.0.18.
3.6
Sumário do Capítulo
Neste capítulo nós apresentamos como foi feita a instanciação do framwork de geração dinâmica de processos sobre o ambiente OSGi. Seguindo a metodologia definida para a instanciação do framework, primeiramente geramos os modelos de domínio. Um metamo- delo específico de domínio foi definido para representar o domínio no qual o framework foi instanciado. A partir do metamodelo especifico de domínio, criamos um modelo de domínio PDDL que contém as caraterísticas do domínio que são consideradas durante o planejamento.
Para realizar o planejamento, implementamos regras de transformação, que transfor- mam modelos específicos de domínio em uma especificação de problema de planejamento. Além disso, também especificamos as tarefas que podem ser utilizadas pelo planejador para compor os planos gerados. Finalmente, nós mostramos uma arquitetura que integra o framework de geração dinâmica de processos ao ambiente OSGi, apresentando também a interação entre esses componentes.