This post originated from an RSS feed registered with .NET Buzz by Raymond Lewallen. Original Post: When to use an endpoint created in Sql Server 2005 Feed Title: Raymond Lewallen Feed URL: /error.htm?aspxerrorpath=/blogs/raymond.lewallen/rss.aspx Feed Description: Patterns and Practices, OOP, .Net and Sql Latest .NET Buzz Posts Latest .NET Buzz Posts by Raymond Lewallen Latest Posts From Raymond Lewallen

Somebody emailed me about my post on Create a web service directly from Sql Server 2005 using an HTTP Endpoint.  The question was, “When would I use this, and why?”

Endpoints have their place, for sure.  The most common mistake I’ll probably see is people creating endpoints for use by their .net application where normal design is applied (business rules located in a .Net assembly; data returned as a dataset or datareader to the .net application).  Not a good idea, but I can see how my original post on how to do it would convey that idea and I apologize for that confusion.  Sql server has great integration with .net, and you’ll end up writing a bunch of code that does nothing but create overhead, unneeded database abstraction and increased system complexity.  Don’t use an endpoint where a simple database connection will suffice.  You have to take into consideration issues like security as well, which can make endpoints a hassle to deploy and consume properly.  Endpoints should typically be deployed in a manner where the data is secured via SSL and only available using good authentication like Kerberos in order to maintain data security.  Most data centers are also located behind a firewall, which adds another layer of security to take into consideration.

Well geez, where can I use endpoints then?  Some applications are designed to deal with raw XML from the database, where the database already has a decent set of business rules being applied.  Here is a perfect example of where an endpoint is a great solution for exposing that data and business logic.  Anybody who’s system is already built around SQLXML also has a good case for moving to endpoints for exposing data in an easy to consume manner.  Endpoints can also be used as a great way to integrate with non-Windows applications that can easily consume a web service.  Ideally, you should only use endpoints to expose information to applications that can easy consume a web service where you can also maintain the level of security your data requires..