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, o Configurator 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 ao QoS 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.
Como nosso objetivo é realizar a reengenharia do Cosmos para permitir sua integração com o framework de geração de processos, estamos adotando uma abordagem baseada na reimplantação de aplicação como maneira de realizar uma adaptação. Desse modo, durante a adaptação, uma aplicação é completamente desativada e seus componentes 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 pelo Configurator 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 componentes producer1 e producer2. Vinculado aos componentes producer1 e producer2 está o mesmo vídeo com qualidades diferentes. A comunicação entre os componentes é realizada pelo conector mediaConnector.
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 na Figura 27, que é seguida para os demais componentes. A descrição contem três re- giões para especificação dos tipos (metamodel:MyArchTypes) da linha 3 até a linha 6, estrutura (metamodel:MyArchStructure) da linha 7 até a linha 16, e instancia (metamo- del:MyArchInstance) da linha 17 até a linha 27. Na estrutura do componente consumer1
A verificação dos estados de um componente é realizada através dos seguintes méto- dos: isRunning: indica se o componente está sendo executado; isRegistered: indica se o componente já foi registrado; isBlocked: indica se o componente está bloqueado; isBound: indica se a interface de um componente está conectada; isConnectedComponentToCon- nector : indica se o componente está conectado ao conector através das suas interfaces; e isConnectedConnectorToComponent: indica se o conector está conectado ao componente através das suas interfaces;
O controle dos componentes é realizado através dos seguintes métodos: getArchIns- tance, getArchStructure: obtém a arquitetura de instância e estrutural da aplicação; get- ComponentInstance: obtém um componente que foi adicionado à arquitetura de instância; addComponent, removeComponent: adiciona e remove um componente à arquitetura de instância; blockComponent, unblockComponent: bloqueia e desbloqueia um componente; startComponent, stopComponent: inicia e para um componente; connectComponentTo- Connector, disconnectComponentToConnector : conecta e desconecta um componente a um conector; e connectConnectorToComponent, disconnectConnectorToComponent: co- necta e desconecta um conector a um componente;
A instanciação de uma aplicação é realizada no Cosmos seguindo os seguintes passos:
1. É solicitado ao Configurator que processe o arquivo descritor da aplicação;
2. O Configurator solicita ao ModelManager que processe o arquivo descritor, com isso, o ModelManager faz a carga dos modelos contidos no arquivo, resultando em um modelo estrutural e um modelo de instâncias da aplicação;
3. Uma vez que os modelos sejam carregados, o Configurator solicita ao MoSAC que selecione uma configuração arquitetural para a aplicação, de acordo com os modelos carregados anteriormente;
4. Após a solicitação ao MoSAC, o Configurator inicia uma adaptação que terá como configuração arquitetural inicial uma arquitetura vazia, essa solicitação e realizada ao Wf.Gen;
5. O Wf.Gen então gera um plano de adaptação e o executa com o auxílio da interface IAdaptable;
(a) o Wf.Gen solicita ao Cosmos que sejam criados todos os componentes;
(b) Uma vez criados os componentes, o Wf.Gen solicita ao Cosmos que conecte os componentes
é apontado seu tipo pela referência consumer1Type, além de suas interfaces. As demais definições são semelhantes a apresentada do componente consumer1.
Figura 27: Descrição do componente consumer.
O envio do fluxo multimídia dos produtores ao consumidor é realizado através do co- nector MediaConnector que é formado por duas interfaces, iInput e iOutput, responsáveis por obter e transferir o fluxo multimídia entre os componentes.
A conexão dos componentes é realizada através do conector a partir de suas interfaces, a descrição dessa ligação é apresentada na Figura 28. A ligação do consumer1 ao connector é realizada através do link entre as interfaces iOutput do conector e IInputMedia do consumer1.
Na inicialização do Cosmos são instanciados e conectados todos os componentes en- volvidos: QoSManager, ArchSelector, PlanGen, ModelManager e as fábricas de recursos virtuais. Para sua utilização foi gerado uma interface gráfica com o intuito de facilitar sua utilização, Figura 29. A partir da interface gráfica podemos carregar a descrição da aplicação, executá-la e pará-la. Ao iniciar a aplicação o Configutator solicita que o Mo- delManager processe o arquivo de descrição da aplicação, o que resulta com a carga do modelo. Com o modelo o Configurator obtêm todos as instâncias dos Recursos Virtuais que devem ser criados e ativados.
Figura 29: Interface gráfica do Cosmos.
Uma vez que sejam ativados os componentes da aplicação são apresentadas duas janelas que representam o producer1 e o consumer1, Figura 30. O producer1 inicia a transmissão de um vídeo, que foi configurado por uma propriedade no modelo, que é apresentado no consumer1. A simulação de necessidade de adaptação é realizada através do botão Adapt, o qual, sinaliza que o consumer1 encontra-se em um estado não desejado através de uma flag contido nele.
Ao iniciar uma adaptação, o Cosmos deve obter uma nova configuração arquitetural que é utilizada na geração do plano de adaptação. A Figura 31 mostra um resumo de uma adaptação realizada no protótipo. No primeiro bloco da figura encontramos o momento no qual o Probe informa da necessidade de adaptação ao Configurator (BEGIN ADAPTA- TION ). A partir da necessidade o Configurator obtêm uma nova configuração arquitetural (GETTING NEW ARCHINSTANCE ). Com a nova configuração o Configurator informa ao gerador de processos que existe a necessidade de adaptação(GENERATING NEW
Figura 30: Janelas dos recursos virtuas do protótipo.
PLAN ). As ações apresentadas no bloco 2 e 3 são realizadas pelo gerador de planos no Cosmos através da interface IAdaptation; as ações do segundo bloco são realizadas com base na configuração atual e as ações do terceiro bloco são realizadas com a configuração desejada. Ao terminar de executar as ações de adaptação o gerador de processos indica ao Configurator (END ADAPTATION ) para que o processo seja finalizado.
Figura 31: Resumo do log contendo as atividade de adaptação.
4.2
A Instanciação do Cosmos sobre o OSGi
A plataforma OSGi é formada por um conjunto de especificações, encontradas em (ALLIANCE, a), que deve ser seguida em suas implementações. Diversas implementações
estão disponíveis como apontamos no Capítulo 2. Com isso, o primeiro passo que seguimos foi definir qual implementação seria utilizada.
Inicialmente adotamos a implementação open source Knopflerfish. Essa implementa- ção utiliza um conjunto de bundles que possibilita o gerenciamento, do próprio ambiente e dos bundles que estão implantados, a partir de uma interface gráfica. Também é dispo-
nibilizado em sua homepage um conjunto de documentos que auxiliam o seu uso. Porém, uma vez que iniciamos o seu uso, verificamos que o framework EMF, utilizado na mani- pulação do nosso metamodelo, tem uma dependência direta a bundles do núcleo de outra implementação, o que nos levou a desistir do Knopflerfish. A partir da dificuldade inicial com o Knopflerfish, passamos a adotar a implementação Equinox. A partir dessa escolha, foi realizada uma pesquisa e escolha de bundles, com o intuito de facilitar o seu uso.
Uma vez que entendemos que a execução do Cosmos deve ser realizada tanto sobre a plataforma OSGi como não, foi adicionado um arquivo MANIFEST.MF que é lido pela plataforma. Na figura 32 é apresentada o conteúdo do arquivo MANIFEST.MF, o qual, define os pacotes que serão disponibilizados na plataforma, os pacotes que são requeridos na implantação do Cosmos, a classe responsável por inicializar e configurar o Cosmos, dentre outras configurações. A classe que é responsável pela inicialização do Cosmos é a CosmosActivator. É a partir do CosmosActivator que é instanciado o ConfiguratorOSGi, que recebe do CosmosActivator o contexto da plataforma. Com o contexto da plataforma, o ConfiguratorOSGi pode instanciar os demais componentes. Cada componente que é criado pelo ConfiguratorOSGi é monitorado por um ProbeOSGi, o qual é responsável por avisar mudanças no ciclo de vida do bundles.
Figura 32: Listagem do arquivo MANIFEST.MF do Cosmos.
A partir do contexto da plataforma, são realizadas operações sobre os bundles e com- ponentes/serviços, o que auxilia na busca das instâncias que formam uma aplicação. Nessa pesquisa são utilizados o identificador do componente e seu tipo, normalmente a interface que ela realiza. De acordo com a especificação, essa pesquisa utiliza o formato utilizado no LDAP1
, como exemplo: (objectClass=MinhaInterface)(id=id do componente).
1
4.2.1
Sumário do capítulo
Esse capítulo apresentou um exemplo de instanciação do Cosmos e de uma aplicação. Para tal, foram definidos componentes para o gerenciamento de QoS, para seleção de configuração arquitetural e geração de planos de adaptação. Também foi apresentada uma aplicação de transmissão de vídeo para teste de conceito.
Ao instanciar o Cosmos e executar uma aplicação, vimos que as atividades relaci- onadas a adaptação foram executadas como planejadas. Um ponto de preocupação é a dependência de componentes especializados externos ao Cosmos, pois, eles são indispen- sáveis no processo de adaptação, com isso, fatores que influenciem a comunicação entre o Cosmos e esses componentes devem ser levados em consideração.
Outro ponto abordado foi a instanciação do Cosmos sobre a plataforma OSGi, a qual, foi encontrada uma dependência com a implementação Equinox. Essa dependência ocorreu devido o uso do framework EMF que tem dependência com bundles do núcleo dessa implementação. Contudo, uma vez que o Cosmos foi instanciado, a aplicação teste conseguiu executar sem a necessidade de adicionar código. Com isso, conseguimos alcançar a premissa de tornar transparente aos componentes Cosmos, a forma de instanciação do Cosmos.