image

http://www.flickr.com/photos/toofarnorth/8670157331/

Aus der RFC 2616:

“It is a generic, stateless, protocol”

Das heißt, das Fundament auf dem wir aufsetzen ist Sitzungslos. Wenn das Applikations-Framework, egal ob mit Web Forms oder MVC, oder Python, oder PHP, oder Rails…, das respektiert, wird es den Anforderungen des Web gerecht:

  • Skaliert besser – Ich brauche mir im NLB-Szenario (Network Load Balancing) keine Gedanken über Shared Memory machen oder mit dem ASP.NET State-Server einen SPOF (Single Point of Failure) einführen.
    Skaliert kostengünstiger – Mit MS SQL-Server kann ich State zwar auch Hochverfügbar ablegen. Dazu sind dann aber SAN (Storage Area Network), Glasfaser, Switches, Kable, Blech, Strom, Betrieb-System & SQL-Server-Lizenzen zusätzliche Kostenfaktoren.
    Ist leichter zu testen – Code der auf State reagiert kann nur getestet werden wenn der State reproduzierbar (im Test) erstellt wird. Tests werden komplizierter. Tests dauern länger – letzten Endes auch ein Kostenfaktor.
    Ist weniger komplex – Code wird verständlicher und transparenter da State sich wie globale Variablen verhält (http://c2.com/cgi/wiki?GlobalVariablesAreBad).

Um mal als Beispiel ein Bild zu malen: Wenn ich eine Rakete bauen will um zum Mond zu Fliegen. Bin ich dann schneller auf dem Mond, wenn ich mich mit Thema  Schwerkraft auseinandersetze?

Was ist eigentlich State? Oder besser was ist nicht State?

Als State werden meist Daten bezeichnet, die temporär sind – also eine sehr befristete Lebensdauer. Häufig ist das aber eine Frage der Perspektive und Granularität.

Beispiel E-Commerce

Sind es nicht die Daten, der Produkte im Warenkorb, die früher oder später zu Positionen in einer Bestellung werden? Ja und Nein. Natürlich, es sei denn, der User entscheidet sich NICHT dazu die Bestellen-Schaltfläche zu betätigen.

Alternativen

Cookies

In Cookies kann eine begrenzte Datenmenge (1024kb) auf dem Rechner des Users abgelegt werden.

VORSICHT: Der User kann die Datei modifizieren. Nicht dass die Produkte im Warenkorb alle nur noch 0 EUR kosten. Auch sensible Daten (selbst wenn verschlüsselt) würde ich hier nicht ablegen: Stichwort Cookie-Hi-Jacking. Je nach Expiration-Date bleiben die Daten hier auch über mehrere Browser-Sitzungen erhalten.

HTML5 Web Storage

Das neue HTML5 API ermöglicht das Speichern von Dateien im sog. Isolated Storage (http://msdn.microsoft.com/en-us/library/3ak841sy(v=vs.80).aspx) einem Benutzerbezogenen lokalen Verzeichnis. Im Gegensatz zu Cookies, die implizit geladen werden ist es schwieriger diese Daten zu hijacken. Hierbei bleiben die Daten über mehrere Browser-Sitzungen erhalten.

http://dev.w3.org/html5/webstorage/

HTML5 Indexed Database API

Mit HTML5 kommt eine weitere API. Diese ermöglicht das Ablegen indizierter Daten, wie in einer Datenbank z.B. MS SQL Server, im Isolated Storage. Wie beim Web Storage werden auch hier werden die Daten explizit geladen. Auch hierbei bleiben die Daten über mehrere Browser-Sitzungen erhalten.

http://www.w3.org/TR/IndexedDB/

Datenbank

Wenn Die Daten (Beispiel E-Commerce) sowieso früher oder später zu einer Bestellung werden, könnte man diese doch einfach so behandeln. Alles was dazu benötigt wird ist eine weiter Spalte in der Datenbank-Tabelle namens z.B. „State“ mit den Werten für „Im Warenkorb“ und „Bestellt“. Hierbei ergeben sich zudem tolle Möglichkeiten:

  • Die Daten bleiben (nur für Angemeldete Benutzer) über mehrere Browser-Sitzungen erhalten

    • Auch über Devices hinweg. Für das Reporting: „TOP 10 Produkte im Warenkorb die aber selten verkauft werden“ und „Verhältnis von Im Warenkorb zu Bestellt“.

Nichts desto trotz die Dateileichen irgendwann mal aufgeräumt. Der MS SQL Server bietet mit dem SQL Server Agent die Möglichkeit in definierten Intervallen Jobs auszuführen: Backups genauso wie Aufräumarbeiten. Im Zweifel tun es aber auch „Scheduled Tasks“ (http://support.microsoft.com/kb/308569) bzw. von der Konsole die at.exe (http://support.microsoft.com/kb/313289) oder einfach CODE.