Hi Chris,
To summarize the posts so far: you have a winform app. You asked if you
needed to design for two sites and the company said 'no'. Now they want you
to deploy to two sites. (Sounds like a change request. Tell them that they
get nothing for free.)
You also said that you don't have experience with ASP.Net so you'd like to
stick with Winforms. Nothing wrong with that.
Yea, but as I said, I had already written the current winforms application
before the second site was even being talked about. At the time of writing
it, I was told I did not need to consider the possibility of a second
site(I did ask).
Also, the functionality at the two sites will be totally different. Main
site: some stock, but mostly invoicing, estimating, deliveries etc. Second
site: Purely stores stuff (primarily booking out of stock). So there is
some common ground between the two, but the second site does not need (and
should not have) access to 90% of the functionality of the main system.
True that you have different users, but you can still have a single
application. When a user logs in, you can drive the amount of access based
on the user. That way, when someone from the home site visits the remote
site and needs to perform a function, they don't have to VPN back to the
headquarters because the local app doesn't work. In other words, instead of
making your security based on the app, make it based on the role assigned to
the user (Role Based Security).
Are you being serious?? Don't forget the second app will be running on a
seperate site 50 miles away, and there is no comms between the two sites
(other than telephone and internet obviously).
With all due respect to John, who I respect and admire, please don't do
this. You could, of course, but there are so many better ways to go.
I would suggest two ideas, together or seperately. Both assume winforms.
I'm also going to make another assumption (below).
1) Upgrade your database to SQL Server. If you are running SBS, you already
have SQL Server. Then, you can use the same client to connect to the SQL
Server.
Correlary: if you have SQL Server 2005, you can expose web services directly
from SQL Server. You'll have to rewrite the parts of your app that call the
database, to call these web services instead. (See below) but the services
can be generated for you. Kinda nice.
2) If you designed your app along the lines of modern patterns, you have
seperated out the database access layer from the rest of your app. If this
is the case, you should not have a lot of difficulty adding a layer between
the calls to the database layer and the actual database layer code... a web
services layer. This would allow you to deploy your data base layer on the
same machine as the database itself, along with web services, and would
allow the front end to call the services in exactly the same way as they
used to call the database. This bit of refactoring should work out OK for
the situation you describe. Note that you are going to want to reduce the
'chattiness' of the connection, so if your app ALWAYS calls 12 queries when
you start up, roll them together as a single stored procedure call that
returns 12 recordsets, and have your app retrieve them as a single service
call.
Shared assumption:
Your app needs to be able to access the server in the corporate office
securely. I would strongly suggest that, if your company doesn't already
have it, to extend your corporate network to the external site using an
IPSEC connection. You may need a Microsoft Partner in your area to help you
set it up, but SBS has all the software on it that you'll need, although you
may need another instance of SBS (I'm not sure).
At a minimum, if you have only one or two computers at the remote location,
you can use VPN. I prefer VPN to be in the firewall, rather than in
software, but you can do both. The end result is that your company will
make a 'corporate network' available to the remote location.
If this is simply not possible, then the option of using the existing app to
SQL Server only should be excluded. In this case, you can make the web
services directly available over the internet, using HTTPS, and add
credentials that your app will have to know about in order to call them.
Personally, I have no great love for doing this, because any other needs
from that PC to the corporate network cannot be served over the same
connection... it's an app-level security scheme when a network level scheme
is more appropriate. On the other hand, the call doesn't belong to me.
It's up to you.
As hard as this sounds, it is much easier to secure web services through
credentials and HTTPS than it is to secure a SQL Server that is visible over
the Internet.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
