Introduction
SQL Server 2005 introduces new features called Endpoints, which make other applications able to connect to SQL
Server 2005 directly. SQL Server 2005 defines two types of endpoints, which are:
- TCP Endpoint (which won’t be covered in this article)
HTTP Endpoint
This article is going to focus on HTTP Endpoints.
Prerequisites
- SQL Server 2005 Developer Edition
- Microsoft Visual Studio.NET 2005
-
AdventureWorks Sample Database
HTTP endpoint overview
The word HTTP might suggest that external applications connect to SQL Server 2005 through IIS.
But this is incorrect! SQL Server 2005 uses the http.sys driver file instead of IIS to provide
communication between an external application and SQL Server 2005 using the HTTP protocol.
Note: HTTP endpoints enable you to expose SQL Server 2005 data to the network in a
manner similar to implementing a Web Service.
How to create an HTTP Endpoint in SQL Server 2005
In the following section I’m going to describe the steps needed to create a HTTP Endpoint in SQL
Server 2005.
- Open Microsoft SQL Server 2005 Management Studio.
- Log onto the Server Type Database Engine using your Authentication type.
- Click on Create New Query.
- Write the
SQL statements needed to create the stored procedures to be exposed through the HTTP
Endpoint, as shown in listing 1.
Listing 1: Stored Procedures exposed through the HTTP Endpoint
5. Write the SQL that creates the HTTP Endpoint, as shown in
listing 2.
Listing 2: SQL code for creating the HTTP Endpoint
How to consume the exposed Stored Procedures through a .NET Application
In the following section I’m going to describe the steps needed to create a web application that consumes the
stored procedures exposed through the HTTP Endpoint.
1. In Visual Studio 2005, create a new ASP.NET application.
2. In the Solution Explorer, right click on the project and select Add Web Reference, as shown in Figure 1.
Figure 1: Adding a web reference to an ASP.NET application

3. As shown in figure 2, type the following URL in the URL field of the “Add Web
Reference” window: http://localhost/SQL?WSDL. The result returned is a web method that represents
the stored procedure exposed through the HTTP Endpoint.
Figure 2: Specifying the URL in the Add Web Reference window

4. Design a web form as shown in figure 3.
Figure 3: Web Form layout

5. Write the code reported in listing 3 in the Page_Load event handler.
Listing 3: Code for the Page_Load method
6. Write the code reported in listing 4 in the event handler for the button’s Click event.
Listing 4: Code under Button Click
7. Run the application by pressing CTRL + F5. In the page, select Accessories from the
dropdown list control; then, click on the Search button.
8. The result of the search is shown in figure 4.
Figure 4: Result of the search

Considerations for using HTTP Endpoints
1. Interoperability. HTTP endpoints use the SOAP protocol. If
your solution requires that clients using operating systems other than Microsoft Windows® be able to access SQL
Server 2005, using HTTP endpoints is an obvious choice.
2. Performance. HTTP endpoints use the http.sys kernel mode
driver, which provides better performance than Internet Information Services (IIS)–based solutions such as
ASP.NET Web Services.
3. Security. You should not use HTTP endpoints to connect the database
directly to an Internet application, because doing so exposes the database to the Internet. This increases the
risk of an attack. If you must provide access to the database over the Internet, you should select more secure
technologies, such as ASP.NET Web Services and SQLXML.
4. Scaling out. HTTP endpoints do not scale out because they use the Database
Engine directly. If you need to scale out your system, you should select another technology, such as
ASP.NET Web Services or SQLXML, which can run on multiple servers.
Scenarios suitable for using HTTP endpoints
The following list describes some scenarios in which you should consider using HTTP
endpoints:
1. Generating reports for internal use. You can quickly create stored procedures that
retrieve the required data and expose them through HTTP endpoints. You can provide internal users
who need this data with the URL of the HTTP endpoint. These users can then use a web browser such as
Microsoft Internet Explorer to connect to this URL and view the data returned by the stored procedure.
2. Using XML. You might have applications that generate and process data as
XML instead of using the relational format used by SQL Server. You can use an HTTP
endpoint to send and receive data as XML documents between an application and SQL Server 2005.
3. Implementing a Service-Oriented Architecture (SOA). The implementation of
HTTP endpoints conforms to the SOA, providing programmers with a consistent means of
exposing and consuming data services.
Scenarios where you should not use HTTP endpoints
The following list describes some scenarios in which it is not appropriate to use HTTP
endpoints:
1. Using Windows 2000 or earlier operating systems. HTTP endpoints use the
http.sys kernel driver. You can use this driver only with Microsoft Windows Server™ 2003 and Windows
XP Service Pack 2.
2. Performing real-time transaction processing. HTTP endpoints cannot provide
the same response time as other data access technologies, such as connecting directly to the database server by
using Microsoft ADO.NET. Do not use HTTP endpoints when you require mission-critical response times.
3. Using large objects (LOBs). XML and HTTP endpoints are not the
most efficient mechanism for transporting LOBs to and from a database server. The serialization mechanism
required to convert LOB data to XML can require considerable processing power and consume
significant network bandwidth.
Best practices for using HTTP endpoints
Keep in mind the following best practices when you use HTTP endpoints:
1. Use Kerberos authentication. You can define an endpoint with one or more of the
following authentication types: Basic, Digest, NTLM, Kerberos, and Integrated (NTLM and Kerberos). Kerberos is
the most secure because it uses stronger encryption algorithms than the other authentication types. It also
identifies both the server and the client. In fact, to use Kerberos, you must associate a server principal name
(SPN) with the account under which SQL Server is running.
2. Limit endpoint access by using the Connect permission. You should limit endpoint access
only to those users or groups that need it. You can accomplish this by granting or denying the SQL Server 2005
Connect permission.
3. Use Secure Sockets Layer (SSL) encryption to exchange sensitive data.
If you are planning to exchange sensitive data by using HTTP endpoints, use SSL to help ensure
the confidentiality of data.
4. Place SQL Server behind a firewall. If you need to provide HTTP access for
SQL Server to Internet users, don’t do it directly. Instead, configure SQL Server behind a firewall that protects
your communications.
5. Disable the Windows Guest account on the server. The Guest account, when enabled, allows
any user to log on to the local computer without having to provide a password.
6. Enable HTTP endpoints only as needed. You should not enable an endpoint if
it is not required or currently in use.
Summary
HTTP endpoints are a new feature provided by Microsoft SQL Server 2005. They can be used to
expose stored procedures directly to external applications.
About Ahmed Mosa
 |
Sorry, no bio is available
View complete profile here.
|
You might also be interested in the following related blog posts
ASP.NET MVC: DevExpress Mail Demo
read more
Letting ASP.NET Handle Image File Extensions in IIS 6
read more
Bind InfoPath form to XML, Tables, SharePoint Lists & Web Services
read more
Export Word documents to XPS - Open XML Paper Specification format
read more
NDC 2009 - Get the code!
read more
RELEASED ASP.NET MVC 2 Preview 2
read more
Create or Manage XPDL 1.0 & 2.1 packages using Aspose.Workflow
read more
Application Identifiers (AI) for EAN-128 barcode generation
read more
Create charts & add ad hoc capabilities to .NET Web & WinForm apps
read more
Western European ReMix Tour 2009
read more
|
|
Please login to rate or to leave a comment.