David Hayden [MVP C#]

Sponsors

The Lounge

News

  • CodeBetter.Com Home

Other Links

Teas

Patterns & Practices

Florida .NET Developer

Book Reviews

Tampa ASP.NET MVC Developer Group

Advertisement

Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
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:

 


Posted 03-31-2006 2:35 PM by David Hayden

[Advertisement]

Comments

Raymond Lewallen wrote re: SQL Server 2005 XML Web Services - Create HTTP Endpoint Using SMO
on 03-31-2006 4:46 PM
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."
Christopher Steen wrote Link Listing - March 31, 2006
on 03-31-2006 11:08 PM
AnkhSVN and a Monad SVN Provider? [Via: scott@hanselman.com (Scott Hanselman) ]
Axis2 [Via: gsusx ]...
David Hayden wrote re: SQL Server 2005 XML Web Services - Create HTTP Endpoint Using SMO
on 04-01-2006 5:04 PM
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.
Raymond Lewallen wrote re: SQL Server 2005 XML Web Services - Create HTTP Endpoint Using SMO
on 04-05-2006 6:50 PM
Absolutely stepping stones to things to come *cough*WinFX*cough*