Udostępnij za pośrednictwem


Instrukcje: Partycjonowanie danych usługi

W tym temacie opisano podstawowe kroki wymagane do partycjonowania komunikatów w wielu wystąpieniach tej samej usługi docelowej. Partycjonowanie danych usługi jest zwykle używane w przypadku konieczności skalowania usługi w celu zapewnienia lepszej jakości usług lub obsługi żądań od różnych klientów w określony sposób. Na przykład komunikaty od klientów o wysokiej wartości lub "Gold" mogą być przetwarzane z wyższym priorytetem niż komunikaty od klienta standardowego.

W tym przykładzie komunikaty są kierowane do jednego z dwóch wystąpień regularnej usługiCalc. Oba wystąpienia usługi są identyczne; jednak usługa reprezentowana przez punkt końcowy calculator1 przetwarza komunikaty odebrane od klientów o wysokiej wartości, kalkulator 2 punkt końcowy przetwarza komunikaty od innych klientów

Komunikat wysłany z klienta nie zawiera żadnych unikatowych danych, które mogą służyć do identyfikowania wystąpienia usługi, do którego ma być kierowany komunikat. Aby umożliwić każdemu klientowi kierowanie danych do określonej usługi docelowej, zaimplementujemy dwa punkty końcowe usługi, które będą używane do odbierania komunikatów.

Uwaga

W tym przykładzie użyto określonych punktów końcowych do partycjonowania danych, ale można to zrobić również przy użyciu informacji zawartych w samym komunikacie, takich jak dane nagłówka lub treści.

Implementowanie partycjonowania danych usługi

  1. Utwórz podstawową konfigurację usługi routingu, określając punkty końcowe usługi uwidocznione przez usługę. W poniższym przykładzie zdefiniowano dwa punkty końcowe, które będą używane do odbierania komunikatów. Definiuje również punkty końcowe klienta, które są używane do wysyłania komunikatów do zwykłych wystąpień usługiCalc.

    <services>  
      <service behaviorConfiguration="routingConfiguration"  
               name="System.ServiceModel.Routing.RoutingService">  
        <host>  
          <baseAddresses>  
            <add baseAddress="http://localhost/routingservice/router" />  
          </baseAddresses>  
        </host>  
        <!--Set up the inbound endpoints for the Routing Service-->  
        <!--create the endpoints for the calculator service-->  
        <endpoint address="calculator1"  
                  binding="wsHttpBinding"  
                  name="calculator1Endpoint"  
                  contract="System.ServiceModel.Routing.IRequestReplyRouter" />  
        <endpoint address="calculator2"  
                  binding="wsHttpBinding"  
                  name="calculator2Endpoint"  
                  contract="System.ServiceModel.Routing.IRequestReplyRouter" />  
       </service>  
    </services>  
    <client>  
    <!--set up the destination endpoints-->  
        <endpoint name="CalcEndpoint1"  
                  address="net.tcp://localhost:9090/servicemodelsamples/service/"  
                  binding="netTcpBinding"  
                  contract="*" />  
    
        <endpoint name="CalcEndpoint2"  
                  address="net.tcp://localhost:8080/servicemodelsamples/service/"  
                  binding="netTcpBinding"  
                  contract="*" />  
     </client>  
    
  2. Zdefiniuj filtry używane do kierowania komunikatów do docelowych punktów końcowych. W tym przykładzie filtr EndpointName służy do określania, który punkt końcowy usługi odebrał komunikat. W poniższym przykładzie zdefiniowano niezbędną sekcję routingu i filtry.

    <filters>  
      <!--define the different message filters-->  
      <!--define endpoint name filters looking for messages that show up on the virtual endpoints-->  
      <filter name="HighPriority" filterType="EndpointName"  
              filterData="calculator1Endpoint"/>  
      <filter name="NormalPriority" filterType="EndpointName"  
              filterData="calculator2Endpoint"/>  
    </filters>  
    
  3. Zdefiniuj tabelę filtrów, która kojarzy każdy filtr z punktem końcowym klienta. W tym przykładzie komunikat zostanie przekierowany na podstawie określonego punktu końcowego, nad który został odebrany. Ponieważ komunikat może być zgodny tylko z jednym z dwóch możliwych filtrów, nie ma potrzeby używania priorytetu filtru do kontrolowania kolejności oceniania filtrów.

    Poniżej zdefiniowano tabelę filtrów i dodano zdefiniowane wcześniej filtry.

    <filterTables>  
       <filterTable name="filterTable1">  
         <!--add the filters to the message filter table-->  
         <add filterName="HighPriority" endpointName="CalcEndpoint1"/>  
         <add filterName="NormalPriority" endpointName="CalcEndpoint2"/>  
       </filterTable>  
    </filterTables>  
    
  4. Aby ocenić komunikaty przychodzące względem filtrów zawartych w tabeli, należy skojarzyć tabelę filtrów z punktami końcowymi usługi przy użyciu zachowania routingu. W poniższym przykładzie pokazano skojarzenie elementu "filterTable1" z punktami końcowymi usługi:

    <behaviors>  
      <!--default routing service behavior definition-->  
      <serviceBehaviors>  
        <behavior name="routingConfiguration">  
          <routing filterTableName="filterTable1" />  
        </behavior>  
      </serviceBehaviors>  
    </behaviors>  
    

Przykład

Poniżej znajduje się pełna lista pliku konfiguracji.

<?xml version="1.0" encoding="utf-8" ?>  
<!-- Copyright (c) Microsoft Corporation. All rights reserved -->  
<configuration>  
  <system.serviceModel>  
    <services>  
      <service behaviorConfiguration="routingConfiguration"  
               name="System.ServiceModel.Routing.RoutingService">  
        <host>  
          <baseAddresses>  
            <add baseAddress="http://localhost/routingservice/router" />  
          </baseAddresses>  
        </host>  
        <!--Set up the inbound endpoints for the Routing Service-->  
        <!--create the endpoints for the calculator service-->  
        <endpoint address="calculator1"  
                  binding="wsHttpBinding"  
                  name="calculator1Endpoint"  
                  contract="System.ServiceModel.Routing.IRequestReplyRouter" />  
        <endpoint address="calculator2"  
                  binding="wsHttpBinding"  
                  name="calculator2Endpoint"  
                  contract="System.ServiceModel.Routing.IRequestReplyRouter" />  
  
      </service>  
    </services>  
    <behaviors>  
      <!--default routing service behavior definition-->  
      <serviceBehaviors>  
        <behavior name="routingConfiguration">  
          <routing filterTableName="filterTable1" />  
        </behavior>  
      </serviceBehaviors>  
    </behaviors>  
  
    <client>  
<!--set up the destination endpoints-->  
      <endpoint name="CalcEndpoint1"  
                address="net.tcp://localhost:9090/servicemodelsamples/service/"  
                binding="netTcpBinding"  
                contract="*" />  
  
      <endpoint name="CalcEndpoint2"  
                address="net.tcp://localhost:8080/servicemodelsamples/service/"  
                binding="netTcpBinding"  
                contract="*" />  
    </client>  
    <routing>  
      <!-- use the namespace table element to define a prefix for our custom namespace-->  
  
      <filters>  
        <!--define the different message filters-->  
        <!--define endpoint name filters looking for messages that show up on the virtual endpoints-->  
        <filter name="HighPriority" filterType="EndpointName"  
                filterData="calculator1Endpoint"/>  
        <filter name="NormalPriority" filterType="EndpointName"  
                filterData="calculator2Endpoint"/>  
      </filters>  
  
      <filterTables>  
        <filterTable name="filterTable1">  
          <!--add the filters to the message filter table-->  
          <add filterName="HighPriority" endpointName="CalcEndpoint1"/>  
          <add filterName="NormalPriority" endpointName="CalcEndpoint2"/>  
        </filterTable>  
      </filterTables>  
  
    </routing>  
  </system.serviceModel>  
</configuration>  

Zobacz też