Arquitetura de software auto-reconfigurável utilizando

Middleware reflexivo e motor de regras

João Henrique Victorino

Orientador: Prof. Dr. Julio Arakaki

Estrutura de apresentação• Motivação

• Objetivo

• Resultados esperados e contribuições

• Método de trabalho

• Fundamentos conceituais

• Estado da arte

• Proposta de uma arquitetura auto-adaptativa

• Exemplo de uma arquitetura auto-adaptativa

• Análise dos resultados

• Conclusão

Motivação

• Software mais complexo e que exigem maiorconhecimento dos seus administradores(Garcia, et al., 2011)

• Falhas por erro humano (Neti & Müller, 2007)

• As duas maiores dificuldades, os pontos devariabilidade do sistema para a reconfiguraçãoem tempo de execução e a tomada de decisãoque o sistema deve executar sobre asreconfigurações (CYBENKO, BEHRE, et al.,2006)

Objetivo

• Arquitetura auto-reconfigurável

• Reagir ou até antecipar situações desfavoráveis

• Pouco invasiva aos componentes de negócio

• Implementar a auto-reconfiguração através daflexibilidade do contêiner de inversão dedependência, da monitoração facilitada pelaprogramação orientada a aspectos e da análise etomada de decisão suportada por um motor deregras

Resultados esperados e contribuições

• Obtenção de um modelo arquitetural auto-reconfigurável pouco invasivo aoscomponentes

• Evitar comportamento inesperado daaplicação em virtude da combinação decomponentes em tempo de execução

• Melhorar o tempo de resposta do software amudanças no ambiente

Método de trabalho

Fundamentos conceituais

• Sistemas autônomos e computação autonômica

• Arquitetura de software

• Requisitos não-funcionais

• Auto-reconfiguração– Ciclo de controle do processamento

– Monitoração

– Análise e decisão

– Reconfiguração

Sistemas autônomos e computação autonômica

• Sistemas que adaptam-se conforme anecessidade utilizando um processo para isso,e contando com pouca ou nenhumaintervenção humana (Ertle, et al., 2010) e(Huang, et al., 2004)

• Software autônomo não é algo novo na áreada robótica e IA (Kramer & Magee, 2007)

Níveis de autonomia

Evolução da autonomia em sistemas Adaptado de (MULLER, O'BRIEN, et al., 2006)

Sistemas autônomos e computação autonômica

Modelo técnico da computação autonômica Fonte: (Huang, et al., 2004)

Arquitetura de software

• Uma estrutura, decomposta em partes, narelação entre elas e nas propriedades visíveisexternamente que essas partes apresentam(Bass, et al., 2003)

• É a junção de todos os componentes, que fazemparte da arquitetura, que determinam se umsistema atende a um determinado requisito(BRAT, DENNEY, et al., 2006).

• Os atributos de qualidade da arquitetura sãoalcançados através das táticas arquiteturais, quesão as decisões de modelagem da arquitetura(Bass, et al., 2003)

Requisitos não-funcionais

• RNF e RF são definidores e validadores daarquitetura de software (Bass, et al., 2003)

• Decisões arquiteturais impactam diretamentena autonomia do software (Fuad &Oudshoorn, 2007)

• Software autônomo necessita de alguns RNFsque outros softwares não necessitam, pois sãomais dinâmicos (Neti & Müller, 2007)

Requisitos não-funcionais

• O atributo de qualidade mais importante paraum sistema auto-reconfigurável é a facilidadede alteração, que está subdividido nacapacidade do sistemas em ser extendido eem ser modificado, pois estes sistemasprecisam estar componentizados empequenas partes em virtude da necessidadede dinamismo (NETI e MÜLLER, 2007)

Ciclo de controle do processamento

Ciclo de controle em sistemas autonômicos Fonte: (Brun, et al., 2009)

Ciclo de controle do processamento

Ciclo MAPEFonte: elaborado pelo autor

Monitoração

• Qual informação é mais relevante para ocomportamento que deseja-se obter dosoftware? (Vassev & Hinchey, 2010)

• A monitoração deve ser simples e rápida paraque não afete a modelagem e o desempenhodo software, também deve prover informaçãoatualizada (Zheng, 2010)

• Requisito transversal

Monitoração

Requisitos transversaisFonte: (Ju & Bo, 2007)

Monitoração

AOP (Aspect Oriented Programming) é umatécnica capaz se separar os requisitostransversais dos outros módulos, de modoque o código fique modularizado e permiteque cada funcionalidade fique concentradaonde deve e não espalhada pelo software (Ju& Bo, 2007)

Análise e decisão

• Para alguns softwares a maior dificuldade ésaber qual é o estado desejado, e caso esteestado seja claro, saber quais modificações naarquitetura são necessárias para que osoftware deixe do estado atual e para oestado desejado (Kramer & Magee, 2007)

• Este tipo de controle pode ser implementadopor regras (Vassev & Hinchey, 2010)

Análise e decisão

IF (TempoResposta > 2 seg) THEN (Aumentar CPU em 5%)

Análise e decisão

Motor de regras:

• É uma DSL (Domain Specific Language) própriapara regras e extensível

• Pode ser modelada por uma ferramenta visual

• A idéia de motor de regras é externalizar alógica de negócio, o motor de regras pode servisto como um sofisticado interpretador dedeclarações IF-THEN (CHEN, XU-PENG eZHENG-QIU, 2010).

Análise e decisão

Elementos de um motor de regrasAdaptado de (CHENG, LEMOS, et al., 2009)

Reconfiguração

Tipos:

• Sistêmica ou infraestrutura

• Aplicacional

– Parametrização

– Componentização

– Arquitetural

Reconfiguração

Componentização:

• Implementação passiva de um conjunto defuncionalidades com uma interface específica,e que passa a ter algum tipo atividade quandoum processo o executa, sendo um processouma representação dos recursos físicos deCPU (Central Process Unit) e memória (Bellur& Narendra, 2006)

Reconfiguração

• Contêiner de injeção de dependência

– Controle a execução dos componentes;

– Mapeamento dos componentes;

– Mantém o estado da aplicação consistente pois varia entre diferentes tipos de árvores de objetos;

Reconfiguração

Árvore de componentes de uma arquiteturaFonte: Elaborado pelo autor

Middleware reflexivo

Middleware Reflexivo é a união das habilidades

da computação distribuída e a capacidade de

reconfiguração, em tempo de execução, que a

reflexão proporciona (Garcia, et al., 2011)

Middleware reflexivo

Modelo técnico da computação reflexivaFonte: (Huang, et al., 2004)

Estado da arte• Meehan, Prasad e Mcginnity, 2007. ADAF

Framework que trouxe mais complexidade,pois os componentes podem ser trocadosdinamicamente e isoladamente.

• Bellur e Narendra, 2006. Uma arquitetura queconsegue carregar componentes de umrepositório.

• Zhang, Qu e Liu, 2006.

• Palma, Popov et al., 2009. Arquitetura dereconfiguração na infraestrutura e não nasolução.

Estado da arte• Calinescu, 2007. Utiliza MDA, onde na

modelagem são definidos os requisitos dereconfiguração, porém não fica claro se poderáser feita uma reconfiguração em tempo deexecução.

• Ju e Bo, 2007. Arquitetura de serviçosreconfiguráveis com IoC e AOP, porém asreconfigurações não são feitas em tempo deexecução.

• Wu, Wu et al., 2010. Framework Fractal, onde osistema legado precisou ser refatorado paraalcançar maior autonomia.

Arquitetura de software reconfigurável

• Requisitos funcionais, não funcionais etécnicos que definem uma soluçãoarquitetural (CORDEIRO MARTINS, 2010)

• A auto-reconfiguração é um estiloarquitetural, e como tal, deve vir a partir dasnecessidades de negócio.

• ISO 9126 (lista de atributos de qualidade paraprodutos e serviços)

• Manutenibilidade (Modificabilidade egerenciabilidade (PARASHAR e HARIRI, 2007))

Arquitetura de software reconfigurável

• Maior benefício é durante a operação dosoftware, devido as alterações decomportamento do mesmo, conforme oambiente e sem supervisão.

• Reconfiguração funcional e arquitetural(PARASHAR e HARIRI, 2007)

• Requisitos não funcionais devem ser levados emconsideração em virtude da reconfiguração,como, transação, concorrência, segurança, entreoutros.

• Extensibilidade em tempo de execução enaturalmente em tempo de modelagem.

Pontos de variabilidade• Um ponto de variabilidade é uma conexão ou a

dependência entre componentes em uma sequênciade execução onde a reconfiguração pode ser acionada(BELLUR e NARENDRA, 2006).

• Os pontos de variabilidade dependerão de quaisrequisitos funcionais e não funcionais serão alteradosdurante a reconfiguração, pois alguns requisitos podemser atingidos apenas alterando o pool de threads doservidor web, ou poderá ser necessária a substituiçãode um componente da aplicação, estes tipos dereconfiguração podem ser feitas no nível de sistema,como uma parametrização de infraestrutura, ou nonível aplicacional como a parametrização ousubstituição de um componente da aplicação (ZHANG,QU e LIU, 2006).

Pontos de variabilidade• Linguagens, padrões, frameworks e arquiteturas foram

desenvolvidos para facilitar a reconfiguração, entretantoestas técnicas necessitam que o sistema seja modelado jápensando nos pontos de variabilidade que terá, pois osistema não conseguirá lidar com isso dinamicamente(BELLUR e NARENDRA, 2006).

• O uso de interfaces da programação orientada a objetos,permite que diferentes componentes implementem amesma interface, desta forma os componentes são domesmo tipo, e existe um contrato de comunicação comeles, definido pela interface, sendo assim ambos oscomponentes podem ter comportamentos diferentes eainda sim serem facilmente substituídos, um pelo outro(BELLUR e NARENDRA, 2006).

Granularidade de componentes

• A granularidade e a forma de modelagem doscomponentes afetam diretamente acapacidade da arquitetura em se reconfigurar

• As estruturas baseadas em componentespermitem uma reconfiguração dinâmicaaltamente granular, sendo que este recursopode ser melhorado utilizando meta dados(PALMA, POPOV, et al., 2009)

Granularidade de componentes

• A abstração permitirá que diferentesimplementações de componentescomuniquem entre si, devendo apenasrespeitar a abstração, que no caso de umalinguagem orientada a objetos podem ser asinterfaces (BELLUR e NARENDRA, 2006).

• Padrões de projeto e princípios de modelagemcomo SOLID podem auxiliar na modelagemcomponentizada tornar-se altamente granular.

SOLID

• Single-responsability principle (Princípio da responsabilidade única)

• Open/closed principle (Princípio aberto/fechado)

• Liskov substituition principle (Princípio de substituição de Liskov)

• Interface segregation principle (Princípio da segregação de interfaces)

• Dependency inversion principle (Princípio da inversão de dependência)

Desempenho X Reconfiguração

• Em uma arquitetura auto-reconfigurável, certosrequisitos não funcionais são trazidos com esta decisão,como a facilidade de modificação que naturalmenteimplica na maior complexidade no desenvolvimento dosoftware.

• O ciclo de processamento de monitoração, análise eexecução requer certo processamento e para minimizarseus impactos no sistema que está sendo gerenciado,este ciclo pode ser feito de forma assíncrona e paralela.

• As desvantagens da reconfiguração devem se pagar pelasvantagens de aumento de escalabilidade edisponibilidade.

Experimento

• Interpolador das curvas de risco e contábeisda tesouraria do banco

Experimento

• As curvas são consumidas por inúmeros sistemasdo banco, desde traders até a área contábil,sendo que os traders, ou seja as curvas de riscode mercado tem prioridade nas requisições damanhã, das 9h às 11h, e da noite, das 19h às 23h,devido a abertura e fechamento do mercado;

• O serviço precisa ter alta disponibilidade eresponder as solicitações de interpolação em até10 segundos para curvas de até 10 anos e quesejam de risco de mercado, mesmo em situaçõesde sobrecarga de requisições, ou seja, até 150requisições no mesmo minuto;

Experimento

• Os horários de pico podem solicitar até 400requisições de interpolação em 5 minutos;

• Sistema atual está respondendo em cerca de20 segundos a interpolação de curvas de 10anos, em sobrecarga de requisições, ou seja,até 150 requisições simultâneas no mesmominuto, sendo que não faz distinção entre ostipos de curvas a serem interpoladas.

Experimento

Requisitos não funcionais

• Disponibilidade – o serviço deverá priorizar requisiçõesde risco de mercado ao invés de requisições de outrasáreas, e se manter disponível nos momentos de pico damanhã, das 9h às 11h, e da noite, das 19h às 23h.

• Modificabilidade – o serviço deve suportar até 150requisições no mesmo minuto e ainda interpolar umacurva de 10 anos em no máximo 10 segundos, paraatingir o requisito de disponibilidade pode sernecessário “desabilitar” a interpolação para outrasáreas e deixar apenas a interpolação disponível para aárea de risco de mercado.

• Desempenho – o serviço deve efetuar o cálculo em até10 segundos para curvas de até 10 anos.

Táticas arquiteturais

• O serviço de cálculo não guardará estado entreuma interpolação e outra, ou seja, não existecompartilhamento de dados entre asinterpolações, seja do mesmo cliente ou deoutros clientes.

• Como não haverá compartilhamento dos dados,o serviço poderá processar as requisições deinterpolação de forma paralelizada.

• O serviço poderá iniciar uma transação nomomento que a requisição chegar ao servidor efinaliza-la quando a interpolação estiver completae a resposta for enviada ao cliente.

Táticas arquiteturais

• O serviço será monitorado a cada 2 segundos paradefinir se o mesmo se encontra em uma situação desobrecarga, ou aumento gradativo de requisições, paraque uma ação de degeneração seja acionada.

• Para descobrir se o serviço está em uma situação dealta demanda, podemos utilizar a quantidade derequisições recebidas no último minuto e o tempomáximo que o serviço está gastando para responder asinterpolações no último minuto.

• Em alta demanda as requisições da área de risco demercado devem ser privilegiadas e as outrasrequisições podem ser desabilitadas, colocando aaplicação em um estado de degeneração parcial com ointuito de atender as requisições prioritárias.

Táticas arquiteturais

• Para que não haja perdas, é interessante que aarquitetura consiga inferir que haverá um aumento dedemanda e degradar seu comportamento, antes que oserviço falhe, ou o mais rápido possível assim quedetectado um aumento de demanda considerável.

• Quando iniciar a diminuição da demanda o serviçodeve voltar ao estado normal e atender a todas asrequisições igualmente, pois a degeneração fará comque o software perca parte de sua qualidade, emvirtude dos requisitos não funcionais e funcionais quenão estarão disponíveis.

Projeto

Projeto (Configuração em baixa demanda)

Projeto (Configuração em alta demanda)

Implementação

Ambiente de infraestrutura do experimento

• Ambiente Microsoft:

– Windows Server 2008 (Servidor)

– Windows 7 (Cliente)

– SQL Server 2012 (Banco de dados)

– IIS 7.5 (Servidor de aplicação)

– .Net Framework 4.0 (Máquina virtual)

– Visual Studio 2010 (Ambiente de desenvolvimento)

Frameworks de desenvolvimento .Net

• Microsoft Enterprise Library 5.0

– Unity (IoC)

– Unity Interception (AOP)

• WCF 4.0 (Windows Communication Foundation)

• WF 4.0 (Workflow Foundation)

• Visual Studio 2010 Test Tools

Base de dados da arquitetura

• Garantia da entrega do pedido deprocessamento

• Facilidade de reproduzir as chamadas, senecessário

• Auditoria e segurança

Base de dados da arquitetura

* Foi utilizado o banco de dados SQL Server 2012 com aconfiguração In-Memory OLTP

Unity Configuração

Unity Configuração

Regra em alta demanda

Regra em baixa demanda

Análise resultados em alta demanda

Análise resultados em alta demanda

Análise resultados em alta demanda

Análise resultados em baixa demanda

Análise resultados em baixa demanda

Análise resultados em baixa demanda

Conclusão

• Auto-reconfiguração e degradação

• Arquitetura e modelo para auto-reconfiguração

• Inclusão gradual da auto-reconfiguração

• Melhora no desempenho, privilégio a um tipo de requisição e aumento da disponibilidade

• Retorno ao estado normal na baixa demanda

Trabalhos futuros

• Única notação para reconfiguração e decisão

• Interface visual de manutenção e depuração

• Outras plataformas além da Microsoft

• Vantagens e desvantagens no uso em Cloud

• Uso em outras áreas de negócio

• Uso de IA no módulo de decisão

Experimento

http://selfadaptmiddleware.codeplex.com/

Versão atual do código fonte disponível em: