CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

David Hayden [MVP C#]

         .NET Tutorials, Patterns, and Practices

SQL Server 2005 XML Web Services - Create HTTP Endpoint Using SMO

SQL Server 2005 has this new feature that allows you to expose XML Web Services from the database without the need for IIS. This is really cool to play with, because one can expose a stored procedure via a web service that you can then consume in your client applications. I wrote a short article if you are interested:

However, I wanted to see if I could create an HTTP Endpoint using SQL Server Management Objects.  The goal is to roughly accomplish the same thing as the following:

 

CREATE ENDPOINT AW_Contacts
    STATE = Started
AS HTTP
    (
        PATH = '/Contacts',
        AUTHENTICATION = (INTEGRATED),
        PORTS = (CLEAR),
        SITE = '*'
    )
FOR SOAP
    (
        WEBMETHOD 'GetContacts'
            (NAME = 'AdventureWorks.dbo.GetContacts'),
        WSDL = DEFAULT,
        DATABASE = 'AdventureWorks',
        NAMESPACE = DEFAULT
    )

 

Briefly, this command essentially exposes a stored procedure, called GetContacts, as a web method that I created in the AdventureWorks Database.

The cool thing is that you can pull this off in SMO, and below is some example code.

 

// Connect to Local Instance
Server server = new Server();

// Create New Endpoint
Endpoint newEndpoint = new Endpoint(server,"AW_Contacts");

newEndpoint.ProtocolType = ProtocolType.Http;
newEndpoint.Protocol.Http.HttpAuthenticationModes = HttpAuthenticationModes.Integrated;
newEndpoint.Protocol.Http.HttpPortTypes = HttpPortTypes.Clear;
newEndpoint.Protocol.Http.WebSite = "*";
newEndpoint.Protocol.Http.WebSiteUrlPath = "/Contacts";

newEndpoint.EndpointType = EndpointType.Soap;

newEndpoint.Payload.Soap.DefaultDatabase = "AdventureWorks";
newEndpoint.Payload.Soap.XmlFormatOption = XmlFormatOption.XmlFormat;
newEndpoint.Payload.Soap.XsdSchemaOption = XsdSchemaOption.Standard;
newEndpoint.Payload.Soap.WsdlGeneratorOption = WsdlGeneratorOption.Procedure;
newEndpoint.Payload.Soap.WsdlGeneratorProcedure =
"[master].[sys].[sp_http_generate_wsdl_defaultcomplexorsimple]"; // Create new Soap Method SoapPayloadMethod method = new SoapPayloadMethod(newEndpoint.Payload.Soap, "GetContacts"); method.MethodXsdSchemaOption = MethodXsdSchemaOption.Standard; method.ResultFormat = ResultFormat.RowSets; method.SetSqlMethod("AdventureWorks", "dbo", "GetContacts"); method.MethodLoginType = MethodLoginType.Windows; newEndpoint.Payload.Soap.SoapPayloadMethods.Add(method); newEndpoint.Create(); newEndpoint.Start();

 

SQL Server 2005 XML Web Services and SQL Server Management Objects are just plain cool.

 

SQL Server Management Objects Resources:

 



Comments

Raymond Lewallen said:

Unfortunately, the ability to expose xml web services directly from Sql Server is also going to be the most misused and overused new feature of Sql Server.  Are they cool?  Of course.  Do most applications have a need for them?  Not at all.  From a blog entry I wrote back in August:

"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.  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."
# March 31, 2006 4:46 PM

Christopher Steen said:

AnkhSVN and a Monad SVN Provider? [Via: scott@hanselman.com (Scott Hanselman) ]
Axis2 [Via: gsusx ]...
# March 31, 2006 11:08 PM

David Hayden said:

I hear ya loud and clear, Raymond. There are a lot of cool new features in SQL Server 2005 that can definitely be misused.

You gotta admit that we are living in interesting times, however. SQL Server 2005 gets web services and CLR. You can toss an SqlDataSource Control on a web page. etc... It's fun to play with these features which feel more like stepping stones to a bigger picture yet to come.
# April 1, 2006 5:04 PM

Raymond Lewallen said:

Absolutely stepping stones to things to come *cough*WinFX*cough*
# April 5, 2006 6:50 PM
Check out Devlicio.us!

This Blog

Syndication

News

CodeBetter.Com Home