MAC5715 - Tópicos Avançados em POO O Padrão Arquitetural Auto-Adaptável Raphael Y. de Camargo e Carlos Alexandre Queiroz 30 de outubro de 2003 1 Intenção O padrão auto-adaptável permite o desenvolvimento de aplicações que se adaptam a mudanças em seu ambiente de execução através de uma arquitetura modular e flexível. Este padrão pode ser aplicado tanto a sistemas centralizados quanto a sistemas distribuídos. 2 Contexto A demanda por sistemas que operem em ambientes altamente dinâmicos e consigam se adaptar a mudanças nas condições desse ambiente, vem crescendo nos últimos anos. Exemplos desses sistemas incluem aqueles presentes em dispositivos móveis, onde a qualidade da comunicação da rede pode sofrer grandes variações em curtos intervalos de tempo, e servidores Web, cuja demanda de requisições costuma variar bastante. Com o passar do tempo, a quantidade de sistemas com este tipo de requisitos apenas tende a aumentar. Técnicas para o desenvolvimento de sistemas com capacidade de adaptar-se a diferentes situações são de grande importância para a indústria de software e vêm recebendo bastante atenção da comunidade acadêmica. Em particular, diversas arquiteturas para o desenvolvimento desses sistemas foram propostas. 3 Problema Ambientes de execução altamente dinâmicos requerem que as aplicações operem em condições bastante variadas. Estas aplicações devem detectar mudanças ocorridas em seu ambiente de execução e realizar os passos necessários para a adaptação. Além disso, para se obter maior flexibilidade, a funcionalidade referente à adaptação deve ser separada do restante da aplicação. Forças O padrão auto-adaptável considera as seguintes forças: Deve haver uma separação dos aspectos relacionados à adaptação do restante da funcionalidade da aplicação; 1
Figura 1: Módulos do padrão auto-adaptável. Deve ser genérico de modo que possa ser aplicado a diferentes situações; Deve poder ser aplicado tanto a sistemas centralizados como distribuídos; 4 Solução Monitorar diferentes parâmetros do ambiente de modo que a aplicação possa se adaptar a mudanças significativas nestes valores. A partir destes parâmetros definir eventos, que são mudanças de estado no ambiente definidas pelo usuário e/ou aplicação. Com base na presença destes eventos, a aplicação pode se adaptar às mudanças ocorridas em seu ambiente de execução. Exemplos de parâmetros incluem o uso de CPU e memória e a disponibilidade de banda na rede. Como exemplos de eventos podemos citar a utilização de um percentual da memória do sistema acima de um determinado valor ou um grande aumento na quantidade de comunicação entre dois componentes da aplicação. 5 Estrutura O padrão arquitetural auto-adaptável é composto por três módulos (Monitor, Analisador e Configurador), além da aplicação que será reconfigurada e do ambiente de execução. Cada módulo é composto por classes que realizam as operações atribuídas aos seus módulos. Estes módulos estão representados na figura 1, onde as setas indicam a dependência entre os módulos. Estes módulos são descritos a seguir. Monitor: Realiza o monitoramento das variáveis de ambiente desejadas; Analisador: Analisa os dados provindos do monitor, checando a presença de eventos; Configurador: Realiza a reconfiguração da aplicação; 2
Figura 2: Diagrama de Sequência. O módulo Monitor é constituído por monitores que acompanham os valores de diferentes parâmetros do sistema, como utilização de memória e CPU, comunicação entre componentes e variáveis de ambiente. Sua função é detectar quando ocorrem mudanças significativas nesses parâmetros. Uma mesma aplicação pode ter diversos monitores atuando simultaneamente. O Analisador é o responsável pela análise dos dados provenientes dos monitores, checando pela presença de eventos. Estes eventos devem ser então comunicados ao Configurador. Este módulo é também responsável por armazenar os eventos que devem ser detectados. O módulo Configurador é o responsável pela realização das modificações na aplicação em decorrência de eventos detectados. Estas modificações podem corresponder desde simples alterações em alguns parâmetros até a substituição ou migração de componentes da aplicação. 6 Dinâmica A dinâmica da arquitetura é apresentada na figura 2. O Monitor realiza a monitoração dos parâmetros que lhe foram atribuídos, notificando o Analisador sempre que ocorre uma mudança significativa nestes valores. Estes dados são analisados no Analisador, que notifica o Configurador sempre que um evento de interesse ocorre. O Configurador realiza então as modificações na aplicação. Pode existir ainda um fluxo de controle na direção oposto, onde o Configurador especifica ao Analisador quais eventos deverão ser detectados. Com base nos eventos definidos, o Analisador sinaliza ao Monitor quais parâmetros devem ser monitorados. A existência deste fluxo depende de quão flexível é a implementação de cada módulo (ver seção 8). 7 Conseqüências A utilização do padrão auto-adaptável numa aplicação traz as seguintes vantagens e desvantagens: Vantagens: 3
Adaptação Dinâmica: Permite a construção de sistemas que se adaptam em tempo de execução a diferentes condições em seu ambiente de execução. Separação de Responsabilidades: Os aspectos relacionados a monitoramento, detecção de eventos e execução de mudanças são separadas da funcionalidade da aplicação. Flexibilidade: O desacoplamento das funcionalidades de adaptação, gera um código mais flexível e fácil de manter. Sistemas Distribuídos: Este padrão pode ser facilmente aplicado a sistemas distribuídos, uma vez que componentes dos módulos podem estar localizados em diferentes máquinas. Desvantagens: Eficiência: A utilização de módulos separados diminui a eficiência com relação a um sistema monolítico devido ao aumento na troca de mensagens. Dificuldade de Implementação: Em alguns casos a arquitetura proposta pode ser mais complicada de implementar do que um sistema onde os mecanismos de adaptação estão inseridos no próprio código. 8 Implementação Monitor: O módulo Monitor pode ser implementado de diversas maneiras. Uma possibilidade é utilizar o padrão de projeto Observer [GHJV95], de modo que o monitor é avisado pelo sistema sobre a mudanças de estado. Uma outra possibilidade é fazer com que classes do Monitor chequem periodicamente o valor dos parâmetros do sistema, enviando os valores para o Analisador. Devese notar que, apesar de normalmente menos eficiente, esta pode ser a única opção caso a aplicação esteja interagindo com um sistema fechado. Um ponto importante é a frequência com que os monitores devem checar os valores dos parâmetros que estão sendo monitorados. Também é preciso definir o quanto um parâmetro deve mudar para que esta mudança seja considerada significativa e seja repassada ao Analisador. Uma possibilidade é definir faixas de valores, onde sempre que o parâmetro muda de faixa, é enviado um sinal para o Analisador com a nova faixa. No módulo Monitor pode-se definir o nível de flexibilidade desejado. Para casos onde não é necessário muita flexibilidade, pode-se implementá-lo utilizando uma única classe que monitora sempre os mesmo parâmetros desejados. Para obter um sistema bastante flexível, pode-se implementar um repositório de monitores, que armazena monitores de diversas funções. Dependendo dos eventos que o Analisador estiver interessado, diferentes combinações de monitores podem então ser ativados. Analisador: O ponto mais importante na implementação deste módulo é a determinação de como implementar regras para detecção de eventos. Uma possibilidade para a implementação é colocar as regras diretamente no código. A vantagem deste método é que ele é bastante simples de ser implementado. Pode se obter uma certa flexibilidade deixando explícitas as variáveis que representam as regras, de modo que os valores dessas variáveis possam ser alterados. Além disso, as regras podem ser substituídas por outras a partir 4
da troca dos componentes que estão realizando a detecção de eventos. Uma outra opção seria utilizar uma linguagem de script ou XML e um interpretador. Este método fornece a maior flexibilidade, permitindo a definição de novas regras em tempo de execução, mas é mais difícil de ser implementado. Configurador: A implementação do módulo Configurador pode ser feita de diversas maneiras. No caso em que desejamos apenas alterar variáveis, a implementação é bastante simples, sendo necessário apenas o envio de uma mensagem para a aplicação. Para casos onde é necessária a substituição de componentes da aplicação, a situação é um mais complexa, podendo ser necessário uma participação ativa da aplicação. Para executar esta troca, é necessário que se utilize um mecanismo que explicite a relação entre os componentes como os ComponentConfigurators [KC00], ou em casos mais simples, utilizar o padrão Strategy [GHJV95]. A escolha do mecanismo apropriado depende do caso. Aplicação: Dependendo do tipo de reconfiguração, pode ser necessário que haja participação da aplicação. Por exemplo, quando um componente é substituído por outro, normalmente é necessário que o estado do componente anterior seja transferido para o novo componente. A determinação dos dados que precisam ser salvos e a reinicialização do novo componente devem ser gerenciadas pela aplicação. Sistemas Distribuídos: O padrão auto-adaptável pode ser facilmente implementado em sistemas distribuídos. Basta colocar cada módulo em um processo separado e realizar comunicação entre eles através de um protocolo de comunicação ou Middleware, como Java RMI ou CORBA. Os módulos podem então ser executados em diferentes máquinas de maneira transparente. 9 Exemplo de Utilização Como exemplo de utilização do padrão arquitetural auto-adaptável, utilizaremos uma aplicação com arquitetura cliente-servidor, onde os clientes enviam requisições para os servidores a uma taxa que varia com o tempo. Os servidores podem ser replicados de modo a poder atender um maior número de clientes simultâneos. Para que o sistema possa implementar e controlar o número de réplicas, módulos Monitor poderiam ser instalados nas máquinas de modo a monitorar a carga na CPU, na memória e no tráfego da rede. Esses dados seriam passados ao Analisador que, sempre que esta carga ultrapassasse um determinado valor, enviaria um sinal ao Configurador, de modo que este possa realizar a replicação do servidor. O oposto ocorreria quando a carga nos computadores fosse muito baixa, com uma diminuição no número de réplicas. A replicação poderia ser feita com o Configurador solicitando à aplicação a criação de uma réplica. De posse desta réplica, o Configurador se encarregaria de encontrar o local para colocá-la e enviaria uma mensagem à aplicação com a localização da nova réplica. 10 Usos Conhecidos O padrão arquitetural auto-adaptável já foi utilizado em diversos trabalhos na área de sistemas adaptativos. O primeiro exemplo é um arcabouço para o desenvolvimentos de aplicações distribuídas adapta- 5
tivas [SEK03b, SEK03a]. Na Universidade do Arizona foi criado um modelo para sistemas adaptativos [HS96] de arquitetura similar ao nosso padrão, com os módulos Monitor e Analisador sendo colapsados em um, além de possuir um sistema adicional para a realização de negociações entre os componentes da aplicação sobre a execução das adaptações. Além disso, o padrão Adaptive Strategy [AB01] pode ser considerada uma especialização de nosso padrão arquitetural, onde é utilizado o padrão Observer para realizar o monitoramento e o padrão Strategy para a realização da adaptação. 11 Padrões Relacionados Adaptive Strategy [AB01]: É uma extensão do padrão Strategy de modo que as diferentes implementações possam ser selecionadas a partir do monitoramento do ambiente de execução. AdapPE [DB03]: Um padrão arquitetural para o desenvolvimento de aplicações adaptativas orientadas a aspectos. As principais diferenças em relação ao nosso padrão estão na organização e tipo de módulos e no uso de programação orientada a aspectos. Referências [AB01] [DB03] Oliver Aubert and Antoine Beugnard. Adaptive strategy design pattern. In Proceedings of KoalaPLoP, 2001. Ayla Dantas and Paulo Borba. Adappe: An architectural pattern for structuring adaptive applications with aspects. In SugarLoafPLOP, Porto de Galinhas, Brazil, August 2003. [GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlisside, editors. Design Patterns. Addison-Wesley Pub Co, 1995. [HS96] [KC00] Matti A. Hiltunen and Richard D. Schlichting. Adaptive Distributed and Fault-Tolerant Systems. International Journal of Computer Systems Science and Engineering, 11(5):125 133, September 1996. Fabio Kon and Roy H. Campbell. Dependence Management in Component-Based Distributed Systems. IEEE Concurrency, 8(1):26 36, January-March 2000. [SEK03a] Francisco J. S. Silva, Markus Endler, and Fabio Kon. Developing adaptive distributed applications: a framework overview and experimental results. In Proceedings of the International Symposium on Distributed Objects and Applications, Sicily, Italy, November 2003. [SEK03b] Francisco J. S. Silva, Markus Endler, and Fabio Kon. A framework for building adaptive distributed applications. In ACM/IFIP/USENIX Middleware 2003 Workshop on Reflective and Adaptive Middleware, pages 110 114, Rio de Janeiro, Brazil, June 2003. 6