É possível e sensato usar o IBM MQ sem um gerenciador de filas local?

Question

Minha equipe está no processo de criar um aplicativo que será implantado no AWS EC2 e se comunicará com os sistemas legados locais por meio do IBM MQ (anteriormente conhecido como WebSphere MQ, anteriormente conhecido como MQSeries).

Já temos gerenciadores de filas do IBM MQ em nossas instalações. Também precisamos implantar um no EC2? Precisamos implantá-los nas caixas do EC2 onde nosso aplicativo será executado?

Sou novo no IBM MQ, embora tenha alguma experiência com o RabbitMQ. Há pessoas na empresa com muita experiência com o IBM MQ, mas nenhum dos aplicativos em nuvem. Fui informado várias vezes por eles que precisamos executar um gerenciador de filas na caixa com nosso aplicativo, que pode então encaminhar para outros gerenciadores de filas, mas em uma máquina em nuvem com um disco efêmero, que não faz sentido algum para mim - não adiciona nenhuma confiabilidade.

Poderíamos implantar um gerenciador de filas em uma máquina EC2 com um volume EBS, o que faria um pouco mais de sentido e permitiria que nossos aplicativos conversassem com isso. Mas isso é realmente melhor do que apenas falar diretamente com os gerenciadores de filas existentes em nossas próprias instalações?

Para adicionar um bônus divertido, não estamos implantando o aplicativo diretamente no EC2, mas no Cloud Foundry implantado no EC2, as instâncias do aplicativo estão sendo executadas em contêineres sobre os quais não temos muita influência.

    

Answer 1

Preocupar-se com o tipo de volume que o gerenciador de filas será implantado não é com o que você deve se preocupar. O IBM MQ possui diretrizes específicas sobre quais volumes são suportados e quais volumes não são suportados. Dê uma olhada no MQ Knowledge Center para mais informações.

Os aplicativos do MQ podem ser executados local ou remotamente (para um gerenciador de filas).

(1) Aplicativos do MQ que se conectam localmente (modo de ligações) a um gerenciador de filas, podem tornar o desenvolvimento de aplicativos e suporte muito mais fácil, porque NÃO há rede envolvida na obtenção e / colocação de mensagens.

(2) Os aplicativos do MQ que se conectam remotamente (modo cliente) a um gerenciador de filas são muito mais complexos. Outra pessoa postou recentemente uma pergunta semelhante no MQ ListServer e aqui está a excelente resposta de T.Rob Wyatt.

There are a whole host of issues when consolidating from stand-alone QMgrs to shared hubs. The one you are asking about is among the most mechanical and uninteresting of the bunch. As FJ points out there are some security implications and the connectivity issues you yourself have stumbled across. Let me give you a high-level round-up of some others. The degree to which you experience most of these depends on how much the environment is currently stand-alone and how much sharing it currently has. The exception is data integrity when switching to client so I'll talk about that first.

No messages lost or duplicated, order mostly assured:

This requires XA transactionality. XA imposes its own set of design constraints, among which is that the app in question cannot fail over to a different QMgr. MQ generally behaves as everyone seems to expect in that no messages are duplicated, lost or disordered under normal circumstances.

Dupe messages, disordering possible:

This requires at least single-phase commit. If you GET a message off a queue under syncpoint and the client app gets a 2059 on the next API call, then you can be assured that the message will be rolled back and not lost. But the app will see it again and if it was processed correctly the first time it will appear to be a dupe. Also, if the app got a 2059 on a COMMIT after PUTting a message, it has no choice but to assume the COMMIT failed and issue the PUT again. Unlike the "functional duplicate" from the GET, this generates multiple identical messages.

The channel agent holding the transaction with one or more GETs won't release the messages until MQ or TCP times it out and kills the orphan connection. Since the rollback doesn't necessarily happen before the app reconnects, it is likely to get subsequent messages not under that syncpoint. When the orphaned channel is killed and the messages reappear on the queue, they will be delivered but the order will be disrupted.

Dupe, missing messages, disordering possible: Client connections that use no XA and no single-phase COMMIT can lose or duplicate messages or disorder them for the reasons stated above.