views:

23

answers:

1

This question is an updated version of a previous question I have asked on here.

I am new to client-server model with SQL Server as the relational database. I have read that public access to SQL Server is not secure. If direct access to the database is not a good practice, then what kind of layer should be placed between the server and the client? Note that I have a desktop application that will serve as the client and a remote SQL Server database that will provide data to the client. The client will input their username and password in order to see their data. I have heard of terms like VPN, ISA, TMG, Terminal Services, proxy server, and so on. I need a fast and secure n-tier architecture.

P.S. I have heard of web services in front of the database. Can I use WCF to retrieve, update, insert data? Would it be a good approach in terms of security and performance?

+2  A: 

A web-service tier is pretty common for smart-clients as a layer between the user-client and the server. This allows:

  • simple networking (http only)
  • you have an app-layer in which to put validation etc without upsetting the db
  • you can have security that isn't tied to the db
  • the db can run as fewer accounts (app accounts), allowing greater connection pooling
  • you can "scale out" the app layer
  • you can cache etc above the db
  • you can have a richer app layer, with more services than sql server provides
  • the client has a known API, and never knows about the db (which is an implementation detail)

You can use WCF to talk to the app layer, but you shouldn't think in terms of "INSERT", "UPDATE" etc - you should think in terms of operations that make sense to your domain model - the "CreateOrder" operation, etc. ADO.NET Data Services allows an API more similar to your "INSERT" etc, but it isn't necessarily as controlled as you might like for a secure service.

Performance is really a factor of "what queries am I running?" and "how much data am I transferring?". As long as you keep the operations sane (i.e. don't fetch the entire "Orders" data over the wire just to find the most recent order-date), then you should be OK.

Marc Gravell
Of course, you don't need to _limit_ yourself to HTTP when using WCF. If you're talking .NET to .NET, you can use TCP/IP to a specific port number opened in the firewall between the two systems. You need not have port 80 or 443 open at all.
John Saunders
Thanks guys. Great answers. I have one more question. If I use WCF, users will talk to computer A with WCF services and computer A will talk to computer B with SQL Server. Am I right?
@worlds-apart89 - right. Note that if the system isn't huge, the app tier (computer A) and SQL Server (computer B) can be the same computer, running both IIS (or some other WCF/comms server) and the DB.
Marc Gravell
@John - possible of course, but in most scenarios http[s] is simple and plenty fast enough. You can always use a binary serializer and MTOM over http if bandwidth is the issue. Now, if only someone had a high performance binary serializer that could integrate into WCF, preferably free. ;p
Marc Gravell
@Marc: since security was a major issue here, I thought it might be best not to require port 80 and 443 to be open.
John Saunders