Accessing the database engine using SOAP via HTTP

Introduction

Microsoft® SQL Server™ 2005 provides a standard mechanism for accessing the database engine using SOAP via HTTP. Using this mechanism, you can send SOAP/HTTP requests to SQL Server to execute:
• Transact-SQL batch statements, with or without parameters.
• Stored procedures, extended stored procedures, and scalar-valued user-defined functions.
Prior to SQL Server 2005, the only mechanism available to connect to SQL Server was through a custom binary protocol named Tabular Data Stream (TDS). With SOAP/HTTP access, we have provided an open and documented protocol that may be used as an alternative to connect to SQL Server. Providing SOAP/HTTP access enables a broader range of clients to access SQL Server, including "zero foot print" clients, because there is no longer a need to have a Microsoft Data Access Components (MDAC) stack installed on the client device trying to connect to SQL Server. It facilitates interoperability with .NET, SOAP Toolkit, Perl, and more on a variety of platforms. Since the SOAP/HTTP access mechanism is based on well-known technologies such as XML and HTTP, it inherently promotes interoperability and access to SQL Server in a heterogeneous environment. Any device that can parse XML and submit HTTP requests can now access SQL Server.
Many enterprises have heterogeneous environments in which applications that run on UNIX and Linux platforms might require connectivity to SQL Server. Traditionally, the only solution available to such users was to use either JDBC or ODBC drivers. The SOAP/HTTP access now provides another, low-cost alternative. It is extremely useful for scenarios where DBA's have scripts written in Perl that run on UNIX and manage a SQL Server resource. It is also useful in developing client applications that connect to SQL Server using smart integrated development environments (IDEs) that have built-in SOAP/HTTP support, such as Microsoft Visual Studio® .NET or Jbuilder. These IDEs generate proxy code that abstracts the communication with SQL Server and provides objects that the client applications can use. Using SOAP/HTTP also enables anytime, anywhere access to SQL Server, which makes it easier to develop applications for mobile or sporadically connected devices. Once a connection has been established and the server has started processing requests, it can be monitored using existing mechanisms that TDS-based clients such as sqlclient, ODBC, and OLEDB use.

Requirements

SQL Server 2005–native Web services require Microsoft Windows Server™ 2003 as the operating system, because they rely on the kernel mode http driver http.sys that this version provides. Since SQL Server leverages the kernel mode http.sys driver, you do not necessarily need to have IIS installed to expose Web services out of SQL Server; this simplifies administration. Instead, you should base your decision to install IIS on application requirements. For example, certain applications benefit from having an explicit middle tier. In such cases, IIS would be useful.

HTTP Endpoints

Setting up SQL Server as a Web Service that can listen natively for HTTP SOAP requests requires creating an HTTP endpoint and defining the methods that the endpoint exposes. When an HTTP endpoint is created, it must be created

--->Extract from MSN Groupz..