Eines der mächtigsten Features der WF, der Persistenz Service (SqlWorkflowPersistenceService), erlaubt es einem, den aktuellen Status von Workflow Instanzen in der Workflow DB zu speichern. Microsoft stellt dabei alles, was benötigt wird, zur Verfügung, mindestens für den hauseigenen SQL Server.

Eine Applikation, die beispielsweise auf mehreren Servern gleichzeitig läuft, kann auf dieselbe WF Persistenz Datenbank zugreifen. Dazu wurde das relativ einfache Konzept der Workflow Ownership geschaffen. Dies ist eigentlich nichts anderes als ein einfacher Lock mit einem Timeout.

In der WF Persistenz Datenbank dienen dazu die beiden Felder ownerId und ownedUntil der Tabelle InstanceState:

Aufbau der Tabelle InstanceState

Im Feld ownerId wird die GUID des Persistenz Services der jeweiligen WF Runtime eingetragen, und in ownedUntil steht (im UTC Format!), wie lange die Instanz gesperrt ist.
Wenn diese beiden Felder nicht null sind, wird die entsprechende WF Instanz also gerade von einem Host bearbeitet.
So wird sichergestellt, dass eine Workflow Instanz immer nur von einem Host gleichzeitig ausgeführt wird.

Dies funktioniert grundsätzlich auch prima, der Persistenz Service hat allerdings einige Unschönheiten.

Bei jedem Neustart der WorkflowRuntime wird der Persistenz Service neu initialisiert. Dabei erhält er auch immer eine neu GUID, mit welcher dann die WF Instanzen in der WF DB gelockt werden.
Wenn nun zum Beispiel die Ausführung einer Workflow Instanz abgebrochen wird, bleibt der Lock bestehen.

Nun würde man erwarten, dass die Instanz nach dem Ablaufen des Lock Timeouts von einem anderen Host geladen und weiterbearbeitet werden kann. Leider ist dies nicht der Fall. Der Persistenz Service lädt beim Pollen nach freien Workflow Instanzen nur solche mit abgelaufenem Timer. Diejenigen mit abgelaufenem Lock werden nur beim Start des Services geladen. Solange also der Service nicht neu gestartet wird, kann die Workflow Instanz nicht mehr geladen werden.

Es wäre doch schön, wenn man dem Persistenz Service eine ID zuweisen könnte, damit wäre nämlich das Problem gelöst. In einer Umgebung mit mehreren Hosts, könnte jeder Service seine eigene ID erhalten.
Leider ist dies nicht vorgesehen.

Dem kann man aber abhelfen. Nach einem kurzen Blick auf die Implementation des SqlWorkflowPersistenceService im Reflector kann man dank der in C# 3.0 eingeführten Extension Methods den Service wie folgt erweitern:

static class WorkflowExtensions
{
    public static void SetServiceInstanceId(this WorkflowPersistenceService workflowPersistenceService, Guid serviceId)
    {
        Type persistenceServiceType = workflowPersistenceService.GetType();
        FieldInfo instanceIdField = persistenceServiceType.GetField("_serviceInstanceId",
                                                                    BindingFlags.NonPublic |
                                                                    BindingFlags.Instance);
        instanceIdField.SetValue(workflowPersistenceService, serviceId);
    }
}

Die Service ID wird einfach via Reflection gesetzt. Verwendung auf eigene Gefahr, bei mir hat’s jedenfalls hervorragend funktioniert.

Ich schreibe mal wieder nur ab: Microsoft veröffentlich endlich auch ein eigenes Chart Control. Das ganze wird im Blog von Scott Guthrie als ASP.NET Charting Control angepriesen. Gerüchten zufolge werkelt unter der Haube Technologie von Dundas, dies ist schon mal ein Garant für gut designte Controls und durchdachte APIs. Der Komponenten Pionier lieferte bereits die Charting Technologie für die Reporting Services von SQL Server 2008.
Bislang musste man ja entweder auf das Angebot eines Drittherstellers zurückgreifen, oder eben selber in die Tasten greifen, wenn man Charts oder ganz allgemein dynamische Grafiken serverseitig erzeugen wollte. Mit GDI+ war das grundsätzlich auch recht einfach machbar, aber eben von Microsoft nicht unterstützt.
Die offizielle MSDN Dokumentation des System.Drawing Namespaces ist zu diesem Punkt nicht allzu ausführlich:

Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions.

Obwohl es nahezu nie Probleme gab, alles immer auch performant funktionierte, hatte ich immer ein ungutes Gefühl während der Entwicklung solcher .NET Komponenten.
Wenn mal was schiefgehen sollte, hat man keine Hilfe zu erwarten. Die sehr komplexe und aufwändige Entwicklung von GDI COM Komponenten kommt kaum als Alternative in Frage.

Während sich nun die ganze .NET Entwickler Welt über das längst fällige Control für die Webentwicklung freut, nehme ich zufrieden zur Kenntnis, dass das ganze auch für die in letzter Zeit von Microsoft stark vernachlässigten WinForms funktioniert. Schade ist nur, dass die Controls .NET 3.5 SP1 voraussetzen.

Heute infolge chronischem Zeitmangel nur ein kurzes Update.
Nächsten Mittwoch werde ich den (mir bislang unbekannten) Technical Day des Shape Events besuchen.
Obwohl der Themen Schwerpunkt mehrheitlich auf den an der PDC gehypten Themen der PDC und Silverlight liegt, erhoffe ich mir eine knappe Einführung in ein paar .NET 3.5 SP1 Technologien. Interessieren tun mich das Entity Framework, die Data Services und ASP.NET Dynamic Data.
Ich werde vom (oder eher nach dem) Event berichten, stay tuned.

Dies ist der erste Teil eines mehrteiligen Artikels zu den Persistenz Mechanismen in der Windows Workflow Foundation.
Zu Beginn werden mal die Workflow Persistenz Grundlagen beleuchtet. Später geht’s dann um den Einsatz des Persistenz Services in Workflow Services und in einer Server Farm.

Die Windows Workflow Foundation stellt für die Persistenz von Workflow Instanzen den Core Dienst SqlWorkflowPersistenceService zur Verfügung. Dieser benötigt einen SQL Server, andere Datenbanken werden nicht unterstützt. Es ist allerdings möglich, einen eigenen Persistenz Dienst zu schreiben, dazu aber später mehr.

Wenn die WorkflowRuntime so konfiguriert wird, dass sie den SqlWorkflowPersistenceService verwenden soll, wird der aktuelle Status der Workflow Instanzen, welche sich gerade im Wartezustand befinden, in der Datenbank persistiert.

Wann genau wird nun eine Workflow Instanz persisitiert?

• Wenn sich eine Workflow Instanz sich im “Idle” Zustand befindet. Dies ist dann der Fall, wenn sie auf einen externen Event warten muss, oder eine DelayActivity ausgeführt wird.
• Wenn eine Workflow Instanz beendet oder terminiert wird.
• Wenn innerhalb des Ablaufs eine TransactionScopeActivity oder eine CompensatableTransactionScopeActivity beendet wird.
• Wenn eine benutzerdefinierte Aktivität beendet wird, die mit dem PersistOnClose Attribut dekoriert wird.
• oder natürlich wenn die Unload() Methode (oder auch TryUnload) der Workflow Instanz aufgerufen wird.

Die Persistierung kann nebst dem Umstand, dass die Workflow Instanzen einen Neustart des Workflow Hosts überleben, die Skalierbarkeit einer einzelnen WorkflowRuntime erhöhen, da nicht benötigte Workflow Instanzen aus dem Speicher entfernt werden.

Der SqlWorkflowPersistenceService kann via Applikations Konfigurationsfile oder via Code eingesetzt werden.

Im Konfigurationsfile

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

    <configSections>
        <section name="WorkflowRuntimeConfiguration"
                 type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </configSections>

    <WorkflowRuntimeConfiguration>
        <CommonParameters>
            <add name="ConnectionString"
                 value="Data Source=localhost;Initial Catalog=WFStore;User=wf;Password=wf;" />
        </CommonParameters>

        <Services>
            <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
                 UnloadOnIdle="true" />
        </Services>

    </WorkflowRuntimeConfiguration>

</configuration>

Im Code

// Adjust the connection string according to your environment.
var connectionString = "Data Source=localhost;Initial Catalog=WFStore;User=wf;Password=wf;";

// When true, the service will persist idle workflows. The service default value is false.
bool unloadOnIdle = true;

// Specifies for how long the service will lock the instance record in the database.
// The service default value is TimeSpan.MaxValue.
TimeSpan instanceOwnershipDuration = new TimeSpan(0, 2, 0);

// The service will check for expired timers in the database this often.
// The service default value is 2 minutes
TimeSpan loadingInterval = new TimeSpan(0, 0, 5);           

var persistenceService = new SqlWorkflowPersistenceService(connectionString,
                                                           unloadOnIdle,
                                                           instanceOwnershipDuration,
                                                           loadingInterval);
workflowRuntime.AddService(persistenceService);

Das angehängte Beispiel Projekt für Visual Studio 2008 zeigt diese beiden Varianten. Sie benötigen zusätzlich zum Beispielprojekt eine SQL Server Datenbank. Eine SQL Server Express Installation auf dem Entwicklungsrechner reicht dabei völlig aus.

Die SQL Skripte für das Anlegen des DB Schemas und der benötigten Stored Procedures findet man unter

C:\Windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\EN

Beispiel Projekt: WorkflowPersistence.zip

In der heutigen Ausgabe der Sonntagszeitung wurde der Amazon Kindle im Multimediateil anlässlich der nächste Woche in Frankfurt stattfindenden Buchmesse besprochen.
Auch das Schweizer Fernsehen hat letzte Woche in der Sendung Kulturplatz einen Beitrag über das Gerät gebracht.
Noch ist das digitale Lesegerät hierzulande nicht verfügbar, doch bereits jetzt polarisiert der E-Book Reader.

Wenn ich die Kommentare im besagten Artikel durchlese, kommt mir die Situation etwa so vor, wie ca. 1998, als der Boom um Musik im MP3 Format so richtig losging, und die Plattenfirmen das ganze zuerst mal ignoriert haben. Als dann realisiert wurde, was das ganze auf sich hat, hat man die Technologie nur als Bedrohung wahrgenommen, und es wurde zuerst mal in alle Richtungen geklagt. Natürlich zieht der Vergleich nicht so ganz, schliesslich vertreibt Amazon keine illegalen Inhalte. Dass die Verlage und sogar auch Autoren die Technologie als Bedrohung und nicht als Chance für einen weiteren Vertriebskanal wahrnehmen, läuft jedoch genau nach dem selben Muster ab. Vielleicht muss ja zuerst wieder Apple ein solches Gerät auf den Markt bringen.

Als technikinteressierter Mensch und Vielleser verfolge ich die Entwicklung dieser Geräte seit vielen Monaten. Ausserdem bin ich seit etwa 6 Monaten stolzer Besitzer eines Sony Readers (PRS-505), den mir ein Freund aus den Staaten mitgebracht hat. Im Gegensatz zum Kindle kann man beim Sony Reader und auch beim Konkurrenzprodukt, dem Iliad von iRex, einer Phillips Tochter, auch ganz einfach eigene (PDF) Dokumente auf die Geräte kopieren. Beim Kindle geht dies zwar grundsätzlich auch, jedoch muss das entsprechendes Dokument dazu immer kostenpflichtig via Amazons Whispernet aufs Gerät geladen werden.

Obwohl der Reader für mich genau das richtige Gerät ist, werden es aus meiner Sicht die Geräte dieser Generation leider noch nicht schaffen, einen wirklichen Markt zu schaffen.

• Sie sind zu teuer. Der Kindle kostet in den Staaten 360 US$, hier wird er wahrscheinlich noch teurer. Der alte Sony PRS-505 war in den USA etwas billiger, der neue PRS-700BC kostet 400US$. Der Iliad kostet noch mehr, nämlich ca. 500 €.
• Sie sind zu langsam. Das Blättern einer Seite dauert einfach noch zu lange. Dies ist auch beim Sony Reader so.
• Die Displays sind monochrom. Das stört beim Lesen eines Krimis oder Fachbuchs nicht weiter, beim Blättern in einer digitalen Zeitschrift jedoch schon.

Die Vorteile sollen aber auch erwähnt werden:

• Die E-Paper Displays sind mit nichts zu vergleichen, was man bis jetzt am Bildschirm gelesen hat. Das Lesegefühl kommt Papier schon recht nahe. Auch stundenlanges Lesen ermüdet die Augen nicht mehr, als es auch beim Papier der Fall wäre.
• Durch die neue Technologie wird extrem wenig Strom für die Darstellung resp. das Blättern der Seiten benötigt. Eine Akkuladung hält so sehr lange.
• Durch die geringen Preise von grossen Speichermedien (SD Card, Memory Stick) kann man wirklich sehr viele Bücher für wenig Geld mit sich herumtragen.
• Jeder Reader hat ein eigenes Dokumentenformat, kann aber auch PDFs anzeigen. Von vielen amerikanischen IT Fachverlagen kann man die Bücher mittlerweile auch als PDF kaufen. Beispiele und Vorreiter sind da APress und Manning.

Während der Rest der (Finanz) Welt langsam zu Grunde geht, gibt Microsoft weiter Vollgas.
Normalerweise beschäftige ich mich erst im Detail mit Entwicklungstools und Technologien, wenn sie verfügbar sind. Betas, CTPs, Release Candidates und wie diese Versionen alle heissen, installiere ich schon lange nicht mehr. Die Zeit reicht einfach nicht mehr, in Projekten muss in der Regel das getan werden, was der Amerikaner lapidar “get the job done” nennt.
Ausserdem muss der interessierte .NET Entwickler erst mal die neuen Technologien des .NET 3.5 SP1 verdauen. Dies alles schliesst aber natürlich nicht aus, dass man sich über neue Technologien informiert.

So hat die am 1. Oktober von Microsoft veröffentlichte Meldung “Overview of WF 4.0, WCF 4.0, and Windows Server “Dublin” mein Interesse geweckt:

…Microsoft is enhancing both the .NET Framework and Windows Server. The company is adding significant functionality to the new version of Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) as part of the .NET Framework 4.0 release, including new messaging and REST capabilities in WCF, new workflow models, seamless integration between WF and WCF to support stateful and conversational services, and a new visual designer. The company is also introducing a set of enhanced Windows Server capabilities codenamed “Dublin” that will offer greater scalability and easier manageability, while extending Internet Information Services (IIS) to provide a standard host for applications that use workflow or communications.

Im Dokument, welches als Download zur Verfügung steht, fällt mir vor allem die Erwähnung der Dublin genannten Windows Server Technologie auf, welche den IIS erweitern wird. Ein Standard Host für WCF und WF Applikationen wäre eine feine Sache.
Natürlich kann man bereits jetzt mit überschaubarem Aufwand in IIS 6 + 7 die Workflow Services als zustandsorientierte, “durable” Dienste anbieten. Funktionen zur Versionierung, Überwachung und Monitoring und zum Deployment von Workflows oder WCF Diensten müssen jedoch noch selber implementiert werden.
Mit Dublin könnte sich der IIS langsam zum Ernst zu nehmenden Applikationsserver mausern. Dies werde ich mal im Auge behalten, mein persönliches Technologie Backlog wird also noch länger…

An der PDC2008, die Ende dieses Monats in Los Angeles stattfindet, wird eine CTP Version der drei Technologien abgegeben. Vielleicht mache ich ja da wieder einmal eine Ausnahme und installiere sie.

Ich bin ebenfalls gespannt, ob die für WF 4.0 angekündigten Erweiterungen die Workfow Foundation von einem reinen Toolset für Entwickler zu einer Technologie wandeln wird, die sich vermehrt in Produkten für Endanwender wieder findet.