Native XML Web Services Overview
This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
This topic compares Native XML Web Services in Microsoft SQL Server to Microsoft SQLXML, describes how native XML Web services works, and lists some benefits from using it.
Native XML Web Services is not useful or recommended for the following scenarios:
Applications characterized by real time highly concurrent access, with short duration transactions.
Web farm type scale-out.
As a replacement for the middle tier, specifically where your application architecture has large-scale business logic demands that are better accommodated within middle-tier components.
Comparing Native XML Web Services to SQLXML
Before SQL Server 2005, access to a SQL Server database requires using Tabular Data Stream (TDS). TDS is a proprietary protocol that must be supported for Windows-based desktop clients. Sometimes, SQL Server clients must use Microsoft Data Access Components (MDAC). The MDAC stack is installed on the client computer that connects to SQL Server. For SQL Server, SQLXML 3.0 is a middle-tier component that supports Web-based access to SQL Server, but Internet Information Services (IIS) must also be used.
Beginning with SQL Server 2005, by combining the use of HTTP and SOAP, native XML Web services provides an alternative for environments other than Windows, as shown in the following illustration.
.gif "Comparing Native XML Web Services to SQLXML")
Because there is no longer a need for either MDAC installed at the client or for SQLXML with its dependency at the middle-tier on IIS, SOAP and HTTP access enables a broader range of clients to access SQL Server. These include Web application clients that use existing client applications, such as a Web browser. Native XML Web Services makes it easier to work with the Microsoft .NET Framework, Microsoft SOAP Toolkit, Perl, and other Web development operating systems and toolsets.
The following table shows some features that each technology offers.
Native XML Web Services |
Microsoft SQLXML |
|---|---|
|
|
How Native XML Web Services Works
To use Native XML Web Services in SQL Server, an HTTP endpoint must to be established at the server. This endpoint is essentially the gateway through which HTTP-based clients can query the server. After an HTTP endpoint is established, stored procedures or user-defined functions can be added or made available to endpoint users. This can occur when the endpoint is either created or updated. When procedures and functions are enabled, they are specified as Web methods. A collection of Web methods that are designed to be used together can be called a Web service.
These Web services can be described by using the WSDL format. The WSDL format is generated by an instance of SQL Server and returned to SOAP clients for any HTTP endpoints on which WSDL is enabled, as shown in the following illustration. If required, the WSDL format can be a custom solution instead of one generated by SQL Server. Optionally, the endpoint can be configured to not answer WSDL requests.
Following this process, collections of SQL Server-enabled Web services can be implemented and used to help build and populate a Service-Oriented Architecture (SOA). For more information, search on the keyword "SOA" in the MSDN Online Library at this Microsoft Web site.
Benefits of Using Native XML Web Services
An instance of SQL Server that can function as its own XML Web service provides the following benefits:
Any Web services application can access an instance of SQL Server
This is the key benefit. Because the native XML Web services is based on well-known technologies such as XML and HTTP, any device that can parse XML and submit HTTP requests can now access SQL Server. This permits greater access to SQL Server in heterogeneous environments in which applications that run on operating systems other than Windows might require connectivity to SQL Server. Traditionally, in these cases, using either Java Database Connectivity (JDBC) or Open Database Connectivity (ODBC) drivers was the only solution available. Native XML Web Services in SQL Server provides another, low-cost alternative. For example, this feature could be very useful for scenarios in which a database administrator has script written in Perl that run on operating systems other than Windows to manage a SQL Server resource.
Improved integration with both Microsoft and third-party Web development toolsets
With Native XML Web Services, SQL query results are returned in XML format. By using predefined schemas, smart integrated development environments (IDEs) that have built-in SOAP/HTTP support, such as Microsoft Visual Studio 2005 or JBuilder, can take advantage of Native XML Web services to help in generating proxy code that abstracts the communication with an instance of SQL Server. Most of the time, the IDE generates and provides the objects that the client applications can then in turn use for Web-based data access.
Better support for mobile clients that are intermittently or loosely connected
Using Native XML Web Services also enables access to an instance of SQL Server anywhere at any time. This makes it easier to develop applications for mobile or intermittently connected devices. After a connection has been established and the server has started processing requests, the server can be monitored by using the existing mechanisms that are available to traditional network-based clients that used TDS and SQL Server Net-Libraries.
Security measures built into the server reduce the need to implement additional firewalls
Native XML Web Services provides a built-in level of security for Web access. Unlike a typical Web server, the HTTP endpoints that are created for use by SQL Server do not permit anonymous user access. To create endpoints, system-level administrative privileges are first required at the server, and endpoints only expose the stored methods that are made public when the endpoints are configured.
See Also