Avaliar/Comparar arquiteturas propostas para modelo híbrido (API Manager em Cloud + APIs publicadas na infraestrutura do cliente)
- Aplicação client faz uma requisição HTTP para o nosso servidor em Cloud
- Essa requisição passa pelo API manager até uma API REST
- Essa API Rest retorna uma resposta de maneira síncrona
- Mais rápido que o modelo de Subscrição de Comandos (246ms)
- API fica acessível de qualquer lugar que possui internet.
- Mais lento que o modelo MicroGateway
- Obrigatório que o cliente definida regras de permissão de porta de entrada (inbound).
- Aplicação client faz uma requisição HTTP para servidor em Cloud
- Essa requisição passa pelo API manager até uma API responsável por informar a solicitação feita pelo cliente em uma fila de comandos (AMQP 0.9)
- Essa fila de comandos está sendo monitorada por um Command Receiver, que está rodando na Infra do cliente. O modo de comunicação é síncrono
- Esse Command Receiver faz uma requisição para o método responsável pelas regras de negócio, e a mesma retorna uma resposta
- Essa resposta vai até uma fila temporária, na qual o REST da cloud está conectada. A partir daí a resposta volta para a aplicação client.
- Não existe necessidade de regras de permissão de porta de entrada (inbound), apenas saída (outbound) na rede do cliente.
- API fica acessível de qualquer lugar que possui internet.
- Maior tempo de resposta encontrado nos testes (380ms).
- Custo do desenvolvimento de Command Receiver.
- Aplicação client, na rede onPremisse do cliente, faz uma requisição HTTP para um gateway existente no servidor dentro de sua própria rede
- Esse gateway redireciona para API Rest, que retorna uma resposta de maneira síncrona
- De tempos em tempos, o microgateway alimenta o API Manager em Cloud com as informações necessárias
- Menor tempo de resposta encontrado nos testes (126ms).
- Todas as requisições ocorrem sem sair da rede do cliente
- É possível trabalhar sem regras de permissão de porta de entrada (inbound), apenas saída (outbound) na rede do cliente.
- API não fica acessível através da internet e se limita a rede à rede interna do cliente. A não ser que esse modelo funcione em conjunto com o de Redirecionamento HTTP, explicado no início do documento.
- TOTVS fica responsável por gerenciar microgateways em todos os clientes que aderirem esse modelo
Foram criadas duas máquinas no Windows Azure:
Papel: Simular ambiente de Cloud controlado pela Totvs
- Windows (Windows Server 2008 R2 Datacenter)
- Leste dos EUA
- Aplicações
- DotNet Core
- WSO2
- CloudRestAPI
- ActiveMQ
- Regras de Saída:
- Regras de Entrada:
- WSO2-1: 8280
- WSO2-2: 8243
- TesteAPI: 8015
- AMQP: 8012
Papel: Simular ambiente OnPremise do cliente, sem abertura de porta, solicitando atualizações de um nó AMQP disponível em Cloud
- Windows (Windows Server 2008 R2 Datacenter)
- Sul do Brasil
- Aplicações
- DotNet Core
- RequestResponseServer
- Regras de Saída:
- Regras de Entrada: (Nenhuma)
Também foi utilizada uma máquina no OpenStack na rede da Totvs
Papel: Simular ambiente OnPremise do cliente, com abertura de porta, disponibilizando uma API Rest
- Windows (Windows Server 2012 R2)
- Sudeste do Brasil
- Aplicações
- Regras de Saída:
- Regras de Entrada:
Foram publicadas duas APIs:
- BUSINESSRESTAPIHTTPREDIRECT
- Faz o redirecionamento para um endpoint remoto, fluxo totalmente focado no REST
- BUSINESSRESTAPIQUEUE
- Faz o redirecionamento para endpoint de API local, responsável por tratar o fluxo de comandos (AMQP)
https://totvstfs.visualstudio.com/IntegrationFramework/_git/IntegrationFramework
Pasta: POC-EventBasedArchitecture
Nessa pasta, encontram-se todos os artefatos criados para esse teste, como:
- Projeto CloudRestAPI
- Projeto RequestResponseServer
- Configuração de APIs no WSO2
- Collection com os casos de teste
https://docs.google.com/spreadsheets/d/17mEMED7fAU14s3iJqNpPeMlcTQ6mWNkG4jK49vZT3ks/edit?usp=sharing
(Tempo de resposta médio em milissegundos)