Hi all,

I'm not sure whether it's the right place for my question. The scenario is:

A web-based .net 2.0 application with 2 servers for each location, i.e. web server and database server. Multiple PCs will be provided for users to access the application. As with the original design, this is an internal application, i.e. which will only be used in a specific location with no internet access. With the new requirements, the application will be used in 2-3 locations, where data for each location should be able to share both internally as well as among all of these locations.

My question is, should I develop a seperate program to store and "centralise" the data from the application of these locations and all the applications from these locations should sync. the data to this centralised program. If the user in location A wanted to access the data from location B, the application in location B should make the queries from this individual program. Or, no seperate program is needed and the application in location A should make the queries from the application in location B directly?

Thanks.

I would question the logic of having a web based application in more than one location in the first place, whats the point?  If each location is on the same network (internal), which it must be if they want you to share the data, then whats wrong with holding the application in one location?  Do they have a specific requirement as to WHY it has to be held locally within a location?  Are they saying that each location has no network connection whatsoever to the other locations?  If so how would you merge the data?  would you send data on disks to each location? Too many questions at this point in time to answer your question...

To further clarify my question, at the very beginning of the project, they have only 1 office where all the PCs are in the same network. During the development, the are planning to have new office(s) in different locations (not in the same building) in the near future. These offices are not networked together but they want the data can be shared, like users in office A can check the work status of the users in office B, at any time.

If the offices are not networked together then you are going to struggle to keep the data up to date.  They would have to exchange data through physical methods, ie portable HDD or CD/DVD/Blu-Rays and in either case, you are going to have to manually check the consistency across the databases.

My biggest worries in this situation would be a) data protection and b) data consistency.  You would also have to manually handle the primary keys of your data.

One solution would be, and this is assuming that users in location A only want ReadOnly access to location Bs data, you could create a data warehouse that merges the 3 databases (1 in each location) and then send copies of this data to each location to provide readonly access to the data.

I think your best best to 'share' or provide access for each of the locations to read data from another is through a service exposed on the internet (not intranet), like a WCF service.

Your 1st thought might be, "Well I don't want this data exposed to the public...".  That will not be a problem.  The extremely robust security model of WCF will provide you with ample support to secure your service both in the message, transport layer, and user authentication / authorization.

I did see you mentioned 'no internet access' but is this a true wall, where the users can not get on the internet to even access Google, or was this just the initial thought of keeping data inside and secure?  If you truely have no outside access and can not use a service like this, then you are going to have a sync problem to tackle and will want to use some of the suggestions presented previously.  I would really push for these sites to be able to communicate though, as the sync process could turn out to be a nightmare.

If your individual site apps connect to the WCF service that sits in the middle, you could access the data securely from wherever and not have to worry about any data sync issues, etc. 

With this solution you do not need to worry about computers being on the same network at all; it is not an issue.  The only thing the computers will need is some kind of network access.

After all, your very scenario is what made so many headaches 10+ years ago, but more recently it has been easier to conquer the problem of connecting multiple individual networks via services like .asmx and WCF.

Mark DotNet Evans and atconway, Thanks for both of your suggestions. For the WCF, it means I need to switch my project from .net 2.0 to .net 3.0/3.5?

john.lam:

For the WCF, it means I need to switch my project from .net 2.0 to .net 3.0/3.5?

Correct.  WCF was avaliable in 3.0 using the extensions for VS.NET 2005, but I think it will be easiest to develop the service using VS.NET 2008 with the .NET Framework 3.5 SP1.

However, if the Framework version is a road block, you can always make a .asmx web service which will work with any Framework version.  The security model from WSE 3.0 is really obsolete at this point because of WCF, but you could still make it work if needed.

Thanks! I'll have a look on WCF.

I'm thinking, as they want to host the server in their own place and they have only 1 domain, which seems the program data from each of the location must be sent to that server frequently in order to keep the data up-to-date, so that the users from different locations can retrieve the data thru the WCF service, i.e. which involves writing the data to and reading the data from the data server?

john.lam:

as they want to host the server in their own place and they have only 1 domain, which seems the program data from each of the location must be sent to that server frequently in order to keep the data up-to-date

The frequency of calling the service should not be a problem.

john.lam:

so that the users from different locations can retrieve the data thru the WCF service, i.e. which involves writing the data to and reading the data from the data server

Again if I understand you correctly, calling the WCF service often which acts as the gateway to the data should not have any issue.  Between a database like SQLServer and using WCF you should be able to have lots of calls to the service and database without issue.  Now locking data and simutaneous updates to records, etc will have to be handled properly in SQLServer if you feel that is an issue, but that is a question for another day once you get into those specifics.