Поделиться через

Настройка служб с использованием файлов конфигурации

  • Статья

Настройка службы Windows Communication Foundation (WCF) с помощью файла конфигурации обеспечивает гибкость предоставления данных по конечной точке и поведению службы непосредственно в точке развертывания, а не во время разработки. В этой теме представлено описание основных доступных методов.

Службу WCF можно настроить с помощью технологии конфигурации .NET Framework. Чаще всего элементы XML добавляются в файл Web.config для узла служб IIS, на котором размещена служба WCF. Эти элементы позволяют изменять данные, такие как адреса конечных точек (фактические адреса, используемые для взаимодействия со службой), по схеме компьютер-компьютер. Кроме того, WCF включает в себя несколько предоставляемых системой элементов, которые позволяют быстро выбрать для службы самые основные функции. Начиная с версии .NET Framework, версия 4, в WCF входит новая модель конфигурации по умолчанию, которая обладает упрощенными требованиями к настройке WCF. Если для службы не указана конфигурация WCF, то среда выполнения автоматически выполняет настройку службы, указывая некоторые стандартные конечные точки, привязку и поведение по умолчанию. На практике запись конфигурации является основной частью процесса программирования приложений WCF.

Дополнительные сведения см. в разделе Настройка привязок для служб Windows Communication Foundation. Список Список чаще всего используемых элементов см. в разделе Привязки, предоставляемые системой. Дополнительные сведения о конечных точках по умолчанию, привязках и поведениях см. в разделах Упрощенная конфигурация и Упрощенная конфигурация служб WCF.

ms733932.Important(ru-ru,VS.100).gif Примечание
При развертывании сценариев параллельного выполнения, в которых развернуты две различные версии службы, необходимо указывать частичные имена сборок, на которые ссылаются файлы конфигурации. Это связано с тем, что файл конфигурации совместно используется всеми версиями службы, которые могут выполняться под управлением различных версий платформы .NET Framework.

System.Configuration: Web.config и App.config

WCF использует систему конфигурации System.Configuration .NET Framework.

Во время настройки службы в Visual Studio используйте либо файл Web.config, либо файл App.config, чтобы задать параметры. Выбор имени файла конфигурации определяется выбранной для службы средой размещения. Если служба размещается с помощью IIS, используйте файл Web.config. Если служба размещается с помощью другой среды размещения, используйте файл App.config.

В Visual Studio файл с именем App.config используется для создания окончательного файла конфигурации. Окончательное имя, которое фактически используется для конфигурации, зависит от имени сборки. Например, сборка с именем "Cohowinery.exe" имеет имя окончательного файла конфигурации "Cohowinery.exe.config". Однако следует изменить только файл App.config. Изменения, внесенные в это файл, автоматически вносятся в окончательный файл конфигурации приложения во время компиляции.

При использовании файла App.config система конфигурации объединяет файл App.config с содержимым файла Machine.config, когда запускается приложение и применяется конфигурация. Этот механизм позволяет определить параметры в рамках всего компьютера в файле Machine.config. Файл App.config можно использовать для переопределения параметров файла Machine.config. Также предусмотрена возможность блокировки в параметрах файла Machine.config согласно привычной работе. В случае использования файла Web.config система конфигурации объединяет файлы Web.config во всех каталогах вплоть до каталога приложения в применяемую конфигурацию. Дополнительные сведения конфигурации и приоритетах параметров см. в темах о пространстве имен System.Configuration.

Основные разделы файла конфигурации

Основные разделы файла конфигурации включают в себя следующие элементы.

<system.ServiceModel>

   <services>
   <!—- Define the service endpoints. This section is optional in the new
    default configuration model in .NET Framework 4. -->
      <service>
         <endpoint/>
      </service>
   </services>

   <bindings>
   <!-- Specify one or more of the system-provided binding elements,
    for example, <basicHttpBinding> --> 
   <!-- Alternatively, <customBinding> elements. -->
      <binding>
      <!-- For example, a <BasicHttpBinding> element. -->
      </binding>
   </bindings>

   <behaviors>
   <!-- One or more of the system-provided or custom behavior elements. -->
      <behavior>
      <!-- For example, a <throttling> element. -->
      </behavior>
   </behaviors>

</system.ServiceModel>
ms733932.note(ru-ru,VS.100).gifПримечание
Разделы привязок и поведения являются необязательными и указываются только при необходимости.

Элемент <services>

Элемент services содержит спецификации для всех служб, которые размещает приложение. Начиная с упрощенной модели настройки в .NET Framework 4, этот раздел задавать необязательно.

<services> element reference

Элемент <service>

Каждая служба имеет следующие атрибуты:

  • name. Определяет тип, обеспечивающий реализацию контракта службы. Это полное имя, состоящее из пространства имен, точки и имени типа, например "MyNameSpace.myServiceType".

  • behaviorConfiguration. Задает имя одного из элементов behavior, найденных в behaviors. Заданное поведение управляет действиями, например, разрешает ли служба олицетворение. Если значением является пустое имя, или объект behaviorConfiguration не указан, то в службу добавляется набор поведений службы по умолчанию.

  • <service> element reference

Элемент <endpoint>

Для каждой конечной точки требуется адрес, привязка и контракт, представленные следующими атрибутами:

  • address. Задает универсальный код ресурса (URI) службы, который может быть абсолютным адресом или адресом, указанным относительно базового адреса службы. Если задана пустая строка, это означает, что конечная точка доступна по базовому адресу, который указывается при создании ServiceHost для службы.

  • binding. Как правило, задает предоставляемую системой привязку типа WsHttpBinding, но также может задавать определяемую пользователем привязку. Заданная привязка определяет используемый тип транспорта, безопасности и кодирования, а также поддерживаются ли или включены ли надежные сеансы, транзакции или потоковая передача.

  • bindingConfiguration. Если требуется изменить значения привязки по умолчанию, можно настроить соответствующий элемент binding в элементе bindings. Этому атрибуту должно быть присвоено то же значение, что и атрибуту name элемента binding, который используется для изменения значений по умолчанию. Если имя не задано, или в привязке не задан объект bindingConfiguration, то в конечной точке используется привязка по умолчанию типа привязки.

  • contract. Задает интерфейс, определяющий контракт. Это интерфейс, реализованный в типе CLR, который задан атрибутом name элемента service.

  • <endpoint> element reference

Элемент <bindings>

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

<bindings> element reference

Элемент <binding>

Элементы binding, содержащиеся в элементе bindings, могут являться либо одной из предоставленных системой привязок (см. в разделе Привязки, предоставляемые системой), либо пользовательской привязкой (см. в разделе Пользовательские привязки). Элемент binding имеет атрибут name, сопоставляющий привязку с конечной точкой, заданной в атрибуте bindingConfiguration элемента endpoint. Если имя не указано, то привязка будет соответствовать значению по умолчанию для этого типа привязки.

Дополнительные сведения настройке служб и клиентов см. в разделе Configuring Windows Communication Foundation Applications.

<binding> element reference

Элемент <behaviors>

Это элемент контейнера для элементов behavior, задающих поведение службы.

<behaviors> element reference

Элемент <behavior>

Каждый элемент behavior определяется атрибутом name и содержит либо предоставляемое системой поведение (например, <throttling>), либо пользовательское поведение. Если имя не задано, то элемент behavior будет соответствовать поведению по умолчанию для службы или конечной точки.

<behavior> element reference

Практическое руководство. Конфигурации привязок и поведения

WCF упрощает совместный доступ к конфигурациям между конечными точками благодаря использованию системы ссылок в конфигурации. Вместо того, чтобы непосредственно назначать значения конфигурации для конечной точки, значения конфигурации, относящиеся к привязке, группируются в элементах bindingConfiguration в разделе <binding>. Конфигурация привязок представляет собой именованную группу параметров привязки. Конечные точки могут ссылаться на bindingConfiguration по имени.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <system.serviceModel>
  <bindings>
    <basicHttpBinding>
     <binding name="myBindingConfiguration1" closeTimeout="00:01:00" />
     <binding name="myBindingConfiguration2" closeTimeout="00:02:00" />
     <binding closeTimeout="00:03:00" />  <!—- Default binding for basicHttpBinding -->
    </basicHttpBinding>
     </bindings>
     <services>
      <service name="MyNamespace.myServiceType">
       <endpoint 
          address="myAddress" binding="basicHttpBinding" 
          bindingConfiguration="myBindingConfiguration1"
          contract="MyContract"  />
       <endpoint 
          address="myAddress2" binding="basicHttpBinding" 
          bindingConfiguration="myBindingConfiguration2"
          contract="MyContract" />
       <endpoint 
          address="myAddress3" binding="basicHttpBinding" 
          contract="MyContract" />
       </service>
      </services>
    </system.serviceModel>
</configuration>

name для bindingConfiguration задано в элементе <binding>. Атрибут name должен содержать уникальную строку в области типа привязки (в данном случае — <basicHttpBinding>) или пустое значение, указывающее на привязку по умолчанию. Конечная точка содержит ссылки на конфигурацию, задавая для этой строки атрибут bindingConfiguration.

behaviorConfiguration реализуется аналогичным образом, как показано в следующем образце.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.serviceModel>
    <behaviors>
      <endpointBehaviors>
        <behavior name="myBehavior">
           <callbackDebug includeExceptionDetailInFaults="true" />
         </behavior>
      </endpointBehaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="true" />
        </behavior>
      </serviceBehaviors>

    </behaviors>
    <services>
     <service name="NewServiceType">
       <endpoint 
          address="myAddress3" behaviorConfiguration="myBehavior"
          binding="basicHttpBinding"
          contract=”MyContract” />
      </service>
    </services>
   </system.serviceModel>
</configuration>

Заметьте, что в службу добавляет по умолчанию набор поведений службы. Эта система обеспечивает для конечных точек совместные общие конфигурации, не переопределяя параметры. Если требуется область уровня компьютера, создайте конфигурацию привязки или поведения в файле Machine.config. Параметры конфигурации доступны во всех файлах App.config. Средство редактирования конфигурации (SvcConfigEditor.exe) упрощает создание конфигураций.

Слияние поведений

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

~\Web.config~\Service.svc~\Child\Web.config~\Child\Service.svc

А файл ~\Web.config содержите следующее:

<configuration>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceDebug includeExceptionDetailInFaults="True" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Кроме того, имеется дочерний файл Web.config, расположенный в папке ~\Child\Web.config, со следующим содержимым:

<configuration>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="True" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Служба, расположенная в ~\Child\Service.svc, будет действовать таким образом, как будто бы для нее заданы и поведение serviceDebug, и поведение serviceMetadata. У службы, расположенной в ~\Service.svc, будет присутствовать только поведение serviceDebug behavior. В этой ситуации две коллекции поведений с одним и тем же именем (в данном случае пустой строкой) объединяются.

Также можно очищать коллекции поведений с помощью тега <clear> и удалять отдельные поведения из коллекции с помощью тега <remove>. Например, действие следующих двух конфигураций приведет к тому, что в дочерней службе будет только поведение serviceMetadata:

<configuration>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <remove name="serviceDebug"/>
          <serviceMetadata httpGetEnabled="True" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

<configuration>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <clear/>
          <serviceMetadata httpGetEnabled="True" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Слияние поведений проводится для безымянных коллекций поведений (как показано выше), а также для именованных коллекций поведений.

Слияние поведений работает в среде размещения IIS, в которой файлы Web.config сливаются в иерархическом порядке с корневыми файлами Web.config и machine.config. Но оно также работает и в среде приложений, где файл machine.config может объединяться с файлом App.config.

Слияние поведений применяется в конфигурациях как к поведениям конечных точек, так и к поведениям служб.

Если коллекция дочерних поведений содержит поведение, которое уже определено в коллекции родительских поведений, то дочернее поведение переопределяет родительское. Если коллекция родительских поведений содержит <serviceMetadata httpGetEnabled="False" />, а коллекция дочерних поведений содержит <serviceMetadata httpGetEnabled="True" />, то дочернее поведение переопределит в коллекции поведений родительское поведение и параметр httpGetEnabled примет значение «true».

См. также

Основные понятия

Упрощенная конфигурация

Другие ресурсы

Configuring Windows Communication Foundation Applications
<service>
<binding>