Daily using/supporting

Get Firefox browser!
Get Thunderbird!
Get Opera browser!
Get The Gimp!
Get Inkscape!
Get LibreOffice!
Get Videolan!
Get Linux!
Get Mandriva!
Get Joomla!
Hacker Emblem

Archives

Which topics would you like us to cover more?

Latest comments

Latest tweets

about 2 days ago Using REDIPS.drag to add drag and drop to your .Net webapplication #li #dib0 http://t.co/n8zY3s7d
about 8 days ago http://t.co/cknQcDbo #Kindle
about 16 days ago Freedom isn't the ability to choose what to do or say, but the ability to choose what not to do or say #freedom
12 Apr 2012 Force the use of a networking adapter using C# #li #dib0 http://t.co/ZTJOPzOz
9 Apr 2012 Mandriva 2010.2 and USB devices in Virtualbox http://t.co/fwq9gbHB
9 Apr 2012 Execute a http request to you own site with PHP http://t.co/DIvWPrpd
Home Architecture, security and coding Why use MQ instead of webservices in webinterface backoffice communication
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.

 

Comments  

 
+1 # Remco Hulshoff 2010-03-20 10:05
Maybe you should turn the question around? If you ask 'fast or slow' the answer is predictable. But if you ask 'high chance of error or low chance of error' the answer is also going to be predictable. Ask the business if they want to present their clients with a potential error or rather with a 'this may take a while' message...
Reply | Reply with quote | Quote
 
 
0 # Bas 2010-03-20 15:55
:lol:Thanks for the addition. You're right. That's what I tried to say. In the end it's what the company wants to communicate to their clients. A potential error isn't a bad thing depending on what your clients expect of you (such as speed or being cheap in comparison to other companies).
Reply | Reply with quote | Quote
 

Add comment


Security code
Refresh

Computer science is no more about computers than astronomy is about telescopes. - Edsger Dijkstra


© 2009 - 2012, Division by Zero

Template based on the empire template by joomlashack 

Valid XHTML 1.0 Strict  Valid CSS!  Creative Commons License
This work by Division by Zero is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Netherlands License.