Servidor de aplicações

Contentor da lógica de negócio, acessível de diferentes maneiras:

• Serviços web com protocolo XML-RPC: ou Lógica de negócio implementada em Powerbuilder ou Lógica de negócio implementada em Java e executada em Tomcat (RPC2).
• Novos serviços acessíveis por meio de REST (pedidos HTTP) e implementados em Java, por meio de framework Spring e executando-se sob Tomcat.

Contentor de diferentes repositórios de dados:

• Base de dados relacional (SQL) que contém dados de negócio com suporte para: ou SQL Server ou Oracle ou Postgre SQL.
• Base de dados não relacional para suporte do novo framework (cache de dados, configuração, auditoria, etc.). A Base de Dados escolhida é Redis.

Contentor para serviços de mensagens entre serviços. Para esta funcionalidade, optou-se pelo protocolo MQTT (Message Queue Telemetry Transport) que permite ter a funcionalidade push (notificações iniciadas pelo servidor para o cliente).

Servidor web

Baseado em NodeJS, é o servidor de elementos estáticos (elementos HTML, imagens, etc.) e atua como um proxy para pedidos REST de negócio do cliente ao servidor.

Servidor cliente

O framework possui uma API formada pelos serviços (sejam os XML-RPC ou os REST) e acessível:

• Diretamente a partir de qualquer cliente que permita fazer chamadas HTTP.
• Por aplicações criadas a partir da API. Para isso, optou-se pelo Angular2, pela flexibilidade quando se trata de criar aplicações executáveis a partir de navegador web e como executável, seja em ambiente Windows, Linux ou iOS.

Novas funcionalidades

• Possibilidade de definição dinâmica de segurança por serviço, ao nível do papel de utilizador, em vários níveis:
  • Definição de lista de serviços sem restrição de acesso.
  • Definição de lista de serviços acessíveis por determinados papéis.
  • Definição de lista de serviços restringidos a determinados papéis.
  • Serviços acessíveis por qualquer papel de utilizador (utilizador com sessão iniciada).
• Para o acesso a serviços com definição de controlo de acesso, deve-se fazer a chamada fornecendo ao serviço um token de acesso obtido ao efetuar um início de sessão.
• Cache de dados baseada em Redis que permite uma melhoria de tempos de execução.
• Aplicações multi-idioma.
• Possibilidade de auditoria dinâmica de eventos.
• Possibilidade de configuração dinâmica de segurança de pedidos de início de sessão falhados, tornando possível o bloqueio de pedidos para evitar ataques do tipo DoS (Denial of Service).
• Funcionalidades mais dinâmicas graças à possibilidade de fazer notificações a partir do servidor para o cliente (notificações push).

A estrutura da arquitetura futura

O novo paradigma é baseado em SERVIÇOS. Um serviço é uma peça do programa que cumpre certos requisitos:

• Abstração e reutilização: fazem o mesmo, independentemente de "quem" os chame.
• Autonomia de execução.
• Flexibilidade para executar o serviço a partir de qualquer local.
• Não haverá programas.

Um trabalho é executado a partir de:

• Um fluxo de serviços.
• Um agrupamento de serviços simples em serviços compostos.
• Uma nova casuística.

Vantagens da Arquitetura 2.0

• 
  Maior flexibilidade e adaptação
• 
  Baseado em padrões
• 
  Aumenta a velocidade e a agilidade
• 
  Autonomia de execução
• 
  Independência da plataforma
• 
  Interoperabilidade