Disconnected Architecture With .NET

Question

I'm working with an n-Tier application using WinForm and WCF

Engine Service (Windows Service) => WCF Service => Windows Form Client Application

The problem is that the WinForm Client Application need to be 100% available for work even if Engine Service is down.

So how can I make a disconnected architecture in order to make my winform application always available ?

Thanks.

Answer 1

Typically you implement a queue that's internal to your application.

The queue will forward the requests to the web service. In the event the web service is down, it stays queued. The queue mechanism should check every so often to see if the web service is alive, and when it is then forward everything it has stored up.

Alternatively, you can go direct to the web service, then simply post it to the queue in the event of initial failure. However, the queue will still need to check on the web service every so often.

EDIT: Just to clarify, yes all of the business logic would need to be available client side. Otherwise you would need to provide a "verify" mechanism when the client connects back up.

However, this isn't a bad thing. As you should be placing the business logic in it's own assembly(ies) anyway.

Answer 2

Have a look at Smart Client Factory: http://msdn.microsoft.com/en-us/library/aa480482.aspx

Just to highlight the goals (this is sniped from the above link):

• They have a rich user interface that takes advantage of the power of the Microsoft Windows desktop.
• They connect to multiple back-end systems to exchange data with them.
• They present information coming from multiple and diverse sources through an integrated user interface, so the data looks like it came from one back-end system.
• They take advantage of local storage and processing resources to enable operation during periods of no network connectivity or intermittent network connectivity.
• They are easily deployed and configured.

Edit

I'm going ansewr this with the usual CYA statement of it really depends. Let me give you some examples. Take an application which will watch the filesystem for files to be generated in any number of different formats (DB2, Flatfile, xml). The application will then import the files, displaying to the user a unified view of the document. And allow him to place e-commerce orders.

In this app, you could choose to detect the files zip them up and upload to the server do the transforms (applying business logic like normalization of data etc). But then what happens if the internet connection is down. Now the user has to wait for his connection before he can place his e-Commerce order.

A better solution would be to run the business rules in the client transforming the files. Now let's say, you had some business logic which would based on the order determine additional rules such as a salesman to route it to or pricing discounts...These might make sense to sit on the server.

The question you will need to ask is what functionality do I need to make my application function when the server is not there. Anything thing which falls within this category will need to be client side.

I've also never used Click Once deployment we had to roll our own updater which is a tale for another thread, but you should be able to send down updates preety easily. You could also code your business logic in an assembly, that you load from a URL, so while it runs client side it can be updated easily.

Answer 3

You can do all your processing off line, and use some thing like Microsoft Sync Framework to sync the data between the client and the server.

Assuming both server and client are .net, you can use same code base to do the data validation both on the server and the client. This way you will have a single code base that will serve both server and client.

You can use frameworks like CSLA.NET to simplify this validation process.