2. Registering the URL with Http.sys
To register a URL to be handled by SQL Server, execute the following T-SQL:
USE AdventureWorks
GO
EXEC sp_reserve_http_namespace N'http://localhost:80/sql'
GO
3. Exposing the Endpoints
Now that the stored procedures and functions are
created and the main URL namespace is registered with Http.sys, the
next step is to create the endpoint that exposes the stored procedures
as Web services, as shown in Listing 5.
Listing 5. Script to create the AdventureWorks endpoint from CreateEndPoints.sql
USE AdventureWorks
GO
CREATE ENDPOINT AdventureWorks
STATE = STARTED
AS HTTP(
PATH = '/sql/AdventureSales',
AUTHENTICATION = (INTEGRATED),
PORTS = (CLEAR),
SITE = 'localhost'
)
FOR SOAP (
WEBMETHOD 'http://Adventure-Works/'.'GetStoreInfo'
(NAME='AdventureWorks.dbo.GetStoreInfo',
SCHEMA=NONE),
WEBMETHOD 'http://Adventure-Works/'.'GetStoreContacts'
(NAME='AdventureWorks.dbo.GetStoreContacts',
SCHEMA=STANDARD),
WEBMETHOD 'http://Adventure-Works/'.'GetStoreRecentOrders'
(NAME='AdventureWorks.dbo.GetStoreRecentOrders',
SCHEMA=STANDARD, FORMAT=ROWSETS_ONLY),
WEBMETHOD 'GetStoreSalesYTD'
(name='AdventureWorks.dbo.ufnGetStoreSalesYTD'),
BATCHES = ENABLED,
SCHEMA = STANDARD,
WSDL = DEFAULT,
DATABASE = 'AdventureWorks',
NAMESPACE = 'http://Adventure-Works/'
)
GO
|
Let’s take a look at some of the options we chose for the CREATE ENDPOINT statement in Listing 5.
We chose to use integrated security over HTTP on port 80 because we
will expose this endpoint over the Internet, but only to employees of
Adventure Works Cycles who have Windows accounts. We have a WEBMETHOD entry for each of our stored procedures and for the user-defined function. For the ufnGetStoreSalesYTD
function, we provided a different name for the Web method than the
actual name of the function in the database, for readability. For the
stored procedures, we supplied the namespace prefix, but for the
function we left it off, taking the default specified in the NAMESPACE
attribute. (We did this simply to demonstrate the ability to define a
default namespace prefix at the endpoint level and to override it at the
Web method level. In this case, the result is the same because the
default namespace prefix is the same as the one used for the first three
WEBMETHOD entries.)
To allow our client to make ad hoc SQL queries against the database (to support the searching functionality), we set the BATCHES option to ENABLED. Because we know that the client is a Windows Forms application using the .NET Framework 2.0, we used the default WSDL option.
Granting Security Access to the Endpoints
To make it easy to control access to our
endpoint and add new users later as needed, we’ll create a Windows
Security Group with the name AdventureWorksSalesTeam, as shown in Figure 1. In this figure, we have added the JSmith user to this group. When you create this group on your server, you should add the user you will use to run this application.
Note
In our example, we use a
local security group because this is probably how you will want to set
up your development environment to run the example. However, in a real
environment this should probably be a domain group. |
Even though we will grant access to the endpoint
to members of the AdventureWorksSales-Team group, we must also grant
access to the stored procedures and functions themselves, just as we
would for any application. Listing 6
shows the T-SQL statements necessary to grant the
AdventureWorksSalesTeam security group access to our stored procedures,
function, and endpoint.
Listing 6. Script to grant rights to stored procedures, UDF, and the endpoint from GrantSecurity.sql
USE master
GO
EXEC sp_grantlogin @loginame='DataServer\AdventureWorksSalesTeam'
EXEC sp_grantdbaccess @loginame='DataServer\AdventureWorksSalesTeam'
GO
USE [AdventureWorks]
GO
GRANT EXECUTE ON [dbo].[GetStoreContacts] TO [DataServer\AdventureWorksSalesTeam]
GRANT EXECUTE ON [dbo].[GetStoreInfo] TO [DataServer\AdventureWorksSalesTeam]
GRANT EXECUTE ON [dbo].[GetStoreRecentOrders] TO [DataServer\AdventureWorksSalesTeam]
GRANT EXECUTE ON [dbo].[ufnGetStoreSalesYTD] TO [DataServer\AdventureWorksSalesTeam]
GO
USE master
GO
GRANT CONNECT ON ENDPOINT::AdventureWorks TO [DataServer\AdventureWorksSalesTeam]
GO
|
Note
In this script, we use the fictional server name DataServer. You should replace all references to DataServer with the name of your server when you set up the sample application to run in your environment. |
That’s all there is to it. With just a few extra
T-SQL commands, we’ve exposed all of the functionality we need for the
Adventure Sales application as a Web service! Let’s go ahead and test
the endpoint to make sure everything is working before we start building
the client application. We can’t easily test the Web methods without a
client application, but we can point to the URL and see that it
generates WSDL as it should. See Figure 2 for the result we get when we browse to http://localhost/sql/AdventureSales?wsdl.
