Is message queuing still a good answer?

Question

A decade and more in the past I studied and used IBM's MQSeries and Websphere MQ software. It seemed to be a great solution for connecting two applications in different companies at different locations: the app at each company could drop off a message with MQSeries on the local machine, MQSeries would transport it to the machine in the other company, and the app on that side would pick up the message locally.

Fast forward to today: I no longer work for IBM, but I'm trying to solve a similar problem. My app needs to send a few messages a day, each a few MB or less, to an app at a remote company, and receive a similar number of somewhat smaller replies.

Is message queuing middleware still a good solution to this architectural need? I've been trying to prototype this with RabbitMQ, but the above seems to be an abnormal thing to do with RabbitMQ. Am I barking down the wrong rabbit hole?

Answer 1

sure it can be - if the remote company intends to provide the same service for others and not just you.

perhaps WMQ low latency is what you need, since there is no server required.
- WebSphere MQ Low Latency Messaging varies from conventional WebSphere products such as WebSphere MQ, WebSphere Message Broker, and WebSphere Application Server in that there is no installed and configured product infrastructure such as queue managers, message brokers, or application servers. Thus, there are no specific product components to be monitored, measured, and managed.

http://www-03.ibm.com/software/products/en/wmq-llm http://pic.dhe.ibm.com/infocenter/wllm/v2r5/index.jsp?topic=%2Fcom.ibm.wllm.doc%2Fintroductiontowebspheremqlowlatencymessaging.html

Of course, a simple RESTful web interface might be able to provide the same functionality.

I do not recommend writing TCP socket applications - why do all that mid-weight lifting when there are so many products out there that will do the heavy and mid-weight lifting for you? You want to only do lightweight lifting - Send the request, get the response - 6 2 and even, over and out.

You need to draw up your list of requirements reagrding: - reliability - how critical is it if a request or response gets lost? - recoverability - can in-flight messages be recovered and resent if the application(s) crash? - round trip time - one side of latency - 1:1 service? many-to-one?

I hope this helps. Dave

Answer 2

WebSphere MQ can still solve your problem... I think the scenario is point to point communication with Request-Response scenario. You can use some relatively new stuff like JMS which integrate well with your application.

But if you are very sure that its only 2 applications that will communicate with each other and there is no network issue that will crop up, you can go in for simple socket communication.

The other way to solve the problem is to share a common database between the 2 applications.