Agente

Toda aplicação parceira deve estar conectada a um agente. Tomando como base o modelo PIM, o agente RASEA é um motor de especialização (IBM, 2009), responsável por converter a linguagem dos WebServices em mensagens específicas das tecnologias das aplicações parceiras. Além disso, o agente executa efetivamente as tarefas de controle de acesso às aplicações, prevenindo o acesso não autorizado ao sistema. Neste tópico serão abordadas as duas principais funções do agente RASEA: i) motor de especialização; e ii) controlador de acesso.

A Figura 19 destaca a especialização do agente RASEA em diferentes tecnologias. O item “A” representa os serviços, providos pelo servidor, que são acessados pelos agentes “B”. A comunicação entre os serviços “A” e os agentes “B” se dá por meio de WebServices, garantindo a independência de plataforma. Os agentes “C”, “D” e “E” são especializações do agente conceitual “B”, construídos para tecnologias específicas, tais como: Java, .NET e PHP. O item “F” representa agentes desenvolvidos em qualquer tecnologia que suporte o consumo de WebServices, proporcionando flexibilidade à solução.

Figura 19 – Tipos de agente

Os agentes devem se especializar ao máximo, garantindo o encaixe perfeito com a tecnologia da aplicação parceira. Como exemplo, pode-se citar a utilização de Java na construção de aplicações comerciais. Existem diversas ferramentas, paradigmas, frameworks, bibliotecas e tecnologias que podem ser utilizadas na construção de aplicações na plataforma Java, tais como: i) JavaServer Faces (JSF); ii) Apache Struts; iii) Google Web Toolkit (GWT); iv) Abstract Window Toolkit (AWT); dentre outras. É fundamental que exista um agente para cada tecnologia específica, ao invés de um motor de especialização genérico para a plataforma Java.

O agente é responsável por interceptar todas as requisições feitas às aplicações parceiras, conforme estabelecido pelo padrão de projeto Front Controller (ALUR; CRUPI; MALKS, 2003, p. 164). Todas as tentativas de acesso devem ser tratadas com base nas informações consultadas no servidor RASEA. De acordo com Kern (2004, p. 90, tradução nossa), “lentidão nas decisões de acesso são críticas para o negócio”, portanto recomenda-se armazenar em cache todas as permissões associadas ao usuário. Segue a baixo o processo executado pelo agente para realizar a autenticação e o armazenamento dos privilégios de acesso:

1.      O usuário informa as credenciais para acessar a aplicação parceira;

2.      O agente acessa o serviço de autenticação provido pelo servidor;

3.      O servidor verifica a autenticidade acessando a base única de usuários;

4.      Caso a autenticação seja bem sucedida, o agente é notificado e o fluxo prossegue. Em caso de falha na autenticação, o usuário é notificado e o fluxo é finalizado;

5.      O agente solicita todos os papéis que o usuário possui e os armazena em cache;

6.      O agente solicita todas as permissões atribuídas ao usuário e as armazena em cache;

7.      O usuário é notificado que o processo de autenticação foi bem sucedido, ganhando acesso à aplicação.

O fluxo a seguir estabelece as etapas do controle de acesso, executadas pelo agente RASEA, ao interceptar requisições aos recursos da aplicação parceira:

1.      O usuário acessa um recurso de uma aplicação executando uma determinada ação.

2.      O agente intercepta a requisição.

3.      Caso esteja autenticado, o fluxo continua. Caso contrário, o usuário é direcionado para o processo de autenticação.

4.      O agente verifica a autorização para executar a ação sob o recurso solicitado. A verificação é feita com base nas informações em cache, armazenadas pelo fluxo de autenticação.

5.      Caso o usuário esteja autorizado, a ação é executada sob o recurso. Caso contrário, o usuário é notificado que a solicitação de acesso foi negada.

O servidor RASEA, elemento central da arquitetura, é também uma aplicação que requer o controle de acesso às suas funcionalidades. Este requisito possui caráter recursivo, visto que o servidor acessa os seus próprios serviços para garantir o controle de acesso a si mesmo, caracterizando-o como uma aplicação parceira. A Figura 20 ilustra o agente acoplado ao servidor “B” acessando os serviços “D” por meio da conexão “C”. Percebe-se que a estrutura do servidor “B” é a mesma adotada pelas aplicações parceiras “A”. Esta técnica é conhecida como bootstrapping, onde o processo é executado sem auxílio externo (DAVISON; HINKLEY, 1997).

Figura 20 – Bootstrapping no RASEA

Existe no mercado uma grande variedade de tecnologias e linguagens de programação. Deve-se construir um agente para cada tecnologia que pretenda utilizar o RASEA. O projeto RASEA está aberto à colaboração da comunidade para a criação de novos agentes, seguindo o modelo Bazaar proposto por Raymond (2001). Durante o desenvolvimento do projeto, diversos codificadores e arquitetos contribuíram para a evolução do RASEA.