SQL Server Native Web Services

И SQL Server, и Analysis Services обладают возможностью общаться с клиентом поверх HTTP. В SQL Server такая возможность появилась в версии 2000. В свое время я освещал ее в докладе на конференции «Корпоративные базы данных-2002» - см. https://www.citforum.ru/seminars/cbd2002/004.zip, параграфы 13, 14. Она позволила засвечивать SQL Server как веб-сервис, а выбранные хранимые процедуры – как методы этого веб-сервиса. Можно было даже включить возможность выполнения произвольных SQL-запросов через HTTP GET. В SQL Server 2005 все стало еще лучше, т.к. IIS в случае установки на Windows Server 2003 стал не нужен. В Windows Server 2003 HTTP API был реализован на уровне драйвера уровня ядра HTTP.SYS, который умел принимать HTTP-запросы от клиентов и форвардить их в зарегистрированные конечные точки (HTTP Endpoints). Соответственно, в Transact-SQL появился оператор CREATE ENDPOINT, который назначал конечной точке URL. HTTP.SYS, получив HTTP-запрос, кидал его на этот URL. Внутри движка SQL Server был реализован стек SOAP (the native SOAP stack built into the database engine obviates the need for a middle-tier process (such as IIS) for this purpose - https://msdn.microsoft.com/en-us/library/ms345140.aspx). Таким образом, SQL Server не стал полноценным веб-сервером, т.к. не умел обслуживать произвольные HTTP-запросы, однако с тем их подмножеством, которое касается поддержки SOAP, справлялся самостоятельно без посредника. Пример создания конечной точки в SQL Server 2005-2008:

if exists(select 1 from sys.endpoints where name = 'sql_Northwind' and protocol_desc = 'HTTP')

drop endpoint sql_Northwind

go

CREATE ENDPOINT sql_Northwind

STATE = STARTED

AS HTTP(

  PATH = '/sql/Northwind', AUTHENTICATION = (INTEGRATED),

  PORTS = (CLEAR) )

FOR SOAP (

  WEBMETHOD 'CustOrderHist'

    (name = 'Northwind.dbo.CustOrderHist',

     schema=STANDARD),

  WEBMETHOD 'TenMostExpensiveProducts_NoSchema'

    (name = 'Northwind.dbo.[Ten Most Expensive Products]',

     schema=NONE),

WSDL = DEFAULT,

BATCHES = ENABLED,

DATABASE = 'Northwind',

NAMESPACE = 'https://Northwind/' )  

Скрипт 1

Этот оператор определяет веб-сервис по адресу https://vistax86sql2008/sql/Northwind, который будет иметь два веб-метода, соответствующих хранимым процедурам Northwind.dbo.CustOrderHist и Northwind.dbo.[Ten Most Expensive Products]. Также, поскольку мы сказали BATCHES = ENABLED, появится третий метод для того, чтобы через него запускать произвольные SQL-запросы. Документацию на оператор CREATE ENDPOINT можно прочитать в Books On-Line на русском (https://msdn.microsoft.com/ru-ru/library/ms181591.aspx) или на английском (https://msdn.microsoft.com/en-us/library/ms181591.aspx). По его выполнении в Object Explorerе (Server Objects -> Endpoints -> SOAP) можно посмотреть созданную конечную точку SOAP

рис.1

а через браузер обратиться к ней, получив определения методов веб-сервиса, висящего на этой конечной точке:

рис.2

Доступиться до конечной точки из браузера (кроме как получить вышеприведенный WSDL) нельзя, т.к. браузер шлет GET и POST-запросы, а мы отмечали, что SQL Server не является полноценным веб-сервером – он умеет обслуживать только SOAP-запросы. Поэтому нам придется написать простенького клиента веб-сервиса. В Visual Studio 2008 процесс создания ссылки на веб-сервис занимает больше кликов, чем в 2005-й, потому что теперь наше все – это Windows Communication Foundation (WCF), и Service Reference означает ссылку на сервис WCF, а Web Reference – устаревший частный случай. Про WCF можно прочитать много славословий: и что он дозволяет более гибкую настройку прокси, и что байндится к любому транспорту (HTTP, TCP, Shared Memory и т.д.) В общем, WCF – это очередное единственное, что нам не хватало для наступления коммунизма, и уж теперь-то, нет сомнений, все будет в полном, извините за каламбур, Azure. Я же, пока коммунизм у нас еще не настал окончательно, буду по старинке пользоваться Web References для того, чтобы подцепиться к созданной в Скрипте 1 конечной точке. Открываем в Visual Studio 2008 новый проект, достаточно какого-нибудь консольного приложения, кликаем правой кнопкой на References, говорим Add Service Reference, в открывшееся окно вводим адрес https://vistax86sql2008/sql/Northwind?WSDL, жмем кнопку Go.

рис.3

На этом не останавливаемся, жмем кнопку Advanced...

рис.4

Здесь ничего не делаем, просто жмем кнопку Add Web Reference...

рис.5

В текстбокс URL повторно вбиваем адрес веб-сервиса, который мы уже вводили на рис.3. Жмем кнопку Go. Вводим свой логин/пароль, потому что веб-сервис создавался с AUTHENTICATION = (INTEGRATED) – см. Скрипт 1. Проверяем в Description под урловой строкой, что все методы она видит правильно, при необходимости в текстбоксе Web reference name меняем, как будет именоваться веб-сервис (по умолчанию имя машины), и жмем кнопку Add Reference. В Solution Explorer появилась веб-ссылка:

рис.6

Пишем следующий код, вызывающий метод CustOrderHist, сопоставленный (см. Скрипт 1) хранимой процедуре Northwind.dbo.CustOrderHist:

 

using System.Data;

using System.Diagnostics;

using System;

namespace ConsoleApplication1

{

    class Program

    {

        static void Main(string[] args)

        {

            vistax86sql2008.sql_Northwind proxy = new vistax86sql2008.sql_Northwind();

            proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

            DataTable results = (proxy.CustOrderHist("ALFKI")[0] as DataSet).Tables[0];

            foreach (DataRow r in results.Rows)

            {

                Debug.WriteLine("");

                for (int i = 0; i < results.Columns.Count; i++) Debug.Write(String.Format("{0}; ", r[0]));

            }

        }

    }

}

Скрипт 2

 

 

Выполняем его и убеждаемся, что все работает. Можно вызвать процедуру из SSMS и сравнить результаты с теми, что мы сейчас видим в Output.

рис.7

Хочу еще раз подчеркнуть, что IIS в данном случае не при делах. Он вообще не установлен:

рис.8

Итак, мы продемонстрировали работу с SQL Server по HTTP, именно – выполнение им SOAP-запросов. Очень удобный и легкий механизм. Тем более, что CREATE ENDPOINT можно всю жизнь было делать AS HTTP и AS TCP, когда никаким WCF еще не пахло. Можно было создавать конечные точки для сервис-брокера, зеркалирования, выделенного административного соединения. Однако при выполнении Скрипта 1 вы заметили сообщение «Creating and altering SOAP endpoints will be removed in a future version of SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use it». Короче, пока это все еще, слава Богу, пашет, но скоро лафа закончится. Естественно, я никоим образом не против наступления светлого будущего. Мне только непонятно, каким образом наличие непосредственно внутри процесса SQL Server функциональности по обработке SOAP-сообщений мешает сейчас написать веб-сервис на ASP.NET, обращающийся к SQL Server, и раскидать его по узлам веб-фермы? Наличие функциональности SQL Server Native Web Services никоим образом не препятствует создать внешний веб-сервис, работающий с SQL Server. Один инструмент для одних задач, другой для других. Зачем вдруг гробить один и утверждать, что это делается в угоду другому, если они друг другу не противоречат? Недоумение разделяют все, от таких грандов, как Боб Бушмен (https://www.sqlskills.com/blogs/bobb/post/HTTP-Endpoints-to-be-deprecated-in-SQL-Server-2008.aspx), и заканчивая рядовыми пользователями (https://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=3807250&SiteID=17). Дабы избежать обвинений в косности и каком-либо уклоне, я просто привожу дискуссию и воздерживаюсь от комментариев:

«SQL2008 UpgradeAdvisor выдал ошибку, что конечные точки, которые мы используем для наших веб-сайтов, будут убраны из следующей версии, и я должен их переделать с использованием WindowsCommunicationFoundation. Однако я нигде не могу найти никаких статей, объясняющих, как промигрировать существующие конечные точки на WCF... Где мне начать смотреть документацию, чтобы решить этот вопрос?»

  «Может быть, я не понимаю твой вопрос, но тем не менее. Идея в том, что сейчас твое клиентское приложение напрямую вызывает методы, написанные на SQL и расположенные на SQL Server. Что нужно сделать – это чтобы клиент обращался к тем же методам на веб-сервере, а не на SQLServer. Методы будут делать по сути то же, что и сейчас, - единственно, они просто будут написаны на ASP.Net вместо SQL. Эти методы на веб-сервере будут коннектиться к твоему SQLServer, чтобы получить результаты и переправить их на клиента, работая как промежуточное звено...»

«Tres;

Может, я тупой, может, это врожденно, но я реально не понимаю, зачем создавать лишнее звено в виде промежуточного ASP.Netwebservice, который будет обращаться к SPs & UDFs на SQLserver, если мой веб-сайт уже напрямую к ним обращается?»

  «На самом деле, я считаю, вы задали очень хороший вопрос. По сути «если не сломалось, то и зачем ремонтировать», правильно? Хорошо, я приведу некоторые соображения, почему Microsoft убирает NativeWebServices и затем вы сможете оценить для себя, насколько вам подходит переходить.

1. Начинаяс SQL Server 2008 Native Web Services будутотменены. Это означает, что Microsoft переходит в режим сопровождения для NativeWebServices. В следующей версии прекратится поддержка, и инноваций в этой области больше не будет.

2. Это позволит Microsoft лучше выровняться с существующими технологиями.

3. SQLServer 2005 NativeWebServices предоставили пользователям простой механизм выставления наружу существующих StoredProcedures (SP) и UserDefinedFunctions (UDF) в качестве веб-методов. Поскольку эта функциональность заложена непосредственно внутри процесса SQLServer, NativeWebServices не могут располагаться на типовой “веб-ферме”, чтобы как-то решить вопрос с высокой стоимостью обработки парсинга текста XML. Задействуя промежуточный слой, такой, как IIS и ASP.Net, можно распределить эту стоимость среди группы веб-серверов, чтобы уменьшить нагрузку по обработке XML на SQLServerе...»

«Ликвидация такой замечательной и полезной функциональности – по моему мнению, исключительно вредный шаг.

Я могу понять желание что-то улучшить, чтобы повысить масштабируемость, тем более, что простор для этого имеется. Но улучшать вещи путем убирания замечательной функциональности, великолепно приспособленной для простых и эффективных реализаций, – это не дело.

Наша компания использует NativeXMLwebservices в SQL Server для систем, предоставляющих легковесный и низкозатратный способ реализации веб-сервисов, которые позволяют кросс-платформенным приложениям обращаться к SQLserver через единые интерфейсы.

Я бы сильно рекомендовал оставить эту функциональность как немаловажную причину, стимулирующую приобретение SQLServer...»