Webservices - the way to go...?

[ChrisM]

Hi,

I have written a stand alone WinForms application with an MS Access back-end
for the (small)company I work for. They are now talking about moving a part
of their operations into a second site 50 miles away from the main one.

The second site will simply be a stores. They will need some software in
order to do a few things here, but this will probably come down to half a
dozen or so main functions (booking stock in, issuing stock etc)

I'd like to be able to use the main database (on the server at head office)
to run this remote system, but I've got very little experience of
distributed systems.

Would a second Winforms app communicating with the database via webservices
be a sensible way to go?

Any suggestions, hints/tips or recommendations of best practices gratefully
received!!

Regards,

Chris.

[John Timney \(MVP\)]

Webservices can be useful for any distributed application. That said, you
may be as well simply creating a few webpages and accessing your database
via that. Its realtively easy to get a winform talking to a webservice, but
you'll need to consider that fact that you need to deploy and manage a
webserver to use webservices, or webforms.

It is possible to host the ASP.NET runtime in an app, by hosting the ASP.NET
runtime and having your WinForms apps act as webservices server, so in
theory your current client could be a webserver for your new app. Not for
the faint hearted but guidance here if your interested:
http://www.microsoft.com/belux/msdn/...staspnet1.mspx

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.

Some light reading
http://www.15seconds.com/Issue/010530.htm
http://samples.gotdotnet.com/quickst...FormsData.aspx

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.
--
Regards

John Timney (MVP)
"ChrisM" <ch**************@suedeyahoo.comwrote in message
news:ug**************@TK2MSFTNGP03.phx.gbl...

Hi,

I have written a stand alone WinForms application with an MS Access
back-end for the (small)company I work for. They are now talking about
moving a part of their operations into a second site 50 miles away from
the main one.

The second site will simply be a stores. They will need some software in
order to do a few things here, but this will probably come down to half a
dozen or so main functions (booking stock in, issuing stock etc)

I'd like to be able to use the main database (on the server at head
office) to run this remote system, but I've got very little experience of
distributed systems.

Would a second Winforms app communicating with the database via
webservices be a sensible way to go?

Any suggestions, hints/tips or recommendations of best practices
gratefully received!!

Regards,

Chris.

[ChrisM]

Hi John,

Thanks for your reply...

Webservices can be useful for any distributed application. That said, you
may be as well simply creating a few webpages and accessing your database
via that. Its realtively easy to get a winform talking to a webservice,
but you'll need to consider that fact that you need to deploy and manage a
webserver to use webservices, or webforms.

Thought about that, but I've not got much experience in ASP.NET and this
needs to be done fairly quickly, so not sure if I've got time to learn... It
will be being used by total computer phobes, so need to be very robust. I
can do this with a winforms app, but not sure about a webby one...

>
It is possible to host the ASP.NET runtime in an app, by hosting the
ASP.NET runtime and having your WinForms apps act as webservices server,
so in theory your current client could be a webserver for your new app.
Not for the faint hearted but guidance here if your interested:
http://www.microsoft.com/belux/msdn/...staspnet1.mspx

I'll check that out when I have a few minutes, but main site has SBS which
already includes a webserver. I don't really want to have to rewrite the
existing system if possible due to the time constraints.

>
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.

>
Some light reading
http://www.15seconds.com/Issue/010530.htm
http://samples.gotdotnet.com/quickst...FormsData.aspx

Thanks I'll check them out.

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).

Cheers,

Chris.

>

"ChrisM" <ch**************@suedeyahoo.comwrote in message
news:ug**************@TK2MSFTNGP03.phx.gbl...

>Hi,

I have written a stand alone WinForms application with an MS Access
back-end for the (small)company I work for. They are now talking about
moving a part of their operations into a second site 50 miles away from
the main one.

The second site will simply be a stores. They will need some software in
order to do a few things here, but this will probably come down to half a
dozen or so main functions (booking stock in, issuing stock etc)

I'd like to be able to use the main database (on the server at head
office) to run this remote system, but I've got very little experience of
distributed systems.

Would a second Winforms app communicating with the database via
webservices be a sensible way to go?

Any suggestions, hints/tips or recommendations of best practices
gratefully received!!

Regards,

Chris.

[Nick Malik [Microsoft]]

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.
--

[Nick Malik [Microsoft]]

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.
--

[John Timney \(MVP\)]

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]" <ni*******@hotmail.nospam.comwrote in message
news:Pq******************************@comcast.com. ..

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.
--