MSMQ

[CodingYoshi]

I am fixing a tcp listening application which is accepting messages on a port. Once the message arrives it is sent to a queue using MSMQ. The message is then received from the queue and put into another queue. So it goes like so: Message arrives > Message is sent to queue (Q1) > Message is received from queue (Q1) > Message is sent to another queue (Q2) The same application is doing all this. I am not sure why this has been implemented this way. The idea is to accept messages in format x, convert them to format y and send it to another application. I understand the above might be unclear but I am still analyzing the code. I am starting to think the implementer did not understand the concept and use of message queues really well. What do you think? CodingYoshi Artificial Intelligence is no match for Human Stupidity.

[Luc Pattyn]

if there are three operations: 1. receive data 2. convert data 3. transmit data then I can imagine a lot of situations that would require or want these to happen independently, i.e. on separate threads and/or using asynchronous I/O; and then having queues between 1 and 2, as well as between 2 and 3, seems logical. OTOH if nothing is happening in between "Message is received from queue (Q1)" and "Message is sent to another queue (Q2)", then I would doubt that is the most logical and efficient approach. :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

[PIEBALDconsult]

I would avoid message queues at most any cost. They seem like a solution looking for a problem, or maybe a solution to a problem that has since moved on to a better solution.

[Mycroft Holmes]

PIEBALDconsult wrote:

solution to a problem that has since moved on to a better solution

I'm interested to hear your thoughts on this. The last time I used MSMQ was in 2000 and using VB6. It sounds like a good solution to the above problem if he does not control the source and final destination but still has to impose some formatting on the data between the 2 systems.

Never underestimate the power of human stupidity RAH

[PIEBALDconsult]

I was speaking in general. Maintaining an existing system is one thing, but I wouldn't (and haven't) create a new system based on message queues. On my last job I had to create a number of processes (Windows Services) and some had to pass data back and forth, but I simply had them write data to the appropriate database tables. On my current job, I'm helping maintain a queue-based system (in-house developed?). Again, some applications may need to pass data to other applications. So messages are written to queues to be read by the other application. But I see no benefit of using queues over simply writing the necessary data to a table that the other application reads. In my opinion, the whole message queueing system is a needless extra middleman that merely adds complexity.

[Mycroft Holmes]

PIEBALDconsult wrote:

no benefit of using queues

That I can understand queues are sooo 90s. I cannot imagine designing a solution with queues today but back then they were a valid solution.

Never underestimate the power of human stupidity RAH

[RobCroll]

It's there to ensure durability (assuming MSMQ is setup to be durable). There are now other options but prior to .NET 3.x it provided a durable solution for third party providers. It also works well in remote locations where connectivity isn't assured. Connectivity may not be an issue here but if the message received, somehow crashes the service/server or the server falls over for whatever reason, the message should still survive.

"You get that on the big jobs."

[CodingYoshi]

I understand, however, how can the message survive if the system crashes before being inserted into a queue? I guess once it is inserted, only afterwards it can survive. I studied the code more and looks like nServiceBus is used as well. Any idea why nServiceBus is used? I did some research and I am starting to think nServiceBus is similar to WCF but has differences. Also nServiceBus is built using MSMQ so why are the messages being inserted into queues again if nServiceBus is taking care of that? CodingYoshi Artificial Intelligence is no match for Human Stupidity.

[RobCroll]

If the system crashes, before inserting into queue there isn’t much you can do. Hopefully the sender is expecting a response and so will assume that the message was not successful. If all is good, receive message, queue to MSMQ and then respond that message has been received. nServiceBus I know nothing about, sorry.

"You get that on the big jobs."

[PIEBALDconsult]

Wow, we agree on something else. :badger:

[PIEBALDconsult]

RobCroll wrote:

in remote locations

Sure, but I'd likely roll my own socket messaging engine that the applications don't need to know about.

[RobCroll]

It was a while ago but the way I remember using MSMQ. The remote server would run a service that handled the tcp/ip communications with the remote applications. The remote server also had in and out MSMQ's. Another service would manage the MSMQ's in the city location. We didn't worry about testing for connectivity, MSMQ managed the "bridging" for us. Hope that helps but it was a while ago. Also each OS had it's own version of MSMQ. That may not be the case now but ensuring the queues were durable could be problematic.

"You get that on the big jobs."