Процесс настройки AppFabric
Расширения AppFabric для диспетчера IIS и командлеты Windows PowerShell для AppFabric предоставляют владельцу приложения или ИТ-специалисту способы непосредственной настройки приложений, основанных на службах WCF и WF. В этом разделе описано, что происходит в файлах Web.config при настройке службы или приложения в расширениях диспетчера IIS или с помощью командлетов настройки AppFabric. Сначала в этом разделе описываются файлы Web.config, которые используются при настройке службы; затем здесь указывается, как непосредственно настроить службу; также здесь рассказывается о настройке значений по умолчанию для наследования службами.
Дополнительные сведения об использовании файлов Web.config в ASP.NET см. в статье ASP.NET Конфигурация.
Иерархия файлов Web.config
Каждый из элементов в иерархии конфигурации IIS может иметь собственный файл Web.config, а служба может наследовать параметры конфигурации по умолчанию из файлов Web.config, связанных с сервером, сайтом, приложением или подкаталогом, к которым принадлежит эта служба. В результате конфигурация службы определяется иерархией файлов Web.config. В этом разделе описаны правила, определяющие, какие файлы Web.config в иерархии определяют конфигурацию службы, и какие элементы в этих файлах являются приоритетными.
При установке AppFabric на сервере создается файл Web.config сервера (если такого файла еще нет), который помещается в тот же каталог, что и файл Machine.config (<диск>:\Windows\Microsoft.NET\Framework\v4.0.xxxxx\Config). Конфигурация в этом файле Web.config сервера включает отслеживание служб, сохраняемость рабочих процессов и управление экземплярами рабочих процессов. Также можно создать файл Web.config для веб-сайта, размещенного в каталоге веб-сайтов (диск:\inetpub\wwwroot), для приложения — в корневом каталоге приложения, а также для подкаталога приложения. Файлы Web.config сайта, приложения и подкаталога не создаются при установке AppFabric. Если при попытке использования расширений AppFabric в диспетчере IIS для изменения конфигурации в какой-либо области не будет файла Web.config, он будет создан автоматически.
Файл Web.config на любом уровне может содержать параметры конфигурации, которые напрямую применимы к службе, однако если необходимо определить службу непосредственно в пользовательском интерфейсе диспетчера IIS, потребуется работать с определением службы в файле Web.config приложения. Помимо этих параметров, файлы Web.config на уровнях сервера, сайта, приложения и подкаталога могут содержать параметры конфигурации по умолчанию, которые могут быть наследованы службой. Параметры приложения, заданные в пользовательском интерфейсе расширений AppFabric для диспетчера IIS, и командлеты конфигурации влияют только на файлы Web.config, но не на файлы machine.config или другие файлы, которые определяют настройки среды. Исключением из этого правила является определение автозапуска приложения в файле applicationHost.config на уровне сервера.
Файл Web.config содержит вложенную иерархию тегов и вложенных тегов XML с атрибутами, которые определяют параметры конфигурации. Некоторые параметры конфигурации для служб, основанных на WCF и WF, определяются в рамках реакции на событие службы. В AppFabric большинство средств конфигурации (но не все) способно изменять реакции на события. Однако некоторые параметры определяются за пределами реакции на события службы. Например, наблюдение, адреса конечных точек и квоты привязки транспорта для службы настраиваются в файле Web.config, но не входят в реакцию на событие. Настройки сборщиков событий и диагностики системы (находятся на уровне приложения и выше) не определяются в рамках реакции на событие.
Примечание
Для управления конфигурацией AppFabric используется средство Microsoft Web Administration (MWA). Для MWA необходимо, чтобы все элементы конфигурации были систематизированы. Сведения о порядке создания схемы для настраиваемого поведения см. в статье Extending IIS 7.0 Schema and Accessing the Custom Sections Using MWA.
Настройка службы напрямую
Можно настроить службу с помощью именованной реакции на событие службы в файле Web.config. Для этого введите в файле Web.config тег <service> с атрибутом behaviorConfiguration, который указывает на тег реакции на событие службы. Именованная реакция на событие может быть определена для службы в файле Web.config на уровне приложения или на более высоком уровне. Ниже приведен пример службы с именем TestService, конфигурация которой определяется в именованной реакции на событие службы с именем TestGetMetaData:
<system.serviceModel>
<services>
<service name="TestService" behaviorConfiguration="TestGetMetaData" >
<endpoint address="/TestService" binding="wsHttpBinding" contract="ITestService"/>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="TestGetMetaData"> <serviceMetadata httpGetEnabled="true" httpGetUrl=""/> </behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
В платформе .NET Framework 3.5 самым прямым способом настройки многих аспектов служб является использование именованной реакции на событие службы в файле Web.config приложения (или подкаталога) службы. В .NET Framework 4.0 новые шаблоны поощряют использование безымянных реакций на события, с помощью которых служба наследует конфигурацию по умолчанию. Дополнительные сведения см. в подразделе "Настройка значений по умолчанию для наследования службой" далее в этом разделе.
Средства настройки AppFabric изменяют следующие реакции на события службы:
sqlWorkflowInstanceStore (сохраняемость);
etwTracking (наблюдение);
serviceThrottling (производительность);
serviceCredentials/serviceCertificate (безопасность);
workflowIdle;
workflowUnhandledException;
workflowInstanceManagement.
Настройка значений по умолчанию для наследования службой
Использование именованной реакции на событие службы в файле Web.config приложения не является единственным способом настройки служб. Служба также может наследовать параметры конфигурации по умолчанию из файлов Web.config сервера, сайта, приложения и подкаталога, к которым принадлежит эта служба. Некоторые параметры конфигурации по умолчанию для служб, основанных на WCF и WF, определяются в рамках безымянной реакции на событие службы.
Использование безымянных реакций на события
Если существует именованная реакция на событие службы, на которую указывает атрибут службы behaviorConfiguration, эта служба будет использовать параметры в именованной реакции на событие. Также она будет наследовать параметры из всех других именованных реакций на события с тем же именем, расположенных на более высоких уровнях. Служба не будет использовать параметры реакции на событие службы по умолчанию, определенные в файлах Web.config на уровнях подкаталога, приложения, сайта и сервера, которые применяются к службе. Однако можно изменить тег <service> в файле Web.config приложения, чтобы служба наследовала значения по умолчанию. Сделать это можно, определив безымянную реакцию на событие службы в файле Web.config на одном или нескольких уровнях и указав, что служба использует эту безымянную реакцию на событие. Служба будет использовать безымянную реакцию на событие, если имя атрибута behaviorConfiguration элемента службы равно пустой строке, как показано в следующем примере кода:
<services>
<service name=”TutorialService” behaviorConfiguration=””
<endpoint address=”” binding=”wsHttpBinding” contract=”IService” />
</service>
</services>
Исключение атрибута behaviorConfiguration, как показано в следующем коде, приведет к такому же результату. Выше безымянная реакция на событие использовалась явно. Ниже она используется неявно.
<services>
<service name=”TutorialService”
<endpoint address=”” binding=”wsHttpBinding” contract=”IService” />
</service>
</services>
Наличие безымянного элемента behaviorConfiguration вызывает наследование настроек службы из одной или нескольких безымянных реакций на события, определенных в элементе serviceBehavior. Ниже приведен безымянный элемент serviceBehavior, который определен по умолчанию на уровне сервера. Эта конфигурация по умолчанию для сервера (созданная при установке AppFabric) включает отслеживание служб, сохраняемость рабочих процессов и управление экземплярами рабочих процессов.
<behaviors>
<serviceBehaviors>
<behavior name=””>
<workflowIdle timeToUnload="00:01:00" timeToPersist="infinite" />
<workflowInstanceManagement authorizedWindowsGroup=”AS_Administrators" />
<etwTracking profileName="HealthMonitoring Tracking Profile" />
</behavior>
</serviceBehaviors>
</behaviors>
Безымянная реакция на событие может быть определена в файле Web.config на любом уровне иерархии. Если безымянные реакции на события определяются на нескольких уровнях, содержащих службу, конфигурация службы будет состоять из объединенных параметров каждой безымянной реакции на событие, определенной в иерархии. Если две и более безымянных реакции на события в иерархии службы содержат конфликтующие параметры, будут использоваться параметры из более низкого или самого низкого уровня. Такой процесс объединения параметров конфигурации службы из нескольких безымянных реакций на события называется объединением реакций на события.
Теги удаления и очистки также могут быть использованы в разделах реакций на события файлов Web.config. Тег удаления служит для удаления параметра из содержащей его безымянной реакции на событие. Тег очистки удаляет все реакции на события для службы.
Все службы со значением атрибута behaviorConfiguration, равным пустой строке, будут наследовать значения настроек по умолчанию из безымянных реакций на события, определенных в иерархии. В файле Web.config любого уровня может быть определена только одна безымянная реакция на событие.
Безымянная реакция на событие используется неявно (без атрибута behaviorConfiguration) в случае неявных служб (также называемых «службами без тегов»). Служба без тегов не объявляется в файле Web.config. C ней не связан узел службы в файле Web.config. По умолчанию новые типы проектов в Visual Studio 10 создают службы без тегов. При обнаружении в среде выполнения службы без тегов к этой службе автоматически применяются соответствующие безымянные реакции на события. Обратите внимание, что конечные точки службы без тегов невозможно изменить в расширениях диспетчера IIS; для этого следует добавить именованный элемент службы в файл Web.config.
Несмотря на то, что некоторые параметры конфигурации по умолчанию для служб на основе WCF и WF определяются в безымянной реакции службы на событие, другие параметры определяются за рамками безымянной реакции на событие. Например, в случае со строками подключения или коллекциями служба будет наследовать значения настроек из всех файлов конфигурации в иерархии.
Настройка значений по умолчанию в диспетчере IIS
Можно настроить приложение непосредственно с помощью пользовательского интерфейса расширений AppFabric для диспетчера IIS. При этом AppFabric задает именованную реакцию на событие службы в соответствующих файлах Web.config (как правило, на уровне приложения). Также диспетчер IIS можно использовать для изменения конфигурации службы с использованием значений по умолчанию с уровней подкаталога, приложения, сайта и сервера вместо прямой настройки службы. При этом безымянные реакции файла Web.config изменяются. AppFabric выполняет слияние реакций для создания полного набора параметров конфигурации приложения.
Если одно и то же свойство конфигурации имеет различные значения в нескольких файлах Web.config, то в AppFabric будет использоваться значение с более низкого или самого низкого уровня. Поля в диалоговом окне Настройка службы для службы заполняются на основе безымянных реакций на события в применимых файлах Web.config. Можно изменить эти значения в пользовательском интерфейсе конфигурации на уровне сервера. В этом случае будет изменена безымянная реакция на событие, применимая к соответствующему приложению. Также можно изменить значения по умолчанию на уровне подкаталога, сайта и сервера. Если изменить параметр по умолчанию в безымянной реакции на событие более высокого уровня после создания безымянной реакции на событие уровня приложения, изменение безымянной реакции на событие более высокого уровня будет распространено на уровень службы, если эта реакция на событие не будет переопределена на более низком уровне.
Чтобы определить параметры по умолчанию для уровня приложения, подкаталога, сайта или сервера в диспетчере IIS, следует выбрать уровень в области «Подключения», а затем выбрать команду Настроить в области «Действия» в разделе Управление службами WCF и WF. Также можно щелкнуть правой кнопкой мыши уровень в области «Подключения», выбрать пункт Управление службами WCF и WF и команду Настроить. Это приведет к отображению диалогового окна настройки этого уровня. Если файл Web.config отсутствует на этом уровне, то при изменении параметров этого уровня по умолчанию в пользовательском интерфейсе такой файл будет создан в AppFabric.
При настройке службы в расширениях AppFabric для диспетчера IIS не выбирается конфигурация именованной реакции на событие, которая будет использоваться. Значения вводятся или выбираются в диалоговом окне Настройка службы для этой службы; AppFabric изменяет файл Web.config. Можно использовать командлеты Windows PowerShell для AppFabric, чтобы задать различные параметры конфигурации реакции на событие.
Использование тегов расположения
AppFabric поддерживает операции чтения для тегов расположения в файлах Web.config. Тег расположения — это очередной способ определения конфигурации службы, помимо использования именованной реакции службы на событие или определения реакций на события по умолчанию с помощью безымянной реакции службы на событие или службы без тегов. Тег расположения — это элемент, встроенный в файл Web.config, который применяет параметры конфигурации к указанному в этом теге объекту. Тег расположения содержит один или несколько параметров конфигурации. Также он содержит путь, указывающий на объект, к которому будут применены свойства конфигурации. В отличие от именованной реакции на событие службы (которая должна быть включена в узел <services> соответствующего файла Web.config приложения), тег расположения может быть указан в любом файле Web.config. В отличие от безымянной реакции на событие тег расположения не нуждается в наличии безымянного элемента behaviorConfiguration, содержащегося в узле <service> файла Web.config приложения.
Ниже приведен пример использования тега расположения в файле Web.config сайта, который применяет параметр конфигурации к службе s1 в приложении app1:
<location path=”app1/s1.svc” overrideMode=”Allow”>
<defaultDocument enabled=”true”>
<files>
<add value=”Developer.htm” />
</files>
</defaultDocument>
</location>
Если путь не указан, используется путь с уровня, на котором располагается тег расположения, с распространением на все дочерние пути (аналогично использованию точки). Если поступить так в файле applicationHost.config, будет указана конфигурация на глобальном уровне. Если элемент overrideMode в теге расположения имеет значение Allow, настройки, указанные в теге расположения, могут быть изменены и переопределены на более низких уровнях иерархии. Если элемент overrideMode не задан и существует несколько тегов расположения с указанием различных значений для одного параметра в одной службе, то для определения используемого параметра применяется набор правил выявления приоритета.
Применяемый к службе параметр конфигурации, который содержится в теге расположения, не может быть изменен в расширениях AppFabric для диспетчера IIS или с помощью командлета настройки AppFabric. Содержимое тега расположения доступно только для чтения как в пользовательском интерфейсе, так и в командлете. Если попытаться изменить тег расположения с помощью диспетчера IIS или командлета, будет возвращена ошибка. Чтобы изменить параметр, применяемый с помощью тега расположения, необходимо вручную изменить тег расположения в файле Web.config.
Утилизация
При нажатии кнопок Применить или ОК в диалоговом окне Настройка службы диспетчера IIS для изменения файла Web.config система утилизирует соответствующий домен приложения. При нажатии кнопок Применить или ОК для определения параметров по умолчанию на уровне подкаталога, приложения, сайта или службы в целях изменения соответствующего файла Web.config домены приложений для всех служб под этой областью будут утилизированы. Рекомендуется по возможности минимизировать количество процессов повторной настройки, особенно на более высоких уровнях, чтобы снизить затраты на утилизацию. При настройке значений по умолчанию рекомендуется придерживаться следующей последовательности: настройка значений по умолчанию на уровне сервера и сайта (в любой последовательности), импорт приложений, настройка приложений и содержащихся в них служб. Причина такой последовательности заключается в том, что настройка значений по умолчанию может привести к утилизации всего дерева. По возможности выполняйте действия по настройке до фактического запуска приложения, чтобы избежать расходов на утилизацию приложений.
2012-03-05