Arquitetura de software auto-
reconfigurável utilizando
Middleware reflexivo e motor de
regras
João Henrique Victorino
Ori...
Estrutura de apresentação
• Motivação
• Objetivo
• Resultados esperados e contribuições
• Método de trabalho
• Fundamentos...
Motivação
• Software mais complexo e que exigem maior
conhecimento dos seus administradores
(Garcia, et al., 2011)
• Falha...
Objetivo
• Arquitetura auto-reconfigurável
• Reagir ou até antecipar situações desfavoráveis
• Pouco invasiva aos componen...
Resultados esperados e contribuições
• Obtenção de um modelo arquitetural auto-
reconfigurável pouco invasivo aos
componen...
Método de trabalho
Fundamentos conceituais
• Sistemas autônomos e computação
autonômica
• Arquitetura de software
• Requisitos não-funcionais...
Sistemas autônomos e computação
autonômica
• Sistemas que adaptam-se conforme a
necessidade utilizando um processo para is...
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, na
relação entre elas e nas propriedades visíveis
extername...
Requisitos não-funcionais
• RNF e RF são definidores e validadores da
arquitetura de software (Bass, et al., 2003)
• Decis...
Requisitos não-funcionais
• O atributo de qualidade mais importante para
um sistema auto-reconfigurável é a facilidade
de ...
Ciclo de controle do processamento
Ciclo de controle em sistemas autonômicos
Fonte: (Brun, et al., 2009)
Ciclo de controle do processamento
Ciclo MAPE
Fonte: elaborado pelo autor
Monitoração
• Qual informação é mais relevante para o
comportamento que deseja-se obter do
software? (Vassev & Hinchey, 20...
Monitoração
Requisitos transversais
Fonte: (Ju & Bo, 2007)
Monitoração
AOP (Aspect Oriented Programming) é uma
técnica capaz se separar os requisitos
transversais dos outros módulos...
Análise e decisão
• Para alguns softwares a maior dificuldade é
saber qual é o estado desejado, e caso este
estado seja cl...
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ópria
para regras e extensível
• Pode ser mode...
Análise e decisão
Elementos de um motor de regras
Adaptado 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 de
funcionalidades com uma interface específica,
e ...
Reconfiguração
• Contêiner de injeção de dependência
– Controle a execução dos componentes;
– Mapeamento dos componentes;
...
Reconfiguração
Árvore de componentes de uma arquitetura
Fonte: Elaborado pelo autor
Middleware reflexivo
Middleware Reflexivo é a união das habilidades
da computação distribuída e a capacidade de
reconfigur...
Middleware reflexivo
Modelo técnico da computação reflexiva
Fonte: (Huang, et al., 2004)
Estado da arte
• Meehan, Prasad e Mcginnity, 2007. ADAF
Framework que trouxe mais complexidade,
pois os componentes podem ...
Estado da arte
• Calinescu, 2007. Utiliza MDA, onde na
modelagem são definidos os requisitos de
reconfiguração, porém não ...
Arquitetura de software reconfigurável
• Requisitos funcionais, não funcionais e
técnicos que definem uma solução
arquitet...
Arquitetura de software reconfigurável
• Maior benefício é durante a operação do
software, devido as alterações de
comport...
Pontos de variabilidade
• Um ponto de variabilidade é uma conexão ou a
dependência entre componentes em uma sequência
de e...
Pontos de variabilidade
• Linguagens, padrões, frameworks e arquiteturas foram
desenvolvidos para facilitar a reconfiguraç...
Granularidade de componentes
• A granularidade e a forma de modelagem dos
componentes afetam diretamente a
capacidade da a...
Granularidade de componentes
• A abstração permitirá que diferentes
implementações de componentes
comuniquem entre si, dev...
SOLID
• Single-responsability principle (Princípio da
responsabilidade única)
• Open/closed principle (Princípio aberto/fe...
Desempenho X Reconfiguração
• Em uma arquitetura auto-reconfigurável, certos
requisitos não funcionais são trazidos com es...
Experimento
• Interpolador das curvas de risco e contábeis
da tesouraria do banco
Experimento
• As curvas são consumidas por inúmeros sistemas
do banco, desde traders até a área contábil,
sendo que os tra...
Experimento
• Os horários de pico podem solicitar até 400
requisições de interpolação em 5 minutos;
• Sistema atual está r...
Experimento
Requisitos não funcionais
• Disponibilidade – o serviço deverá priorizar requisições
de risco de mercado ao invés de requi...
Táticas arquiteturais
• O serviço de cálculo não guardará estado entre
uma interpolação e outra, ou seja, não existe
compa...
Táticas arquiteturais
• O serviço será monitorado a cada 2 segundos para
definir se o mesmo se encontra em uma situação de...
Táticas arquiteturais
• Para que não haja perdas, é interessante que a
arquitetura consiga inferir que haverá um aumento d...
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)
– S...
Frameworks de desenvolvimento .Net
• Microsoft Enterprise Library 5.0
– Unity (IoC)
– Unity Interception (AOP)
• WCF 4.0 (...
Base de dados da arquitetura
• Garantia da entrega do pedido de
processamento
• Facilidade de reproduzir as chamadas, se
n...
Base de dados da arquitetura
* Foi utilizado o banco de dados SQL Server 2012 com a
configuraçã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-r...
Trabalhos futuros
• Única notação para reconfiguração e decisão
• Interface visual de manutenção e depuração
• Outras plat...
Experimento
http://selfadaptmiddleware.codeplex.com/
Versão atual do código fonte disponível em:
Próximos SlideShares
Carregando em…5
×

Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras

382 visualizações

Publicada em

Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
382
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Arquitetura de software auto-reconfigurável utilizando Middleware reflexivo e motor de regras

  1. 1. Arquitetura de software auto- reconfigurável utilizando Middleware reflexivo e motor de regras João Henrique Victorino Orientador: Prof. Dr. Julio Arakaki
  2. 2. 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
  3. 3. Motivação • Software mais complexo e que exigem maior conhecimento dos seus administradores (Garcia, et al., 2011) • Falhas por erro humano (Neti & Müller, 2007) • As duas maiores dificuldades, os pontos de variabilidade do sistema para a reconfiguração em tempo de execução e a tomada de decisão que o sistema deve executar sobre as reconfigurações (CYBENKO, BEHRE, et al., 2006)
  4. 4. 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 da flexibilidade do contêiner de inversão de dependência, da monitoração facilitada pela programação orientada a aspectos e da análise e tomada de decisão suportada por um motor de regras
  5. 5. Resultados esperados e contribuições • Obtenção de um modelo arquitetural auto- reconfigurável pouco invasivo aos componentes • Evitar comportamento inesperado da aplicação em virtude da combinação de componentes em tempo de execução • Melhorar o tempo de resposta do software a mudanças no ambiente
  6. 6. Método de trabalho
  7. 7. 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
  8. 8. Sistemas autônomos e computação autonômica • Sistemas que adaptam-se conforme a necessidade utilizando um processo para isso, e contando com pouca ou nenhuma intervenção humana (Ertle, et al., 2010) e (Huang, et al., 2004) • Software autônomo não é algo novo na área da robótica e IA (Kramer & Magee, 2007)
  9. 9. Níveis de autonomia Evolução da autonomia em sistemas Adaptado de (MULLER, O'BRIEN, et al., 2006)
  10. 10. Sistemas autônomos e computação autonômica Modelo técnico da computação autonômica Fonte: (Huang, et al., 2004)
  11. 11. Arquitetura de software • Uma estrutura, decomposta em partes, na relação entre elas e nas propriedades visíveis externamente que essas partes apresentam (Bass, et al., 2003) • É a junção de todos os componentes, que fazem parte da arquitetura, que determinam se um sistema atende a um determinado requisito (BRAT, DENNEY, et al., 2006). • Os atributos de qualidade da arquitetura são alcançados através das táticas arquiteturais, que são as decisões de modelagem da arquitetura (Bass, et al., 2003)
  12. 12. Requisitos não-funcionais • RNF e RF são definidores e validadores da arquitetura de software (Bass, et al., 2003) • Decisões arquiteturais impactam diretamente na autonomia do software (Fuad & Oudshoorn, 2007) • Software autônomo necessita de alguns RNFs que outros softwares não necessitam, pois são mais dinâmicos (Neti & Müller, 2007)
  13. 13. Requisitos não-funcionais • O atributo de qualidade mais importante para um sistema auto-reconfigurável é a facilidade de alteração, que está subdividido na capacidade do sistemas em ser extendido e em ser modificado, pois estes sistemas precisam estar componentizados em pequenas partes em virtude da necessidade de dinamismo (NETI e MÜLLER, 2007)
  14. 14. Ciclo de controle do processamento Ciclo de controle em sistemas autonômicos Fonte: (Brun, et al., 2009)
  15. 15. Ciclo de controle do processamento Ciclo MAPE Fonte: elaborado pelo autor
  16. 16. Monitoração • Qual informação é mais relevante para o comportamento que deseja-se obter do software? (Vassev & Hinchey, 2010) • A monitoração deve ser simples e rápida para que não afete a modelagem e o desempenho do software, também deve prover informação atualizada (Zheng, 2010) • Requisito transversal
  17. 17. Monitoração Requisitos transversais Fonte: (Ju & Bo, 2007)
  18. 18. Monitoração AOP (Aspect Oriented Programming) é uma técnica capaz se separar os requisitos transversais dos outros módulos, de modo que o código fique modularizado e permite que cada funcionalidade fique concentrada onde deve e não espalhada pelo software (Ju & Bo, 2007)
  19. 19. Análise e decisão • Para alguns softwares a maior dificuldade é saber qual é o estado desejado, e caso este estado seja claro, saber quais modificações na arquitetura são necessárias para que o software deixe do estado atual e para o estado desejado (Kramer & Magee, 2007) • Este tipo de controle pode ser implementado por regras (Vassev & Hinchey, 2010)
  20. 20. Análise e decisão IF (TempoResposta > 2 seg) THEN (Aumentar CPU em 5%)
  21. 21. Análise e decisão Motor de regras: • É uma DSL (Domain Specific Language) própria para regras e extensível • Pode ser modelada por uma ferramenta visual • A idéia de motor de regras é externalizar a lógica de negócio, o motor de regras pode ser visto como um sofisticado interpretador de declarações IF-THEN (CHEN, XU-PENG e ZHENG-QIU, 2010).
  22. 22. Análise e decisão Elementos de um motor de regras Adaptado de (CHENG, LEMOS, et al., 2009)
  23. 23. Reconfiguração Tipos: • Sistêmica ou infraestrutura • Aplicacional – Parametrização – Componentização – Arquitetural
  24. 24. Reconfiguração Componentização: • Implementação passiva de um conjunto de funcionalidades com uma interface específica, e que passa a ter algum tipo atividade quando um processo o executa, sendo um processo uma representação dos recursos físicos de CPU (Central Process Unit) e memória (Bellur & Narendra, 2006)
  25. 25. 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;
  26. 26. Reconfiguração Árvore de componentes de uma arquitetura Fonte: Elaborado pelo autor
  27. 27. 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)
  28. 28. Middleware reflexivo Modelo técnico da computação reflexiva Fonte: (Huang, et al., 2004)
  29. 29. Estado da arte • Meehan, Prasad e Mcginnity, 2007. ADAF Framework que trouxe mais complexidade, pois os componentes podem ser trocados dinamicamente e isoladamente. • Bellur e Narendra, 2006. Uma arquitetura que consegue carregar componentes de um repositório. • Zhang, Qu e Liu, 2006. • Palma, Popov et al., 2009. Arquitetura de reconfiguração na infraestrutura e não na solução.
  30. 30. Estado da arte • Calinescu, 2007. Utiliza MDA, onde na modelagem são definidos os requisitos de reconfiguração, porém não fica claro se poderá ser feita uma reconfiguração em tempo de execução. • Ju e Bo, 2007. Arquitetura de serviços reconfiguráveis com IoC e AOP, porém as reconfigurações não são feitas em tempo de execução. • Wu, Wu et al., 2010. Framework Fractal, onde o sistema legado precisou ser refatorado para alcançar maior autonomia.
  31. 31. Arquitetura de software reconfigurável • Requisitos funcionais, não funcionais e técnicos que definem uma solução arquitetural (CORDEIRO MARTINS, 2010) • A auto-reconfiguração é um estilo arquitetural, e como tal, deve vir a partir das necessidades de negócio. • ISO 9126 (lista de atributos de qualidade para produtos e serviços) • Manutenibilidade (Modificabilidade e gerenciabilidade (PARASHAR e HARIRI, 2007))
  32. 32. Arquitetura de software reconfigurável • Maior benefício é durante a operação do software, devido as alterações de comportamento do mesmo, conforme o ambiente e sem supervisão. • Reconfiguração funcional e arquitetural (PARASHAR e HARIRI, 2007) • Requisitos não funcionais devem ser levados em consideração em virtude da reconfiguração, como, transação, concorrência, segurança, entre outros. • Extensibilidade em tempo de execução e naturalmente em tempo de modelagem.
  33. 33. Pontos de variabilidade • Um ponto de variabilidade é uma conexão ou a dependência entre componentes em uma sequência de execução onde a reconfiguração pode ser acionada (BELLUR e NARENDRA, 2006). • Os pontos de variabilidade dependerão de quais requisitos funcionais e não funcionais serão alterados durante a reconfiguração, pois alguns requisitos podem ser atingidos apenas alterando o pool de threads do servidor web, ou poderá ser necessária a substituição de um componente da aplicação, estes tipos de reconfiguração podem ser feitas no nível de sistema, como uma parametrização de infraestrutura, ou no nível aplicacional como a parametrização ou substituição de um componente da aplicação (ZHANG, QU e LIU, 2006).
  34. 34. Pontos de variabilidade • Linguagens, padrões, frameworks e arquiteturas foram desenvolvidos para facilitar a reconfiguração, entretanto estas técnicas necessitam que o sistema seja modelado já pensando nos pontos de variabilidade que terá, pois o sistema 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 a mesma interface, desta forma os componentes são do mesmo tipo, e existe um contrato de comunicação com eles, definido pela interface, sendo assim ambos os componentes podem ter comportamentos diferentes e ainda sim serem facilmente substituídos, um pelo outro (BELLUR e NARENDRA, 2006).
  35. 35. Granularidade de componentes • A granularidade e a forma de modelagem dos componentes afetam diretamente a capacidade da arquitetura em se reconfigurar • As estruturas baseadas em componentes permitem uma reconfiguração dinâmica altamente granular, sendo que este recurso pode ser melhorado utilizando meta dados (PALMA, POPOV, et al., 2009)
  36. 36. Granularidade de componentes • A abstração permitirá que diferentes implementações de componentes comuniquem entre si, devendo apenas respeitar a abstração, que no caso de uma linguagem orientada a objetos podem ser as interfaces (BELLUR e NARENDRA, 2006). • Padrões de projeto e princípios de modelagem como SOLID podem auxiliar na modelagem componentizada tornar-se altamente granular.
  37. 37. 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)
  38. 38. Desempenho X Reconfiguração • Em uma arquitetura auto-reconfigurável, certos requisitos não funcionais são trazidos com esta decisão, como a facilidade de modificação que naturalmente implica na maior complexidade no desenvolvimento do software. • O ciclo de processamento de monitoração, análise e execução requer certo processamento e para minimizar seus 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 pelas vantagens de aumento de escalabilidade e disponibilidade.
  39. 39. Experimento • Interpolador das curvas de risco e contábeis da tesouraria do banco
  40. 40. Experimento • As curvas são consumidas por inúmeros sistemas do banco, desde traders até a área contábil, sendo que os traders, ou seja as curvas de risco de mercado tem prioridade nas requisições da manhã, 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 e responder as solicitações de interpolação em até 10 segundos para curvas de até 10 anos e que sejam de risco de mercado, mesmo em situações de sobrecarga de requisições, ou seja, até 150 requisições no mesmo minuto;
  41. 41. Experimento • Os horários de pico podem solicitar até 400 requisições de interpolação em 5 minutos; • Sistema atual está respondendo em cerca de 20 segundos a interpolação de curvas de 10 anos, em sobrecarga de requisições, ou seja, até 150 requisições simultâneas no mesmo minuto, sendo que não faz distinção entre os tipos de curvas a serem interpoladas.
  42. 42. Experimento
  43. 43. Requisitos não funcionais • Disponibilidade – o serviço deverá priorizar requisições de risco de mercado ao invés de requisições de outras áreas, e se manter disponível nos momentos de pico da manhã, das 9h às 11h, e da noite, das 19h às 23h. • Modificabilidade – o serviço deve suportar até 150 requisições no mesmo minuto e ainda interpolar uma curva de 10 anos em no máximo 10 segundos, para atingir o requisito de disponibilidade pode ser necessá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.
  44. 44. Táticas arquiteturais • O serviço de cálculo não guardará estado entre uma interpolação e outra, ou seja, não existe compartilhamento de dados entre as interpolações, seja do mesmo cliente ou de outros clientes. • Como não haverá compartilhamento dos dados, o serviço poderá processar as requisições de interpolação de forma paralelizada. • O serviço poderá iniciar uma transação no momento que a requisição chegar ao servidor e finaliza-la quando a interpolação estiver completa e a resposta for enviada ao cliente.
  45. 45. Táticas arquiteturais • O serviço será monitorado a cada 2 segundos para definir se o mesmo se encontra em uma situação de sobrecarga, ou aumento gradativo de requisições, para que uma ação de degeneração seja acionada. • Para descobrir se o serviço está em uma situação de alta demanda, podemos utilizar a quantidade de requisições recebidas no último minuto e o tempo máximo que o serviço está gastando para responder as interpolações no último minuto. • Em alta demanda as requisições da área de risco de mercado devem ser privilegiadas e as outras requisições podem ser desabilitadas, colocando a aplicação em um estado de degeneração parcial com o intuito de atender as requisições prioritárias.
  46. 46. Táticas arquiteturais • Para que não haja perdas, é interessante que a arquitetura consiga inferir que haverá um aumento de demanda e degradar seu comportamento, antes que o serviço falhe, ou o mais rápido possível assim que detectado um aumento de demanda considerável. • Quando iniciar a diminuição da demanda o serviço deve voltar ao estado normal e atender a todas as requisições igualmente, pois a degeneração fará com que o software perca parte de sua qualidade, em virtude dos requisitos não funcionais e funcionais que não estarão disponíveis.
  47. 47. Projeto
  48. 48. Projeto (Configuração em baixa demanda)
  49. 49. Projeto (Configuração em alta demanda)
  50. 50. Implementação
  51. 51. 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)
  52. 52. 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
  53. 53. Base de dados da arquitetura • Garantia da entrega do pedido de processamento • Facilidade de reproduzir as chamadas, se necessário • Auditoria e segurança
  54. 54. Base de dados da arquitetura * Foi utilizado o banco de dados SQL Server 2012 com a configuração In-Memory OLTP
  55. 55. Unity Configuração
  56. 56. Unity Configuração
  57. 57. Regra em alta demanda
  58. 58. Regra em baixa demanda
  59. 59. Análise resultados em alta demanda
  60. 60. Análise resultados em alta demanda
  61. 61. Análise resultados em alta demanda
  62. 62. Análise resultados em baixa demanda
  63. 63. Análise resultados em baixa demanda
  64. 64. Análise resultados em baixa demanda
  65. 65. 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
  66. 66. 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
  67. 67. Experimento http://selfadaptmiddleware.codeplex.com/ Versão atual do código fonte disponível em:

×