Freigeben über

Permanenter Duplex

  • Artikel

Dieses Thema gilt für Windows Workflow Foundation 4.

In diesem Beispiel wird veranschaulicht, wie permanenter Duplexnachrichtenaustausch mithilfe der Messagingaktivitäten in Windows Workflow Foundation (WF) eingerichtet und konfiguriert wird. Ein permanenter Duplexnachrichtenaustausch ist ein bidirektionaler Nachrichtenaustausch, der im Verlauf eines langen Zeitraums stattfindet. Die Lebensdauer des Nachrichtenaustauschs ist möglicherweise länger als die Lebensdauer des Kommunikationskanals und die Lebensdauer der Dienstinstanzen im Arbeitsspeicher.

Beispieldetails

In diesem Beispiel werden zwei mit Windows Workflow Foundation implementierte Windows Communication Foundation (WCF)-Dienste für einen permanenten Duplexnachrichtenaustausch konfiguriert. Der permanente Duplexnachrichtenaustausch wird aus zwei unidirektionalen Nachrichten erstellt, die über MSMQ gesendet und mit dem .NET-Kontextaustausch korreliert werden. Die Nachrichten werden mit den Messagingaktivitäten Send und Receive gesendet. Der .NET-Kontextaustausch wird verwendet, um die Rückrufadresse in den gesendeten Nachrichten anzugeben. Beide Dienste werden mit WAS (Windows Process Activation Services) gehostet und sind konfiguriert, um Persistenz der Dienstinstanzen zu ermöglichen.

Der erste Dienst (Service1.xamlx) sendet eine Anforderung an den zweiten Dienst (Service2.xamlx), einige Arbeiten zu erledigen. Sobald die Arbeit abgeschlossen ist, sendet Service2.xamlx eine Benachrichtigung an Service1.xamlx zurück, um anzugeben, dass die Arbeit abgeschlossen ist. Eine Konsolenanwendung für Workflows richtet die Warteschlangen ein, die die Dienste überwachen, und sendet die ursprüngliche Startnachricht, um Service1.xamlx zu aktivieren. Sobald Service1.xamlx die Benachrichtigung von Service2.xamlx empfangen hat, dass die angeforderte Arbeit abgeschlossen ist, speichert Service1.xamlx das Ergebnis in einer XML-Datei. Während des Wartens auf die Rückrufmeldung behält Service1.xamlx den Instanzzustand mit dem standardmäßigen WorkflowIdleBehavior bei. Service2.xamlx behält den Instanzzustand als Teil des Abschlusses der von Service1.xamlx angeforderten Arbeit bei.

Um die Dienste zu konfigurieren, sodass der .NET-Kontextaustausch über MSMQ verwendet wird, werden beide Dienste zur Verwendung einer benutzerdefinierten Bindung konfiguriert, die aus ContextBindingElement und MsmqTransportBindingElement besteht. Eine Rückrufadresse wird mit ContextBindingElement angegeben und ist in einem Rückrufkontextheader von allen Nachrichten enthalten, die mit einer benutzerdefinierten Bindung gesendet werden. Im folgenden Codebeispiel wird die benutzerdefinierte Bindung definiert.

<configuration>
     <system.serviceModel>
          …
          <bindings>
               <customBinding>
                    <binding name="netMsmqContextBinding">
                         <context clientCallbackAddress="net.msmq://localhost/private/DurableDuplex/Service1.xamlx"/>
                         <msmqTransport exactlyOnce="False">
                              <msmqTransportSecurity msmqAuthenticationMode="None" msmqProtectionLevel="None"/>
                         </msmqTransport>
                    </binding>
               </customBinding>
          </bindings>
          …
     </system.serviceModel>
</configuration>
Ee662960.note(de-de,VS.100).gifHinweis:
Die von diesem Beispiel verwendete Bindung ist nicht sicher. Wenn Sie die Anwendung bereitstellen, sollten Sie die Bindung auf Grundlage der Sicherheitsanforderungen der Anwendung konfigurieren.

Ee662960.note(de-de,VS.100).gifHinweis:
Die in diesem Beispiel verwendeten Warteschlangen sind nicht transaktionsgebunden. Ein Beispiel, das zeigt, wie WCF-Nachrichtenaustausch mit Transaktionswarteschlangen eingerichtet wird, finden Sie im Beispiel MSMQ Activation.

Die von Service1.xamlx an Service2.xamlx gesendete Nachricht wird mit einem Clientendpunkt gesendet, der mit der Adresse von Service2.xamlx und der benutzerdefinierten Bindung, die zuvor definiert wurden, konfiguriert ist. Der Rückruf von Service2.xamlx an Service1.xamlx wird mit einem Clientendpunkt ohne explizit konfigurierte Adresse gesendet, da die Adresse dem Rückrufkontext entnommen wird, der von Service1.xamlx gesendet wurde. Im folgenden Codebeispiel werden die Clientendpunkte definiert.

<?xml version="1.0"?>
<configuration>
     <system.serviceModel>
          …
          <client>
               <endpoint address="net.msmq://localhost/private/DurableDuplex/Service2.xamlx" binding="customBinding" bindingConfiguration="netMsmqContextBinding" contract="IDoWork"/>
               <endpoint binding="customBinding" bindingConfiguration="netMsmqContextBinding" contract="INotify"/>
          </client>
          …
     </system.serviceModel>
</configuration>

Das folgende Codebeispiel macht Endpunkte verfügbar, die diese benutzerdefinierte Bindung verwenden, indem die Standardprotokollzuordnung für net.msmq-Basisadressen auf die Verwendung dieser benutzerdefinierten Bindung geändert wird.

<configuration>
     <system.serviceModel>
          <protocolMapping>
               <add scheme="net.msmq" binding="customBinding" bindingConfiguration="netMsmqContextBinding"/>
          </protocolMapping>
          …
     </system.serviceModel>
</configuration>

Im folgenden Codebeispiel wird Persistenz für beide Dienste ermöglicht, indem das SqlWorkflowInstanceStoreBehavior-Verhalten den Diensten hinzufügt und die Verbindungszeichenfolge für die Persistenzdatenbank angegeben wird.

<?xml version="1.0"?>
<configuration>
    <system.serviceModel>
          …
          <behaviors>
               <serviceBehaviors>
                    <behavior>
                         <serviceDebug includeExceptionDetailInFaults="True"/>
                         <serviceMetadata httpGetEnabled="True"/>
                         <sqlWorkflowInstanceStore connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=DefaultSampleStore;Integrated Security=True"/>
                    </behavior>
               </serviceBehaviors>
          </behaviors>
     </system.serviceModel>
</configuration>

Systemanforderungen

Folgende Komponenten sind für dieses Beispiel erforderlich.

  1. Internetinformationsdienste.

  2. Internetinformationsdienste -> IIS 6.0-Verwaltungskompatibilität -> IIS-Metabasis und IIS 6.0-Konfigurationskompatibilität.

  3. WWW-Dienste -> Anwendungsentwicklungsfunktionen -> ASP.NET.

  4. Microsoft-Server für Meldungswarteschlangen (MSMQ).

So verwenden Sie dieses Beispiel

  1. Richten Sie die Persistenzdatenbank und das Ergebnisverzeichnis ein.

    1. Öffnen Sie eine Visual Studio 2010-Eingabeaufforderung.

    2. Navigieren Sie zum Ordner für dieses Beispiel, und führen "Setup.cmd" aus.

  2. Richten Sie die virtuelle Anwendung ein.

    1. Registrieren Sie an einer Visual Studio 2010-Eingabeaufforderung ASP.NET, indem Sie den folgenden Befehl ausführen.

      aspnet_regiis -i

    2. Führen Sie Visual Studio 2010 mit Administratorberechtigungen aus, indem Sie mit der rechten Maustaste auf Visual Studio 2010 klicken und Als Administrator ausführen auswählen.

    3. Öffnen Sie mit Visual Studio 2010 die Datei "DurableDuplex.sln".

  3. Richten Sie die Dienstwarteschlangen ein.

    1. Um den DurableDuplex-Client auszuführen, drücken Sie F5.

    2. Öffnen Sie die Konsole Computerverwaltung, indem Sie Compmgmt.msc an einer Eingabeaufforderung ausführen.

    3. Erweitern Sie Dienste und Anwendungen, Message Queuing. Private Warteschlangen.

    4. Klicken Sie mit der rechten Maustaste auf die Warteschlangen durableduplex/service1.xamlx und durableduplex/service2.xamlx, und wählen Sie Eigenschaften aus.

    5. Wählen Sie die Registerkarte Sicherheit aus, und gewähren Sie allen die Berechtigungen Nachricht empfangen, Nachricht einsehen und Nachricht senden für beide Warteschlangen.

    6. Öffnen Sie den IIS-Manager (Internet Information Services, Internetinformationsdienste).

    7. Wechseln Sie zu Server, Sites, Standardwebsite, Privat, Permanenter Duplex, und wählen Sie Erweiterte Optionen aus.

    8. Ändern Sie Aktivierte Protokolle in http,net.msmq.

  4. Führen Sie das Beispiel aus.

    1. Wechseln Sie zu https://localhost/private/durableduplex/service1.xamlx und https://localhost/private/durableduplex/service2.xamlx, um sicherzustellen, dass beide Dienste ausgeführt werden.

    2. Drücken Sie F5, um DurableDuplexClient auszuführen.

      Wenn der permanente Duplexnachrichtenaustausch abgeschlossen ist, wird eine result.xml-Datei im Ordner C:\Inbox gespeichert und enthält das Ergebnis des Nachrichtenaustauschs.

So führen Sie eine (optionale) Bereinigung durch

  1. Führen Sie die Datei "Cleanup.cmd" aus.

    1. Öffnen Sie eine Visual Studio 2010-Eingabeaufforderung.

    2. Navigieren Sie zum Ordner für dieses Beispiel, und führen "Cleanup.cmd" aus.

  2. Entfernen Sie die virtuelle Anwendung für die Dienste.

    1. Öffnen Sie den IIS-Manager, indem Sie Inetmgr.exe an einer Eingabeaufforderung ausführen.

    2. Wechseln Sie zur Standardwebsite, und entfernen Sie das virtuelle Verzeichnis Privat.

  3. Entfernen Sie die Warteschlangeneinrichtung für dieses Beispiel.

    1. Öffnen Sie die Konsole Computerverwaltung, indem Sie Compmgmt.msc an einer Eingabeaufforderung ausführen.

    2. Erweitern Sie Dienste und Anwendungen, Message Queuing, Private Warteschlangen.

    3. Löschen Sie die Warteschlangen durableduplex/service1.xamlx und durableduplex/service2.xamlx.

  4. Entfernen Sie das Verzeichnis C:\Inbox.

Ee662960.Important(de-de,VS.100).gif Hinweis:
Die Beispiele sind möglicherweise bereits auf dem Computer installiert. Überprüfen Sie das folgende (standardmäßige) Verzeichnis, bevor Sie fortfahren.

<Installationslaufwerk>:\WF_WCF_Samples

Wenn dieses Verzeichnis nicht vorhanden ist, rufen Sie Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) Samples for .NET Framework 4 auf, um alle Windows Communication Foundation (WCF)- und WF-Beispiele herunterzuladen. Dieses Beispiel befindet sich im folgenden Verzeichnis.

<Installationslaufwerk>:\WF_WCF_Samples\WF\Basic\Services\DurableDuplex