Re: Webservices - the way to go...?
- From: "John Timney \(MVP\)" <x_john@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 11 Sep 2006 10:51:36 +0100
Chris,
I agree with everything that Nick has suggested and given what you have said
about your lack of secure network connectivity your between a rock and a
hard place - the UNC option given you are not using a secure VPN is not the
best approach. To complement what Nick has suggested (and they are good
suggestions worth considering) there is another option to consider and that
may be to use some form of terminal server to your head office and expose
your single application via a remote desktop. It could in theory save you a
lot of work and should have a relatively low learning curve.
Regards
John Timney (MVP)
"Nick Malik [Microsoft]" <nickmalik@xxxxxxxxxxxxxxxxxx> wrote in message
news:PqCdnXYpKKDzBpzYnZ2dnUVZ_tqdnZ2d@xxxxxxxxxxxxxx
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.
If I was going to use winforms I would likely create a single
application that had its business layer as a webservice and deply that
same app to both locations otherwise you'll be managing two approaches
to data access, but then I would be unlikely to develop a distributed
application using winforms when webforms are ideally suited for it, even
using a webservices data layer to handle all the database interactions.
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).
You can of course stick with your two app scenario, use a single access
database and access it remotely over a UNC share from your new app.
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.
--
.
- References:
- Webservices - the way to go...?
- From: ChrisM
- Re: Webservices - the way to go...?
- From: John Timney \(MVP\)
- Re: Webservices - the way to go...?
- From: ChrisM
- Re: Webservices - the way to go...?
- From: Nick Malik [Microsoft]
- Webservices - the way to go...?
- Prev by Date: Change OpenFileDialog Size (width and height)
- Next by Date: RE: Hosting ASP .NET Applications On A Windows Media Server...
- Previous by thread: Re: Webservices - the way to go...?
- Next by thread: Bounded DataSet slow data updation problem
- Index(es):
Relevant Pages
|
