Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I want to design a bullet-proof, fault tolerant, DB driven web application and was wondering on how to architect it.

the system will have a asp.net UI, web services middle tier and SQL2005 back end. The UI and Services will communicate using JSON calls.

I was wondering on how to ensure transactions are committed and if not for any error to bubble up and be logged. ideally the action to be retried a couple times after 5 minute intervals, like an email app does.

I was planing to use try catch blocks in SQL and was wondering what the interface (or contract if you will) would look like between the SQL stored procs and the Services that call them would look/ function. this interface will play 2 roles one is to pass params for the proc to function and return expected results. the next will be for the proc to return error information. maybe somethign like error number and error message.

my quagmire is how to i structure this intelligently so that the services expect and react accordingly to both data and error info returned from procs and handle each accordingly?

is there a framework for this because it seems very boiler plate?

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

Of course! Like most interesting problems in mission-critical applications, this was actually solved by IBM in the 1970s, but the IT industry is always chasing the shiniest new thing and has no respect for the great engineers of the past. I am referring of course to message oriented middleware, or as it was known back in the day, TPF. The principle of this is actually very simple, and has been proven time and time again, by banks, airlines, telcos, you name it.

The fundamental operations are, to place a message on the queue, and to take a message off the queue. So when your application needs to do some work, it packages that as a message and places it on the queue for the next service. The TPM then dequeues that message and attempts to get work done on it. If this fails, the message simply goes back onto the queue to be tried again, and if it continues to fail, gets shunted across to the queue that handles failures. The message bus also handles routing, load balancing and all that good stuff. You can buy these capabilities off the shelf: MQSeries and Tibco Rendezvous are the "serious" ones, but there are plenty of others around, many of which are compatible with JMS so you aren't tied into one vendor (of course if you go JMS then you are also bound to the lowest common denominator). You spec your message bus to be ultra-reliable and fault-tolerant, then you just hang the services off the back of it, and put your app on the front. SOA is another example of an old idea that's been reheated with new buzzwords...

share|improve this answer
    
I was thinking more of a paradigm for interfacing the app to the SQL db such to create a contract that can handle both the result set as well as a non-grid result per-se for errors –  kacalapy Apr 20 '11 at 16:56
    
What's the problem? They're all just messages. The way to think about this is app <-> bus <-> DB. The intelligence is in the messaging layer. –  Gaius Apr 20 '11 at 16:58
    
PS "paradigm" probably doesn't mean what you think it does... –  Gaius Apr 20 '11 at 16:59
    
PPS probably neither does "mission critical", nothing wrong with the technologies you've picked, but none of them are designed for 5 9s. Right tool for the job. –  Gaius Apr 20 '11 at 17:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.