Arquitetura RASEA

A Arquitetura de Software auxilia na identificação dos componentes e seus “relacionamentos de alto nível” (SHAW; GARLAN, 1994), facilitando o entendimento da solução como um todo. O projeto RASEA fundamenta sua arquitetura sob quatro perspectivas para assegurar o controle de acesso cross-plataforma às aplicações comerciais, que, conforme a Figura 9, são: independência de plataforma, integração, servidor e agente.

Figura 9 – Perspectivas da arquitetura RASEA

Cada perspectiva funciona como uma peça de quebra-cabeça, completando o modelo com o encaixe perfeito de todos os elementos. O componente “independência de plataforma” agrega padrões, paradigmas e tecnologias, possibilitando que aplicações comerciais em diferentes tecnologias beneficiem-se com a solução proposta. O elemento “integração” permite que o RASEA utilize dados legados da organização e que as aplicações consumam os serviços providos pelo RASEA. Enquanto a perspectiva “servidor” preocupa-se com serviços e disponibilidade, o “agente” aborda aspectos das plataformas das aplicações. Tais elementos serão tratados em detalhes mais à diante.

Figura 10 – Visão geral da arquitetura RASEA

De acordo com Kruchten (1995), a arquitetura define os componentes, suas conexões e relacionamentos, conforme ilustrado na Figura 10. O elemento “A” representa o servidor, o qual disponibiliza telas “B” para que o administrador do acesso “C” gerencie as permissões e autorizações dos sistemas. O servidor também provê serviços “D” agrupados em dois EndPoints: controle de acesso e gerenciamento. Os serviços para controle de acesso respaldam os agentes com informações suficientes para executar o seu trabalho. Os agentes são conectados às aplicações, a exemplo de “E” e “F”, denominadas aplicações parceiras. As aplicações que não utilizam o controle de acesso do RASEA são chamadas de aplicações autônomas, que podem acessar os serviços de gerenciamento, caso desejem.

Ainda na Figura 10, o servidor “A” mantém a base de dados “H”, que contém informações estruturadas nos moldes do padrão RBAC, possibilitando o controle de acesso às aplicações comerciais. A base de dados “I” detém credenciais dos usuários da organização, geralmente mantidas em um Lightweight Directory Access Protocol  (LDAP). O servidor “A” acessa a base de dados legada “I” para verificar a autenticidade dos usuários. Almejando a flexibilidade da solução, o servidor “A” pode ser parametrizado a partir de um arquivo de configuração “J”.

Objetivando a padronização de vocabulário, segue a relação dos os elementos envolvidos na arquitetura RASEA e suas respectivas descrições, conforme Eden e Kazman (2003, s. 1 apud SHAW; GARLAN, 1996):

• Credenciais de usuário: dados dos usuários da organização, tais como: nome, senha, e-mail, etc.
• Base de dados: repositório com dados persistidos estruturadamente com base no padrão RBAC, sendo dividido em dois domínios: dados para controle de acesso e credenciais de usuários.
  
• Servidor: principal elemento da arquitetura, responsável por centralizar o controle de acesso, manter a conexão com as bases de dados e prover telas e serviços.
  
• Telas: interface gráfica com o usuário, também conhecida como GUI (do inglês Graphical User Interface), que possibilita o gerenciamento das permissões e autorizações das aplicações.
  
• Serviços de controle de acesso: agrupamento de serviços (ou EndPoint) consumido pelos agentes. Disponibilizam informações necessárias para controle de acesso.
  
• Serviços de gerenciamento: agrupamento de serviços (ou EndPoint) acessado  por consumidores que desejem gerenciar o servidor RASEA.
  
• Agente: elemento da arquitetura responsável por interceptar e analisar as requisições às aplicações, liberando ou revogando o acesso com base nas informações obtidas no serviço de controle de acesso.
  
• Aplicação parceira: é toda aplicação conectada a um agente, que utiliza o servidor RASEA como dispositivo de controle de acesso centralizado. As aplicações parceiras podem, adicionalmente, consumir os serviços de gerenciamento.
  
• Aplicação autônoma: é toda aplicação não está conectada a um agente e que, conseqüentemente, não utiliza o RASEA como dispositivo de controle de acesso centralizado. As aplicações autônomas podem consumir os serviços de gerenciamento, caso necessitem.
• Container: representa um Servidor de Aplicação ou Servidor WEB que hospeda as aplicações.
  

Nos próximos tópicos, cada uma das perspectivas da arquitetura (independência de plataforma, integração, servidor e agente) será abordada em detalhes. Para tanto, serão considerados requisitos de performance, disponibilidade, concorrência, distribuição e tolerância à falhas, assuntos imprescindíveis para a definição da arquitetura do software (KRUCHTEN, 1995). Porém, faz-se necessário conhecer a estrutura dos dados mantidos pelo RASEA, tratada a seguir.