Quando nos deparamos com cenários de integrações onde não podemos nos dar ao luxo de perdermos alguma mensagem devido a eventuais problemas de conectividade, diponibilidade ou de qualquer outro tipo, dizemos que esta integração deve ter garantia de entrega das mensagens que são trafegadas, e para endereçar esta questão existem alguns design patterns, e 2 dos mais comuns são:
Guaranteed Delivery:
Este pattern está associado muito ao processo de store-and-foward, ou seja para prevenir que a mensagem se perca, persistimos em disco ou em banco a mensagem antes de seguir para um próximo passo do processo que tenha potencial de falha. O código da integração ou serviço pode ter a responsabilidade de persistir as mensagens, mas não é o ideal, pois geralmente as próprias ferramentas de integração ou servidores de mensageira já possuem esta funcionalidade.
No tibco por exemplo, além de usar o checkpoint, onde o próprio BW persiste o estado do processo, e obviamente as mensagens que estão sendo trafegadas, temos uma forma mais elegante de implementarmos este pattern, que é uma funcionalidade do EMS, onde podemos configurá-lo para que todo subscritor e publicador tenham uma fila local e que o ems se encarregue de copiar a mensagem da fila local do publicador para a fila local do subscritor e enquanto não conseguir isto, a mensagem permanece na fila esperando retentativas de envio por parte do EMS até que a mensagem expire (se a expiração tiver configurada). Esta configuração é feita configurando a propriedade Delivery mode da task JMS Queue Sender com o valor Persistent, como sugere a imagem abaixo:
Durable Subscriber:
Quando o cenário de integração envolve vários subscritores, e todos precisam receber todas as mensagens publicadas, preferimos usar tópico ao invés de fila por justamente a diferença entre eles ser a gestão que o servidor de mensageira implementa, relativa a fazer com que a mensagem permaneça no tópico até todos os subscritores conectados ao a ele recebam a mensagem, e então logo depois remove a mensagem do tópico.
Mas esta gestão está baseada nas conexões ativas originadas dos subscritores no momento que a mensagem é publicada, e isto quando pensamos em garantia de entrega é uma brecha para falhas. Imagine um cenário onde os N subscritores tem que ficar conectados ao tópico, esperando mensagens 24/7, mas por uma questão qualquer a conexão é perdida e alguns segundos depois é restabelecida ou até a máquina do subscritor cai e volta depois de um tempo, sendo que uma mensagem é publicada neste mesmo periodo. Se isto ocorrer o subscritor que ficou indisponível perderá as mensagens que foram publicadas neste periodo.
O Pattern Durable Subscriber tem como objetivo tirar esta brecha de falha, fazendo com o servidor de mensageria registre os subscritores e não dependa mais de suas conexões estarem ativas ou não com ele.
No tibco para tornar um subcritor durável é necessário apenas marcar a checkbox de Durable Subscription nas configurações do subscritor, como sugere a imagem abaixo:
TaaS - Thoughts as a Service 