Working on a application design with a failover mechanism that too from the user perspective. Application will be a n-tier architecture with UI, Business Layer and services interacting with different platforms.
Logic to implement -
1) Even if one of backend platform is down then user will not get a error message. User should be able to submit his request (for various different platforms such as SP, documentum and SQL) and when the platform is up then system should be able to process
the request. For this need to store user request temperorily (Messages Queues?) and then process
2) What if system has started process request and then one of platform goes down? As some of the platform request can take hours to complete.
3) IF user request is to be stored at a temporary location such as Message Queue or SQL, then only Business layer (BL) should interact with it or both BL and platform services?
Any guidance on application design will be helpful. Thanks
1) Even if one of backend platform is down then user will not get a error message. User should be able to submit his request (for various different platforms such as SP, documentum and SQL) and when the platform is up then system should be able to process the
request. For this need to store user request temperorily (Messages Queues?) and then process
You could use something like a service or message bus to handle this for you. Something like
NServiceBus?
ankushgandotra
2) What if system has started process request and then one of platform goes down? As some of the platform request can take hours to complete.
If you are performing something like the previous question, then most message buses will support re-tries in cases where a particular process wasn't successfully executed.
ankushgandotra
3) IF user request is to be stored at a temporary location such as Message Queue or SQL, then only Business layer (BL) should interact with it or both BL and platform services?
This is really going to vary on how you want to implement it (i.e. up to you).
I believe you posted this on MSDN as well or it automatically cross posted (not sure). Anyway...
You are on the right track. The proper solution is to use a distributed architecture.
As you pointed out, you need a reliable storage medium. A queuing technology such as (RabbitMQ, Azure queues, WebSphere message queues, Microsoft message queueing, Hangfire). Any kind of reliable storage should work. You will also need a way to store
the background work in that storage medium.
You need a host to perform the background work. An Azure WebJob if you are familiar with it, a service, or you can use a separate thread in an ASP.NET app (see below). The host must be reliable in the sense that it should either complete the work or leave
the work in storage to try again, but not both. You should also implement “poison message” recovery. If there is background work that gets into the system, and can’t complete correctly / successfully, there should be a procedure for removing that background
work and setting it aside so that the system as a whole can continue processing.
Your BL (Business Logic) should perform business logic. You should implement service interfaces that your business logic would go through. Better “SoC” (separation of concerns) this way.
You should check out Hangfire. It’s an open-source framework that helps you to create, process and manage background jobs
None
0 Points
4 Posts
.NET Architecture with fail over mechanism
Mar 28, 2016 06:23 PM|ankushgandotra|LINK
Hi,
Working on a application design with a failover mechanism that too from the user perspective. Application will be a n-tier architecture with UI, Business Layer and services interacting with different platforms.
Logic to implement -
1) Even if one of backend platform is down then user will not get a error message. User should be able to submit his request (for various different platforms such as SP, documentum and SQL) and when the platform is up then system should be able to process the request. For this need to store user request temperorily (Messages Queues?) and then process
2) What if system has started process request and then one of platform goes down? As some of the platform request can take hours to complete.
3) IF user request is to be stored at a temporary location such as Message Queue or SQL, then only Business layer (BL) should interact with it or both BL and platform services?
Any guidance on application design will be helpful. Thanks
Regards,
Ankush
All-Star
113010 Points
18360 Posts
MVP
Re: .NET Architecture with fail over mechanism
Mar 28, 2016 06:38 PM|Rion Williams|LINK
You could use something like a service or message bus to handle this for you. Something like NServiceBus?
If you are performing something like the previous question, then most message buses will support re-tries in cases where a particular process wasn't successfully executed.
This is really going to vary on how you want to implement it (i.e. up to you).
Participant
1190 Points
395 Posts
Re: .NET Architecture with fail over mechanism
Mar 30, 2016 05:06 PM|deepalgorithm|LINK
I believe you posted this on MSDN as well or it automatically cross posted (not sure). Anyway...
You are on the right track. The proper solution is to use a distributed architecture.
You should check out Hangfire. It’s an open-source framework that helps you to create, process and manage background jobs
http://hangfire.io/
If you are using ASP.NET, have a look at using HostingEnvironment.QueueBackgroundWorkItem
https://msdn.microsoft.com/en-us/library/dn636893(v=vs.110).aspx