Anybody familiar with MQ?
-
What is the advantage of using MQ? We have a web application that needs to save data into an external sql server database. If it is up to me, I will write a simple web service and the web application will call this web service to do the job. But I was told that I must use MQ, the people who insisted on MQ have been working on this project for more than a year with no real progress (still in requiremetns gathering stage). I promised my manager to get the web service done in two weeks, may be that alone makes someone look extremely bad, therefore I must be stopped?
My .NET Business Application Framework My Younger Son & His "PET"
-
What is the advantage of using MQ? We have a web application that needs to save data into an external sql server database. If it is up to me, I will write a simple web service and the web application will call this web service to do the job. But I was told that I must use MQ, the people who insisted on MQ have been working on this project for more than a year with no real progress (still in requiremetns gathering stage). I promised my manager to get the web service done in two weeks, may be that alone makes someone look extremely bad, therefore I must be stopped?
My .NET Business Application Framework My Younger Son & His "PET"
Message queues have the advantage of providing guaranteed delivery. You could still do a web service and App using WCF, and use MQ as the transport mechanism. Some examples hereon CP: Sample Starter Project Using WCF and MSMQ[^] WCF Queued Messaging[^]
-
What is the advantage of using MQ? We have a web application that needs to save data into an external sql server database. If it is up to me, I will write a simple web service and the web application will call this web service to do the job. But I was told that I must use MQ, the people who insisted on MQ have been working on this project for more than a year with no real progress (still in requiremetns gathering stage). I promised my manager to get the web service done in two weeks, may be that alone makes someone look extremely bad, therefore I must be stopped?
My .NET Business Application Framework My Younger Son & His "PET"
Based on my understanding, MQ you can do the thing declaratively using a designer. It is similar to Biztalk in designing integration and similar to MSMQ is the messaging aspect. But I think you will still need a webservice either SOAP or POX. For simple applications, it does not make much sense but if you have a complex system talking with variety of different applications MQ may simplify the integration. I am guessing you mean IBM Webshphere MQ.
-
What is the advantage of using MQ? We have a web application that needs to save data into an external sql server database. If it is up to me, I will write a simple web service and the web application will call this web service to do the job. But I was told that I must use MQ, the people who insisted on MQ have been working on this project for more than a year with no real progress (still in requiremetns gathering stage). I promised my manager to get the web service done in two weeks, may be that alone makes someone look extremely bad, therefore I must be stopped?
My .NET Business Application Framework My Younger Son & His "PET"
Sonic documentation is extremely good. I had to install three different messaging servers to test them with an integration app (along with -- ugh! -- Kerberos, which has the worst documentation in the world!) The Sonic was the easiest, because the doc steps you through it very well, and the management console is a breeze. If you have trouble configuring it to work with your app, give me a shout.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Message queues have the advantage of providing guaranteed delivery. You could still do a web service and App using WCF, and use MQ as the transport mechanism. Some examples hereon CP: Sample Starter Project Using WCF and MSMQ[^] WCF Queued Messaging[^]
From what I read on MQ, it seems to be asynchronous. The message placed on queue will not be guaranteed to be delivered to receiving application immediately. My project explicitly requires the immediate return status (whether the data is successfully saved into the external database or not). It seems to be a total misuse of MQ.
My .NET Business Application Framework My Younger Son & His "PET"
-
Sonic documentation is extremely good. I had to install three different messaging servers to test them with an integration app (along with -- ugh! -- Kerberos, which has the worst documentation in the world!) The Sonic was the easiest, because the doc steps you through it very well, and the management console is a breeze. If you have trouble configuring it to work with your app, give me a shout.
I wanna be a eunuchs developer! Pass me a bread knife!
If I have to use MQ synchronously (the sending application has to know the processing status of the receiving application right away), is it possible? Does it defeat the purpose of MQ? Your insight is very much appreciated.
My .NET Business Application Framework My Younger Son & His "PET"
-
From what I read on MQ, it seems to be asynchronous. The message placed on queue will not be guaranteed to be delivered to receiving application immediately. My project explicitly requires the immediate return status (whether the data is successfully saved into the external database or not). It seems to be a total misuse of MQ.
My .NET Business Application Framework My Younger Son & His "PET"
Xiangyang Liu 刘向阳 wrote:
a total misuse of MQ.
Probably not the first or the last time either! :)
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
If I have to use MQ synchronously (the sending application has to know the processing status of the receiving application right away), is it possible? Does it defeat the purpose of MQ? Your insight is very much appreciated.
My .NET Business Application Framework My Younger Son & His "PET"
Not exactly synchronously (no blocking), but you can configure the resource adapter to fire back status messages on a separate queue or a notification topic easily enough, that can give the impression of synchronous behaviour.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Not exactly synchronously (no blocking), but you can configure the resource adapter to fire back status messages on a separate queue or a notification topic easily enough, that can give the impression of synchronous behaviour.
I wanna be a eunuchs developer! Pass me a bread knife!
Ok, I understand what you said. Thanks for the info. I have to do the following: 1. Send to MQ. 2. Try to read status from the receiver immediately. 3. If status is not there yet, keep polling until timeout. Sounds like a lot of fun to misuse MQ. :-D
My .NET Business Application Framework My Younger Son & His "PET"
-
Ok, I understand what you said. Thanks for the info. I have to do the following: 1. Send to MQ. 2. Try to read status from the receiver immediately. 3. If status is not there yet, keep polling until timeout. Sounds like a lot of fun to misuse MQ. :-D
My .NET Business Application Framework My Younger Son & His "PET"
heh. That's pretty much it. You'll be happy to know that everyone does it.
I wanna be a eunuchs developer! Pass me a bread knife!
-
From what I read on MQ, it seems to be asynchronous. The message placed on queue will not be guaranteed to be delivered to receiving application immediately. My project explicitly requires the immediate return status (whether the data is successfully saved into the external database or not). It seems to be a total misuse of MQ.
My .NET Business Application Framework My Younger Son & His "PET"
Xiangyang Liu 刘向阳 wrote:
My project explicitly requires the immediate return status (whether the data is successfully saved into the external database or not). It seems to be a total misuse of MQ.
Not to open a can of worms, but there really are two issues: 1. message delivery 2. success of acting on the message MQ guarantees message delivery (in a sense, I mean, if the computer goes boom, well, no messages), but it means that when the connection recovers, anything queued will be delivered. So asynchronous does make sense, but it (as you point out) implies that the response is asynchronous as well. When everything is working well, the effective "feel" is that the response is immediate, but it does mean internally you are dealing with an async response. Frankly, I think that architecture is actually better, and the separation of "message" vs. "action on the message" is important. Does that make sense? I feel like I'm being a bit vague. Marc
-
What is the advantage of using MQ? We have a web application that needs to save data into an external sql server database. If it is up to me, I will write a simple web service and the web application will call this web service to do the job. But I was told that I must use MQ, the people who insisted on MQ have been working on this project for more than a year with no real progress (still in requiremetns gathering stage). I promised my manager to get the web service done in two weeks, may be that alone makes someone look extremely bad, therefore I must be stopped?
My .NET Business Application Framework My Younger Son & His "PET"
write your own mq
Opium is my business. The bridge mean more traffic. More traffic mean more money. More money mean more power. Speed is important in business. Time is money. You said opium was money. Money is Money. Well then, what is time again? icalburner.net
-
Xiangyang Liu 刘向阳 wrote:
My project explicitly requires the immediate return status (whether the data is successfully saved into the external database or not). It seems to be a total misuse of MQ.
Not to open a can of worms, but there really are two issues: 1. message delivery 2. success of acting on the message MQ guarantees message delivery (in a sense, I mean, if the computer goes boom, well, no messages), but it means that when the connection recovers, anything queued will be delivered. So asynchronous does make sense, but it (as you point out) implies that the response is asynchronous as well. When everything is working well, the effective "feel" is that the response is immediate, but it does mean internally you are dealing with an async response. Frankly, I think that architecture is actually better, and the separation of "message" vs. "action on the message" is important. Does that make sense? I feel like I'm being a bit vague. Marc
Marc Clifton wrote:
Does that make sense?
Yes in a lot of situations. In this case, I question the use of MQ. The web app and the web service can be physically next to each other, the "actions" are simply data validation and calling a stored procedure to put the validated data into sql server. With MQ: 1. Web app executes code to put data in the queue. 2. MQ never fails to deliver data once #1 is successful (we all know that already :) ). 3. The receiving application executes code to get data from the queue, does data validation, and put data into sql server database. 4. Then it executes code to put processing status in #3 in the queue. 5. The web app has to execute code to get the processing status in #4 from the queue. Without MQ:: 1. The web app execuate code to call the web service (to do data validation and put to data into sql server database). Who would not have picked MQ in this case? :-D Seriously, even though #2 above is supposed to never fail, #1, #3, #4, and #5 all can fail. It just does not make sense to me. My .NET Business Application Framework My Younger Son & His "PET"
