Создание бизнес-приложений с помощью Silverlight - Междоменные политики для веб-служб, размещенных вне IIS

Междоменные политики для веб-служб, размещенных вне IIS

Возможны ситуации, когда с целью эффективного управления состоянием службы размещают в процессах ОС вне IIS. Для междоменного доступа к таким службам WCF процесс должен будет разместить политики в корневом каталоге конечной точки HTTP. При вызове междоменной веб-службы Silverlight выдает запрос HTTP Get к clientaccesspolicy.xml. Если служба размещена внутри IIS, файл clientaccesspolicy.xml можно скопировать в корневой каталог веб-узла, а все остальное обслуживание файла выполнит IIS. В случае пользовательского размещения на локальной машине http://localhost:<port>/clientaccesspolicy.xml должен представлять допустимый адрес URL.

Поскольку в демонстрационном примере центра обработки вызовов не используются никакие размещаемые пользователем веб-службы, для демонстрации концепций я буду использовать в приложении консоли простую службу TimeService. Консоль будет предоставлять конечную точку передачи репрезентативного состояния (REST) с помощью новых возможностей REST платформы Microsoft .NET Framework 3.5. В качестве значения свойства UriTemplate необходимо установить именно тот литерал, который приведен на рис. 7.

Рис. 7. Реализация для размещаемых пользователем служб WCF

[ServiceContract]
public interface IPolicyService
{
    [OperationContract]            
    [WebInvoke(Method = "GET", UriTemplate = "/clientaccesspolicy.xml")]  
    Stream GetClientAccessPolicy();
}
public class PolicyService : IPolicyService
{
    public Stream GetClientAccessPolicy()
    {
        FileStream fs = new FileStream("PolicyFile.xml", FileMode.Open);
        return fs;
    }
}

Имя интерфейса или имя метода не имеет никакого значения для результата; вы можете выбрать любое, которое вам понравится. У WebInvoke имеются другие свойства, такие как RequestFormat и ResponseFormat, которые по умолчанию настроены на XML; нет необходимости указывать их значения явно. Точно так же мы полагаемся на значение BodyStyle.Bare, установленное по умолчанию для свойства BodyStyle, что означает, что ответ не будет заключаться в оболочку.

Реализация службы крайне проста: в ответ на запрос клиента Silverlight файл clientaccesspolicy.xml просто передается в потоке. Имя файла политики можно выбирать самостоятельно, поэтому оно может быть любым. Реализация службы политик показана на рис. 7.

Теперь нам требуется настроить IPolicyService для обслуживания запросов HTTP в стиле REST. App.Config для приложения консоли (ConsoleWebServices) показан на рис. 8. Следует сделать несколько замечаний относительно необходимости специальной настройки: привязку конечной точки ConsoleWebServices.IPolicyServer необходимо настроить на webHttpBinding. Кроме этого, поведение конечной точки IPolicyService необходимо настроить с помощью WebHttpBehavior, как показано в файле настройки. В качестве базового адреса PolicyService следует установить адрес URL корневого каталога (как в ), а адрес конечной точки следует оставить пустым (например <endpoint address="" … contract="ConsoleWebServices.IPolicyService" />.

Рис. 8. Настройки WCF для пользовательской среды размещения

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <!-- IPolicyService end point should be configured with 
           webHttpBinding-->
      <service name="ConsoleWebServices.PolicyService">
         <endpoint address="" 
               behaviorConfiguration="ConsoleWebServices.WebHttp"
               binding="webHttpBinding" 
               contract="ConsoleWebServices.IPolicyService" />
         <host>
           <baseAddresses>
             <add baseAddress="http://localhost:3045/" />
           </baseAddresses>
         </host>
      </service>
      <service behaviorConfiguration="ConsoleWebServices.TimeServiceBehavior"
               name="ConsoleWebServices.TimeService">
         <endpoint address="TimeService" binding="basicHttpBinding" 
               contract="ConsoleWebServices.ITimeService">
         </endpoint>
         <host>
            <baseAddresses>
              <add baseAddress="http://localhost:3045/TimeService.svc" />
            </baseAddresses>
         </host>
       </service>
     </services>
     <behaviors>
        <endpointBehaviors>
          <!--end point behavior is used by REST endpoints like 
              IPolicyService described above-->
          <behavior name="ConsoleWebServices.WebHttp">
            <webHttp />
          </behavior>
        </endpointBehaviors>
       ... 
      </behaviors>
    </system.serviceModel>
</configuration>

Наконец, службы, размещаемые в консоли, например TimeService, приведенная в примерах кода и настроек, должны быть настроены так, чтобы их адрес URL имел вид, подобный адресу их IIS аналогов. Например, адрес URL конечной точки службы TimeService, размещаемой в IIS, может иметь следующий вид на HTTP по умолчанию: http://localhost/TimeService.svc. В этом случае метаданные можно получить с http://localhost/TimeService.svc?WSDL.

В случае размещения в консоли метаданные можно получить, добавив «?WSDL» к базовому адресу места размещения службы. В настройке, показанной на рис. 8, видно, что базовый адрес службы TimeService имеет вид http://localhost:3045/TimeService.svc, следовательно, метаданные можно получить с адреса http://localhost:3045/TimeService.svc?WSDL.

Этот адрес URL подобен тому, который мы используем при размещении в IIS. Если базовый адрес настроен на значение http://localhost:3045/TimeService.svc/, тогда метаданные адреса URL имеют вид http://localhost:3045/TimeService.svc/?WSDL, что выглядит несколько странно. Так что следите за этим поведением, поскольку это может сэкономить вам время при вычислении метаданных URL.