Оконечные точки HTTP в MSSQL server

Tsql теория > Оконечные точки HTTP в MSSQL server
14.02.2013 17:24:33



Статья:

Оконечные точки HTTP

В отношении данной темы следует отметить, что решение о том, следует ли включать ее описание в настоящую книгу, было полностью передано на мое усмотрение. Дело в том, что задачи создания, настройки, защиты, а также определения многих других аспектов использования оконечных точек HTTP в основном относятся к сфере деятельности администратора базы данных. С другой стороны, вполне очевидно, что основное направление использования оконечных точек HTTP (в качестве собственной Web-службы) безусловно является прерогативой разработчика. Поэтому в настоящей главе принят промежуточный подход: приведено общее описание оконечных точек HTTP и показано, в чем состоит их значимость с точки зрения проектировании, но исключено все то, что касается функций администрирования оконечных точек HTTP.

Оконечные точки HTTP не поддерживаются в версии SQL Server Express. Кроме того, операционная система Windows ХР не поддерживает некоторые из обязательных основополагающих технологий. Иными словами, оконечные точки HTTP не могут применяться, если приложение работает под управлением версии SQL Server Express или развернуто в операционной системе Windows ХР.

Краткое описание оконечных точек HTTP приведено ниже. Прежде всего следует отметить, что оконечные точки HTTP предназначены для поддержки протокола SOAP (Simple Object Access Protocol— простой протокол доступа к объектам). А протокол SOAP, в свою очередь, призван обеспечить устранение многих проблем доступа к службам по Web, в том числе связанных с применением брандмауэров. До внедрения протокола SOAP для обеспечения взаимодействия объектов главным образом требовалось открывать некоторые специальные порты и передавать через них двоичные вызовы, которыми обмениваются объекты. Количество возникающих при этом проблем нарушения защиты было чрезвычайно велико, и одна из причин заключалась в том, что приходилось обеспечивать беспрепятственное прохождение двоичного трафика, относящегося к Web-службам, через брандмауэры. Поэтому отделы информационной технологии возражали против использования Web-служб.

С другой стороны, протокол SOAP обеспечивает передачу и прием запросов к Web-службам и ответов Web-служб по обычному протоколу HTTP. Запрос к Web-службе представляет собой пакет SOAP, содержащий вызов метода наряду со всеми необходимыми параметрами. Таким образом, пакет SOAP — это не что иное, как текстовый документ, содержащий информацию, необходимую для интерпретации и выполнения запроса, а не активный исполняемый файл, непосредственно осуществляющий выполнение запроса, поэтому компонент системы, находящийся на приемном конце, может полностью взять на себя функции по определению того, какие действия должны быть проведены с этим пакетом.

В этот момент мы обязаны сделать отступление и пояснить, что создание оконечной точки HTTP, позволяющей получить доступ к Web-службе, по-прежнему остается ответственной задачей, в ходе решения которой необходимо избежать появления предпосылок нарушения защиты. Как было указано в начале настоящего раздела, фактически вся проблематика создания и настройки конфигурации оконечных точек HTTP зависит от конкретной реализации и рассматривается как относящаяся в основном к сфере деятельности администратора базы данных именно по этой причине при решении задач, связанных с подготовкой оконечных точек HTTP к работе приходится учитывать целый ряд соображений, без которых невозможно наладить успешное функционирование брандмауэра и организовать защиту данных. Оконечные точки HTTP определяются в масштабах сервера, а не в масштабах отдельной базы данных, поэтому любые нарушения в работе, возникающие в процессе использования оконечных точек HTTP, ставят под угрозу нормальное функционирование всего сервера, а не только отдельной базы данных конкретного приложения.

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

Оконечные точки HTTP главным образом предназначены для создания Web-служб, поддержка которых предусмотрена непосредственно в программном обеспечении СУБД SQL Server. СУБД SQL Server обеспечивает ввод и обработку запросов Web-служб без привлечения дополнительных программ. Как правило, такие запросы представляют собой требования на получение информации, поступающие из базы данных. При этом, безусловно, предусмотрена возможность управлять тем, какой объем информации должен стать доступным и что нужно сделать для ее получения.

Безопасность

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

¦ Управление. На этом уровне регламентируются права доступа, от которых зависит то, может ли данный пользователь внести изменения в определение некоторой оконечной точки или даже удалить ее.

¦ Определение представления. Этот уровень доступа позволяет указать, имеет ли пользователь право хотя бы просматривать информацию об оконечной точке (метаданные).

¦ Подключение. От этого уровня доступа зависит, сможет ли пользователь получать даже сами данные через оконечную точку. Следует отметить, что пользователю можно предоставить право управлять оконечной точкой и вместе с тем лишить его права просматривать данные, поступающие через оконечную точку (такая возможность становится очень удобной, когда возникает необходимость обеспечить эксплуатацию приложений, предоставив некоторым пользователям административные права, но вместе с тем исключить для этих пользователей доступ к конфиденциальной информации, передаваемой через оконечную точку).

Методы оконечной точки HTTP

Автор решил подготовить отдельный раздел, посвященный описанию этой темы, лишь для того, чтобы дать понять, что фактически методы оконечной точки HTTP существуют не самостоятельно, а в составе определенного приложения. Для предоставления доступа к методу через оконечную точку HTTP достаточно подготовить к использованию код, на который может указывать ссылка.

Пример создания оконечной точки и использования метода приведен ниже. В данном случае рассматривается Web-служба, имеющая типичное назначение — составление списка товаров, позволяющего получить самую свежую информацию о состоянии товарных запасов. Для этого используется хранимая процедура, с помощью которой осуществляется выборка данных о наличии на складе велосипедов:

USE AdventureWorks GO

CREATE PROCEDURE spListBikes AS

SELECT    p.ProductID, p.ProductNumber, p.Name, p.ListPrice

FROM    Production.Product AS p

JOIN Production.ProductInventory AS i ON p.ProductID = i.ProductID JOIN Production.ProductSubcategory psc

ON p.ProductSubcategorylD = psc.ProductSubcategorylD JOIN Production.ProductCategory pc

ON psc.ProductCategorylD = pc.ProductCategorylD WHERE p.ListPrice > 0

AND p.DiscontinuedDate IS NULL

AND    pc.Name = 'Bikes'

ORDER BY p.Name

Кроме того, ради разнообразия введем дополнительную хранимую процедуру, с помощью которой будет осуществляться обработка запросов, позволяющих оценить состояние запасов:

CREATE PROCEDURE spGetProductInventory ©ProductID int

AS

BEGIN

SELECT p.ProductID, p.ProductNumber, p.Name, i.Quantity FROM Production.Product AS p

INNER JOIN Production.ProductInventory AS i ON p.ProductID = i.ProductID WHERE p.ProductID = @ProductID

END

В настоящем разделе созданы лишь две хранимые процедуры, на которых должны быть основаны методы Web-службы, а сама процедура ввода в действие Web-службы будет рассматриваться ниже.

Создание оконечных точек HTTP и управление ими

Само понятие оконечной точки выходит далеко за рамки использования оконечных точек HTTP, но для развертывания Web-служб в СУБД SQL Server применяются исключительно оконечные точки HTTP, причем, как уже было сказано, почти вся связанная с этим проблематика рассматривается как относящаяся к сфере деятельности администратора базы данных. В данном разделе будут приведены краткие сведения о том, как создаются и используются оконечные точки. В частности, следует отметить, что в операторе создания оконечной точки применяется основной синтаксис CREATE cobject type> cobject name>, который уже встречался в книге достаточно часто, но в данном случае имеет некоторые дополнительные опции. Тем не менее в данном разделе рассматривается лишь самый простой пример применения оконечной точки HTTP (автор не собирается даже приводить полное определение синтаксиса оператора создания оконечной точки HTTP, поскольку эта тема в основном выходит за рамки настоящей книги и является очень сложной), в котором демонстрируется применение хранимых процедур, созданных в предыдущем разделе:

CREATE ENDPOINT EP_AW STATE = STARTED AS HTTP (

PATH = '/AW',

AUTHENTICATION = (INTEGRATED),

PORTS = (CLEAR),

SITE = 1localhost1

)

FOR SOAP (

WEBMETHOD 'ListBikes'

(NAME='AdventureWorks.dbo.spListBikes'),

WEBMETHOD 'ProductStocklnfо'

(NAME=1AdventureWorks.dbo.spGetProductInventory'),

BATCHES = DISABLED,

WSDL = DEFAULT,

DATABASE = 'AdventureWorks1,

NAMESPACE = 'http://Adventure-Works/1

В результате выполнения этого оператора создается оконечная точка HTTP, которая предоставляет доступ к двум указанным хранимым процедурам. В данном случае создание оконечной точки HTTP равносильно созданию Web-службы.

Для того чтобы убедиться в том, что новая Web-служба действительно действует, попытайтесь перейти по адресу http://localhost/aw?wsdl. В окно браузера должен быть выведен большой объем кода XML, который по существу представляет собой документ, позволяющий определить, какие возможности предоставляет данная Web-служба. После прокрутки этого документа и достижения его нижней части должны быть обнаружены ссылки на методы, которые были введены в состав Web-службы, например, как показано ниже.

- <xsd:element name="ListBikes">

- <xsd:complexType>

<xsd:sequence />

</xsd:complexType>

</xsd:element >

В этом фрагменте кода показан узел, который определяет метод ListBikes. После того как происходит вызов этого метода, вызывается хранимая процедура spListBikes и формируются результирующие данные.

Читатели, которые знают, как работать с Web-службами в программе Development Studio, теперь могут приступить к их использованию. Рекомендуем сделать такую попытку и ознакомиться с полученными результатами.

Заключительные примечания

Перспективы использования Web-служб вполне очевидны, но ими не следует слишком увлекаться. Ниже приведены некоторые соображения на этот счет.

¦ В целом не рекомендуется предоставлять непосредственный доступ к СУБД SQL Server через Интернет. В частности, если непосредственный доступ через Интернет должен быть предоставлен для работы с Web-службами, то необходимо предусмотреть использование прокси-сервера того или иного типа, который разделил бы внешнюю и внутреннюю сеть, в которой развернуты Web-службы СУБД SQL Server. Для этого не требуется обязательно применять какой-то необычайно мощный брандмауэр. Достаточно, например, ввести в действие обычный ретранслирующий брандмауэр, но важно именно то, что в результате появляется еще один уровень преобразования адресов, который становится преградой между данными (обычно весьма ценными) и внешним миром.

¦ Что же касается внутрифирменных приложений, то, по-видимому, вполне приемлемым является непосредственный доступ (в конечном итоге приложение, созданное на основе Web-службы, ненамного отличается по степени защищенности данных от того приложения, в котором применяются прямые соединения ADO, а в действительности первый из этих вариантов может даже оказаться более безопасным). Но следует учитывать, что на практике приходится сталкиваться с таким неприятным явлением: приложения, которые вначале обозначались как предназначенные “только для внутрифирменного использования”, со временем становятся нужными для все более широкого круга пользователей, а перечень поддерживаемых ими функций постоянно растет, поэтому в процессе работы пользователя с приложением ему все чаще приходится сталкиваться с предупреждением “ожидается добавление средства <ххххх>”. Например, системы учета товарно-материальных ценностей, разработанные для головной конторы, становятся доступными для филиалов и партнеров, заказчиков и поставщиков. А данные собственных приложений со временем начинают рассматриваться как важные внешние источники в других приложениях.

¦ Иными словами, приходится снова изыскивать возможность организации защищенного доступа и проводить доработку приложения в связи с расширением области его применения. В таком случае снова приходится прибегать к использованию прокси-сервера, но не исключено, что количество эксплуатируемых серверов базы данных возрастет и в связи с этим появится необходимость обеспечить успешное переключение с одного сервера базы данных на другой. Для этого может потребоваться, чтобы доступ приложений ко всей группе применяемых серверов через прокси-сервер был организован с помощью виртуального сервера. Но благодаря этому появляются дополнительные возможности. Например, в экстренных случаях основной экземпляр СУБД SQL Server может быть переведен в автономный режим для восстановления после крупного сбоя, а весь поток запросов перенаправлен через прокси-сервер к резервной базе данных (разумеется, при условии, что в приложениях не будут применяться операции обновления).