DEAI1-2476 - Arquitetura AMQP

Propósito

O objetivo desse Spike é discutir as demandas relacionadas a integração via AMQP e apresentar as frentes de trabalho a serem abertas, juntamente com as definições tomadas durante as reuniões que fizeram parte desta tarefa.

Desenvolvimento

Durante as reuniões de Brainstorm foi identificado que existem três diferentes demandas relacionadas à comunicação via AMQP, que serão assim quebradas em três tópicos deste documento e assim também devem ser divididas na criação das Stories.

Protocolo de Mensagem Padronizada via AMQP (Sync/Async)

Em reuniões de brainstorm foram discutidas os prós e contras de diversas soluções para implementação do canal de comunicação via AMQP para o protocolo de Mensagem Padronizada já definido (sync/async). Analisando o trade-off de todas as soluções foram feitas as definições listadas abaixo para a primeira entrega. 

• A parametrização do canal de envio (Soap/Rest/AMQP) deverá ser realizada no cadastro do aplicativo integrado.
• Será utilizada a Exchange padrão para envio e recebimento de mensagens. 
  • A Exchange padrão é do tipo Direct, orientada por RoutingKey (nome da fila).
• Os aplicativos devem consumir, na Exchange padrão, a fila com RoutingKey igual seu AppId (padrão [SourceApplication]@[Produto] ) para recebimento de mensagens.
• Os aplicativos devem publicar as mensagens na fila de RoutingKey igual ao AppId do aplicativo de destino, também na Exchange padrão. 
• Será utilizado o padrão RPC para a comunicação, viabilizando assim o aguardo da mensagem de resposta, conforme o protocolo de Mensagem Padronizada.
• As filas de comunicação pelos EAIs deverão ser definidas com os parâmetros listados no sub-tópico.
  
  • exclusive: false
• O serviço de consumo da fila de mensagens deve ser iniciado automaticamente com os servidores de aplicação (RM.Host, AppServer, etc), caso parametrizado para tal.
  • Permitir parametrização de "Prefetch" para cada AppServer.
  • Permitir que o usuário informe quantos "Consumers" subir para cada AppServer ou implementar paralelismo no Consumer padrão

Pontos de atenção:

• Deve-se verificar forma de identificar se existe a fila e ao menos um Consumer antes da postagem, para evitar que a transação não será travada até o timeout desnecessariamente.
  • Outra forma de implementação é utilizando o método do RabbitMQ client que obtém o número de consumers de uma fila, mas não encontrei confirmação que este método também funcionaria com outro Server AMQP e este método não é definido na especificação do AMQP 0.9.1.
  • O método "channel.QueueDeclarePassive" gera exceção caso a fila não exista e caso exista retorna informação com número de mensagens e de consumers, podendo assim ser utilizado para esta validação.
• Caso haja Timeout é importante remover a mensagem da fila para que não haja processamento posterior por outro Consumer.
• Necessário definir forma de identificação da ReceiptMessage
  • Será considerado o Ack como ReceiptMessage, mesmo o Ack não garantindo envio ao sistema de destino?
  • Será considerado como ReceiptMessage o retorno de string vazia como mensagem de resposta?
  • Será novamente exigido o envio do Xml/Json de ReceiptMessage?
• Será necessário voltar com a tag "Event" no "Header" da mensagem Json
• A criação de Connections é considerada lenta, devendo assim ser feito cache desta classe para reutilização a cada envio.

Criação do tipo de envio Publish/Subscriber no Protocolo de Mensagem Padronizada

Deve-se especificar no Protocolo de Mensagem Padronizada o envio por Publish/Subscribe, viabilizando o uso deste protocolo com AMQP mas não restringindo ao mesmo. O protocolo definido deve poder ser implementado por outros canais de comunicação, como por exemplo uma futura implementação para os EAIs funcionarem como "Broker".

Este novo método de envio se caracteriza pelo sistema de origem direcionar suas mensagens para um "Broker", que redirecionará esta mensagem para os sistemas que tiverem se subscrito nele para receber mensagens desta origem. O sistema de origem não necessariamente saberá quais sistemas receberão sua mensagem e assim sendo não deve controlar o recebimento por cada nó de destino.

Durante as reuniões foi discutida como primeira proposta de solução a criação de um novo tipo de aplicativo integrado que o define como "Broker", assim devendo rever os tratamentos de fila, monitor, de-para e outros.

Criação de infraestrutura para consumo de serviços via AMQP

Foi recebida recentemente pela equipe Datasul uma demanda sobre o uso de AMQP para consumo de APIs/Serviços no modelo de Mensagem Padronizada.Durante reuniões de Brainstorm foi identificado que o consumo destas APIs será executada pelo modelo de "Contents", assim não utilizando o "protocolo padrão de Mensagem Única" e não sendo executado pelo EAI.

É aconselhável analisar o uso do WSO2 ESB para esta tarefa, uma vez que este possui integração com o RabbitMQ.

Visando viabilizar o desenvolvimento e consumo das APIs via AMQP deverá ser desenvolvido pela equipe T-Talk a infraestrutura necessária.

Tarefas identificadas

• Especificação da arquitetura de integração do protocolo Contents via AMQP.
• Especificação do modelo de desenvolvimento de Producers e Consumers.
• Codificação das tarefas definidas nas etapas de especificação.