Archives
- ► 2012 (8)
- ► 2011 (157)
- ► 2010 (174)
- ► 2009 (12)
Which topics would you like us to cover more?
Latest comments
- How to reset you Kindle
3, eve...
Thanks for this article and the related "Inside th...
By H K - How to reset you Kindle
3, eve...
How do you drain power on the board? I dont have r...
By Grace - How to reset you Kindle
3, eve...
You're welcome!
By Bas - How to reset you Kindle
3, eve...
Thanks man....removing the battery worked like a c...
By DaveMan - nHapi
example
Hi Slypete, Thank you for your comment. This way w...
By Bas - nHapi
example
Hello, Employing .Net dynamics, one can implement ...
By slypete - Implementing MLLP in C#
Hi Mayura, I'm not sure I understand your question...
By Bas - Implementing MLLP in C#
I have used SSL stream to secure the MLLP transact...
By Mayura
Latest tweets
| Why use MQ instead of webservices in webinterface backoffice communication |
| Written by Division by Zero |
| Friday, 19 March 2010 09:53 |
|
Yesterday I had this discussion again. Why use MQ instead of a webservice. Actually it is a good question to asked when designing an application. Actually, it's a question you must ask. In this case we are building a .Net website which communicates with an Oracle back office system. The website is mainly used to display data from the back office, but now we have to update the back office. the display function uses webservices to get the data. The question is, should the update function use the same technology? We asked our business what they wanted. Actually, we asked: "Does the user need to see the changed data right away?" As you would expect the answer was yes. The same answer I would have given if I was my client. This means we have to choose webservices, but is this still the right choice? Guaranteed delivery MQ guarantees the delivery of the message. Http doesn't. If everything works as expected there is no problem: the happy flow. But, as always, Murphy's law applies. The problem with Http is in the fault situations. Even if the service returns an error, we should be able to handle it, but what if we get a time out in our communications? Do you know what happened? Did the service get the message and handled it, but the answer got lost? Or didn't the message even reach the service? We can retry a few times if the service is robust enough. To do this we have to write some code, which could contain bugs and it cost more money to implement. And if the retry fails we have to handle an unknown error. Mostly it is to tell our user that "something went wrong." (I hate when that happens, don't you?) If we use MQ to send the message, we know it will reach the service. We know it will be handled and we know that, in most cases, the result will quite soon, if not immediately, be visible to the user. In this case we can communicate this trust to our users: "We have got your change and we will process it." Image is the key What image does our company want to present to the user? We are fast, mistakes could happen, and we apologize for them. Or is it that we are trustworthy, you (our client) can rely upon us, but sometimes it will take time. The choice depends on the company profile and the money it is willing to invest. If you work at a bank, the latter image would be a good idea. If you work at a small company with a small client base and a lot of questions, the first will be. Tags:
|
Computer science is no more about computers than astronomy is about telescopes. - Edsger Dijkstra





Comments
RSS feed for comments to this post