Many of you already know that you can expose your data as a web service natively in SQL 2005. No IIS. There are plenty of great articles that talk about it; one of them is at http://www.developer.com/db/article.php/3390241.
There are a few articles and blogs that talk about when you should use SQL endpoints. For example, check out When to Use HTTP/SOAP Endpoints section at the bottom of this article -- http://www.devx.com/dbzone/Article/28525/1954?pf=true.
But I found no information on the resource cost of SQL EndPoints. So, I ran my own tests comprised of getting data from a simple small table with a hundred or so rows via SQL endpoints and by calling the stored proc directly, lazily using SQLDataAdapter.Fill method. I found that the processor on the SQL box is highly utilized for a significantly longer period of time, when using endpoints. Other server resources did not show a big difference.
#Threads Web Service Performance Stored Proc Performance1 24 ms/iteration 3 ms/iter 5 58 ms/iter 4 ms/iter 10 109 ms/iter 5 ms/iter
Now, I know… it’s not quite an apple-to-apple comparison. But the data led me to the following conclusion: don’t use SQL endpoints unless you need web services without IIS; otherwise, just create a traditional web service using .NET, which calls the stored proc. After all, scaling web/middle tier is easy, scaling SQL is not.