Konfigurowanie usług za pomocą plików konfiguracji

  • Artykuł

Skonfigurowanie usługi Windows Communication Foundation (WCF) przy użyciu pliku konfiguracji zapewnia elastyczność dostarczania danych dotyczących zachowania punktu końcowego i usługi w momencie wdrażania zamiast w czasie projektowania. W tym temacie opisano dostępne podstawowe techniki.

Usługa WCF można skonfigurować przy użyciu technologii konfiguracji programu .NET Framework. Najczęściej elementy XML są dodawane do pliku Web.config dla witryny usług Internet Information Services (IIS), która hostuje usługę WCF. Elementy umożliwiają zmianę szczegółów, takich jak adresy punktów końcowych (rzeczywiste adresy używane do komunikowania się z usługą) na maszynie według maszyny. Ponadto program WCF zawiera kilka elementów dostarczanych przez system, które umożliwiają szybkie wybieranie najbardziej podstawowych funkcji usługi. Począwszy od programu .NET Framework 4, program WCF jest wyposażony w nowy domyślny model konfiguracji, który upraszcza wymagania dotyczące konfiguracji programu WCF. Jeśli nie podasz żadnej konfiguracji programu WCF dla określonej usługi, środowisko uruchomieniowe automatycznie konfiguruje usługę przy użyciu niektórych standardowych punktów końcowych i domyślnego powiązania/zachowania. W praktyce pisanie konfiguracji jest główną częścią programowania aplikacji WCF.

Aby uzyskać więcej informacji, zobacz Konfigurowanie powiązań dla usług. Aby uzyskać listę najczęściej używanych elementów, zobacz Powiązania dostarczone przez system. Aby uzyskać więcej informacji na temat domyślnych punktów końcowych, powiązań i zachowań, zobacz Uproszczone konfigurowanie i uproszczona konfiguracja usług WCF.

Ważne

Podczas wdrażania równoległych scenariuszy, w których wdrażane są dwie różne wersje usługi, należy określić częściowe nazwy zestawów, do których odwołuje się pliki konfiguracji. Dzieje się tak, ponieważ plik konfiguracji jest współużytkowany we wszystkich wersjach usługi i może być uruchomiony w różnych wersjach programu .NET Framework.

System.Configuration: Web.config i App.config

Program WCF używa systemu konfiguracji System.Configuration programu .NET Framework.

Podczas konfigurowania usługi w programie Visual Studio użyj pliku Web.config lub pliku App.config, aby określić ustawienia. Wybór nazwy pliku konfiguracji zależy od wybranego środowiska hostingu dla usługi. Jeśli używasz usług IIS do hostowania usługi, użyj pliku Web.config. Jeśli używasz innego środowiska hostingu, użyj pliku App.config.

W programie Visual Studio plik o nazwie App.config służy do tworzenia końcowego pliku konfiguracji. Ostateczna nazwa faktycznie używana dla konfiguracji zależy od nazwy zestawu. Na przykład zestaw o nazwie "Cohowinery.exe" ma ostateczną nazwę pliku konfiguracji "Cohowinery.exe.config". Należy jednak zmodyfikować tylko plik App.config. Zmiany wprowadzone w tym pliku są automatycznie wprowadzane do końcowego pliku konfiguracji aplikacji w czasie kompilacji.

W przypadku korzystania z pliku App.config system konfiguracji scala plik App.config z zawartością pliku Machine.config po uruchomieniu aplikacji i zastosowaniu konfiguracji. Ten mechanizm umożliwia definiowanie ustawień całego komputera w pliku Machine.config. Plik App.config może służyć do zastępowania ustawień pliku Machine.config; Możesz również zablokować ustawienia w pliku Machine.config, aby były używane. W przypadku pliku Web.config system konfiguracji scala pliki Web.config we wszystkich katalogach prowadzących do katalogu aplikacji do konfiguracji, która zostanie zastosowana. Aby uzyskać więcej informacji na temat konfiguracji i priorytetów ustawień, zobacz tematy w System.Configuration przestrzeni nazw.

Główne sekcje pliku konfiguracji

Główne sekcje w pliku konfiguracji zawierają następujące elementy.

<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>

Uwaga

Sekcje powiązań i zachowań są opcjonalne i są uwzględniane tylko w razie potrzeby.

Element <usług>

Element services zawiera specyfikacje wszystkich usług hostów aplikacji. Począwszy od uproszczonego modelu konfiguracji w programie .NET Framework 4, ta sekcja jest opcjonalna.

<services>

Element <usługi>

Każda usługa ma następujące atrybuty:

  • name. Określa typ, który zapewnia implementację kontraktu usługi. Jest to w pełni kwalifikowana nazwa, która składa się z przestrzeni nazw, kropki, a następnie nazwy typu. Na przykład: "MyNameSpace.myServiceType".

  • behaviorConfiguration. Określa nazwę jednego z behavior elementów znalezionych w elemecie behaviors . Określone zachowanie zarządza akcjami, takimi jak to, czy usługa zezwala na personifikację. Jeśli jego wartość jest pustą nazwą lub nie behaviorConfiguration jest podana, domyślny zestaw zachowań usługi jest dodawany do usługi.

  • <Usługi>

Element punktu końcowego <>

Każdy punkt końcowy wymaga adresu, powiązania i kontraktu, które są reprezentowane przez następujące atrybuty:

  • address. Określa identyfikator URI (Uniform Resource Identifier) usługi, który może być adresem bezwzględnym lub podanym względem podstawowego adresu usługi. Jeśli ustawiono pusty ciąg, oznacza to, że punkt końcowy jest dostępny pod adresem podstawowym określonym podczas tworzenia ServiceHost dla usługi.

  • binding. Zazwyczaj określa powiązanie dostarczone przez system, takie jak WSHttpBinding, ale może również określać powiązanie zdefiniowane przez użytkownika. Określone powiązanie określa typ używanego transportu, zabezpieczeń i kodowania oraz czy obsługiwane są niezawodne sesje, transakcje lub przesyłanie strumieniowe.

  • bindingConfiguration. Jeśli należy zmodyfikować wartości domyślne powiązania, można to zrobić, konfigurując odpowiedni binding element w elemecie bindings . Ten atrybut powinien mieć taką samą wartość jak name atrybut binding elementu, który jest używany do zmiany wartości domyślnych. Jeśli nie podano nazwy lub nie określono jej bindingConfiguration w powiązaniu, domyślne powiązanie typu powiązania jest używane w punkcie końcowym.

  • contract. Określa interfejs definiujący kontrakt. Jest to interfejs zaimplementowany w typie środowiska uruchomieniowego języka wspólnego (CLR) określonym przez name atrybut service elementu.

  • <Punktu końcowego>

Element <bindings>

Element bindings zawiera specyfikacje wszystkich powiązań, które mogą być używane przez dowolny punkt końcowy zdefiniowany w dowolnej usłudze.

<Powiązania>

<Element powiązania>

binding Elementy zawarte w elemecie bindings mogą być jednym z powiązań dostarczanych przez system (zobacz Powiązania dostarczone przez system) lub powiązaniem niestandardowym (zobacz Powiązania niestandardowe). Element binding ma name atrybut, który koreluje powiązanie z punktem końcowym określonym w bindingConfiguration atrybucie endpoint elementu. Jeśli nie określono nazwy, to powiązanie odpowiada domyślnemu typowi powiązania.

Aby uzyskać więcej informacji na temat konfigurowania usług i klientów, zobacz Konfigurowanie usług WCF.

<Wiązania>

Element <behaviors>

Jest to element kontenera behavior dla elementów, które definiują zachowania usługi.

<Zachowania>

> Zachowanie, <element

Każdy behavior element jest identyfikowany przez name atrybut i zapewnia zachowanie udostępniane przez system, takie jak <throttling>, lub zachowanie niestandardowe. Jeśli nie podano nazwy, ten element zachowania odpowiada domyślnemu zachowaniu usługi lub punktu końcowego.

<Zachowanie>

Jak używać konfiguracji powiązań i zachowań

Program WCF ułatwia udostępnianie konfiguracji między punktami końcowymi przy użyciu systemu referencyjnego w konfiguracji. Zamiast bezpośrednio przypisywać wartości konfiguracji do punktu końcowego, powiązane z powiązaniem wartości konfiguracji są grupowane w bindingConfiguration elementach <binding> w sekcji. Konfiguracja powiązania jest nazwaną grupą ustawień w powiązaniu. Punkty końcowe mogą następnie odwoływać się do elementu bindingConfiguration według nazwy.

<?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>

Element name jest bindingConfiguration ustawiony w elemecie <binding> . Musi name być unikatowym ciągiem w zakresie typu powiązania — w tym przypadku <parametrem basicHttpBinding> lub pustą wartością, aby odwołać się do powiązania domyślnego. Punkt końcowy łączy się z konfiguracją bindingConfiguration , ustawiając atrybut na ten ciąg.

Element A behaviorConfiguration jest implementowany w taki sam sposób, jak pokazano w poniższym przykładzie.

<?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>

Należy pamiętać, że do usługi jest dodawany domyślny zestaw zachowań usługi. Ten system umożliwia punktom końcowym udostępnianie typowych konfiguracji bez ponownego definiowania ustawień. Jeśli wymagany jest zakres obejmujący całą maszynę, utwórz konfigurację powiązania lub zachowania w pliku Machine.config. Ustawienia konfiguracji są dostępne we wszystkich plikach App.config. Narzędzie edytora konfiguracji (SvcConfigEditor.exe) ułatwia tworzenie konfiguracji.

Scalanie zachowania

Funkcja scalania zachowania ułatwia zarządzanie zachowaniami, gdy chcesz, aby zestaw typowych zachowań był używany spójnie. Ta funkcja umożliwia określenie zachowań na różnych poziomach hierarchii konfiguracji i dziedziczenie zachowań usług z wielu poziomów hierarchii konfiguracji. Aby zilustrować, jak to działa, załóżmy, że w usługach IIS masz następujący układ katalogu wirtualnego:

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

~\Web.config Plik ma następującą zawartość:

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

Masz podrzędną konfigurację Web.config znajdującą się w lokalizacji ~\Child\Web.config z następującą zawartością:

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

Usługa znajdująca się w lokalizacji ~\Child\Service.svc będzie działać tak, jakby zachowywała się zarówno w przypadku zachowania serviceDebug, jak i serviceMetadata. Usługa znajdująca się w lokalizacji ~\Service.svc będzie miała tylko zachowanie serviceDebug. Dzieje się tak, że dwie kolekcje zachowań o tej samej nazwie (w tym przypadku pusty ciąg) są scalane.

Kolekcje zachowań można również wyczyścić przy użyciu tagu <clear> i usunięte poszczególne zachowania z kolekcji przy użyciu tagu <remove> . Na przykład następujące dwie konfiguracje powoduje, że usługa podrzędna ma tylko zachowanie 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>

Scalanie zachowania odbywa się również w przypadku kolekcji zachowań bez nazw, jak pokazano powyżej i nazwanych kolekcji zachowań.

Scalanie zachowania działa w środowisku hostingu usług IIS, w którym pliki Web.config scalają hierarchicznie z głównym plikiem Web.config i machine.config. Działa również w środowisku aplikacji, w którym plik machine.config może zostać scalony z plikiem App.config.

Scalanie zachowania dotyczy zarówno zachowań punktów końcowych, jak i zachowań usługi w konfiguracji.

Jeśli kolekcja zachowań podrzędnych zawiera zachowanie, które jest już obecne w kolekcji zachowań nadrzędnych, zachowanie podrzędne zastępuje element nadrzędny. Więc jeśli kolekcja zachowań nadrzędnych miała <serviceMetadata httpGetEnabled="False" /> i kolekcja zachowań podrzędnych miała <serviceMetadata httpGetEnabled="True" />wartość , zachowanie podrzędne zastąpi zachowanie nadrzędne w kolekcji zachowań i httpGetEnabled będzie miało wartość "true".

Zobacz też