ASP.NET 3 TIRED APPLICATION Webservice Vs Stored Procedure

Hello Experts:

I am designing a internet facing website that will access data from our sql server database and display it on the web.

There are two machines
MACHINE A is the webserver. It  has IIS and it is facing the internet.
MACHINE B is has SQLServer 2005 Database.
MACHINE A AND MACHINE B ARE IN THE SAME FACILITY.

Option 1:
(A) Install WebService on MACHINE B.
(B) Web Server(MACHINE A) will call webservice.
(C) Webservice will access SQLServer database and return data.

Option 2:
(A) Do not install webservice on MACHINE B.
(B) Web server directly access SQL Server database on MACHINE B exclusively using ONLY STORED PROCS through Data Layer. ( just like in 3 tier application )

Question:
(1) Security wise which option is better. Option 1 or Option 2 or are both equally vulnerable.
(2) What are the relative advantages / disadvantages of both the method.
(3) What method would you recommend?
(4) What is the general industry trend?

THANK YOU FOR ALL YOUR HELP.





neetu2008Asked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
Carl TawnConnect With a Mentor Systems and Integration DeveloperCommented:
1) Shouldn't make much difference as long as you are careful about how you code your SQL procedures.

2) Depends what you're overall objective is really. Hiding the web app from the details of the data store makes your app more loosely coupled and gives you more options in terms of scalability. Straight app -> DB comms will be quicker to develop.

3) Which I would go with would depend on the app. Either works, you could even go for a combination of the two. If the stuff you are planning to put in a web service is reusable across apps then that will save you time in the future too and allow you to just update the service without having to recode the app if the DB changes.

4) Again a good mixture of the two.
0
 
Alfred A.Connect With a Mentor Commented:
1) Both options have security features that would be almost the same (permissions, logins, etc.).  

2) In my opinion, option 1 is more scalable than option 2 but from experience, it is easier for me to debug or maintain option 2 setup.

3) It really depends on your short, medium, and long term plans.  If you plan to offer services to clients, like consuming raw data for use in third-party portals through the internet, web services would be the one I am going to use (option 1).  If your website is only focused or centralised in your company, meaning all control of data is through web browsers, you might as well stick with option 2.  

You can even have both option 1 and option 2 combined if you want.  You can have both web browser or web service interface accessing the same Business Logic Layer and Data Access Layer.  I am actually implementing this scenario in a project I am doing right now.

4) Both are general industry trend.   As @carl_tawn mentioned in his number 4, a good mixture of the two.
0
 
wls3Connect With a Mentor Commented:
Securitywise, you want to keep your datastore on a separate segment (separated by a firewall) from the web server.  Since you don't appear to have multiple tiers (2-tier seems the most logical), isolate the application from the data base server.  This way if the application is compromised, you still have the database outside the DMZ.  Additionally, if you are still concerned about database security, encrypt your data.  It does slow SQL, but, it guarantees that, even if cracked, the data is still not an issue. That being said, option 2, perhaps with .NET 4.0 and strongly typed entity framework datasets and well-written parametrized queries to your stored procs would eliminate all but a small handful of hackers.  As I tend to recommend often, adding custom httphandlers to filter out garbage from the incoming requests can add an extra layer of security.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.