Durable Service

Eintrag zuletzt aktualisiert am: 09.01.2009

Persistente Dienste (Durable Services) sind WCF-Dienste, die zwischen zwei Methodenaufrufen den Zustand der Dienstklasse in einer Datenbank persistieren können. Dies ist besonders geeignet für lang andauernde Kommunikationsbeziehungen, also zwei Computern, die über einen längeren Zeitraum miteinander in Kontakt stehen. Während dieser Zeit soll auf dem Server ein Zustand verwaltet werden. Der Client kann zwischen-zeitlich sogar beendet werden und dennoch später die Kommunikation wieder aufgenommen werden. Dazu persistiert der Server den Zustand in einer Datenbank. Die notwendigen Token zur Identifizierung des Clients werden automatisch ausgetauscht.

Microsoft hat diese Idee aus Windows Workflow Foundation (WF) übernommen und bietet sie seit .NET 3.5 auch für WCF an. Allerdings ist das Datenbankschema ein anderes (viel einfacher). Die persistenten Dienste benötigen nur eine Tabelle (InstanceData) und fünf gespeicherte Prozeduren.

Anders als bei dem Persistenzdienst in WF hat man bei dem WCF-Persistenzdienst die Wahl zwischen binärer Serialisierung und XML-Serialisierung (serializeAsText="true|false"). WF kann nur binäre Serialisierung. Wie bei WF liefert Microsoft nur einen Provider für Microsoft SQL Server, man kann sich aber eigene Provider schreiben.

Folgende Punkte sind zu beachten:

• hilfe der im .NET Framework 3.5 Redistributable mitgelieferten SQL-Skripte (SqlPersistencePro-viderSchema.sql und SqlPersistenceProviderLogic.sql) muss man die Datenbankstruktur und die zugehörigen gespeicherten Prozeduren anlegen. Zu beachten ist, dass die Skripte die Datenbank selbst nicht anlegen. Man muss erst eine leere Datenbank mit beliebigem Namen erzeugen und die Skripte legen dann dort die benötigten Elemente an.
• Eine Dienstklasse, die persistent werden soll, muss mit [DurableService] (Namensraum: System.ServiceModel.Description, Assembly: System.WorkflowServices.dll) annotiert sein. Die Schnittstellendefinition bleibt unverändert.
• Die Methode, nach deren Ende ein Speichervorgang erfolgen soll, muss mit [DurableOperation] annotiert sein. Durch die Zusätze CanCreateInstance und CompletesInstance kann man die Lebens-dauer einer Sitzung steuern.
• In der Konfigurationsdatei muss man die Verbindung zur Datenbank festlegen:

<connectionStrings>
<add name="CS_WCFServerData" connectionString="Data Source=ServerName;Initial Catalog=WCFServerData;Integrated Security=SSPI"/>
</connectionStrings>

• In der Konfigurationsdatei muss man den WCF-Persistenzdienst als Dienstverhalten aktivieren.

<!-- Persistente Dienste -->
<behavior name="Persistenz">
<persistenceProvider type="System.ServiceModel.Persistence.SqlPersistenceProviderFactory, System.WorkflowServices, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
connectionStringName="CS_WCFServerData"
persistenceOperationTimeout = "00:00:10"
lockTimeout="00:01:00"
serializeAsText="false"/>
<serviceMetadata/>
<serviceDebug includeExceptionDetailInFaults="True" />
</behavior>

• Der WCF-Dienst muss mit einer speziellen Kontextbindung (z. B. basicHttpContextBinding, wsHttpContextBinding) konfiguriert werden. Eine Kontextbindung erlaubt den Austausch einer ID zwischen Client und Server, die der Wiedererkennung der Sitzung dient (vgl. Sitzungs-ID in ASP.NET). Außerdem muss man das oben definierte Dienstverhalten zuordnen.

<!-- ZUSTANDSDIENST -->
<service behaviorConfiguration="Persistenz" name="de.WWWings.Dienste.Zustandsdienst">
<endpoint address ="http://localhost:89/WWWings/Zustandsdienst" binding="wsHttpContextBinding" contract="de.WWWings.Dienste.Izustandsdienst"/>
<endpoint address="http://localhost:89/WWWings/Zustandsdienst/mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>

Im Client ist zunächst nichts weiter zu beachten. Einen Proxy kann man wie gewohnt über Add Service Reference erstellen und nutzen wie jeden anderen WCF-Dienst. Der Client eines persistenten Dienstes hat aber die zusätzliche Möglichkeit, das vom Server gesendete Identifizierungs-Token lokal zu per-sistieren und zu einem späteren Zeitpunkt in einer neuen Instanz des Clients wieder zu verwenden. Auf diese Weise kann die Kommunikation fortgesetzt werden, selbst wenn der Client zwischenzeitlich beendet war.