Konfigurowanie i rozszerzanie środowiska uruchomieniowego przy użyciu zachowań

Zachowania umożliwiają modyfikowanie zachowania domyślnego i dodawanie niestandardowych rozszerzeń, które sprawdzają i weryfikują konfigurację usługi lub modyfikują zachowanie środowiska uruchomieniowego w aplikacjach klienckich i usług programu Windows Communication Foundation (WCF). W tym temacie opisano interfejsy zachowania, sposób ich implementowania oraz sposób ich dodawania do opisu usługi (w aplikacji usługi) lub punktu końcowego (w aplikacji klienckiej) programowo lub w pliku konfiguracji. Aby uzyskać więcej informacji na temat używania zachowań udostępnianych przez system, zobacz Określanie zachowania Run-Time usługi i Określanie zachowania Run-Time klienta.

Zachowania

Typy zachowań są dodawane do obiektów opisu punktu końcowego usługi lub usługi (odpowiednio w usłudze lub kliencie), zanim te obiekty będą używane przez program Windows Communication Foundation (WCF) do utworzenia środowiska uruchomieniowego, które wykonuje usługę WCF lub klienta WCF. Gdy te zachowania są wywoływane podczas procesu budowy środowiska uruchomieniowego, mogą uzyskiwać dostęp do właściwości i metod środowiska uruchomieniowego, które modyfikują środowisko uruchomieniowe skonstruowane przez kontrakt, powiązania i adresy.

Metody zachowania

Wszystkie zachowania mają metodę AddBindingParameters, metodę ApplyDispatchBehavior, metodę Validate i metodę ApplyClientBehavior z jednym wyjątkiem: ponieważ IServiceBehavior nie może być wykonywana w kliencie, nie implementuje metody ApplyClientBehavior.

• AddBindingParameters Użyj metody , aby zmodyfikować lub dodać obiekty niestandardowe do kolekcji, do których powiązania niestandardowe mogą uzyskiwać dostęp do ich użycia podczas konstruowania środowiska uruchomieniowego. Na przykład w ten sposób określono wymagania dotyczące ochrony, które mają wpływ na sposób tworzenia kanału, ale nie są znane przez dewelopera kanału.

• Validate Użyj metody , aby zbadać drzewo opisu i odpowiadający mu obiekt środowiska uruchomieniowego, aby upewnić się, że jest on zgodny z pewnym zestawem kryteriów.

• Użyj metod ApplyDispatchBehavior i ApplyClientBehavior, aby zbadać drzewo opisu i zmodyfikować środowisko wykonawcze dla określonego zakresu w usłudze lub na kliencie. Można również wstawić obiekty rozszerzeń.

  Uwaga / Notatka

  Mimo że drzewo opisu jest podane w tych metodach, jest przeznaczone tylko do badania. Jeśli drzewo opisu zostanie zmodyfikowane, zachowanie jest niezdefiniowane.

Właściwości, które można zmodyfikować, oraz interfejsy dostosowywania, które można zaimplementować, są dostępne przez klasy środowiska uruchomieniowego usługi i klienta. Typy usług to klasy DispatchRuntime i DispatchOperation. Typy klientów to klasy ClientRuntime i ClientOperation. Klasy ClientRuntime i DispatchRuntime to punkty wejścia rozszerzalności, aby uzyskać dostęp odpowiednio do właściwości środowiska uruchomieniowego całego klienta i całej usługi oraz kolekcji rozszerzeń. Podobnie klasy ClientOperation i DispatchOperation kolejno ujawniają właściwości środowiska uruchomieniowego operacji klienta i operacji usługi oraz kolekcje rozszerzeń. Można jednak uzyskać dostęp do obiektu środowiska uruchomieniowego o szerszym zakresie z obiektu środowiska uruchomieniowego operacji lub na odwrót, jeśli jest to konieczne.

Większość użytkowników programu WCF nie współdziała bezpośrednio ze środowiskiem uruchomieniowym; Zamiast tego używają podstawowych konstrukcji modelu programowania, takich jak punkty końcowe, kontrakty, powiązania, adresy i atrybuty zachowania w klasach lub zachowaniach w plikach konfiguracji. Te konstrukcje składają się na drzewo opisu, które jest pełną specyfikacją tworzenia środowiska uruchomieniowego do obsługi usługi lub klienta opisanego przez drzewo opisu.

W programie WCF istnieją cztery rodzaje zachowań:

• Zachowania usługi (IServiceBehavior typy) umożliwiają dostosowanie całego środowiska uruchomieniowego usługi, w tym ServiceHostBase.

• Zachowania punktów końcowych (IEndpointBehavior typy) umożliwiają dostosowywanie punktów końcowych usługi i skojarzonych z EndpointDispatcher nimi obiektów.

• Zachowania kontraktów (IContractBehavior typy) umożliwiają dostosowywanie zarówno klas ClientRuntime w aplikacjach klienckich, jak i klas DispatchRuntime w aplikacjach usługowych.

• Zachowania operacji (IOperationBehavior typy) umożliwiają ponowne dostosowywanie klas ClientOperation i DispatchOperation na kliencie i usłudze.

Te zachowania można dodać do różnych obiektów opisu, implementując atrybuty niestandardowe, używając plików konfiguracji aplikacji lub bezpośrednio dodając je do kolekcji zachowań w odpowiednim obiekcie opisu. Jednak element ten musi być dodany do obiektu opisu usługi lub opisu punktu końcowego usługi przed wywołaniem ICommunicationObject.Open na ServiceHost lub ChannelFactory<TChannel>.

Zakresy zachowania

Istnieją cztery typy zachowań, z których każdy odpowiada określonemu zakresowi dostępu do środowiska uruchomieniowego.

Zachowania serwisowe

Zachowania usługi, które implementują IServiceBehavior, są podstawowym mechanizmem, za pomocą którego można modyfikować całe środowisko uruchomieniowe usługi. Istnieją trzy mechanizmy dodawania zachowań usługi do usługi.

1. Używanie atrybutu w klasie usługi. Kiedy konstruowany jest ServiceHost, implementacja ServiceHost wykorzystuje refleksję do wykrywania zestawu atrybutów typu usługi. Jeśli którykolwiek z tych atrybutów jest implementacją IServiceBehavior, są one dodawane do kolekcji zachowań na ServiceDescription. Dzięki temu te zachowania mogą uczestniczyć w konstruowaniu środowiska uruchomieniowego usługi.

2. Programowe dodawanie zachowania do kolekcji zachowań w programie ServiceDescription. Można to zrobić za pomocą następujących wierszy kodu:

   ServiceHost host = new ServiceHost(/* Parameters */);
   host.Description.Behaviors.Add(/* Service Behavior */);
   

3. Implementowanie niestandardowego BehaviorExtensionElement, które rozszerza konfigurację. Umożliwia to korzystanie z zachowania usługi z plików konfiguracji aplikacji.

Przykłady zachowań usługi w programie WCF obejmują ServiceBehaviorAttribute atrybut, ServiceThrottlingBehavior i ServiceMetadataBehavior zachowanie.

Zachowania kontraktu

Zachowania kontraktu, które implementują interfejs IContractBehavior, są wykorzystywane do rozbudowy środowiska uruchomieniowego zarówno klienta, jak i usługi w ramach kontraktu.

Istnieją dwa mechanizmy dodawania zachowań kontraktu do kontraktu. Pierwszy mechanizm polega na utworzeniu atrybutu niestandardowego, który ma być używany w interfejsie kontraktu. Gdy interfejs kontraktu jest przekazywany do elementu ServiceHost lub ChannelFactory<TChannel>, program WCF sprawdza atrybuty dotyczące interfejsu. Jeśli jakiekolwiek atrybuty są implementacjami IContractBehavior, są one dodawane do kolekcji zachowań na System.ServiceModel.Description.ContractDescription utworzonej dla tego interfejsu.

Można również zaimplementować atrybut zachowania niestandardowego kontraktu System.ServiceModel.Description.IContractBehaviorAttribute. W takim przypadku zachowanie jest następujące w przypadku zastosowania do:

•Interfejs kontraktu. W takim przypadku zachowanie jest stosowane do wszystkich umów tego typu w dowolnym punkcie końcowym, a usługa WCF ignoruje wartość właściwości IContractBehaviorAttribute.TargetContract.

•Klasa usługi. W takim przypadku zachowanie jest stosowane tylko do punktów końcowych, których kontrakt jest wartością TargetContract właściwości.

•Klasa wywołania zwrotnego. W takim przypadku zachowanie jest stosowane do punktu końcowego klienta dwustronnego, a WCF pomija wartość właściwości TargetContract.

Drugi mechanizm polega na dodaniu zachowania do kolekcji zachowań w obiekcie ContractDescription.

Przykłady zachowań kontraktów w programie WCF obejmują atrybut System.ServiceModel.DeliveryRequirementsAttribute. Aby uzyskać więcej informacji i przykład, zobacz temat referencyjny.

Zachowania punktów końcowych

Zachowania punktów końcowych, które implementują IEndpointBehaviorelement, są podstawowym mechanizmem, za pomocą którego można zmodyfikować całą usługę lub środowisko wykonawcze klienta dla określonego punktu końcowego.

Istnieją dwa mechanizmy dodawania zachowań punktów końcowych do usługi.

1. Dodaj zachowanie do właściwości Behaviors.

2. Zaimplementuj niestandardowy BehaviorExtensionElement , który rozszerza konfigurację.

Aby uzyskać więcej informacji i przykład, zobacz temat referencyjny.

Zachowania systemu

Zachowania operacji, które implementują IOperationBehavior interfejs, są używane do rozszerzania zarówno środowiska uruchomieniowego klienta, jak i usługi dla każdej operacji.

Istnieją dwa mechanizmy dodawania zachowań operacyjnych do działań. Pierwszy mechanizm polega na utworzeniu atrybutu niestandardowego, który ma być używany w metodzie modelowej operacji. Po dodaniu operacji do ServiceHost lub ChannelFactory, WCF dodaje wszelkie IOperationBehavior atrybuty do kolekcji zachowań na OperationDescription utworzonej dla tej operacji.

Drugi mechanizm polega na bezpośrednim dodaniu zachowania do kolekcji zachowań na skonstruowanym OperationDescription.

Przykłady zachowań operacji w programie WCF obejmują elementy OperationBehaviorAttribute i TransactionFlowAttribute.

Aby uzyskać więcej informacji i przykład, zobacz temat referencyjny.

Używanie konfiguracji do tworzenia zachowań

Zachowania usługi i punktu końcowego oraz kontraktu mogą być określone w kodzie lub przy użyciu atrybutów; Tylko zachowania usługi i punktu końcowego można skonfigurować przy użyciu plików konfiguracji aplikacji lub sieci Web. Uwidacznianie zachowań przy użyciu atrybutów umożliwia deweloperom określenie zachowania w czasie kompilacji, którego nie można dodać, usunąć ani zmodyfikować w czasie wykonywania. Jest to często odpowiednie w przypadku zachowań, które są zawsze wymagane do prawidłowej operacji usługi (na przykład parametrów związanych z transakcją z atrybutem System.ServiceModel.ServiceBehaviorAttribute ). Uwidacznianie zachowań przy użyciu konfiguracji umożliwia deweloperom pozostawienie specyfikacji i konfiguracji tych zachowań osobom wdrażającym usługę. Jest to odpowiednie w przypadku zachowań, które są opcjonalnymi składnikami lub inną konfiguracją specyficzną dla wdrożenia, takie jak uwidocznienie metadanych dla usługi lub określonej konfiguracji autoryzacji dla usługi.

Aby uwidocznić zachowanie przy użyciu konfiguracji, deweloper musi utworzyć klasę pochodną, BehaviorExtensionElement a następnie zarejestrować to rozszerzenie w konfiguracji.

Poniższy przykład kodu pokazuje, jak IEndpointBehavior implementuje BehaviorExtensionElement.

// BehaviorExtensionElement members
public override Type BehaviorType
{
  get { return typeof(EndpointBehaviorMessageInspector); }
}

protected override object CreateBehavior()
{
  return new EndpointBehaviorMessageInspector();
}

Aby system konfiguracji mógł załadować niestandardowy BehaviorExtensionElementelement , musi zostać zarejestrowany jako rozszerzenie. Poniższy przykład kodu przedstawia plik konfiguracji poprzedniego zachowania punktu końcowego:

<configuration>
  <system.serviceModel>
    <services>
      <service
        name="Microsoft.WCF.Documentation.SampleService"
        behaviorConfiguration="metadataSupport"
      >
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:8080/ServiceMetadata" />
          </baseAddresses>
        </host>
        <endpoint
          address="/SampleService"
          binding="wsHttpBinding"
          behaviorConfiguration="withMessageInspector"
          contract="Microsoft.WCF.Documentation.ISampleService"
        />
        <endpoint
           address="mex"
           binding="mexHttpBinding"
           contract="IMetadataExchange"
        />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
      <behavior name="metadataSupport">
        <serviceMetadata httpGetEnabled="true" httpGetUrl=""/>
      </behavior>
      </serviceBehaviors>
      <endpointBehaviors>
        <behavior name="withMessageInspector">
          <endpointMessageInspector />
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <extensions>
      <behaviorExtensions>
        <add
          name="endpointMessageInspector"
          type="Microsoft.WCF.Documentation.EndpointBehaviorMessageInspector, HostApplication, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null"
        />
      </behaviorExtensions>
    </extensions>
  </system.serviceModel>
</configuration>

Gdzie Microsoft.WCF.Documentation.EndpointBehaviorMessageInspector jest typem rozszerzenia zachowania i HostApplication jest nazwą zestawu, do którego została skompilowana ta klasa.

Kolejność oceny

System.ServiceModel.ChannelFactory<TChannel> i System.ServiceModel.ServiceHost są odpowiedzialne za tworzenie środowiska uruchomieniowego z modelu programowania i opisu. Zachowania, zgodnie z wcześniejszym opisem, przyczyniają się do tego procesu budowania w usłudze, punkcie końcowym, kontrakcie i operacji.

Zachowania ServiceHost są stosowane w następującej kolejności.

1. Usługa

2. Kontrakt

3. Punkt końcowy

4. Operacja

W ramach dowolnej kolekcji zachowań nie ma gwarantowanej kolejności.

Zachowania ChannelFactory<TChannel> są stosowane w następującej kolejności.

1. Kontrakt

2. Punkt końcowy

3. Operacja

W ramach każdej kolekcji zachowań ponownie nie ma gwarantowanej kolejności.

Programowe dodawanie zachowań

Właściwości System.ServiceModel.Description.ServiceDescription w aplikacji serwisowej nie mogą być modyfikowane po wywołaniu metody CommunicationObject.OnOpening na System.ServiceModel.ServiceHostBase. Niektóre elementy członkowskie, takie jak właściwość ServiceHostBase.Credentials i metody AddServiceEndpoint na ServiceHostBase i System.ServiceModel.ServiceHost, zgłaszają wyjątek, jeśli zostaną zmodyfikowane po tym punkcie. Inni zezwalają na ich modyfikowanie, ale wynik jest niezdefiniowany.

Podobnie na kliencie wartości System.ServiceModel.Description.ServiceEndpoint nie mogą być modyfikowane po wywołaniu metody OnOpening na System.ServiceModel.ChannelFactory. Właściwość ChannelFactory.Credentials zgłasza wyjątek, jeśli zostanie zmodyfikowana po tym punkcie, ale inne wartości opisu klienta można modyfikować bez żadnego błędu. Wynik jest jednak niezdefiniowany.

Niezależnie od tego, czy chodzi o usługę, czy klienta, zaleca się zmodyfikowanie opisu przed wywołaniem CommunicationObject.Open.

Reguły dziedziczenia dla atrybutów zachowania

Wszystkie cztery typy zachowań można wypełnić za pomocą atrybutów — zachowania usługi i zachowania kontraktu. Ponieważ atrybuty są definiowane na zarządzanych obiektach i elementach członkowskich, a zarządzane obiekty i elementy członkowskie obsługują dziedziczenie, należy zdefiniować sposób działania atrybutów zachowania w kontekście dziedziczenia.

Na wysokim poziomie reguła jest taka, że dla określonego zakresu (na przykład usługi, kontraktu lub operacji) są stosowane wszystkie atrybuty zachowania w hierarchii dziedziczenia dla tego zakresu. Jeśli istnieją dwa atrybuty zachowania tego samego typu, używany jest tylko najbardziej pochodny typ.

Zachowania serwisowe

Dla danej klasy usługi, wszystkie atrybuty zachowania usługi w tej klasie oraz jej klasach nadrzędnych są stosowane. Jeśli ten sam typ atrybutu jest stosowany w wielu miejscach w hierarchii dziedziczenia, najczęściej używany jest typ pochodny.

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
[AspNetCompatibilityRequirementsAttribute(
    AspNetCompatibilityRequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class A { /* … */ }

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
public class B : A { /* … */}

Na przykład w poprzednim przypadku usługa B kończy się na InstanceContextModeSingle, z trybem AspNetCompatibilityRequirementsModeAllowed i wartością ConcurrencyModeSingle. ConcurrencyMode jest Single, ponieważ atrybut ServiceBehaviorAttribute w usłudze B jest "bardziej rozwinięty" niż w usłudze A.

Zachowania kontraktu

W przypadku danego kontraktu stosowane są wszystkie atrybuty zachowania kontraktu w tym interfejsie i na elementach nadrzędnych tego interfejsu. Jeśli ten sam typ atrybutu jest stosowany w wielu miejscach w hierarchii dziedziczenia, najczęściej używany jest typ pochodny.

Zachowania systemu

Jeśli dana operacja nie zastępuje istniejącej operacji abstrakcyjnej ani wirtualnej, nie mają zastosowania żadne reguły dziedziczenia.

Jeśli operacja zastąpi istniejącą operację, zostaną zastosowane wszystkie atrybuty zachowania operacji dla tej operacji i elementy nadrzędne tej operacji. Jeśli ten sam typ atrybutu jest stosowany w wielu miejscach w hierarchii dziedziczenia, najczęściej używany jest typ pochodny.