partially connected application using asp.net 3.5 (not mobile apps)

Question

We had a requirement to build a ASP.NET 3.5 web application using web forms, WCF, ADO.NET and SQL Server. The users would connect via Internet.

Recently we understood that it is possible that users would often remain disconnected and would have Internet access intermittently.

I need to understand if we can create occasionally connected web application using asp.net 3.5 - what all technologies/features we need to use? Is MS Sync Framework the answer to the problem - is it a viable option to use with web application?

Is windows application the right approach instead of web applications - where the business logic would be run at the client itself, using local SQL Express editions with data then been synced up with Enterprise SQL server at server end when connection is established using replication and/or MS Sync framework. In that case is there a need to use WCF?

Does Silverlight applications help in this context -building paritally connected web apps?

Really appreciate if you can give pointers to how to go about this task of creating .net partially connected apps (not mobile apps)?

Answer 1

It looks to me as if you'll need to store your client data locally when not connected. If you use wcf you can determine what type of protocol to use according to connectivity without affecting your main code e.g. tcp/ip for LAN, http for internet and msmq for storing up data when disconnected. If data for transfer is stored up using msmq, as soon as a connection is remade then the data will be passed to your main server. If you write your wcf, or communications code to run as a service (assuming windows functionality here) then it is up to you whether to retain the asp code or write a new windows app.

edit

Setup MSMQ at both ends, its part of windows setup and can be installed on a client machine, just the same as IIS is, it's on the installation disk but not installed by default.

I wouldn't use it to get web pages, have those available on the local machine, but instead use it to queue up data that MUST get back to the server. Your data access layer should be separated from your GUI layer anyway. I assume that your using the MVC pattern or similar.

I don't know what your application is requried to do but here is the example that I've worked on.

A mobile user who visits clients. He has a replicated copy of a company product database on his laptop. When he visits client sites he may not be able to connect to his company server, but still wants to place client orders. This he does using his laptop based application and database. Order data is queued up in MSMQ on the laptop.

As soon as he is able to connect to his company server MSMQ automatically sends the order data. The server has queued up MSMQ messages of changes to pricing and stock etc. that took place whilst he was disconnected. These are now received and the local database is updated.

The choice of TCP/IP, HTTP or MSMQ all happens seemlessly to the main application, the WCF code copes with the choice.

Answer 2

From what I know, you have two options:

1. Use Gears (abandoned) or Web Storage to store and sync local data, combined with heavily javascripted web pages that can detect loss of connection and work against the local data store.

2. Use the Sync Framework with a rich client (WinForms, WPF or possibly Silverlight OOB if it gets supported). The Sync Framework does not require a local installation of a database, instead it uses SQL Server Compact, which is simply a local file.

Answer 3

At this stage using Sync franework with probably rich client seems to be better option. Thanks a lot Guys for taking your time out and trying to answer my queries. I will let you know the technologies used after i manage to deploy the app!