Промежуточная среда веб служб ASP.NET

7.2. Использование расширения WSE

Для расширения функциональности веб служб ASP.NET служит надстройка WSE. WSE 3.0 позволяет так же создавать безопасные службы без использования IIS, используя любое приложение в качестве носителя, но при этом выбор транспортного протокола ограничен протоколом TCP. Установка WSE приводит к созданию гибкой настраиваемой промежуточной среды для использования веб сервисов, что позволяет как использовать дополнительные стандарты, так и реализовывать нестандартные расширения благодаря SOAP фильтрам, обрабатывающих передаваемые между клиентом и сервером пакеты SOAP. Последовательность фильтров образует трубопровод ( pipeline ), рис. 7.3.

Рис. 7.3. Архитектура WSE

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

Политика доступа к веб службе может изменяться администратором системы через конфигурационные файлы (рис. 7.4). Как на клиенте, так и на сервере политика хранится в отдельном файле (по умолчанию wse3policyCache.config ), а в файле конфигурации клиента или службы ( web.config ) указывается ссылка на нее. Данные файлы можно редактировать при помощи утилиты WseConfigEditor3.exe или вручную.

Рис. 7.4. Конфигурация WSE

Далее приведен пример файла конфигурации web.config при использовании WSE. Раздел <system.web><webServices><soapServerProtocolFactory> включает WSE в цепочку обработки сообщений SOAP. Раздел <microsoft.web.services3><diagnostics> позволят вести журнал всех принятых и отправленных пакетов, что может быть полезно на этапе тестирования.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.web>
    <webServices>
      <soapServerProtocolFactory type="Microsoft.Web.Services3.WseProtocolFactory, 
Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </webServices>
    <compilation debug="false">
      <assemblies>
        <add assembly="Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, 
						PublicKeyToken=31BF3856AD364E35" />
      </assemblies>
    </compilation>
  </system.web>
  <microsoft.web.services3>
    <diagnostics>
      <trace enabled="true" input="C:\Inetpub\logs\InputTrace.webinfo"
          output="C:\Inetpub\logs\OutputTrace.webinfo" />
    </diagnostics>
    <policy fileName="wse3policyCache.config" />
  </microsoft.web.services3>
</configuration>

Файл политики будет подробнее рассмотрен далее в примере создания собственных расширений и фильтров.

7.3.Создание веб-службы в среде .NET Framework

Будучи основаными на обмене сообщениями, веб службы поддерживают только одну модель удаленного вызова – активацию объекта сервером на время единственного удаленного вызова. Реализация веб сервисов в ASP.NET не имеет поддержки пула объектов. Доступ к каким либо свойствам или полям удаленного объекта невозможен, поскольку сообщения SOAP в ASP.NET связываются только с методами объекта.

Описание веб службы

При использовании ASP.NET в директории IIS (по умолчанию это C:\Inetpub\wwwroot\ ) должен быть создан файл с расширением .asmx и строкой следующего вида.

<%@ WebService class="SampleService" language="C#" %>

Она означает, что при доступе к связанному с данным файлом URL по протоколам SOAP/HTTP будет активирована веб служба на основе класса SampleService. Класс веб службы может быть либо описан в этом же файле, либо помещен в сборке в подкаталоге bin. Класс веб службы не может быть классом общего вида. Класс веб службы обычно имеет необязательный атрибут System.Web.Services.WebServiceAttribute, имеющих два основных свойства – Description с текстовым описанием службы и Namespace с указанием уникального пространства имен, используемого при генерации описания интерфейса веб службы на языке WSDL. В его роли должен выступать уникальный URI, обычно связанный с адресом домена веб службы. Пространство имен не обязательно должно являться некоторым URL. Класс веб службы может быть унаследован от класса System.Web.Services.WebService. Необходимым на практике атрибутом класса веб службы при использовании WSE 3.0 является также атрибут Microsoft.Web.Services3.PolictyAttribute, который задает имя политики, в дальнейшем связываемое через файлы конфигурации с расширениями или списком допущенных пользователей.

Для того, чтобы включить метод класса веб службы в его общедоступный интерфейс, к методу применяется атрибут System.Web.Services.WebMethodAttribute. Он имеет два важных поля – Description и TransactionOption. Последний позволяет стать веб методу корневым объектом новой транзакции. Происходит это аналогично использованию сервисов без компонент COM+. Следует отметить, что веб метод может быть либо только корнем транзакции, либо не участвовать в ней. Поддержка распределенных между несколькими веб службами транзакций в .NET Framework 2.0 / WSE 3.0 отсутствует. Следующий веб метод является корнем новой транзакции.

<%@ WebService class="BankAccount" language="C#" %>

using System;
using System.Web.Services;
using System.EnterpriseServices;
using Microsoft.Web.Services3;

[WebService(Namecpace="http://super.bank/webservices")]
[Policy("BankAccountService")]
public class BankAccount : WebService 
{
    [WebMethod(TransactionOption=TransactionOption.RequiresNew]
     public void Transfer(double Amount)  
     {
       // ...
       // необязательное завершение транзакции в явном виде
       ContextUtil.SetComplete();
     }
 }

Еще двумя важными атрибутами веб методов являются SoapRpcMethodAttribute и SoapDocumentMethodAttribute. Они определяют описание интерфейса метода на языке WSDL. В частности, при атрибуте SoapDocumentMethodAttribute будет использоваться кодирование параметров SOAP Document, что в настоящее время является стандартом, а при использовании SoapRpcMethodAttribute будет применяться кодирование SOAP RPC, в настоящее время признанное устаревшим. Следует отметить, что для преобразования содержимого тела пакета SOAP в параметры метода в обоих случаях используется класс XmlSerializer, поэтому на типы аргументов и результатов веб метода действуют все описанные в главе о сериализации ограничения, связанные с классом XmlSerializer. Атрибуты SoapDocumentMethod и SoapRpcMethod также содержат свойство OneWay, позволяющее клиенту производить односторонний вызов метода службы.