Tools for Building an OCA (Occasionally Connected Application)

Question

I will be building an in-house, Occasionally Connected App (OCA). What technologies would you suggest I employ.

Here are my parameters:

1. .NET Shop(3.5sp

Answer 1

You could create this stuff from the ground up, it seems.

However, this seems an awful lot like a CRM application, and it wouldn't surprise me if you could find an enterprise software package to do this without starting from scratch and instead modify one of the configurations to meet your business rules.

In a previous life, I was a configuration developer for this thing called Siebel that might be close to what your'e looking for. They even have a built-in synchronization tool called Siebel Remote.

It might be a cheaper route to go than rolling your own from scratch.

Answer 2

Once you solve the problem of change detection and data movement, everything else is trivial. In other words technologies like WPF, Silverlight, Forms and even WCF are orthogonal to your main problem and your choice should be based on your personal preferences and experience. The real hard nut to crack is working disconnected and synchronizing changes. Which leaves two out-of-the-box avenues: Synch Framework or Replication.

I would say, for your scenario, definetely Synch Framework. Merge replication, like all forms of replication, is designed for systems that are connected continously with intermitent disconnects. And most critically replication can work only over static names. Laptops connecting from various hot-spots and ISPs have a nasty habit of changing FQ names with each connection. Replication can overcome this only if a VPN of sort is used and VPN is usually a major support issue. Replication is just not designed for the high mobility of OCA systems.

Synch Framework will pretty much force you to SQL 2008 back end because of the need to Change Data Capture or Change Tracking, both being SQL 2008 only features.

You will still have plenty of hard problems to solve ahead (authentication, versioning and upgrade, data conflict resolution policies, securing data on the client for accidental media loss etc etc)

Answer 3

Having worked on an occasionally connected application, I'd encourage you to look in to SQL Server CE for the client machines, with Sync Services to handle the connections. Here is a good tutorial.

Answer 4

use unique-identifier for key if you are creating stuff while offline and not connected and when you do connect, updating the database.

this is going to be way easier than using auto-increment key

Answer 5

I wrote an order taking program for wine sales reps. Here is the video. The client software is installed using click-once. That also installs SQL Server Express and loads the database. I used the Microsoft Sync Framework to sync the local database with the one on the server (see the last section of the video.)

• With powerful clients now I don't see any reason to not use SQL Server Express, it is free with a limit of 4GB.

• SQL CE had too many limitations - no stored procs being a major one.

• You will need to use GUIDs everywhere as the primary key - see the new NewSequentialID().

• I love click-once, it is a big time saver.

I'm looking forward to Silverlight, but just haven't had time to look into it. Not sure if I would have done it with Silverlight if doing it now or not.

Having said all this, this is not a project for anyone inexperienced. So I would also get some very experienced help.

Answer 6

Personally, I would say:

• .NET 3.5
• WCF Data Services (for communication between the client app and your data)
• SQL Server 2k5/2k8 (whichever you can use)
• Silverlight w/ Out of Browser Functionality
• VistaDB (to store data locally on the client until you can push to the server)