Sicher durch die Wolke: Persistenz in der Cloud

Konfiguration

Die Konfiguration, ob die Sessiondaten lokal oder auf Amazon gehalten werden, wird von der Klasse cloudsession.SessionServiceFactory.java übernommen. Möchte man die Daten auf Amazon halten, wird ein Amazon-Web-Services-Account [6] benötigt. In /src/main/resources/AwsCredentials.properties müssen außerdem die eigenen Credentials eingetragen werden, die man beim Anlegen des Accounts bekommen hat. Ggf. muss man sich beim Amazon SimpleDB Service [7] kostenfrei anmelden. Innerhalb von SDB muss initial eine Domaine „Sessions“ angelegt werden, damit diese der Anwendung zur Verfügung steht. Dazu wird der Code aus Listing 1 benötigt.

Zunächst werden die eigenen Credentials aus credentials.properties gelesen. Dann wird eine Instanz der Klasse AmazonSimpleDB erzeugt, die den Zugriff auf den SimpleDB Service bereitstellt. Mittels createDomain(CreateDomainRequest) wird die Domaine in SimpleDB angelegt (Listing 1).

Listing 1
public class CreateSessionDomain {
private static String SESSIONS_DOMAIN = "Sessions";

public static void main(String args[]) {
AWSCredentials creds = new Utilities().getCreds();
AmazonSimpleDB sdb = new AmazonSimpleDBClient(creds);
sdb.createDomain(new CreateDomainRequest().withDomainName(SESSIONS_DOMAIN));
}
}

Zur Laufzeit übernimmt jetty die Rolle des Webservers. Unter dem URL localhost:8080/sessiontest erscheint die Maske zum Testen (Abb. 3). Beim Druck auf den „StartSession“-Button wird ein Wert in der Session abgelegt. Dieser kann im Browser über die AWS-Konsole [8] im Bereich „SDB“ angeschaut werden.

Abb. 3: Testprojekt zur Laufzeit

Durch wiederholtes Neuladen wird angezeigt, dass sich der Sessioneintrag dem Timeout-Zeitpunkt nähert. Über „kill session“ kann die Session gelöscht, d. h. das Anlegen einer neuen Session bewirkt werden (Abb. 3).

Die Cache-Timeout-Zeit ist in der Servlet-Klasse NonStickySessionTest.java in der Konstante CACHE_LIVETIME_SECONDS konfigurierbar und Default-mäßig auf 5 Sekunden eingestellt.

Die wichtigsten Klassen

Schauen wir uns den Code genauer an. Im Package Cloudservice ist der für die Sessionverwaltung relevante Teil des Codes implementiert. Im Package util sind weitere Hilfsklassen zur Objektserialisierung mittels xStream, zum Auslesen der Credentials usw. Es gibt nur ein Servlet NonStickySessionTest.java, das die Steuerung des Session-API übernimmt.

Lokales testen

Die Sessionpersistenz kann lokal getestet werden, indem alle read/write-Aufrufe an die Session durch ein Interface gekapselt werden. In bestehenden Anwendungen müssen alle Zugriffe auf die Session entsprechend angepasst werden. Das Package stellt eine Implementierung zum lokalen Testen (LocalSessionService.java) und eine für Amazons SDB (AmazonSessionService.java) bereit. Die beiden Klassen implementieren das Interface CloudSession.java und sind dadurch leicht austauschbar. Gewechselt wird über File.pathSeparator, d.h. auf Windows läuft der Dummy- und auf Unix der AmazonSessionService. In SessionServiceFactory.java kann durch das Ändern weniger Zeilen leicht zwischen beiden Implementierungen gewechselt werden.

Cache

Es ist ein Cache vorgeschaltet (CloudSessionCache.java), damit nicht bei jedem Sessionzugriff ein externer Zugriff zum SDB Service erfolgen muss. Der Timeout dieses Caches ist Default-mäßig 10 Sekunden, kann aber mittels einer anderen getInstance(int seconds) -Methode eingestellt werden. Das folgende Listing zeigt die Handhabung des API mit und ohne definiertem Timeout:

CloudSession cs = SessionServiceFactory.getInstance();
CloudSession csDefinedTimeout = SessionServiceFactory.getInstance([TIMEOUT]);

Um die Session der eigenen Anwendung in die Cloud zu verlagern, ist Folgendes zu beachten: Es müssen alle Zugriffe auf die HTTP-Session gesucht und die get– bzw. set-Zugriffe gemäß Listing 2 geändert werden.

Listing 2
// code before:
session = request.getSession();
session.getAttribute(name);
...
session.setAttribute(name, value);

// code after:
CloudSession cs = SessionServiceFactory.getService();
Long lat = (Long)cs.getSessionValue(cookieSessionID, name);

cs.setSessionValue(cookieSessionID, name, value);
Fazit

Die Anforderung persistenter Sessions ist im Cloud-Umfeld mittels leichtgewichtiger Persistenzdienste einfach realisierbar. So kann das Problem der Sticky Sessions vermieden werden, Downscaling stellt kein Problem mehr dar und die Webanwendung kann innerhalb der Cloudumgebung skalieren.

Thorsten Rottschäfer entwickelt für ITinera Consulting Softwarelösungen im Risikomanagement für Banken und Versicherungen.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.