Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras
-
Upload
joao-victorino -
Category
Technology
-
view
74 -
download
0
Transcript of Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras
![Page 1: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/1.jpg)
Arquitetura de software auto-reconfigurável utilizando
Middleware reflexivo e motor de regras
João Henrique Victorino
Orientador: Prof. Dr. Julio Arakaki
![Page 2: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/2.jpg)
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
![Page 3: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/3.jpg)
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)
![Page 4: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/4.jpg)
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
![Page 5: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/5.jpg)
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
![Page 6: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/6.jpg)
Método de trabalho
![Page 7: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/7.jpg)
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
![Page 8: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/8.jpg)
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)
![Page 9: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/9.jpg)
Níveis de autonomia
Evolução da autonomia em sistemas Adaptado de (MULLER, O'BRIEN, et al., 2006)
![Page 10: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/10.jpg)
Sistemas autônomos e computação autonômica
Modelo técnico da computação autonômica Fonte: (Huang, et al., 2004)
![Page 11: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/11.jpg)
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)
![Page 12: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/12.jpg)
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)
![Page 13: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/13.jpg)
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)
![Page 14: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/14.jpg)
Ciclo de controle do processamento
Ciclo de controle em sistemas autonômicos Fonte: (Brun, et al., 2009)
![Page 15: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/15.jpg)
Ciclo de controle do processamento
Ciclo MAPEFonte: elaborado pelo autor
![Page 16: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/16.jpg)
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
![Page 17: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/17.jpg)
Monitoração
Requisitos transversaisFonte: (Ju & Bo, 2007)
![Page 18: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/18.jpg)
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)
![Page 19: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/19.jpg)
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)
![Page 20: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/20.jpg)
Análise e decisão
IF (TempoResposta > 2 seg) THEN (Aumentar CPU em 5%)
![Page 21: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/21.jpg)
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).
![Page 22: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/22.jpg)
Análise e decisão
Elementos de um motor de regrasAdaptado de (CHENG, LEMOS, et al., 2009)
![Page 23: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/23.jpg)
Reconfiguração
Tipos:
• Sistêmica ou infraestrutura
• Aplicacional
– Parametrização
– Componentização
– Arquitetural
![Page 24: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/24.jpg)
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)
![Page 25: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/25.jpg)
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;
![Page 26: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/26.jpg)
Reconfiguração
Árvore de componentes de uma arquiteturaFonte: Elaborado pelo autor
![Page 27: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/27.jpg)
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)
![Page 28: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/28.jpg)
Middleware reflexivo
Modelo técnico da computação reflexivaFonte: (Huang, et al., 2004)
![Page 29: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/29.jpg)
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.
![Page 30: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/30.jpg)
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.
![Page 31: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/31.jpg)
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))
![Page 32: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/32.jpg)
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.
![Page 33: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/33.jpg)
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).
![Page 34: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/34.jpg)
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).
![Page 35: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/35.jpg)
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)
![Page 36: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/36.jpg)
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.
![Page 37: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/37.jpg)
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)
![Page 38: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/38.jpg)
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.
![Page 39: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/39.jpg)
Experimento
• Interpolador das curvas de risco e contábeisda tesouraria do banco
![Page 40: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/40.jpg)
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;
![Page 41: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/41.jpg)
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.
![Page 42: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/42.jpg)
Experimento
![Page 43: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/43.jpg)
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.
![Page 44: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/44.jpg)
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.
![Page 45: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/45.jpg)
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.
![Page 46: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/46.jpg)
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.
![Page 47: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/47.jpg)
Projeto
![Page 48: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/48.jpg)
Projeto (Configuração em baixa demanda)
![Page 49: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/49.jpg)
Projeto (Configuração em alta demanda)
![Page 50: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/50.jpg)
Implementação
![Page 51: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/51.jpg)
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)
![Page 52: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/52.jpg)
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
![Page 53: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/53.jpg)
Base de dados da arquitetura
• Garantia da entrega do pedido deprocessamento
• Facilidade de reproduzir as chamadas, senecessário
• Auditoria e segurança
![Page 54: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/54.jpg)
Base de dados da arquitetura
* Foi utilizado o banco de dados SQL Server 2012 com aconfiguração In-Memory OLTP
![Page 55: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/55.jpg)
Unity Configuração
![Page 56: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/56.jpg)
Unity Configuração
![Page 57: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/57.jpg)
Regra em alta demanda
![Page 58: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/58.jpg)
Regra em baixa demanda
![Page 59: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/59.jpg)
Análise resultados em alta demanda
![Page 60: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/60.jpg)
Análise resultados em alta demanda
![Page 61: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/61.jpg)
Análise resultados em alta demanda
![Page 62: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/62.jpg)
Análise resultados em baixa demanda
![Page 63: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/63.jpg)
Análise resultados em baixa demanda
![Page 64: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/64.jpg)
Análise resultados em baixa demanda
![Page 65: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/65.jpg)
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
![Page 66: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/66.jpg)
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
![Page 67: Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras](https://reader030.fdocument.pub/reader030/viewer/2022032714/55abba121a28abec1b8b45cc/html5/thumbnails/67.jpg)
Experimento
http://selfadaptmiddleware.codeplex.com/
Versão atual do código fonte disponível em: