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