Departmento de Informática e Matemática Aplicada Programa de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Reengenharia do Framework Cosmos:
Uma Solução para Prover Suporte a
Adaptações Abertas
José Augusto Nascimento de Medeiros
Reengenharia do Framework Cosmos:
Uma Solução para Prover Suporte a Adaptações
Abertas
Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informá-tica e MatemáInformá-tica Aplicada da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Sistemas e Computação.
Orientador
Prof. Dr. Adilson Barboza Lopes
Co-orientador
Prof. Dr. Carlos Eduardo da Silva
PPgSC – Programa de Pós-Graduação em Sistemas e Computação DIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da Terra UFRN – Universidade Federal do Rio Grande do Norte
Natal-RN
UFRN / Biblioteca Central Zila Mamede Catalogação da Publicação na Fonte
Medeiros, José Augusto Nascimento de.
Reengenharia do framework cosmos: uma solução para prover suporte e adaptações abertas. / José Augusto Nascimento de Medeiros. – Natal, RN, 2013.
66 f.: il.
Orientador: Prof. Dr. Adilson Barboza Lopes. Co-orientador: Prof. Dr. Carlos Eduardo da Silva.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação.
1. Software – Adaptação aberta - Dissertação. 2. Autoadaptação - Dissertação. 3. Software - Componentes - Dissertação. 4. OSGi – Dissertação. I. Lopes, Adilson Barboza. II. Silva, Carlos Eduardo da. III. Universidade Federal do Rio Grande do Norte. IV. Título.
para Prover Suporte a Adaptações Abertas apresentada por José Augusto Nascimento de Medeiros e aceita pelo Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Prof. Dr. Adilson Barboza Lopes
Presidente
DIMAp – Departamento de Informática e Matemática Aplicada UFRN – Universidade Federal do Rio Grande do Norte
Prof. Dr. Uira Kulesza
Examinador Interno
DIMAp – Departamento de Informática e Matemática Aplicada UFRN – Universidade Federal do Rio Grande do Norte
Prof. Dr. Carlos Eduardo da Silva
Examinador Externo ao Programa
ECT – Escola de Ciências e Tecnologia UFRN – Universidade Federal do Rio Grande do Norte
Prof. Dr. Nelson Souto Rosa
Examinador Externo à Instituição
Centro de Informática Universidade Federal de Pernambuco
Agradeço primeiramente à Deus por ter me dado a dádiva da vida, por me sustentar em todos os momentos da minha vida e por não ter desistido de mim. Durante a elaboração desse trabalho Ele esteve sempre no controle, nunca me deixando só e me lembrando que Ele tudo suportou por mim.
Agradeço aos meus familiares por serem os apoiadores de meus sonhos. Aos meus pais por me darem todas as condições necessárias para que eu me tornasse o homem que hoje sou. A minha querida irmã que me inspira por sua dedicação acadêmica. A minha sobrinha amada por me lembrar que temos que ter força para alcançar nossos desejos. Ao meu irmão (em memoria) que estaria vibrando comigo nesse momento, para ele eu digo: te amo muito. A minha nova família, meu sogro (em memoria), minha Sogra, minha cunhada e sobrinha por completarem minha família. E em especial a minha amada esposa Danielle, você é a direção, a compreensão, o amor, o meu tudo.
Agradeço aos meus amigos e orientadores Adilson e Carlos Eduardo, foi através de vocês que pude trilhar o caminho do saber, de maneira a culminar em mais um degrau em minha vida. De maneira especial ao Prof. Adilson por acreditar e me guiar desde a graduação. Fico bastante feliz e grato a Deus por Ele ter colocado vocês em minha vida.
Agradeço aos meus amigos do IFRN e de forma especial à Túlio e Anderson. Começa-mos essa caminhada juntos e pela graça de Deus, conseguiComeça-mos terminar essa caminhada.
para Prover Suporte a Adaptações Abertas
Autor: José Augusto Nascimento de Medeiros Orientador: Prof. Dr. Adilson Barbosa Lopes Co-orientador: Prof. Dr. Carlos Eduardo da Silva
Resumo
Sistemas de software autoadaptativos são caracterizados por terem a capacidade de alte-rar sua estrutura e/ou comportamento em tempo de execução em resposta a mudanças ocorridas em seus requisitos, seu ambiente de execução ou em seus componentes. Uma das maneiras de se alcançar a autoadaptação é a utilização de uma sequência de ações (conhecidas como planos de adaptação) que normalmente são definidas em tempo de de-senvolvimento. Esse tipo de adaptação foi adotado pelo Cosmos - umframework proposto para dar suporte à configuração e ao gerenciamento de recursos em ambientes distribuí-dos. De maneira a lidar com a variabilidade inerente a sistemas autoadaptativos, como por exemplo, o aparecimento de novos componentes que permitam o estabelecimento de configurações que não foram consideradas em tempo de desenvolvimento, o presente tra-balho procura dar ao Cosmos a possibilidade de utilizar planos de adaptação gerados em tempo de execução. Para tal, foi necessário realizar a reengenharia do mesmo, de maneira a permitir sua integração com um mecanismo capaz de gerar planos de adaptação dinami-camente. Nesse contexto, o presente trabalho se concentrou na reengenharia do Cosmos. Dentre as mudanças realizadas no Cosmos, podemos destacar alterações no metamodelo utilizado para representar componentes e aplicações, que foi redefinido com base em uma linguagem de descrição arquitetural. Essas alterações foram propagadas para a imple-mentação de um novo protótipo do Cosmos, que foi utilizado para o desenvolvimento de aplicações definidas para fins de prova de conceito. Outro esforço empreendido consistiu em tornar o uso do Cosmos mais atrativo ao viabilizar sua integração com outras plata-formas. Especificamente, no presente trabalho, com a plataformaOSGi, uma plataforma bem aceita pela indústria.
Support Open Adaptations
Author: José Augusto Nascimento de Medeiros Supervisors: Dr. Adilson Barbosa Lopes, Dr. Carlos Eduardo da Silva
Abstract
Self-adaptive software system is able to change its structure and/or behavior at runtime due to changes in their requirements, environment or components. One way to archieve self-adaptation is the use a sequence of actions (known as adaptation plans) which are typically defined at design time. This is the approach adopted by Cosmos - a Framework to support the configuration and management of resources in distributed environments. In order to deal with the variability inherent of self-adaptive systems, such as, the appearance of new components that allow the establishment of configurations that were not envisioned at development time, this dissertation aims to give Cosmos the capability of generating adaptation plans of runtime. In this way, it was necessary to perform a reengineering of the Cosmos Framework in order to allow its integration with a mechanism for the dynamic generation of adaptation plans. In this context, our work has been focused on conducting a reengineering of Cosmos. Among the changes made to in the Cosmos, we can highlight: changes in the metamodel used to represent components and applications, which has been redefined based on an architectural description language. These changes were propagated to the implementation of a new Cosmos prototype, which was then used for developing a case study application for purpose of proof of concept. Another effort undertaken was to make Cosmos more attractive by integrating it with another platform, in the case of this dissertation, the OSGi platform, which is well-known and accepted by the industry.
1 Feedback control loop (CHENG et al., 2009) . . . p. 14
2 Arquitetura do Cosmos (LOPES, 2006). . . . p. 21
3 Ciclo de vida dos componentes (LOPES, 2006). . . . p. 21
4 Visão geral do processo de geração de processos (SILVA, 2011). . . p. 25
5 Modelo das camadas do framework OSGi (ALLIANCE, b). . . p. 27
6 Diagrama de estados dos pacotes. . . p. 28
7 Relação entre simplificada dos elementos do xADL. . . p. 29
8 Metamodelo adotado. . . p. 34
9 Descrição de um componente em nosso metamodelo. . . p. 35
10 Visão geral do Cosmos. . . p. 36
11 Interface IQoSManager. . . p. 37
12 Interface IArchSelector. . . p. 37
13 Interface IPlanGen. . . p. 37
14 Interface IAdaptable. . . p. 38
15 Modelo de componentes original. . . p. 39
16 Interfaces do modelo de componentes. . . p. 39
17 Interface do ModelManager. . . p. 40
18 Processo de adaptação. . . p. 42
19 Especialização do Cosmos para OSGi. . . p. 43
20 Diagrama da implementação padrão. . . p. 44
21 Modelo de domínio PDDL. . . p. 46
24 Webservice para seleção de configuração arquitetural. . . p. 51
25 Webservice para geração do plano de adaptação. . . p. 51
26 Visão da aplicação de transmissão de vídeos. . . p. 51
27 Descrição do componente consumer. . . p. 52
28 Descrição da ligação de componente e conector. . . p. 52
29 Interface gráfica do Cosmos. . . p. 53
30 Janelas dos recursos virtuas do protótipo. . . p. 54
31 Resumo do log contendo as atividade de adaptação. . . p. 54
32 Listagem do arquivo MANIFEST.MF do Cosmos. . . p. 55
33 Visão Geral da Solução (SOARES; LOPES; SILVA, 2013). . . p. 57
1 Elementos da linguagem xADL. . . p. 28
2 Metamodelo definido por Lopes. . . p. 32
3 Descrição dos métodos das interfaces do componente. . . p. 40
4 Relação entre os ciclos de vida do Cosmos e OSGi. . . p. 45
5 Lista de templates de tarefa. . . p. 46
OSGi – Open Services Gateway Initiative
PDDL – Planning Domain Description Language
JAR – Java ARchive
API – Application Programming Interface
XML – eXtensible Markup Language
EMF – Eclipse Modeling Framework
XMI – XML Metadata Interchange
1 Introdução p. 14
1.1 Motivação . . . p. 16
1.2 Objetivos . . . p. 17
1.3 Organização do trabalho . . . p. 18
2 Referencial Teórico p. 20
2.1 Cosmos . . . p. 20
2.2 Reengenharia . . . p. 22
2.3 Geração de Procesos . . . p. 24
2.4 OSGi . . . p. 26
2.5 xADL . . . p. 27
2.6 Sumário do capítulo . . . p. 30
3 Reengenharia do Cosmos p. 31
3.1 Metamodelo Arquitetural . . . p. 32
3.2 Nova Arquitetura do Cosmos . . . p. 35
3.2.1 Visão Geral . . . p. 35
3.2.2 Modelo de Componentes . . . p. 38
3.2.3 Gerenciador de Modelos . . . p. 39
3.3 Integração com a Plataforma OSGi . . . p. 42
3.4 Integração com gerador de processos . . . p. 45
4.1 A Instanciação do Cosmos . . . p. 48
4.1.1 Componentes externos . . . p. 50
4.1.2 Protótipo . . . p. 51
4.2 A Instanciação do Cosmos sobre o OSGi . . . p. 54
4.2.1 Sumário do capítulo . . . p. 56
5 Trabalhos Relacionados p. 57
6 Considerações finais p. 61
6.1 Limitações . . . p. 62
6.2 Trabalhos Futuros . . . p. 63
1
Introdução
Sistemas de software autoadaptativos têm recebido cada vez mais atenção de diferentes comunidades de pesquisa como meio de lidar com a crescente complexidade e dinamismo dos sistemas de software (CHENG et al., 2009). De acordo com (SALEHIE; TAHVILDARI, 2009) um sistema autoadaptativo modifica seu próprio comportamento e/ou estrutura em resposta a mudanças em seus requisitos, seu ambiente de operação ou em si próprio.
Dentre as técnicas empregadas para alcançar autoadaptação em sistemas de software, apontamos o uso defeedback control loop (DOBSON et al., 2006)(CHENG et al., 2009)(BRUN et al., 2009). A Figura 1 apresenta uma visão dofeedback control loop, o qual é composto por quatro fases básicas. Ele inicia com a coleta de informações sobre o sistema, incluindo seus requisitos, dados sobre os componentes do sistema e seu ambiente de execução, fase coletar (Collect). Com os requisitos e dados coletados do sistema, é realizada uma análise que verifica a necessidade de adaptação, fase analisar (Analyze). Uma vez identificada a necessidade de adaptação, a fase decidir (Decide) define os componentes que devem ser adaptados e os passos necessários para realizar a adaptação. Esses passos são represen-tados através de um plano de adaptação. Por fim, a fase atuar (Act) executa o plano de adaptação alterando efetivamente o sistema.
De acordo como as mudanças são realizadas em sistemas de software autoadaptativos, a adaptação pode ser classificada como paramétrica ou estrutural, como aponta ( MCKIN-LEY et al., 2004). Uma adaptação é classificada como paramétrica quando a mudança ocorre nos parâmetros (variáveis) dos componentes que compõem os sistema de software. Por outro lado, uma adaptação é classificada como estrutural quando a mudança é rea-lizada com a adição, substituição ou remoção de componentes que formam o sistema de software.
Baseado em como são gerados os planos de adaptações, podemos classificar a adapta-ção como fechada ou aberta. De acordo com (OREIZY et al., 1999) a adaptação é fechada quando os planos de adaptação são definidos estaticamente, em tempo de desenvolvi-mento, sendo autocontidos e para realizar mudanças é necessário nova codificação. Por outro lado, a adaptação é aberta quando os planos de adaptação são definidos dinamica-mente, em tempo de execução, possibilitando sua mudança em decorrência dos elementos envolvidos.
Com o sentido de possibilitar mudanças no processo de adaptação algumas aborda-gens discutem o uso da adaptação aberta, como exemplo temos: seu uso com interface de usuário (BALME et al., 2004) e (COUTAZ, 2010), uso de planejadores (SILVA, 2011), (FONSECA F. L.; BENEDITTO, 2012) e (BENEDITTO; MADEIRA, 2012), entre outros.
A autoadaptação de sistemas de software envolve um processo complexo que depende de diversos fatores que podem mudar durante a execução do sistema. Fatores que podem se originar das entidades que interagem com o sistema, seu ambiente de execução e o próprio sistema. Com isso, espera-se que um sistema de software autoadaptativo seja capaz de gerar planos de adaptação durante sua execução, afim de lidar com a variabilidade e incerteza envolvida na autoadaptação de sistemas de software (SILVA; LEMOS, 2011a).
Uma abordagem que podemos explorar para alcançar adaptação dinâmica é o uso de arquitetura de software. Para tal, podemos descrever um sistema de software por meio de vários pontos de vista (KRUCHTEN, 1995), desde seu modelo lógico até seu modelo físico. Assim, uma adaptação pode ser caracterizada pela reconfiguração do sistema, de maneira a satisfazer a mudanças em sua especificação e/ou ambiente (KRAMER; MAGEE, 2007). A visão de componente-conector pode ser considerada, como aponta (SILVA, 2011), por caracterizar o comportamento do sistema em tempo de execução e o estado do sistema. Assim o sistema pode ser visto como uma visão de tempo de execução, como também uma visão estrutural.
fra-mework de geração de processos (SILVA, 2011), por apresentar uma solução reutilizável e possibilitar sua instanciação em diferentes domínios de aplicação. Esseframework é com-posto por um processo de referência para controlar a geração e execução de processos, uma infraestrutura de que dá suporte ao processo de referência e uma metodologia para sua instanciação. No framework os planos de adaptação são alcançados através da produção de processos que por sua vez são mapeados em workflows.
Tendo em vista o cenário de sistemas autoadaptativos, (LOPES, 2006) procurou con-tribuir apresentando o framework Cosmos, que constitui-se em uma base genérica para dar suporte à configuração e gerenciamento de recursos de sistemas multimídia baseados em componentes de software. No suporte a autoadaptação, o Cosmos explora o conceito de reflexão computacional (MCKINLEY et al., 2004), onde um modelo da aplicação que está em execução é utilizado para se tomar decisões sobre a adaptação do sistemas.
O Cosmos define um metamodelo que é usado na definição dos modelos das aplicações. Esse metamodelo é composto por Componentes, Portas, Conexões e Propriedades. Com o auxílio das propriedades, as seguintes tarefas são realizadas sobre os sistemas: a confi-guração, o gerenciamento e as adaptações. Também é definido um modelo de QoS que é utilizado no monitoramento do comportamento dos componentes e conexões. Quando é apontada a necessidade de adaptação, o Cosmos utiliza o plano que foi definido durante seu desenvolvimento e realiza a mudança nas propriedades dos componentes, adaptação paramétrica. Na direção de tornar a adaptação estrutural no Cosmos, foi apresentado por (PINTO, 2011) uma evolução que trata a adaptação por meio de modelos, contudo, o plano de adaptação utilizado foi definido em tempo de desenvolvimento.
1.1
Motivação
O uso da adaptação fechada, em sistemas autoadaptativos, implica no uso de planos estáticos. Para tal, pode-se explorar o uso de políticas de seleção de planos de adaptação, por meio da definição de regra de evento-condição-ação, porém, em sistemas complexos a elaboração dessas regras não é uma atividade trivial. Com isso, o uso dessa abordagem se torna complexa, uma vez que a antecipação de todos os possíveis contextos, quando o sistema está em adaptação, é uma tarefa difícil, como aponta (SILVA, 2011).
tempo de execução, o que caracteriza a adaptação aberta; apontamos seu uso em algumas abordagens: composição de serviços Web (DUSTDAR; SCHREINER, 2005); grades compu-tacionais (DEELMAN et al., 2003); gerenciamento de software (ANDRZEJAK; HERMANN; SAHAI, 2005); e reconfiguração arquitetural (SILVA; LEMOS, 2011b).
A partir do uso de adaptação aberta, busca-se a elaboração de planos de adaptação que levem em consideração o contexto atual do sistema de software, com isso, podemos utilizar informações sobre o estado do sistema, do seu ambiente de execução e dos novos requisitos. Outro fator importante é a possibilidade de componentes/serviços serem adicionados ou removidos. Essa possibilidade deve ser considerada na elaboração dos planos de adaptação.
Tendo em vista que o uso de adaptação aberta, (SILVA, 2011) apresenta uma solução reutilizável que utiliza técnicas de transformação de modelos para possibilitar seu uso em diversos domínios de aplicação. Em sua validação, oframework apresentado foi instanciado em dois domínios diferentes, reconfiguração arquitetural e testes de integração. Em nosso contexto seu uso se torna interessante, isso devido ao fato do Cosmos ser uma solução para configuração e gerenciamento de recursos e componentes e que se ajusta bem ao problema de reconfiguração arquitetural.
Contudo no Cosmos o processo de adaptação é formado por um plano de adaptação estático. Ao executar esse plano, recursos que foram considerados em sua elaboração podem não estar mais disponíveis e novos recursos podem estar disponíveis, o que pode levar a mudança no plano de adaptação. Realizar a integração com oframework de geração de processos, (SILVA, 2011), requer uma série de modificações no Cosmos.
1.2
Objetivos
O objetivo principal desse trabalho é realizar a reengenharia do framework Cosmos para possibilitar o uso do framework de geração de processos. Com isso, buscamos a elaboração de planos de adaptação em tempo de execução e, consequentemente, a mudança no estilo de adaptação do Cosmos de fechada para aberta. De maneira mais específica, estamos focando nas fases decidir e atuar do feedback control loop, concentrando nossos esforços na geração e execução de planos de adaptação, e assumindo a existência de mecanismos responsáveis por lidar com as fases coleta e análise, os quais foram definidos pelo modelo deQoS do Cosmos.
necessidade de representar modelos tanto na visão de tipos e estrutura quanto na visão de instâncias, já que esse fato é um pré-requisito do framework de geração de processos. Para tanto, basearemos o nosso metamodelo arquitetural pelo xADL apresentado por (DASHOFY; HOEK; TAYLOR, 2005) pelo fato dele dá suporte as duas visões (tipo/estrutura e instância) e por este ser o modelo adotado pelo Framework de geração de processos, facilitando assim na integração.
Com a mudança do metamodelo arquitetural, deve-se realizar os ajustes necessários a infraestrutura existente no Cosmos. Com isso, deve-se ajustar o modelo de componentes, atualizar o mecanismo de gerência de modelos e os demais componentes que realizam operações com o auxílio do metamodelo.
Um segundo objetivo que apontamos é realizar a integração do Cosmos com a plata-formaOSGi1
. Nosso interesse com essa integração é tornar o uso do Cosmos mais atrativo por essa plataforma ser bem aceita pela indústria, como exemplo de seu uso apontamos: Adobe, BMW, Eclipse, Siemens, Oracle, entre outros. Um ponto importante é torná-la transparente para as aplicações executadas sobre o Cosmos, ou seja, a relação dos compo-nentes dessas aplicações continuará sendo com o Cosmos, e eles não precisam saber que o Cosmos está sendo executado sobre a plataformaOSGi.
Uma vez que estamos explicitando parte da fase decidir e a fase atuar do feedback control loop, pela integração com o Framework de geração de processos, vemos como oportuno explicitar as demais fases do feedback control loop. Essas fases são executadas por componentes existentes no Cosmos, os quais não estão sendo alterados.
Por fim, demostraremos o uso do Cosmos com as novas facilidades por meio de um aplicativo de transmissão de vídeo, para tal, serão definidos componentes responsáveis por transmitir um vídeo em diferentes qualidades e um componente para receber e exibir esses vídeos. Para validar as integrações e o processo de adaptação, realizaremos simulações de falhas na transmissão.
1.3
Organização do trabalho
Esse trabalho está organizado da seguinte forma: O Capítulo 2 apresenta uma breve discussão envolvendo os fundamentos teóricos considerados como base para o desenvolvi-mento do trabalho, além de fazer a apresentação do Cosmos. No Capítulo 3, abordamos as mudanças que foram geradas por esse trabalho para possibilitar sua integração com o
2
Referencial Teórico
Esse capítulo tem como objetivo apresentar uma breve discussão sobre os principais conceitos e trabalhos que fornecem a base para a construção da nossa proposta. Inicial-mente é apresentado o Cosmos que é a base desse trabalho; seguindo por conceitos sobre reengenharia de software, pelo fato que iremos adicionar novas facilidades ao Cosmos; o Framework de Geração de Processos, responsável por gerar dinamicamente planos de adaptação; a plataforma OSGi, plataforma orientada a serviços; e por fim, a linguagem de descrição arquiteturalxADL.
2.1
Cosmos
O Cosmos foi concebido para ser um framework para configuração e gerenciamento de recursos e componentes de sistemas multimídia distribuídos abertos (LOPES, 2006). Para isso, o Cosmos define um modelo básico de componentes e um modelo demetacomponentes
que serve de base para especificação de configuração e descrição de componentes e de aplicações. Nesse modelo, os componentes concretos são denominados de recursos virtuais (VirtualResource).
Com a necessidade de realizar o gerenciamento e possibilitar adaptações em tempo de execução, foi criado um modelo deQoS que possibilita o monitoramento e eventuais ajus-tes de comportamento dos componenajus-tes, bem como de conexões entre componenajus-tes. Tais ajustes são baseados em políticas de adaptação definidas em tempo de desenvolvimento.
A Figura 2 mostra a arquitetura de alto nível onde o Configurator é o elemento central responsável por iniciar, configurar e coordenar o processo de gerenciamento dos componentes da aplicação. Para a instanciação das aplicações, o Configurator utiliza o
de propriedades desses componentes. A criação dos componentes, portas, serviços e re-cursos, da aplicação, são realizadas peloFactory. Os recursos de hardware e software são representados peloResource. E por fim, oService permite agregar novas funcionalidades.
Figura 2: Arquitetura do Cosmos (LOPES, 2006).
O ciclo de vida dos componentes é gerenciado pelo Configurator que altera o estado dos componentes com o auxílio do ApplicationProxy. A Figura 3 mostra o diagrama de estados do ciclo de vida dos componentes. A fase inicial corresponde à criação do compo-nente, ou seja, sua instanciação. Após a instanciação, o componente passa por um processo de configuração e alocação dos recursos necessários. Uma vez que os recursos necessários tenham sido alocados, o componente pode ser utilizado e assim entrar no estado de exe-cução. Durante a execução, o componente pode eventualmente entrar em um estado de adaptação. Quando um componente termina sua atividade, ele passa ao estado finalizado e com isso pode ser destruído.
Figura 3: Ciclo de vida dos componentes (LOPES, 2006).
faixas de valores e são associados ao paramentos dos componentes que devem ser monito-rados. Para tal, foi definido o componenteQoS Manager que é responsável por gerenciar o processo de monitoramento dos componentes das aplicações em execução. Esse monito-ramento é realizado através de monitores, conhecidos comoQoS Monitor. Uma vez que os paramentos de QoS não sejam satisfatórios, o QoS Monitor avisa ao QoS Manager, que por sua vez, notifica o Configurator.
O Configurator também tem a responsabilidade por gerenciar as adaptações no Cos-mos. As adaptações são indicadas pelo QoS Manager, que utiliza monitores no monito-ramento dos Recursos Virtuais. Com a necessidade de adaptação, o Configurator realiza mudanças nas propriedades dosRecursos Virtuais.
Para poder lidar com mudanças de componentes nas adaptações, (PINTO, 2011) propôs um framework, baseado no Cosmos, que mantem modelos de representação da aplicação em tempo de execução. Para tal, foi proposto um metamodelo para descrição arquitetural que é capaz de representar componentes e seus relacionamento, políticas para especificação deQoS e ações de adaptação. Para suportar e o novo metamodelo, (PINTO, 2011) realizou ajustes noAppicationProxy, que passou a ser conhecido como SystemModel.
2.2
Reengenharia
A reengenharia de software é um processo que envolve o exame, analise e altera-ção de um sistema de software existente, de maneia a reconstruí-lo e sua subsequente reimplementação, como aponta (AFSHAR, 2010), podendo englobar: engenharia reversa, redocumentação, reestruturação, tradução e foward engineering. Seu principal foco é en-tender um sistema de software existente, a partir de sua especificação, de seu design ou sua implementação, com isso, reimplementar funcionalidades, melhorar a performance ou sua implementação.
Com base nos requisitos do sistema e dos usuários, a reengenharia de software apre-senta dois objetivos específicos: a melhoria da qualidade e migração.
ou linguagens de programação obsoletas.
Um desafio da reengenharia de software é ser aplicada em sistemas de software exis-tentes e em funcionamento, e gerar um novo sistema de software que mantenham suas funcionalidades enquanto se aplica novas tecnologias. Nesse sentido, é apontado quatro objetivos gerais para a reengenharia de software:
• preparação para melhorar funcionalidades: onde procura-se facilitar a adição
de novas facilidades ao sistema;
• melhorar sua manutenção: onde busca-se melhorar o processo de manutenção,
podendo ser realizada através da melhoria do código, documentação interna ou externa;
• migração: onde busca-se ajustar sistemas de software de maneira que eles possam
ser usados em novas plataformas, sistemas operacionais ou mudança na linguagem de programação utilizada;
• melhorar sua confiança: devido ao número elevado de manutenções ou mudanças
no sistema de software o que pode diminuir sua aceitação.
Nesse contexto, o nosso trabalho busca realizar a reengenharia do Cosmos, de maneira a possibilitar seu suporte a adaptação aberta e sua instanciação sobre a plataformaOSGi. Dessa maneira, podemos classificar a reengenharia do Cosmos a partir dos objetivos gerais e específicos da reengenharia de software da seguinte maneira:
• Objetivo Geral
– migração, por adicionar novos requisitos ao Cosmos, como exemplo sua
ins-tanciação sobre a plataforma OSGi.
• Objetivos Específicos
– preparação para melhorar funcionalidades, ao preparar os componentes
básicos, do Cosmos, para possibilitar o uso de componentes especializados, por exemplo oframework de geração de processos;
2.3
Geração de Procesos
Com relação à geração de processos, nosso trabalho considera o framework de geração dinâmica de processos definido por (SILVA, 2011). Esse framework apresenta uma solução reutilizável para a geração de processo que pode ser instanciada em diferentes domínios de aplicação. O framework é baseado em três tecnologias, transformação de modelos, planejamento em inteligência artificial (IA) e gerenciamento deworkflow. A transformação de modelos é utilizada para tradução de modelos específicos de domínio em problemas de planejamento de IA baseados em PDDL (Planning Domain Description Language) (FOX; LONG, 2003)(GEREVINI; LONG, 2006). O planejamento em inteligencia artificial é responsável por gerar os workflows com base em um conjunto de tarefas definidas pelo desenvolvedor. Por fim, mecanismos de gerenciamento de workflows são utilizados para executar os workflows gerados sobre o sistema alvo da adaptação.
A linguagem PDDLé utilizada tanto na geração dos problemas de IA quanto na des-crição das taregas utilizadas na geração dosworkflows. Ela é uma linguagem de descrição de domínios e problemas de planejamento. Domínios PDDL descrevem um conjunto de predicados que podem ser usados para expressar o estado do ambiente, e as ações que podem ser utilizadas para se gerar um plano. Um problema de planejamento descreve o estado inicial e um estado final em termos dos predicados definidos no domínio. Domínio e problema PDDL são então usados como entrada para um planejador que produz um plano PDDL, que descreve uma sequencia de ações que leva o estado inicial ao estado final.
O framework é composto por três elementos principais: um modelo de domínio, um processo de referência e uma infraestrutura de suporte. O modelo de domínio abrange modelos, metamodelos e regras de transformação que são usadas durante a geração. O processo de referência descreve as atividades principais associadas com a geração, en-quanto que a infraestrutura de suporte identifica os diferentes componentes que fornecem suporte para o processo de referência. Estes elementos constituem a base do framework
e são customizados de acordo com o domínio da aplicação onde o framework está sendo instanciado.
recur-sos disponíveis não são referenciados. Por outro lado, um workflow concreto é gerado a partir de um abstrato, nesse momento as tarefas referenciam os recursos que serão utili-zados para sua execução. Dessa maneira, umworkflow abstrato pode dar origem a vários
workflows concretos, dependendo dos recursos disponíveis.
O framework define um processo de referência que organiza as atividades associadas a geração dosworkflows. Esse processo de referência é dividido em três fases: estratégica, tática e operacional, como mostra a Figura 4. Essa divisão visa a melhoria da escalabili-dade e performance na geração dos processo, sendo baseada nas ideias apresentadas por (LEE et al., 2009) e (CHENG; GARLAN; SCHMERL, 2006).
Figura 4: Visão geral do processo de geração de processos (SILVA, 2011).
A fase estratégica é representada pela atividadeGenerate abstract workflow que é res-ponsável por gerar osworkflows abstratos e uma vez gerado umworkflow abstrato, a fase tática inicia. A fase tática é representada com a tarefaGenerate concrete workflow a qual é responsável por gerar workflows concretos a partir de um abstrato. A fase operacional é iniciada quando um workflow concreto é gerado e é representado pela atividade Exe-cute concrete workflow. Essa tarefa tem como responsabilidade a execução do workflow
concreto sobre o sistema alvo.
Uma vez que ocorra algum erro durante a geração do plano de adaptação a fase
Recovery é executada. Essa fase é responsável por desfazer todas as tarefas já executadas sobre o sistema e de acordo com fase em execução ela age de maneira apropriada. Caso o processo esteja na fase operacional, a recuperação é realiza com a geração de umworkflow
que irá desfazer as tarefas já executadas. Se o erro ocorrer durante a fase tática, o processo retorna a fase estratégica e um novo workflow abstrato é solicitado. Por fim, caso o erro ocorra durante a fase estratégica oframework de geração de processos returna uma exceção para o sistema alvo.
defi-nidos os passos necessários para seu uso no domínio de aplicação específico. No contexto do Cosmos, onde entendemos que as adaptações são realizadas através da reconfiguração arquitetural, os passos que devemos seguir são listados abaixo:
• o Cosmos deve definir um metamodelo que represente os modelos de aplicação;
• construir regras de transformação que traduzam os modelos, do Cosmos, em
pro-blemas de inteligencia artificial;
• definirtemplatesde tarefas para compor os planos a partir dos elementos do modelo,
do Cosmos;
• realizar a customização do processo de referência;
• realizar a customização da infraestrutura de suporte.
Por fim, para realizar a integração com o Cosmos, se faz necessário que o Cosmos disponibilize uma interface de comunicação. Essa interface deve ser capaz de prover mo-delos estruturais e de instância das aplicações, para o uso nas fases estratégica e tática, respectivamente, além de ser capaz de aplicar as tarefas do plano sobre os componentes da aplicação.
2.4
OSGi
OSGi é um conjunto de especificações que seguem uma arquitetura orientada a ser-viço, definindo um sistema de pacotes dinâmicos para Java denominados bundles. Essa especificação define um modelo de desenvolvimento onde aplicações são compostas por pacotes em um ambiente dinâmico. Diversas implementações podem ser encontrada na comunidade de software livre, como exemplo: Apache Felix1
, Equinox2
e Knopflerfish3
.
O OSGi define o bundle como sendo uma unidade de modularização, composta por classes Java e outros recursos, que juntos provêem as funcionalidades. O bundle é im-plantado como um arquivo JAR (Java ARchive) e contem um arquivo de manifesto (MANIFEST.MF), recursos necessários para provimento de funcionalidades e documen-tação. A partir do arquivo de manifesto é realizada a configuração dobundle.
As funcionalidades do OSGi são divididas nas seguintes camadas: segurança ( Secu-rity), módulo (Module), ciclo de vida (Life Cycle) e serviço (Service); como apresentado na Figura 5.
Figura 5: Modelo das camadas do framework OSGi (ALLIANCE, b).
A camada de segurança é baseada na camada de segurança do Java com algumas adições. A partir dessa camada é possível autenticar o uso dos bundle, gerenciar as per-missões de uso dos serviços, como também assinar osbundle digitalmente. A camada de módulo é o local que é definida a unidade de modularização. A camada de ciclo de vida fornece uma API para gerenciamento dos bundles na camada de modulo. A camada de serviço (Service) fornece um modelo de programação dinâmico, conciso e consistente para os desenvolvedores, simplificando a implantação de bundles. A partir dessa camada, podemos registrar serviços, localizar serviços, operar com as propriedades dos bundles, entre outras operações.
A API definida pela camada de ciclo de vida cria um modelo para gerenciamento de pacotes em tempo de execução, como também define o estado dosbundles. Esses estados são apresentados na Figura 6, onde um bundle pode ser instalado (INSTALLED) no
framework. Uma vez instalado é verificada se todas as dependências estão satisfeitas e uma vez estando satisfeitas osbundles passam para o estado de resolvido (RESOLVED). Ao ser iniciado (STARTING) o bundle passa ao estado de ativo (ACTIVE) e poderá ser paradoSTOPPING) voltando ao estado (RESOLVED).
2.5
xADL
defi-Figura 6: Diagrama de estados dos pacotes.
nição é formada por um conjunto de esquemasXML , o que torna sua extensão simples, além de conter um bom número de ferramentas.
Uma das características dessa linguagem apontada por (BOUCKÉ; GARCIA; HOLVOET, 2007) é a capacidade de expressar modelos em três tipos de visões: visão de tipos; visão estrutural e visão de instância. Nas visões de tipos e estruturas encontramos a descrição dos elementos que compõe uma arquitetura por meio de componentes, conectores, tipos e como estão ligados, formando assim a estrutura arquitetural (ArchStructure em xADL). A visão de instancia descreve as instâncias dos componentes e conectores e como eles estão ligados, formando assim a instância arquitetural (ArchInstance em xADL).
A definição das visões é realizada por dois conjuntos de esquemas que realizam a sepa-ração dos modelos de desenvolvimento e execução. Os aspectos de tempo de execução são definidos no esquema de instância, o qual define os elementos comuns para a maioria das ADLs. Os aspectos de tempo de desenvolvimento são definidos no esquema de estrutura e tipos (DASHOFY; HOEK; TAYLOR, 2002). A Tabela 2.5 apresenta os elementos de cada um dos esquemas.
Tabela 1: Elementos da linguagem xADL.
Modelo de tempo de execução Modelo de tempo de desenvolvimento Modelo Estrutura Tipo
ComponentInstance Component ComponentType
ConnectorInstance Conector ConnectorType
InterfaceInstance Interface InterfaceType
LinkInstance Link
comportamento e restrições sobre a disposição dos elementos; os elementos de tempo de execução podem incluir a distribuição física do sistema de software, a identificação de todos os componentes em execução, ou o estado de um conector em particular (por exemplo, se ele está bloqueado) (DASHOFY; HOEK; TAYLOR, 2005).
A relação simplificada entre os elementos pode ser vista na Figura 7, onde é apre-sentado um exemplo de um modelo arquitetural. Nessa figura são definidos dois tipos de componentes (Component1Type e Component2Type) e um tipo de conector ( Connec-torType). Associados aos tipos criados, estão os componentesComponent1 eComponent2, além doConnector, formando a visão de desenvolvimento. Na visão de tempo de execução encontramos os componentesComp1Isntance e Comp2Instance que são estruturados que acordo comComponent1 eComopoent2, e oConnInstance que é estruturado por Connec-tor. A ligação apresentada é realizada através das interfaces providas pelos componentes e interfaces requeridas do conector.
Figura 7: Relação entre simplificada dos elementos do xADL.
O uso da linguagem de descrição arquitetural xADL foi motivada por sua capacidade de representar modelos nas visões estrutural e de instância que é explorada peloframework
2.6
Sumário do capítulo
3
Reengenharia do Cosmos
Este capítulo apresenta as mudanças no Cosmos realizadas a partir de sua reengenha-ria. Como isso buscamos realizar sua integração com oframework de geração de processos (SILVA, 2011) de maneira a dar suporte ao modelo de adaptação aberta, e também possi-bilitar sua instanciação sobre a plataforma OSGi.
Para a integração com oframework de geração de processos é necessário que o Cosmos suporte a representação de seus modelos tanto por meio de suas estruturas como por meio de suas instâncias. Esse suporte é necessário pelo fato que o framework de geração de processos necessite do modelo estrutural para gerar osworkflows abstratos e o modelo de instâncias para poder gerar os workflows concretos. Atualmente o Cosmos só dá suporte a representação do modelo de instâncias.
Uma vez que o metamodelo seja alterado, se faz necessário realizar as devidas atuali-zações nos elementos que interagem diretamente com o metamodelo, com isso, é necessário atualizar os seguintes componentes: de gerenciamento de modelos, o Configurator, o mo-delo de Componente do Cosmos.
Outro ponto abordado nesse capítulo é a explicitação das fases do feedback control loop. Para tal, serão realizadas mudanças no componenteConfigurator, que era responsável por gerenciar e executar as etapas dofeedback control loop, fazendo com que a execução dessas fases sejam realizadas por componentes especializados, com isso, serão definidos mecanismos que serão utilizados na integração com esses componentes especializados.
3.1
Metamodelo Arquitetural
O metamodelo arquitetural do Cosmos deve possibilitar a representação das aplicações por meio de seus componentes, suas propriedades e conexões. A definição original do metamodelo foi apresentada por Lopes (LOPES, 2006) e ele era composto em síntese pelos elementos:
Tabela 2: Metamodelo definido por Lopes.
Elemento Descrição
CosmosComponent Representa um componente no Cosmos.
Port Representa as portas associadas aos componentes. Property Representa as propriedades dos componentes e portas.
Com a evolução do Cosmos, um outro metamodelo foi definido com o intuito de utilizar o estilo componente-conector, da engenharia de software. Pinto (PINTO, 2011) apresenta um metamodelo que, além de representar componentes e propriedades, introduz elementos para representar as interfaces. As ligações entre os componentes, que era realizada por meio das portas, passou a ser realizada através das interfaces, com isso, os componentes passaram a prover e requerer interfaces.
Em ambas as abordagens, (LOPES, 2006) e (PINTO, 2011), os metamodelos definidos somente eram capazes de representar o modelo das aplicações por meio de suas instâncias, não possibilitando sua representação estrutural, por meio dos seus elementos e tipo. O uso dessa separação nos possibilita ter, tanto uma visão da composição da aplicação, quanto dos seus componentes concretos. A separação dessas visões é importante por estarmos realizando a integração do Cosmos com oframework de geração de processos.
Em nossa abordagem estamos adotando o metamodelo definido pela linguagem xADL
(DASHOFY; HOEK; TAYLOR, 2005). Essa adoção foi realizada tendo em vista os seguintes pontos:
• A linguagem xADL tem a capacidade de representar modelos tanto por meio de
tipos e estrutura, quanto por instâncias;
• A linguagem xADL possibilita que seja realizada extensões de maneira a torná-la
• Essa linguagem foi adotada pelo framework de geração de processos;
• E por entender que a criação de uma nova ADL não é a nosso foco.
O novo metamodelo é apresentado pela Figura 8 onde encontramos a representação de arquiteturas de instancia (ArchInstance), arquiteturas de estrutura (ArchStructure) e tipos da estrutura (ArchTypes). A arquitetura de instância é composta pelas instâncias dos elementos componente (ComponentInstance), conector (ConnectorInstance), interface (InterfaceInstance) e link (LinkInstance). As interfaces são associadas aos componentes e conectores, e podem ser requeridas ou providas. A indicação de que a interface é re-querida ou provida é realizada através da direção (Direction) a qual está associada. A ligação entre duas interfaces se dá através links, que contêm pontos de ligação. A arqui-tetura estrutural é composta de maneira semelhante a arquiarqui-tetura de instância por meio de componente (Component), conector (Connector), interface (Interface) e link (Link). A principal diferença entre a arquitetura de instância e estrutural é que nos elemen-tos componente, conector e interface são associados seus respectivos tipos; esses tipos são representados por: tipo de componente (ComponentType), tipo de conector ( Connec-torType) e tipo de instância (InterfaceInstance). O elo de ligação entre a arquitetura de instância e de estrutura é realizada através dos elementosPrescribedComponentInstance,
PrescribedInterfaceInstance ePrescribedConnectorInstance.
Além dos elementos existentes no metamodelo xADL introduzimos o elemento pro-priedade (Property) que pode ser associado aos componentes, conectores e interfaces. A associação de propriedades aos componentes é realizada através de sua estrutura ( Virtual-Resource) e sua instância (VirtualResourceInstance) que são especializações dos elemen-tosComponent ePrescribedComponentInstance. De maneira semelhante, as propriedades também podem ser associadas aos links através da especialização MyPrescribedInterfa-ceInstance.
A geração do metamodelo foi realizada com o auxílio do framework EMF1
. Esse fra-mework disponibiliza um conjunto de ferramentas gráficas que auxiliam a especificação de componentes e aplicações. A partir da especificação do metamodelo, gerada pelo fra-mework EMF, podemos gerar arquivos no formato XMI. A descrição simplificada de um componente é apresentada na Figura 9. Nela encontramos a definição do tipo de compo-nenteMyVRType que é utilizado na definição do componenteVR1. Também encontramos a definição do tipo da interface MyInterfaceType que define a interface MyInteface. As
instancias,vr emyInterface são estruturadas pelos elementosVR1 eMyInterface, respec-tivamente.
Figura 9: Descrição de um componente em nosso metamodelo.
3.2
Nova Arquitetura do Cosmos
Na reengenharia realizada, uma nova arquitetura foi projetada para atender as novas necessidades introduzidas, adaptação aberta e integração com a plataforma OSGi. Com isso, parte dos componentes que compunham o antigoframework foram substituídos por componentes especializados e novos componentes foram adicionados.
3.2.1
Visão Geral
A arquitetura original do Cosmos, apresentada no capítulo anterior pela Figura 2, é centrada no componenteConfigurator, o qual é responsável pelas atividades de adaptação, com o auxílio de monitores na coleta de informações. Com isso, oConfigurator é o respon-sável por analisar os dados obtidos nos componentes e realizar as operações necessárias na realização da adaptação. Com a reengenharia realizada, as fases que compõem ofeedback control loop foram extraídas do Configurator.
pelas fases do feedback control loop. A fase de coleta e analise é realizada pelo QoS Ma-nager através do gerenciamento da qualidade de serviços. A fase decidir é realizada pelo
MoSAC através da seleção de novas arquiteturas. Por fim, as fases decidir, no que se refere a geração dos planos de adaptação, e atuar é realizada pelo Wf.Gen. A interação entre o Configurator e esses componentes é realizada com o uso das interfaces IQoSMa-nager, IArchSelector, IPlanGen. No contexto da geração dos planos, o Wf.Gen interage com oConfigurator por meio da interfaceIAdaptable. Também destacamos que ocorreram mudanças e ajustes em alguns componentes. De forma a entender melhor a arquitetura, vamos descrever e destacar os principais elementos. Como componente central da arqui-tetura, temos o Configurator, que é o responsável por todos os processos do framework. Ao instanciar o Cosmos, o Configurator precisa, na sequencia, instanciar o gerenciador de modelos (ModelManager), que por sua vez utiliza o metamodelo (MetaModel) definido anteriormente. A criação de componentes, ou seja, recursos virtuais (VirtualResource) das aplicações que serão executadas no framework, é realizada pelo Configurator. Com a instanciação de um novo recurso virtual, o Configurator associa ao recurso virtual um
Probe que tem como papel monitorar as propriedades relacionadas à qualidade de serviço do recurso virtual.
Figura 10:Visão geral do Cosmos.
Ao instanciar uma aplicação no Cosmos, o Configurator configura o gerenciador de
inte-gração com um gerenciador de QoS é realizada através da interface IQosManager que contem as seguintes atividades: adicionar um monitor (addMonitor), remover um Probe
(removeMonitor) e avaliar dados(checkData), como apresentada pela Figura 11.
Figura 11:Interface IQoSManager.
Uma vez identificada a necessidade de adaptação, o Cosmos utiliza um componente de seleção arquitetural, o MoSAC (SILVA, 2011) para encontrar uma nova arquitetura; para tal, o Cosmos envia ao seletor de arquiteturas a configuração arquitetural atual, indicando os componentes que falharam. O seletor deve devolver uma nova arquitetura para ser instanciada no Cosmos. A integração entre o Cosmos e o componente seletor de arquiteturas é realizada através da interface IArchSelector que deve ser disponibilizada pelo componente especializado MoSAC. Essa interface pode ser observada na Figura 12 e contem o método getNewArch que deve retornar a nova arquitetura, para tal, deve-se informar a arquitetura de instância e de estrutura atuais.
Figura 12: Interface IArchSelector.
A partir da nova arquitetura, o Cosmos utiliza um gerador de planos de adaptação que tem a responsabilidade de gerar e executar as ações necessárias para a realização da adaptação. Para isso, o Cosmos necessita que o gerador de planos disponibilize a interface
IPlanGenque é capaz de iniciar o processo de geração de planos (Figura 13). Essa interface apresenta o métodogeneratePlanque é utilizado para indicar o início da geração do plano de adaptação ao gerador de processos, e receber como parâmetros a configuração atual (oldInstance) e a nova configuração (newInstance).
Uma vez que o plano seja gerado, o gerador de planos utiliza a interface IAdaptable
para efetuar as ações de adaptação. A interface IAdaptable é apresentada pela Figura 14 e contem as ações disponíveis para adaptar o sistema. Essas ações correspondem aos
templates de tarefas exigidos pelo framework de geração de processos durante a geração dos planos de adaptação. A seguir apresentamos as ações:
• start: solicita ao Cosmos que inicie o componente indicado;
• stop: solicita ao Cosmos que pare o componente indicado;
• connectComponentToConnector: solicita ao Cosmos que conecte as interfaces do
componentes e conector indicados;
• connectConnectorToComponent: solicita ao Cosmos que conecte as interfaces do
conector e componente indicados;
• disconnectComponentToConnector: solicita ao Cosmos que desconecte as interfaces
do componente e conector indicados;
• disconnectConnectorToComponent: solicita ao Cosmos que desconecte as interfaces
do conector e componente indicados;
• block: solicita ao Cosmos que bloqueie o componente, o que indica que o componente
está em processo de adaptação. Esse bloqueio ocorre em nível de modelo;
• unblock: solicita ao Cosmos que desbloqueie o componente;
Figura 14: Interface IAdaptable.
3.2.2
Modelo de Componentes
que foram realizadas na arquitetura e a integração com componentes especializados, foi realizada uma atualização das interfaces do modelo de componentes de maneira que as seguintes interfaces foram unidas: IMonitored com IBasicService e IPropertyConstranint
com IPropertyInquiry.
Figura 15:Modelo de componentes original.
Com a união das interfaces mencionadas e o refinamento dos métodos, apresentamos na Figura 16 a assinatura das interfaces do novo modelo de componentes. Entendendo que obter o valor de uma determinada propriedade pode ser caracterizado por um ser-viço do componente, o método getValue foi movido da antiga interface IMonitored para
IBasicService. O métodoactualizeSelectedValue foi retirado da interfaceIPropertyUpdate, uma vez que assumimos que mudanças de propriedades devem ser realizadas com base noModelManager; as interfacesIPropertyInquiry eIPropertyConstraint foram unidas por tratarem de acesso as propriedades.
Figura 16:Interfaces do modelo de componentes.
A descrição das operações relacionadas com as interfaces apresentadas pela Figura 16 é listada na Tabela 3.
3.2.3
Gerenciador de Modelos
Tabela 3: Descrição dos métodos das interfaces do componente.
Método Descrição Interface IBasicService
getName Retorna o nome do componente.
getInterfaces Retorna uma lista com as interfaces do componente. getValue Obtem o valor de uma propriedade.
Interface IPropertyUpdate
activate Ativa o componente. deactivate Desativa o componente.
activateAdaptation Indica ao componente que ele está em adaptação. changeStateTo Muda o estado de um componente
Interface IPropertyInquiry
getProperties Obtêm uma lista com todas as propriedades de um componente. getProperty Obtém uma propriedade especifica de um componente.
o sistema. Com isso, a mudança no modelo deve ser refletida no sistema e vice-versa, como indicado por (BLAIR; BENCOMO; FRANCE, 2009)(MORIN et al., 2009).
No Cosmos as aplicações são representadas por modelos, baseados no metamodelo apresentado anteriormente na Figura 8, e, esses modelos são gerenciados pelo ModelMa-nager. No gerenciamento, oModelManager realiza toda a validação do modelo de instância baseado-se na estrutura e tipos, como também todas as operações de controle e gerencia-mento. A Figura 17 apresenta a interface que é seguida na construção do ModelManager. Nessa interface encontramos métodos de verificação do estado dos componentes e de con-trole do estado.
(c) Por fim, o Wf.Gen indica o fim da adaptação.
6. Uma vez que os componentes sejam criados, o Configurator instancia um Probe e o associa aos atributos que devem ser monitorados.
O processo de adaptação no Cosmos é apresentado pelo diagrama da Figura 18. Ele é iniciado quando oQoS Manager verifica a necessidade de adaptação, a partir dos dados que foram lido pelos Probes. Uma vez verificado que a leitura não está conforme, o QoS Manager indica ao Configurator que o processo de adaptação deve ser iniciado. A partir da notificação de inicio de adaptação, oConfigurator obtém as arquiteturas de instância e de estrutura, cujas informações devem ser passadas para o seletor de arquitetura ( Mo-SAC). Uma vez selecionada a nova arquitetura pelo seletor de arquitetura, o Configurator
encaminha essa configuração para o gerador de processos (ProcessGenerator) que irá gerar um plano de adaptação e irá executá-lo noConfigurator. O processo é terminado quando o gerador de processo sinalizar com o fim da adaptação; com isso, oConfigurator efetua as mudanças no ModelManager e replica as ações para serem executadas nos componentes concretos.
Figura 18: Processo de adaptação.
3.3
Integração com a Plataforma
OSGi
tomamos como princípio que as aplicações que foram desenvolvidas para serem executadas noframework Cosmos não necessitem de codificação extra quando o Cosmos estiver sendo executado sobre a plataforma OSGi.
Aplicações baseadas em componentes e baseadas em serviços utilizam conceitos dife-rentes, onde a principal diferença é que no modelo de componentes as ligações são estáti-cas enquanto que no modelo baseado em serviços as ligações são dinâmiestáti-cas (DESERTOT; CERVANTES; DONSEZ, 2006). Ao realizar essa integração, assumimos que os componentes Cosmos serão mapeados como serviços na dessa plataforma.
Para usar o OSGi como suporte, foi criado uma extensão do Cosmos contendo fábri-cas de componentes, configurador, probe, e ativador específicos para oOSGi. A Figura 19 mostra a relação entre oframework e sua extensão onde apresentamos o componente Con-figuratorOSGi como responsável por efetuar as atividades do Configurator no ambiente
OSGi; para dar suporte aoConfiguratorOSGifoi necessário criar fábricas específicas ( Fac-toryOSGi) que servem para criar os componentes concretos e publicá-los na plataforma
OSGi. Foi introduzido também um novo tipo de Probe, ProbeOSGi que é implementado como uma especialização da interfaceOSGi ServiceTrackCustomizer. A interface Service-TrackCustomizer é utilizada para monitorar serviços, na plataformaOSGi, possibilitando adicionar ações quando um serviço é adicionado, alterado ou removido.
Figura 19: Especialização do Cosmos para OSGi.
como também um implementação específica para para a plataforma OSGi.
Figura 20:Diagrama da implementação padrão.
Os componentes que compõem as aplicações, no Cosmos, são instanciadas e publica-das como serviçosOSGi, por meio doConfiguratorOSGi. As ligações entre os componentes Cosmos/serviçosOSGi, são tratadas de maneiras distintas, enquanto que no Cosmos as li-gações são explícitas, noOSGi as ligações são implícitas. Para poder lidar com a diferença no tratamento das ligações, passamos a responsabilidade da ligação para o Configurato-rOSGi, o qual, utiliza o mecanismo de busca da plataforma OSGi. Na busca são utiliza-dos o tipo do componente/serviço e sua identificação. Essa identificação é adicionada ao serviço OSGi, no momento da publicação do serviço, e corresponde ao identificador do componente Cosmos.
O estado associado ao bundle, descrito no capítulo 2, influencia os componentes Cos-mos, pois, uma vez que umbundle é parado, todos os seus serviços também são parados. A Tabela 4 apresenta a relação entre o ciclo de vida de um bundle e um componente OSGi. Um componente é consideradoInstantiated no Cosmos quando todas as dependências es-tão disponíveis e o componente pode ser instanciado, esse comportamento é semelhante a instalação de umbundle OSGi, nesse momento o componente é carregado na plataforma e o bundle passa por uma validação de suas dependências, estados Installed e Resolved
respectivamente. Uma vez que o componente Cosmos seja instanciado, ele passa por uma etapa de configuração, a qual define todos os seus atributos, e por fim a alocação de todos os recursos necessários ao seu funcionamento; de maneira semelhante na plataformaOSGi
a configuração do bundle é realizada no momento em que ele está sendo iniciado, estado
atualizar os componentes, a nível de modelo, e que indique a necessidade de adaptação ocasionada pela parada de um bundle.
Tabela 4: Relação entre os ciclos de vida do Cosmos e OSGi.
Componente Cosmos Bundel OSGi Instantiated Installed
Resolved
Configured Starting
Allocated
Running Active
Finishing Stopping
Released Unistalled
O monitoramento na mudança dos estados em umbundle é realizado através do Probe-OSGi. Assim, quando umbundle é parado na plataforma OSGi, oProbeOSGi informa ao
ConfiguratorOSGique os componentes contidos nobundletambém pararam. Uma vez que oConfiguratorOSGi é informado da parada dos componentes, ele inicia uma adaptação da aplicação. De maneira semelhante, quando um bundle é desinstalado, o ProbeOSGi deve informar aoConfiguratorOSGi que os componentes associados aobundle foram removidos e o ConfiguratorOSGi deve iniciar uma adaptação da aplicação.
3.4
Integração com gerador de processos
Na busca de tornar o processo de adaptação aberto no Cosmos, introduzimos a inter-faceIPlanGen, que é utilizada para iniciar o processo de geração de planos de adaptação. Para essa integração utilizamos oframework de geração de processos definido por (SILVA, 2011) que utiliza técnicas de inteligência artificial eworkflows na geração e execução dos planos.
Uma vez que o plano é gerado, o framework de geração de planos utiliza a interface
IAdaptablepara enviar os comandos necessários para alcançar a arquitetura desejada. Essa interface é disponibilizada na forma de umWeb service pelo Cosmos. Na realização dessa integração alguns artefatos devem ser gerados, como apontado (SILVA, 2011) e brevemente descritos nos parágrafos seguintes.
encontramos os tipos: componente (component), conector (connector), interface requerida (requiredInterface) e interface provida (provideInterface); e os predicados: componente conectado a conector (connectedComponentConnector), conector conectado a componente (connectedConnectorComponent), requer (requires), prover (prover), bloqueado (blocked) e em execução (running). Esses predicados são utilizados pelo framework de geração de processos para compor os planos de adaptação, ou seja, uma vez que um plano seja gerado ele representará cada componente e cada operação por meio desses predicados.
Figura 21:Modelo de domínio PDDL.
Uma vez definido o modelo de domínio PDDL, definimos as regras de transformação do modelo específico de domínio em modelos de problema PDDL. Essa transformação segue o padrão de transformação MDE (JOUAULT et al., 2008). Por fim, foi definido o conjunto de templates de tarefas que são utilizadas pelo gerador de processos. Essas tarefas são apresentadas na Tabela 5 e são equivalentes aos métodos apresentados pela interface IAdaptable.
Tabela 5: Lista de templates de tarefa.
Tarefa Descrição
connectComponentConnector Conecta um componente a um conector
connectConnectorComponent Conecta um conector a um componente
disconnectComponentConnector Desconecta um componente de um conector
disconnectConnectorComponent Desconecta um conector de um componente
startcomponent Inicia um componente específico
stopcomponent Para um componente específico
block Bloqueia o componente específico
unblock Desbloqueia o componente específico
removecomponent Remove da arquitetura o componente específico
Nela identificamos o componente pelo parâmetro ?C, a precondição dessa tarefa é que o componente não pode estar bloqueado e a pós-condição da tarefa é que o componente deverá estar bloqueado.
Figura 22: Template para a tarefa bloquear um componente.
3.5
Sumário do capítulo
Esse capítulo apresentou a reengenharia do Cosmos e integração com a plataforma
4
Prova de Conceito
Este capítulo descreve como foi realizada a instanciação do framework Cosmos apon-tando os elementos necessários na instanciação e como se dá o processo de implantação de uma aplicação no Cosmos. O capítulo discute algumas dificuldades encontradas e limi-tações de nossa implementação. Nesse sentido, o texto aponta como essas questões foram tratadas.
Um dos objetivos desse capítulo, além da instanciação, é comprovar seu uso por meio de uma aplicação simples de transmissão de vídeo. Através dessa aplicação, poderemos comprovar a interação do Cosmos com os componentes integrados, e verificar sua viabili-dade, no que se refere-se a adaptação.
4.1
A Instanciação do Cosmos
O Cosmos foi proposto para ser uma base para o desenvolvimento de aplicações mul-timídia distribuídas, como aponta (LOPES, 2006), e uma vez instanciado se torna uma plataforma para execução de aplicações baseadas em componentes. Nesse sentido o Cos-mos define um modelo de componentes, que foi apresentado no capítulo 3, que deve ser usado como base de construção dos componentes que compõem as aplicações. Uma vez que as aplicações estejam em execução, o Cosmos utiliza de componentes especializados no monitoramento e adaptação das aplicações, caso seja necessária alguma mudança.
Inicialmente verificamos como seria a integração do Cosmos com o Wf.Gen, seguindo a metodologia apresentada por (SILVA, 2011). Essa integração deve ser realizada através de uma interface WSDL, disponibilizada pelo Cosmos através do Configurator, que dê suporte a obtenção da configuração estrutural, configuração de instância e execução das tarefas do plano gerado. Além disso, foi criado um componente simples que simula a geração e execução do plano.
integração com o MoSAC, a qual deve ser baseada em (SILVA, 2011). Para realizar essa integração foi identificado que teríamos que realizar mudanças no MoSAC de maneira que ele passasse a usar o metamodelo do Cosmos ou um mecanismo de tradução do nosso metamodelo para o usado no MoSAC. Com isso, criamos um componente que armazena estaticamente algumas configurações, de maneira a validar o funcionamento do Cosmos.
OQoS Manager passou a ser tratado como um componente externo ao Cosmos, para tal, foi criada uma interface que é consumida pelo Configurator. As atividades de con-figuração e gerenciamento, dos elementos monitorados, são realizadas pelo Configurator. Enquanto que a leitura dos valores, junto aos elementos monitorados, é realizada pelos
Probes.
Uma vez realizada essas mudanças no Cosmos, para que sejam realizados os procedi-mentos de adaptação das aplicações em execução, o Cosmos deve interagir com compo-nentes especializados para cada fase dofeedback control loop. Essa interação é apresentada pela Figura 10 apresentada no Capítulo 3 e a relação entre os componentes especializados e as fases do feedback control loop é apresentada na tabela 4.1. As leituras das proprie-dades são realizadas pelosProbes que informam ao QoS Manager o valor obtido. O QoS Manager mantem uma tabela com informação dos elementos monitorados e as faixas de valores esperados, uma vez que ele identifica que uma leitura está fora da faixa aceitável, ele informa ao Configurator, indicando o elemento (componente) que deve ser corrigido. Com isso, o Configurator solicita ao MoSAC que encontre uma nova configuração para a aplicação. A partir da nova configuração, o Configurator inicia o processo de geração e execução do plano de adaptação, realizadopelo Wf.Gen. Nesse processo oWf.Gen solicita as configurações arquiteturais ao Configurator e uma vez criado o plano de adaptação o
Wf.Gen executa-o através doConfigurator.
Tabela 6: Relação entre componentes especializados e fases dofeedback control loop
Componente Fase Descrição
Probe Coleta Monitoramento e coleta de dados.
QoS Manager Análise Analise dos dados coletados e verificação de necessidade de adaptação.
MoSAC Decidir Encontrar uma nova configuração.
Wf.Gen Decidir e Atuar Gerar e executar o plano de adaptação.
4.1.1
Componentes externos
O uso de componentes externos nas atividades de gerenciamento de QoS, seleção de configuração arquitetural e geração de planos de adaptação torna flexível a interação desse conjunto com o Cosmos. Com isso, novos componentes que atuem em uma das atividades apresentadas, podem ser utilizados pelo Cosmos desde que eles forneçam as interfaces es-peradas pelo Cosmos. A seguir apresentamos a implementação dos componentes externos utilizados na validação do nosso trabalho.
O QoS Manager, apresentado pela Figura 23, foi baseado em (AMARO et al., 2005) e (LOPES et al., 2006) e ele deve manter uma lista de monitores. Esses monitores devem ser associados às propriedades que devem ser monitoradas, definido-se por um par de valores que formam uma faixa de valores aceitáveis. Dessa forma, oConfigurator utiliza a interface do QoS Manager para informar as propriedades e faixas de valores dos componentes que devem ser monitorados. As leitura das propriedades são realizadas pelos Probes que informam aoQoS Manager o valor obtido. Uma vez que o valor lido está fora da faixa de aceitação é indicado ao Configurator que o processo de adaptação deve ser iniciado.
Figura 23: Webservice para controle de QoS.
A partir da necessidade de adaptação o Configurator acessa o componente ArchSe-lector, Figura 24, que foi criado para ser utilizado no lugar do MoSAC. Esse componente simula o processo de escolha de uma nova configuração arquitetural. Ele é acessado através da interface IArchSelector e tem como entradas a configuração arquitetural de instância atual e a sua estrutura. De acordo com a configuração arquitetural de instância obtida, o componente retorna uma nova configuração arquitetural.
desconecta-Figura 24: Webservice para seleção de configuração arquitetural.
dos. Em seguida, os componentes da nova configuração são conectados e ativados. Esse processo foi implementado através de um componente, Figura 25, que simula o gerador de processos, e utiliza a interface providas peloConfigurator para adaptar o sistema. Assim, do ponto de vista do Configurator, um plano de adaptação pode ser considerado como definido fora do Cosmos.
Figura 25: Webservice para geração do plano de adaptação.
4.1.2
Protótipo
Na validação do uso da arquitetura, foi criada uma aplicação de transmissão de vídeo que contêm três componentes, Figura 26. O consumer1 é o responsável por apresentar o vídeo que está sendo transmitido pelos componentesproducer1 e producer2. Vinculado aos componentesproducer1 eproducer2 está o mesmo vídeo com qualidades diferentes. A comunicação entre os componentes é realizada pelo conectormediaConnector.
Figura 26:Visão da aplicação de transmissão de vídeos.
De acordo com o metamodelo, a representação dessa aplicação deve conter desde sua estrutura até as instâncias, com isso apresentamos a descrição do componente consumer1
