Implementierung eines Applikations-Prototypen auf Windows Azure Basis

Aus Winfwiki

1 Abkürzungsverzeichnis

2 Abbildungsverzeichnis

3 Tabellenverzeichnis

4 Einleitung / Problemstellung

Das Konzept des Cloud Computings ist aktuell ein starker Wachstumsmarkt der IT-Branche, dessen Marktvolumen sich bis zum Jahre 2013 verdreifachen wird^[1]. Kurz nach einigen anderen Anbietern, wie beispielsweise Amazon und Google, hat auch Microsoft auf der Professional Developer Conference (PDC) im Oktober 2008 in Los Angeles die Entwicklung einer Cloud Computing Plattform angekündigt. Diese Plattform befindet sich im Mai 2009 im Stand einer Community Technology Preview (CTP), was etwa einer öffentlichen Beta-Phase entspricht. Wie auch andere Cloud Computing Anbieter verspricht Microsoft durch die angebotene Plattform Rechen- und Speicherleistung auf Abruf bereitzustellen und dadurch beliebig skalierbare Anwendungen zu ermöglichen.

Im Rahmen dieser Fallstudie soll deswegen ein Hauptaugenmerk darauf gelegt werden zu untersuchen was bei der Entwicklung einer Applikation beachtet werden muss, die dieses Potenzial ausnutzen soll. Dazu soll die wissenschaftliche Methode des Prototypings angewendet werden. Diese Methode wurde gewählt, um anhand der Entwicklung des Prototyps eines Online-Buchungssystems für Konzertkarten einen Überblick über die technologischen Aspekte der Microsoft Plattform zu schaffen. Desweiteren soll versucht werden für die bei der Entwicklung auftretenden Probleme Musterlösungen zu erarbeiten. Diese praxisnahe Vorgehensweise soll im Anschluss einen Überblick über die Benutzbarkeit der Plattform schaffen.

Diese Arbeit erlangt wissenschaftliche Relevanz indem sie ein Thema erschließt, zu dem bislang keine Veröffentlichungen vorliegen. Da sich die Plattform noch in der Entwicklung befindet und die Qualität der Informationsquellen daher beschränkt ist, soll die Funktionsweise möglichst vieler untersuchter Aspekte im Prototypen verifiziert werden.

Der Vergleich der Cloud Computing Lösung von Microsoft mit den Plattformen anderer Anbieter ist nicht Teil dieser Arbeit. Genauso wenig beschäfigt sich diese Arbeit mit deren Wirtschaftlichkeitsbetrachtung sowie der Betrachtung von Sicherheitsaspekten oder Performancemessungen.

5 Grundlagen

5.1 Cloud Computing

Cloud Computing ist das Bereitstellen von IT-Diensten auf einer hochskalierbaren Infrastruktur^[2]. Die Speicher- und Rechenkapazitäten werden dabei von einem Dienstleister bereitgestellt. Diese sind durch Standardschnittstellen, Service Level Agreements und Abrechnungsmodelle, definiert. Wie diese Dienstleistungen erbracht werden ist im weitesten Sinne irrelevant.^[3].

Ein Vergleich ist hier das Stromgeschäft. Ein Stromabnehmer kennt nur den Stromstecker, der die Schnittstelle darstellt. Desweiteren ist die von ihm erwartete Spannung und die Stromstärke in einem Service Level Agreement festgelegt, sowie die Preise pro Kilowattstunde (kWh) im Abrechnungsmodell. Spätestens am Sicherungskasten wird das Stromnetz zu einer Cloud, da hier für den Stromabnehmer nicht mehr abwägbar ist, wo der Strom herkommt und was in der Cloud, dem Stromnetz, passiert. Wie der Strom bis zu seinem Sicherungskasten kommt, interessiert den Abnehmer nicht. Durch diesen Zusammenhang zu Cloud Computing wird auch häufig über „Rechenleistung aus der Steckdose“ gesprochen^[3].

Im klassischen Betrieb von Computernetzen werden Anwendung lokal auf mehreren Rechnern ausgeführt und der Austausch von erstellten Dokumenten findet über das Netzwerk statt. Ein Aspekt des Cloud Computing ist es, dass sowohl auf Dokumente, wie auch auf Anwendungen, über das Netzwerk zugegriffen wird. Dadurch können die Dokumente in Echtzeit gemeinsam bearbeitet werden und es kann, ohne lokal ein Update durchführen zu müssen, immer die aktuellste Softwareversion benutzt werden. Von welchem Gerät letztendlich auf den Service in der Cloud zugegriffen wird, ist demnach nicht relevant^[4].

Abbildung 1: Verbindungen zur Cloud^[5]

In der Cloud wird von grundsätzlich anderen Voraussetzungen ausgegangen als dies im klassischen Softwarebetrieb der Fall ist. Es wird massiv auf Scale-Out gesetzt, dies bedeutet, dass massiv-redundante Standard-Hardware zum Einsatz kommt. Diese Cloud besteht aus einer großen Menge von vernetzten Rechnern, die von einem Betreiber in einem Rechenzentrum betrieben werden. Die Ausfallsicherheit dieser Hardware ist aufgrund der redundanten Auslegung gewährleistet. So werden Services, die auf einem dieser Server laufen und ausfallen, durch die Architektur unmittelbar auf ein anderes Gerät geschaltet und können so ohne Ausfallzeit weiterbetrieben werden. Daher kann eine hohe Verfügbarkeitsanforderung von 24/7 in der Cloud gewährleistet werden. Für den Anwender, der die Cloud als einzelne Anwendung, Gerät oder Dokument sieht, ist diese Infrastruktur nicht sichtbar und in der Regel auch nicht relevant^[5],[6],[7].

Abbildung 2: Architektur und Funktionsweise in der Cloud^[8]

Ebenso spielt es keine Rolle, auf welcher Technologie die Cloud Services, wie HTTP, HTML, XML, JavaScript oder andere, basieren. Cloud Computing ermöglicht eine Verlagerung der Anwendungen und der Daten von dem Rechner des Benutzers in die Cloud, auf die ein Zugriff von jedem Standort mit Internetverbindung möglich ist. Ein Anwender muss sich keine Gedanken mehr über das Daten-Management machen, er wird nicht einmal wissen, wo seine Daten genau liegen. Wichtig ist, dass die Daten in der Cloud für die autorisierten Benutzer unmittelbar zur Verfügung stehen^[4].

Die Vorteile die dadurch entstehen sind eine geringe „Time-to-Market“ für IT-Dienstleistung, da die Infrastruktur in den Rechenzentren bereits vorhanden ist und lediglich zugeschaltet werden muss. Eine hohe Flexibilität für Tests ist ebenfalls garantiert, da schnell eine Testumgebung eingerichtet und freigegeben werden kann. Sicherstellung des Betriebes oder Einhaltung von Service Levels können an den Dienstleister einer Cloud abgegeben werden. Auch Entwickler profitieren insofern davon, dass sie sich keine Gedanken über die Hardware machen müssen^[6].

Greift ein Anwender durch den Start einer Anwendung oder durch das Öffnen eines Dokuments auf die Cloud zu, beginnt die interne Bearbeitung in der Cloud. Die Anfrage des Benutzers wird über das System Management an die intern verteilten Storage- und Applikations-Services weitergeleitet.

Parallel dazu wird ein Monitoring zum Messen des eigentlichen Nutzens der Cloud Dienste gestartet, dass als Abrechnungsgrundlage für den Cloud-Betreiber dient^[5].

5.2 Einordnung der Microsoft Windows Azure Plattform

Derzeit kommen immer mehr Fachbegriffe zum Thema Cloud Computing auf und von diversen Firmen werden Services aus der Cloud angeboten. Auch Microsoft bietet hier mit seinen Global Foundation Services und der Windows Azure Service Plattform eine technische Basis für verschiedene Service-Angebote an^[9],[10]. Im folgenden werden diese Services, nach Geschäftsmodellen gegliedert, erläutert:

IaaS:

Dieser Service beinhaltet die Dienstleistung für die Bereitstellung der virtualisierten Hardware für Rechenleistung und Speicherkapazität. Dadurch ist die Bereitstellung der Infrastruktur auf den Dienstleister übertragen. Nutzer können auf dieser Infrastruktur ihre eigenen Dienste bis hin zu vollständigen Anwendungen installieren und nutzen. Dies ist der Ersatz für die eigenen Server- und Netzwerk Infrastruktur. Microsoft setzt hierfür seine Global Foundation Services ein, die als Infrastrukturdienste erbracht werden. Hier können komplette Eigenentwicklungen eingebracht und in Betrieb genommen werden.

PaaS:

Dieser Dienst ist eine etwas komplexere Art des IaaS und stellt die Grundlage für Anwendungsdienste bzw. Anwendungen dar. Diese Dienste richten sich an Software-Entwickler, um eigene Anwendungen anzureichern bzw. diese Anwendungen auf einer Cloud-Plattform installieren, überwachen und betreiben zu können. Microsofts Windows Azure bietet auf dieser leistungsfähigen und skalierbaren Plattform eine Basis für die Dienste von den fünf Live Services an. Diese gliedern sich in die Dienste Microsoft Live Services, Microsoft .NET Services, Microsoft SQL Services, Microsoft SharePoint Online und Microsoft Dynamics CRM Services. Entwickler haben hier die Möglichkeit diese Dienste über Standardwebschnittstellen anzusprechen und in Ihren bestehenden Anwendungen zu nutzen.

SaaS:

Als SaaS werden Dienste bereitgestellt, die bereits fachliche Funktionen jenseits von reinen Infrastrukturlösungen fertig implementiert haben. Diese Dienste richten sich an Nutzer die sich nicht mit deren Betrieb, Wartung und Entwicklung auseinandersetzen wollen. Microsoft bietet hier für verschiedene Anwenderkreise unterschiedliche Lösungen. Zu diesen zählen Office Live Workspace, Office Live Small Business, Windows Live, SharePoint Online und Exchange Online^{[9],[10],[11],[12]}.

Abbildung 3: Technischer Überblick - Microsofts Software plus Services-Konzept^[10]

Microsoft ergänzt dieses Angebot mit der Marktstrategie "Software plus Services" und stellt den Zusammenhang mit der lokal betriebenen Software, für die der Anwender selbst verantwortlich ist, her. Anwender sollen dabei dadurch profitieren, dass dieser Software auch durch Erfahrungen anderer Anwender verbessert wird und dass diverse Endgeräte unterstützt werden. Zusätzlich sollen die Aufwände für den Betrieb lokal installierter Software wegfallen. Microsoft stellt Entwicklungs- und Management-Werkzeuge für die Überwachung, die Steuerung und die Konfiguration für die Software-plus-Services-Lösung und deren hybriden Nutzung bereit^[9],[13].

Software:

Diese Schicht bildet die Grundlage für Microsofts Standardsoftware, die bereits im Einsatz ist. Hier wird der Betrieb von Anwendungen auf verschiedenen Geräten ermöglicht.

plus:

Das von Microsoft erstellte Konzept "Software plus Services" beinhaltet eine Standardwebschnittstelle, über die alle in der Cloud liegenden Dienste von Microsoft angesprochen werden können. Diese Schnittstellen sind bereits gängig genutzte, wie SOAP beziehungsweise REST^[9],[10].

5.3 Microsoft Azure

Microsoft Windows Azure wurde auf der PDC 2008 (Professional Developer Conference) in Los Angeles erstmals als Cloud-Betriebssystem der Öffentlichkeit präsentiert. Diese Plattform ermöglicht es Entwicklern Anwendungen zu erstellen die als Cloud-Service in den Microsoft Rechenzentren laufen können. Diese Plattform bietet desweiteren Speicherplatz in der Cloud an. Auch bereits vorhandene Services können hier zu einer neuen Anwendung zusammengestellt und verwendet werden. Dadurch entsteht für Unternehmen und Anwender eine flexible Auswahl für deren unterschiedliche Anforderungen^[14].

Microsoft Azure ist die Microsoft Plattform für Cloud Computing. Microsoft Windows Azure ist ein Cloud Computing Betriebssystem. Dieses System baut auf die Technologie von Microsofts Windows Server 2008 auf und ist für die Anforderungen der Cloud optimiert. Das System wurde zudem im Hinblick auf vertikale und horizontale Skalierbarkeit angepasst. Unter Skalierbarkeit versteht sich das vom Bedarf abhängige Zuschalten von Rechenleistung. Wird diese benötigt, kann sie zugeschaltet werden, wenn sie nicht mehr benötigt wird, kann sie für andere Prozesse verwendet oder abgeschaltet werden. Auch auf eine homogene Infrastruktur hin, die in den Rechenzentren von Microsoft herrscht, wurde dieses Cloud Betriebssystem optimiert und kommt bisher auch nur dort zum Einsatz. Ein Verkauf ist derzeit nicht geplant, sodass ein lokaler Einsatz oder der Aufbau einer unternehmenseigenen Cloud somit nicht mit Microsofts Windows Azure möglich ist^[12],[15].

Die Microsoft Azure Plattform basiert auf einem Rechenzentrum inklusive Speicherdienstleistung und Load-Balancer. Der charakteristische Unterschied zwischen der Microsoft Windows Azure Plattform und anderen Hosting-Plattformen besteht dadurch, dass diese primär dafür ausgelegt sind einen Server oder ein Cluster von etwa 10-16 Rechnern zu betreiben. Windows Azure ist dafür gebaut zehntausende von Rechnern zu managen, d.h. hier ist die Abstraktionsebene eine ganz andere. Das Verteilen von Diensten findet nun nicht mehr nur lokal auf einem Rechner statt, sondern man verteilt sie auf einer großen Menge von vernetzten Rechnern. Nachdem die Anzahl von parallel zu benutzenden Prozessen für einen Dienst festgelegt wurde, ist es die Aufgabe Windows Azure's diese auf die vorhandenen Rechner zu verteilen. Durch Azure wird sichergestellt, dass diese wenn ein System ausfällt, automatisch auf einen anderen Rechner verteilt werden. Diese Funktionalität ist in Windows Azure, dem Microsoft Cloud Betriebssystem, im Design berücksichtigt. Das Ganze wird ein Dienst sein, der pro benutzter CPU-Zeit sowie Bandbreite und Speicherplatznutzung bezahlt wird. Das System selbst ist dafür gedacht Rechenzentren, die mit einer großen Menge von Rechnern ausgestattet sind, sowie den darauf laufenden Anwendungen zu managen^{[6],[7],[12],[16]}.

Microsoft bezeichnet Windows Azure bzw. die Windows Azure Services und die lokal betriebene Software als Konzept und Marktstrategie "Software plus Services". Dieses Konzept bedeutet, dass lokal betriebene Software mit den Cloud Services kombiniert werden soll. Microsoft betrachtet diese beiden Technologien gleichwertig, da beide, auch in naher Zukunft, eine beträchtliche Rolle spielen werden. Somit hat auch die lokale Software ihre Daseinsberechtigung auf dem Markt. Diese ist derzeit noch immer die Schnittstelle zum Benutzer und ist durch ihre hohe Verbreitung nicht wegdenkbar. Auch werden unter anderem mit der lokalen Software diverse Endgeräte unterstützt, die somit lokal und auch "offline – ohne Cloud" betrieben werden können. Verbindet man diese Strategie "Software plus Services", so versteckt sich dahinter auch die Möglichkeit seine Daten offline zu bearbeiten, zum Beispiel wenn die Cloud nicht erreichbar ist, und diese anschließend, nach erfolgreicher Herstellung der Verbindung, automatisch mit sogenannten SyncroFeatures in die Cloud zu portieren und mit anderen Geräten abzugleichen^[17],.

Für Unternehmungen spielt hier allerdings das Vertrauen eine große Rolle, da die Daten nun nicht mehr lokal abgelegt werden, sondern in der Cloud verteilt. Durch Regularien ist es, z.B. für Finanzämter oder Regierungseinrichtungen, nicht denkbar eine Cloudlösung einzusetzen. Diese sind durch Vorschriften zur internen Speicherung von Daten verpflichtet und können sie daher nicht "aus dem Haus" geben^[18].

Wichtige Einflussfaktoren und Herausforderungen, die zum Trend des Cloud Computing und der Entwicklung von Microsoft Azure führen, sind Skalierbarkeit, redundant ausgelegte Systeme und große Rechen- und Speicherkapazitäten, die vorgehalten werden müssen. Ein Serviceprovider wie Microsoft hat hier mehr Möglichkeiten diese Faktoren beziehungsweise Herausforderungen zu bedienen, da dieser mit etwa zehntausend Rechnern pro Rechenzentrum schnell und flexibel auf die Bereitstellung von IT-Dienstleistungen reagieren und diese so den Anwendern zugänglich machen kann. Durch diese schnelle und flexible Reaktion kann somit die kurze "Time-to-Market" erzielt werden. Auch die flexible Bezahlung beziehungsweise die alternativen Bezahlmodelle spielen dabei ebenso eine Rolle. Bei Microsofts Cloud Services soll nach dem "Pay for what you use"-Prinzip abgerechnet werden, damit wird nur die effektiv genutzte Rechenzeit in Rechnung gestellt. Derzeit liegt noch keine Preistabelle von Microsoft vor^[6],[16].

Windows Azure Cloud Services

Auf der Windows Azure Services Plattform läuft das Cloud Betriebssystem Windows Azure. Auf diesem basieren verschiedene Azure Services. Diese sind zum Beispiel Microsoft Live Services, Microsoft .NET Services, Microsoft SQL Services, Microsoft SharePoint Online und Microsoft Dynamics CRM Services.

Microsoft Windows Azure läuft auf der Microsoft Infrastruktur (Rechenzentren etc.), die derzeit nur in den USA vorhanden ist. Es sind aber auch in Europa Rechenzentren geplant, bislang in Dublin und Amsterdam. Die Windows Azure Plattform bildet die Grundlage für alle anderen Online Services, die von Microsoft bereitgestellt werden, wie Microsoft Windows Live, Microsoft Office Live, Microsoft Exchange Live und Microsoft Sharepoint Live, die darauf aufsetzen. Ein entscheidender Punkt ist, das diese Plattform Entwicklern bereitgestellt wird, um dort ihre eigenen Anwendungen zu installieren und laufen zu lassen. Die Plattform steht Entwicklern ebenfalls offen, die Services der Microsoft Windows Azure Plattform nutzen wollen um sie in klassische Anwendungen zu integrieren^{[7],[12],[19]}.

Abbildung 4: Microsofts Betriebsmodelle - S+S-Konzept^[14]

Mit dieser Plattform bietet Microsoft den Unternehmungen die Möglichkeit eine Erweiterung bestehender Anwendungen um Cloud Services in Microsoft Windows Azure, eine Migration beziehungsweise komplette Neuentwicklung ganzer WebAnwendungen für Microsoft Windows Azure und eine Zusammenstellung neuer Anwendungen aus vorhandenen Cloud Services in Microsoft Windows Azure zu verwirklichen^[14],[22].

Zwei bei der Entwicklung des Prototypen benutzte Elemente von Windows Azure sind der StorageAccount und die Hosted Services, deren Funktionalität im folgenden kurz erläutert werden soll:

5.3.1 Storage Account

Der Storage Account ist in der Cloud bereitgestellter Speicherplatz mitsamt Passwort und HTTP-Adresse. Dieser ist in drei Unterarten gegliedert, die verschiedene Charakteristiken aufweisen.

TableStorage

Im TableStorage können Datensätze innerhalb einer Tabelle abgespeichert werden. Da jedoch für eine Tabelle kein festes Datenschema und keine referentielle Integrität besteht, ist der TableStorage keine relationale Datenbank, sondern kann eher mit einem Dateisystem in der Cloud verglichen werden.

QueueStorage

Queues sind Warteschlangen, die den Zweck erfüllen sollen verschiedenen in der Cloud laufenden Prozesen als Zwischenspeicher für asynchrone Nachrichten zu dienen. Wird einem Prozess beispielsweise von einem Kunden ein Buchungsauftrag über ein Web-User-Interface übergeben, so kann dieser Prozess ihn in einer Queue speichern, von wo ihn dann mehrere andere Prozess entnehmen und bearbeiten können. Diese können so parallel arbeiten und ein Ergebnis erarbeiten, welches in eine weitere Queue oder im Table-Storage gespeichert wird. Queues sind ein wichtiger Bestandteil in der Kommunikation zwischen der Azure Web-Role und Worker-Role.

BlobStorage

Ist ebenfalls ein, einem Dateisystem nachempfundener Speicher für große binäre Daten, wie zum Beispiel Bilder oder Dateien^{[23],[24],[25]}.

5.3.2 Hosted Services

Abbildung 5: Instanzen von Webrole und Workerrole^[26]

Dienste, die unter Windows Azure laufen, werden als sogenannte Rollen bezeichnet. Diese Rollen unterscheiden sich in sogenannten Web-Roles und Worker-Roles. Eine Web-role ist eine Webanwendung, die über HTTP oder HTTPS aufgerufen wird. Eine Webrole ist standardmäßig in ASP.NET und mittels der WCF (Windows Communication Foundation) Technologie implementiert. Eine Worker-Role ist ein Hintergrunddienst. Sie eignet sie sich besonders zur Verarbeitung von Nachrichten aus einer Azure-Queue.

Ein Dienst kann aus einer Web-Role, einer Worker-Role oder beiden bestehen. Diese Rollen haben die Möglichkeit über HTTP, HTTPS oder über das Microsoft.NET-API TCP/IP-Socket eine ausgehende Verbindung zu anderen Internetquellen herzustellen. Lediglich die Web-roles können auch eingehende Verbindungen annehmen. Die Rollen haben ebenso die Möglichkeit über die Azure SDK runtime API folgende Optionen zu nutzen:

• zusätzlichen lokalen Speicher für Caching allokieren
• Standarddienste für Loggingfunktionen aufzurufen
• Auslösen von kritischen Fehlern und direkt zum Anbieter senden
• Schnittstellen für den Programmstatus bedienen

Die Form eines Dienstes ist in der Datei ServiceConfiguration.cscfg definiert (siehe 6.5.1.1). In dieser Datei wird festgelegt, ob es bei einem Programm um eine Web-Role oder eine Worker-Role handelt. Handelt es sich um eine Web-role, so steht in der Definitionsdatei, ob diese über HTTP oder HTTPS angesprochen werden kann. Darüber hinaus können die Konfigurations-Parameter für den Zugriff bei Caching auf den lokalen Speicher definiert werden^{[26],[27] [28]}.

5.4 Anwendungsfälle des Prototypen

Um die Funktionalitäten von Windows Azure im Rahmen dieser Fallstudie zu verifizieren, wurde ein Applikationsprototyp auf Windows Azure Basis implementiert. Es handelt sich bei dem, in dieser Fallstudie entwickelten, Prototypen um ein Online-Buchungssystem zur Buchung von Veranstaltungskarten per Internet. Das Buchungssystem wurde als Webanwendung implementiert und ist über ASP.NET-Webseiten für den Endanwender erreichbar.

Abbildung 6: Anwendungsfall

Die Abbildung Anwendungsfall zeigt mit Hilfe eine UML Use-Case-Diagramms den Anwendungsfall, der diesem Projekt und dieser Fallstudie zu Grunde lag.

Der Nutzer hat die Möglichkeit die Anwendung per Browser aufzurufen. Zunächst kann der Anwender über die Applikation Veranstaltungen aus dem Veranstaltungskatalog sichten. Aus den Veranstaltungen die ein Anwender gesichtet hat, kann dieser eine auswählen und Karten für diese buchen.

Hat ein Anwender eine Veranstaltung gebucht, so bekommt er anschließend automatisch eine eMail mit der Buchungsbestätigung zu seinem Auftrag. Zudem wird über die Anwendung eine Meldung mit den restlichen freien Plätzen der Anwendung an den Microblogging Dienst „Twitter“ gesendet, falls ein kritischer Kartenstand erreicht ist (z.B. die letzten 50 Karten).

Zusätzlich zu dem Anwenderbereich stellt die Webanwendung auch noch einen Adminstrationsbereich zur Verfügung. Ein Administrator hat die Möglichkeit Veranstaltungen anzulegen, zu löschen oder diese zu editieren. Es handelt sich hier um eine klassische Funktion zur Stammdatenpflege des Systems.

6 Entwicklung des Prototypen

In diesem Kapitel werden die für die Entwicklung von Azure-Applikationen notwendigen Vorbereitungen beschrieben. Desweiteren wird das Konzept dargestellt, welches bei der Entwicklung des Prototypen umgesetzt wurde und die dabei verwendeten Technologien angesprochen. Im Anschluss werden die Lösungen diskutiert, welche bei der Entwicklung entstanden sind und Relevanz über die Entwicklung des Prototypen hinaus besitzen.

6.1 Vorbereitungen für die Entwicklung

Um einen Prototypen zu entwickeln und diesen auch in einer reellen Cloud von Microsoft zu testen, bedarf es einiger Vorbereitungen. Vorerst benötigt man einige Software-Komponenten, die auf dem eigenen PC installiert werden müssen. Dieser PC muss mit einem neueren Betriebssystem ausgestattet sein. Eine Internetverbindung ist obligatorisch^[29].

6.1.1 Systemvoraussetzungen

Derzeit werden für die Windows Azure Tools die Betriebssysteme Windows Vista Service Pack 1, Windows Vista Service Pack 2, Windows Server 2008 und Windows 7 unterstützt. Diese Systeme können für Tests auch als virtuelles System aufgesetzt werden. Dies ist die Basis für die Installation der Windows Azure Tools. Weitere Spezifikationen werden von Microsoft nicht genannt und sind bei der Entwicklung nicht aufgefallen^[29].

6.1.2 Softwareinstallationen

Für den Betrieb der Microsoft Windows Azure Tools benötigt man Microsoft Visual Studio 2008 mit Service Pack 1, Microsoft Visual Studio 2010 Beta 1 oder Microsoft Visual Web Developer 2008 Express Edition mit Service Pack 1, um die Services implementieren zu können. Bei der Installation sollte darauf geachtet werden, dass mindestens der SQL Server 2005 Express Edition mit auf dem System installiert wird^[29].

Abbildung 7: Installation von Microsofts IIS 7 und WCF HTTP Activation (eigener Screenshot)

Auf dem Entwicklungssystem müssen zusätzlich noch einige Dienste gestartet werden, um die Windows Azure Tools anschließend zu installieren. Sind diese Dienste während der Installation nicht aktiv, so bricht diese Installation mit Fehlermeldungen ab. Die Voraussetzungen für die Installation erfordern die integrierten Windows Dienste Internet Information Server 7.0, ASP.NET mit optional aktivierten CGI und den Windows Communication Foundation HTTP Activation-Dienst (siehe Abbildung 7). Diese müssen über die Systemsteuerung im Menüpunkt Programme unter Windows Funktionen aktiviert werden. Sind alle Dienste erfolgreich aktiviert, kann man die aktuelle Version der Windows Azure Tools for Microsoft Visual Studio May 2009 CTP [[1]] installieren. Es kann sein, dass zuvor einige Hotfixes eingebunden werden müssen, diese Informationen befinden sich auf der Microsoft-Seite^[29].

6.1.3 Registrierung

Um die Windows Azure Infrastruktur zu nutzen, bedarf es der vorherigen Registrierung bei den Services von Microsoft. Dafür kann man den Link [[2]] nutzen, um sich für eine LiveID zu registrieren. Nach dem Standardprozedere mit der Anmeldung bei Microsofts LiveID kann man sich auf der Azure Plattform anmelden. Man bekommt nach erfolgreicher Anmeldung nach wenigen Tagen einen Token zugesandt, mit dem man anschließend seine eigenen Projekte anlegen und Implementierungen auf dem Windows Azure Services Developer Portal hochladen kann^[30].

Derzeit erhält man im CTP pro Account:

6.2 Konzept

Abbildung 8: Konzeptioneller Überblick über den Prototypenhreibung

Das grundlegende Anwendungskonzept, welches dem Applikationsprototypen zu Grunde liegt, lässt sich der Abbildung 8 entnehmen. Die nachfolgenden Abschnitte geben dazu ergänzend einen Überblick über das Anwendungsdesign in Bezug auf die Abbildung.

6.2.1 Datenhaltung

Die Datenhaltung innerhalb des Applikationsprototypen erfolgt innerhalb zweier Message Queues und dem TableStorage. Beide Konstrukte werden dem Entwickler innerhalb des AzureStorage-Accounts zur Verfügung gestellt.

Die beiden Queues (Buchungen & Buchungsbestätigung) dienen dabei der temporären Datenhaltung. Eine speichert Buchungsanfragen während die andere Buchungsbestätigungen bzw. Absagen speichert. Die Queues speichern die Informationen so lange, bis diese durch eine Worker-Role von der Applikation verarbeitet wurden.

Die "Stammdaten" der Anwendung werden im Azure TableStorage gespeichert. Es handelt sich hierbei um Kundendaten, bereits akzeptierte Buchungen sowie die Veranstaltungsdaten mitsamt der noch verfügbaren Kartenanzahl des Buchungssystems.

Alle Objekte dieses Prototypen wurden mit normalen C#-Klassendateien realisiert. Diese Klassen sind analog zu Klassen in normalen Client-Server Anwendungen aufgebaut. Anbei folgt ein kurzes Code Beispiel für die Veranstaltungsklasse:

//die Klasse erbt von "TableStorageEntity" damit sich die Klasse 
//später im Azure Table Storage speichern lässt
public class Happening : TableStorageEntity
{
   //Konstruktor
   public Happening(){}

   //get- und set-Methoden der Attribute  
   public string Title { get; set; }
   public int Seats { get; set; }
   public int StandingRoom { get; set; }
   public DateTime Datum { get; set; }
}

6.2.2 Schnittstellen

Die Anwendung verfügt insgesamt über 4 Schnittstellen zu anderen Systemen. Es handelt sich hierbei um die Benutzerschnittstelle, der Schnittstelle zum Java Client, welcher aktuelle Veranstaltungsdaten anzeigt, die Anbindung an den Microbloggingdienst Twitter sowie dem E-Mail Versand über die zweite Worker-Role.

6.2.2.1 Webseiten

Die Websiten des Applikationsprototypen wurden mit ASP.NET erstellt. Die Webseiten implementieren die in Abbildung 8 abgebildete Web-Role. Erstens ermöglicht diese den administrativen Zugriff auf die Stammdaten und greift dazu auf den TableStorage zu. Zweitens, stellen sie die Benutzerschnittstelle dar, über die der Kunde das Buchungssystem erreichen kann.

Es gibt eine Startseite und jeweils eine Webseite zum Anzeigen, Erstellen und Ändern von Veranstaltungsdatensätzen. Eine weitere Webseite ermöglicht dem Kunden das Buchen einer Veranstaltung. Alle Datenänderungen der Veranstaltungen werden von der Web-Role auf dem Azure TableStorage durchgeführt. Das Hinzufügen einer Veranstaltung ist im Quellcode einer ASP.NET-Webseite wie folgt implementiert:

protected void bt_submit_Click(object sender, EventArgs e)
{
   // Anlegen einer Instanz der Klasse Happening 
   // und Füllen mit Benutzereingaben
   Happening newEntry = new Happening() { Seats = System.Int32.Parse(tb_seats.Text), Title = tb_titel.Text, 
                                                  StandingRoom = System.Int32.Parse(tb_standing.Text), 
                                                  Datum = System.DateTime.Parse(tb_date.Text) };
   // die DataSource ermöglicht den Zugriff auf die Storage Table
   HappeningDataSource ds = new HappeningDataSource();
   // das neue Happening der DataSource hinzufügen
   ds.AddHappening(newEntry);
   daten_eingabe.Visible = false;
   erfolgreich.Visible = true;
}

Zu sehen ist, dass das Data-Access-Object Design-Pattern angewandt wurde. Innerhalb der Klasse HappeningDataSource ist die komplette Logik enthalten um eine Veranstaltung, die dieser per AddHappening()-Methode übergeben wird im TableStorage anzulegen.

Ein Ausschnitt aus der HappeningDataSource-Klasse zeigt, dass die Arbeit dort auch einfach weiterdelegiert wird. Nur die Benennung der Table (Happening) im TableStorage wird hier vorgenommen:

public void AddHappening(Happening newItem)
{
   _context.AddObject("Happening", newItem);
   _context.SaveChanges();
}

Das Objekt _context ist vom Typ der Klasse TableStorageDataServiceContext, die nichtmehr selber implementiert werden muss, falls keine weiteren Funktionalitätem gewünscht sind, sondern in einer Microsoft Bibliothek mitgeliefert wird.

Alle anderen Zugriffe auf den Azure Storage, also Queue und Table sind im Prototypen gleichermaßen implementiert worden. Wie gezeigt, ist der Zugriff auf den Azure-Storage ist also einfach zu implementieren.

6.2.2.2 "Info-Anzeige"

Abbildung 9: Screenshot des CloudViewers

Die Info-Anzeige wird von einem Java Client generiert. Der Client ruft aktuelle Daten aus dem Azure TableStorage ab und generiert aus diesen eine Übersicht der aktuellen Veranstaltungsdaten. Der Client sendet und empfängt die Daten per REST over HTTP. Das folgende Code Beispiel demonstriert, wie diese REST Anbindung implementiert werden kann:

// Der Rückgabewert des Aufrufs ist ein XML-Document 
// wie es von WebServices in Java genutzt wird
private org.w3c.dom.Document getResponseFromCloud() throws ResourceException, IOException,
                                                           ParserConfigurationException,
                                                           SAXException
{
   // Als erstes  ist die Adresse zu dem Azure Storage Account bekannt zumachen
   ClientResource resource = new ClientResource("http://fomstorage.table.core.windows.net/Happening");
   // Eine Authentifizierung unseres Java Clients wird ebenfalls benötigt
   ChallengeScheme scheme = ChallengeScheme.HTTP_MS_SHAREDKEY_LITE;
   ChallengeResponse authentication = new ChallengeResponse(scheme,
   // Hier werden die Zugangsdaten zu dem Storage Account hinterlegt
   // Account, Passwort
                                             "fomstorage","XXXXXXXXXXXXXXXXrVJPq2ftTQp8bR3CAJgPhg==");
   resource.setChallengeResponse(authentication);
   // Die Anfrage per HTTP GET-Befehl an  den Storage senden
   resource.get();
   // das zurück gelieferte Document parsen 
   if (resource.getStatus().isSuccess()) {
      String input = resource.getResponse().getEntityAsText();
      return makeStringDOM(input);
   }
   // Authentifizierung ist fehlgeschlagen 
   else
      if (resource.getStatus().equals(
				org.restlet.data.Status.CLIENT_ERROR_UNAUTHORIZED))
      {
         // Unauthorized access
	 System.out.println("Access authorized by the server, check your credentials");
	 return null;
      }
      // anderer Fehlerfall 
      else
      {
         // Unexpected status
	 System.out.println("An unexpected status was returned: "
		            + resource.getStatus());
	 return null;
      }
}

Hierdurch ist gezeigt worden, dass der Azure Storage leicht durch externe Applikationen, welche auch nicht auf der .NET-Plattform basieren müssen, zugreifbar ist.

6.2.3 Interne Verarbeitung

Die Applikation folgt einer festen Bearbeitungsreihenfolge. Ausgangspunkt ist der Browser des Anwenders, über den ein HTTP-Request an die WebRole des Prototypen gesendet wird. Die WebRole hat an dieser Stelle die Aufgabe die eingegangenen Daten für Veranstaltungen und Kunden an den TableStorage weiterzuleiten. Die geschieht über die bereits erwähnte Methode submit_click().

6.2.3.1 Worker-Role1: "Buchung Prüfen"

Abbildung 10: Screenshot der Meldungen auf Twitter.com

Worker-Role1 entnimmt der Queue in der die Buchungen vom Web-Front-End abgelegt wurden eine Buchungsanfrage nach der anderen und prüft, ob für diese noch genug Karten buchbar sind. Dazu muss die Role eine Verbindung mit dem TableStorage aufbauen und den Veranstaltungsdatensatz lesen. Je nach Erfolg der Prüfung wird ein anderer Text generiert, der in der zweiten Queue (in Abbildung 8 mit "Buchungsbestätigungen" beschriftet) gespeichert wird. Wurde für eine Veranstaltung eine Buchung vorgenommen, wird geprüft, ob die Anzahl der restlichen Karten unter einen bestimmten Wert gefallen ist. Ist dies der Fall, veröffentlicht die Worker-Role mittels einer ausgehenden HTTP-Verbindung diesen Umstand in einem speziellen Account auf Twitter. Hierdurch konnte gezeigt werden, wie Azure-Applikationen auf andere Dienste zugreifen können. Die Implementierung des Zugriffs unterscheidet dabei nicht von der eines HTTP, einer nicht-Cloud-Anwendung.

6.2.3.2 Worker-Role2: "Email senden"

Abbildung 11: Bestellbestätigung per Email

Um zu verifizieren, ob auf der Azure-Plattform Applikationen auch Applikationen laufen, welche nicht in .NET-Sprachen geschrieben wurden, wurde die Logik zum Versandt der Buchungsbestätigungen in Java implementiert. Dazu greift die Java-Applikation auf die Message-Queue mit den Buchungsbestätigungen zu und versendet die Bestätigungen nacheinander per Mail. Die Implementierung der Java-Anwendung unterscheidet sich dabei nicht von einer, die nicht auf der Azure-Plattform laufen soll. Da auf der Azure-Plattform kein Java-Runtime-Environment vorhanden ist, wurde dieses zusammen mit der Anwendung hochgeladen. Da alle Roles in .NET-Sprachen geschrieben werden müssen, wurde eine Wrapper Klasse in C# implementiert. Im folgenden Quelltextauszug ist zu sehen, wie aus dieser Klasse das Java-Programm via Kommandozeile gestartet wird. Dabei wird die komplette Ausgabe des Java-Programmes an die C#-Worker-Role weitergeleitet:

public override void Start()
{
	Process p = new Process()
	{
		StartInfo = new ProcessStartInfo(Path.Combine(Environment.GetEnvironmentVariable
                              ("RoleRoot"), @"jre\bin\java.exe"), @"-jar MailSenderWorker.jar")
		{
			RedirectStandardInput = true,
			RedirectStandardOutput = true,
			RedirectStandardError = true,
		}
	};
	
	p.OutputDataReceived += (sender, e) =>
	{
		if (e.Data != null)
			RoleManager.WriteToLog("Verbose", e.Data);
		else
			RoleManager.WriteToLog("Error", "null");
	};
}

Hierdurch wurde gezeigt, dass auf der Azure-Plattform auch Programme beliebiger Programmiersprachen eingesetzt werden können.

6.3 Verwendete Technologien

6.3.1 ASP.NET

Bei ASP.NET handelt es sich um einen Bestandteil des Microsoft .NET Frameworks. ASP.NET umfasst eine Sammlung von speziellen Klassen und Funktionalitäten, die Microsoft für die Entwicklung von Web-Anwendungen in das .NET Framework implementiert hat. Zusammen mit den anderen Paradigmen des Microsoft .NET bilden diese, die Grundlage für die Entwicklung von Web-Anwendungen mit dem .NET Framework. Durch die feste Integration dieser Technologien in das .NET Framework lassen sich innerhalb von ASP.NET Web-Anwendungen alle Klassen, Methoden und Objekte nutzen, die auch in herkömmlichen, unter .NET entwickelten, Anwendungen zur Verfügung stehen. Des Weiteren kann durch die Integration in das Framework jede CLR (Common Language Runtime) fähige Sprache für die Implementation von Web-Anwendungen auf ASP.NET Basis verwendet werden. Der Entwickler hat z.B. die Möglichkeit zwischen C#.NET oder VB.NET zu wählen, um die gewünschten Funktionalitäten der zu entwickelnden Web-Anwendung zu implementieren. Es gibt jedoch auch Sprachen, die nicht nativ dem .NET Framework zugehörig sind, aber das .NET Framework dennoch unterstützen. Als Beispiele sind hier Perl, Python oder PHP zu nennen. Die Integration dieser Skriptsprachen in das Framwork ist so ausgeprägt, dass es bereits Erweiterungen für das von Microsoft entwickelte Visual Studio gibt, um diese Sprachen in die IDE zu integrieren und dort nutzen zu können.

6.3.1.1 Gründe für den Einsatz von ASP.NET

Folgende Punkte werden in der Literatur, als Gründe für den Einsatz der ASP.NET Technologie für Web Anwendungen, aufgeführt:

• Performance:

Mit ASP.NET entwickelte Anwendungen werden bereits vor ihrer Ausführung in die Microsoft Intermediate Language, die IML kompiliert, Anwendungen im klassischen ASP oder PHP werden erst zur Laufzeit von einem Web Server interpretiert.

• Einheitlichkeit:

ASP.NET Webseiten werden üblicherweise unter VB.NET implementiert. Es ist nicht nötig, sich eine eigene Programmiersprache für das Entwickeln von Web-Anwendungen anzueignen. Zudem lassen sich bereits bekannte Module des .NET Frameworks für das Lösen von Standardaufgaben, wie dem Lesen aus oder das Schreiben in Dateien, nutzen.

• Versionssicherheit:

Auf einem ASP-Server können verschiedene Versionen des .NET Frameworks parallel betrieben werden. Dadurch lassen sich auch Anwendungen, die in verschiedenen Versionen des Frameworks entwickelt wurden parallel auf diesem Server betreiben. Es treten keine Versionskonflikte zwischen den Anwendungen und dem Server auf.

• Verwaltung des Arbeitsspeichers:

Das .NET Framework verfügt über seine eigene Speicherverwaltung. Diese ermöglicht das dynamische Allokieren von Hauptspeicher für besonders große Objekte. Hierdurch sollen Geschwindigkeitsvorteile gegenüber anderen Technologien erreicht werden. Zudem nutzen ASP.NET Anwendungen, wie normale .NET Anwendungen, die Garbage-Collection des Frameworks, welche zur Laufzeit der Anwendung den Speicher bereinigt^[32].

6.3.2 Representational State Transfer (REST)

Represential State Transfer, im folgenden sowie in der Fachliteratur REST genannt, wurde von Roy Fielding, in dessen Dissertation aus dem Jahre 2000, entwickelt und beschrieben. Bei REST handelt es sich nicht um eine konkrete Technologie, sondern um einen spezielle Softwarearchitektur, die dazu dient die Kommunikation zwischen einer Web-Anwendung und einem Server, üblicherweise per HTTP/HTTPS Protokoll zu realisieren. Da es sich bei REST um einen rein architektonischen Ansatz handelt, wäre es auch denkbar, die Kommunikation mit anderen Protokollen zu realisieren.

6.3.2.1 Service Anfragen

REST ermöglicht es, dass Web-Applikationen über ein zustandsloses Verfahren Anfragen an einen Service senden können. Eine solche Anfrage besteht in der Regel aus zwei Teilen, der eigentlichen Nachricht an den Server und den Endpunkt. Hier handelt es sich normalerweise um eine URL unter welcher ein Dienst zu erreichen ist. Anfragen innerhalb der REST-Architektur werden über die aus dem HTTP-Protokoll zur Verfügung stehenden Befehle abgewickelt. Es handelt sich hierbei um einen GET-, POST, PUT oder DELETE-Befehl^[33].

6.3.2.2 Vorteil gegenüber SOAP

Der Vorteil von REST-Anwendungen gegenüber SOAP-Anwendungen, soll in ihrer Einfachheit und Performance liegen^[34].

6.3.2.3 Microsoft REST APIs

Unter Microsoft Azure haben Entwickler die Möglichkeit, die Microsoft REST APIs zu nutzen, um REST in einer Web-Anwendung zu implementieren. Im Prototyp werden die REST APIs genutzt um einen BlobStorage, eine Queue oder ein TableStorage anzusprechen. Die REST APIs realisieren also den Zugriff auf die Speicher-Dienste. In den Java-Teilen des Prototypen geschah dies direkt, in den C#-Teilen durch eine Microsoft-Bibliothek gekapselt. Die URL des Storage-Accounts ist die Grundlage der REST APIs um Speicherdienste in Anspruch zu nehmen. Es handelt sich hierbei um einen Namespace der den Zugriff auf Elemente, die zur Datenhaltung benötigt werden, regelt. Authentifizierungen werden ebenfalls durch den Storage Account geregelt. Die folgenden Speicherdienste werden in Windows Azure Web-Anwendungen genutzt:

BlobStorage

Daten im Blob werden in Containern organisiert. Jeder Blob muss einem Container zugehörig sein. Ein Container kann mehrere Blobs enthalten. Blobs werden über die REST API als PUT-Befehl abgesetzt. Mittels der Container kann eine Verzeichnishierarchie emuliert werden, welche dann über REST angesprochen wird. Ein einzelner Blob darf bis zu 64MB umfassen. Blobs, die mehr Daten umfassen müssen, werden in Blöcke à 4MB aufgeteilt und einzeln verarbeitet. Die maximale Dateigröße für Blobs beträgt während der CTP 50GB. Blobs werden über einen GET-Befehl zurück gelesen.

QueueStorage

Um Nachrichten zu speichern oder zu lesen, stehen einzelne Queues und Nachrichten als Objekte innerhalb der REST-APIs zur Verfügung. Einem Storage Account können beliebig viele Queues zugeordnet werden, für die Anzahl der Nachrichten innerhalb einer Queue gibt es ebenfalls keine Begrenzung. Eine Nachricht darf 8KB an Daten umfassen.

TableStorage

Der Zugriff auf TableStorage Einträge funktioniert über einen eindeutigen RowKey, der ein Element innerhalb einer Table eindeutig identifiziert. Der Zugriff wird hier über die Azure REST APIs sowie ADO.Net geregelt^[35].

6.3.3 Verteilung und Installation

Abbildung 12: Interne Struktur der Cloud

Da es sich bei Anwendungen auf Windows Azure Basis um Web-Anwendungen handelt, ist es nötig diese auf einem Server für die Benutzer zugänglich zu machen. Bei diesem Prozess handelt es sich im Windows Azure Framework, analog wie in bereits bekannten Web-Anwendungs-Frameworks um das sogenannte „deployen“. Bei Microsoft wird der Bereich, in welchen die Anwendung deployed werden, Fabrik-Controller genannt. Der Fabrik Controller abstrahiert die in der Cloud zur Verfügung stehenden Ressourcen und bietet dem Entwickler eine Schnittstelle zu diesen Ressourcen an. Innerhalb dieser Fabrik stehen verschiedene Funktionen zur Verfügung. Es werden die Ressourcen der Web Anwendung verwaltet, des weiteren stellt die Fabrik das so genannte Load-Balancing zur Verfügung. Das Nutzen dieser „Fabrik“ zur Administration der entwickelten Azure Anwendungen soll laut Microsoft auch dazu beitragen, Fehler in der Verfügbarkeit zu verringern und das Upgraden der Anwendung zu vereinfachen^[36].

6.3.3.1 Fault Domains

Microsoft selbst wirbt damit, das alle über Azure angebotenen Services, durch das Nutzen des Fabrik Controllers hoch verfügbar sind. So hat der Entwickler zum Beispiel die Möglichkeit ein Rollback auf vorherige Versionen durchzuführen. Desweiteren nutzt Microsoft sogenannte Fault Domains. Bei diesen Fault Domains handelt es sich um isolierte Rollen. Isoliert bedeutet, dass jede in der Web-Anwendung genutzte Rolle, redundant auf verschiedenen Servern zur Verfügung steht. Dadurch werden Ausfälle durch einen sogenannten Single Point of Failure, einen Ausfall durch einen Defekt an einem Server, verhindert^[37].

6.3.3.2 Update-Domains

Die gleiche Strategie verfolgt Mircosoft bei einem Update einer Azure Anwendung. Hier stehen so genannte Update Domains zur Verfügung. Sie sorgen dafür, dass die zu updatende Anwendung auch während des Updatevorgangs verfügbar ist^[38].

6.3.3.3 Fabrik

Die Fabrik stellt zwei Umgebungen für Anwendung zur Verfügung, die Production-Umgebung, die für externe Benutzer zugänglich ist und das Produktiv-System hosted, sowie die Staging-Umgebung. Der Begriff Staging oder Staging-Area ist bisher eher aus der Data Warehouse oder Datenbank Welt bekannt. Hier bezeichnet der Begriff eine Schicht, die dazu genutzt wird Daten zu sammeln, anschließend zu validieren oder konsolidieren und dann in die eigentliche Datenquelle zu transportieren. Im Azure Umfeld wird die Staging-Area dazu genutzt, Testversionen der Anwendung zu hosten und von dieser aus Updates am Produktiv-System durchzuführen. Sowohl die Produktiv- wie auch die Staging-Umgebung, sind über einen eigenen HTTP/HTTPS Endpunkt zu erreichen. Die Factory ermöglicht es, zu jeder Zeit, die Produktiv- gegen die Staging-Umgebung auszutauschen. In diesem Fall wird die DNS-Auflösung der beiden Endpunkte einfach getauscht^[39].

6.3.4 GeoLocation

Mit GeoLocation ist es für Entwickler möglich einen Standort der Rechenzentren und somit die Lage der Daten und der Services zu wählen. Dies hat mehrere Vorteile. Unter anderem spielt hier die Performance, sprich die Geschwindigkeit und auch der Netzwerk-Verkehr eine Rolle. Ebenfalls ist diese Option wichtig, um Regularien, die den Speicherort von Daten betreffen, zu erfüllen.^[40].

Derzeit sind zwei Rechenzentren von Microsoft in Betrieb. Eines befindet sich im Nord-Westen der USA und eines im Süden. Geplant sind weitere Standorte wie zum Beispiel Dublin und Amsterdam in Europa^[19].

Mit GeoLocations entsteht für Entwickler die Möglichkeit den Standort oder die Standorte der Rechenzentren zu wählen, auf denen Daten gespeichert beziehungsweise wo Dienste gehostet werden sollen. Das hat den Vorteil, dass die Netzwerklatenz, sprich die Performance, relativ gering gehalten werden kann, wenn die Daten in einem unmittelbaren Umkreis in einem Rechenzentrum liegen. So muss nicht erst ein entfernter Request geroutet werden und der Zugriff erfolgt schneller. Die weitere Möglichkeit, die mit der Wahl von GeoLocations hervorgerufen wird, ist Unternehmen zu gewinnen, die ihre Daten aufgrund von Regularien zum Beispiel in einem bestimmten Bereich halten müssen. Aber auch die andere Möglichkeit, die mit GeoLocations entsteht, Daten verteilt auf vielen Standorten zu halten, um die Sicherheit bei höherer Gewalt zu gewährleisten, ist denkbar. Somit kann auch die Datenhaltung über die Welt verteilt werden^[40].

Die Organisation der Daten geschieht mittels sogenannter Affinity Groups. Diese Gruppen können vom Benutzer beziehungsweise vom Entwickler erstellt werden und legen fest, welche Daten und Dienste zusammen gespeichert werden sollen und wo. Mit diesen Gruppen können Code und Daten so zentral wie möglich gehalten werden. Azure-Accounts, die sich in dieser Gruppe befinden werden als eine Einheit betrachtet und arbeiten zusammen. Erstellt man beispielsweise eine Gruppe im Norden von Amerika und trägt dort mehrere Storage-Accounts und Hosted-Services ein, so werden diese als ein Ganzes aus Netzwerksicht betrachtet und so eng wie möglich zusammen gelegt. Außerdem kann Microsoft mit Hilfe dieser Affinity Groups Informationen herausfiltern, um Entscheidungen darüber treffen, wie die Infrastruktur beziehungsweise die virtuellen Systeme für diese Anwendungen und Daten im Rechenzentrum ausgelegt werden müssen um Überlastungen zu vermeiden^[41].

6.4 Entwicklungsprozess

Im folgenden wird der während der Entwicklung von Windows Azure Applikationen zu beachtende Aspekte beschrieben. In den nächsten zwei Abschnitten wird auf die Möglichkeiten des Debuggings und des Loggings von Windows Azure Applikationen eingegangen. Abschnitt 6.4.3 erläutert die Prozessschritte, die nötig sind um eine Azure-Applikation bis zur Produktionsreife zu führen.

6.4.1 Debugging

Ein wesentlicher Bestandteil jedes Softwareentwicklungsprozesses ist das Beheben von Softwarefehlern.

Lokal

Wird die Applikation auf dem Entwicklersystem lokal in der Development Fabric gestartet, bestehen die gleichen Möglichkeiten des Debuggings, wie bei jeder anderen .NET Anwendung auch. Dies bedeutet, dass aus dem Visual Studio heraus Break-Points gesetzt werden können und alle Variableninhalte eingesehen werden können et cetera. Welche Möglichkeiten des Debuggings es bei der Benutzung anderer IDEs gibt, wurde während der Fallstudie nicht betrachtet. Eine Möglichkeit sich die Daten im lokalen Development Storage anzusehen, wie es beispielsweise bei der Benutzung eines DBMS wie dem Microsoft SQL-Server möglich ist, ist nicht direkt gegeben. Da der Development Storage aber via REST angesprochen wird, könnte aber theoretisch ein Werkzeug das diese Funktionalität bietet selber entwickelt werden.

In der Cloud

Applikationen welche bereits in der Cloud laufen, können nicht mehr durch das Visual Studio debuggt werden. Alle auftretenden Fehler müssen also, falls die Ursache nicht offensichtlich ist, in der lokalen Umgebung reproduziert werden, um den Fehler zu beheben. Dazu sollte bei Web-Roles, die nicht direkt Kunden zugänglich sind, immer eine aussagekräftige Fehlermeldung zusammen mit einem Stack-Trace ausgegeben werden. Dies kann jedoch ein mögliches Sicherheitsrisiko darstellen. Bei Kunden-Applikationen und Worker-Roles muss stattdessen rein aus den Log-Dateien der aufgetretene Fehler und dessen Ursache ermittelt werden.

6.4.2 Logging

Die Möglichkeit des Loggings ist bei Server-Applikationen ein wichtiger Aspekt, der deshalb kurz erläutert werden soll.

Der Quelltextauszug zeigt, wie einfach aus einer Role in die Logdatei geschrieben werden kann:

//erster Parameter bestimmt den Log-Level (u.a. Verbose, Information, Error)
//zweiter Parameter ist der Logbucheintrag als String
RoleManager.WriteToLog("Verbose", "Worker-Role gestartet");

Abbildung 13: Screenshot Development Fabric

Der RoleManager ist die zentrale Klasse jeder Worker- und Web-Role, mit der die Konfiguration gelesen werden kann oder wie im Beispiel gezeigt, ein Eintrag ins Log geschrieben werden kann. Sollen die in die Log-Dateien geschriebenen Einträge ausgewertet werden, so ist bei der Vorgehensweise zu unterscheiden, ob die Applikation in der Development Fabric oder in der Cloud gestartet wurde.

Lokal

Wird die Applikation in der Development Fabric gestartet, können dort direkt alle Log-Einträge nach Log-Level gefiltert angezeigt werden (siehe Abbildung 13). Besonders hilfreich ist es dabei, dass dies für jede gestartete Instanz einer Role separat getan werden kann.

In der Cloud

Um auf die Logdateien einer in der Cloud laufenden Applikation zuzugreifen, müssen diese dazu erst über einen Button im Azure Services Developer Portal in den Blob Storage kopiert werden. Den Blob-Storage kann man dann, z.B. mittels Powershell-Plugin als virtuelles Laufwerk einbinden, um auf die Dateien zuzugreifen^[42],[43].

Microsoft empfiehlt, dass wenn ein Objekt durch mehrere Roles nacheinander verarbeitet wird, diesem eine eindeutige ID mitgegeben wird und diese geloggt werden soll. So sollen das Auffinden der Ursache eines Problems erleichtert werden. Insbesondere in dem Fall, wo das Auftreten eines Fehlers und dessen Verursachung in unterschiedlichen Roles passiert^[44].

6.4.3 Schritte im Lebenszyklus einer Softwareversion

Abbildung 14: Die Entwicklungsstufen

Da der entwickelte Prototyp der zweiten Einschränkung nicht unterlag, wurde bei kleineren Änderungen nicht auf die Einhaltung aller Schritte bestanden. Diese wurden allerdings so konzipiert, dass sie auch bei einer gewünschten durchgehenden Erreichbarkareit der Applikation anwendbar sind und haben sich während der Fallstudie bei der Arbeit am Prototypen bewährt. Prinzipiell werden die Möglichkeiten des Debuggings von Stufe zu Stufe geringer, die Applikation nähert sich der produktiven Umgebung jedoch langsam an.

Entwicklungsstufe 1

Zu Beginn der Entwicklung wird die Applikation komplett lokal getestet. Dies betrifft sowohl die Software, die in der Development Fabric läuft, wie auch die Datenhaltung im Development Storage. Dadurch ist sie komplett von der bereits in Produktion befindlichen Version getrennt. Die Debugging Möglichkeiten sind lokal auch sehr umfangreich (siehe 6.4.1 Debugging).

Entwicklungsstufe 2

Die Veränderung von Entwicklungsstufe 1 zu 2 betrifft nur die Datenhaltung. Statt des lokalen Development Storage wird der Hosted Storage in der Cloud benutzt. Dadurch kann die Anwendung noch im gleichen Umfang debuggt werden. Es besteht die Möglichkeit diese Stufe zu teilen, um eine Sicherheitsstufe einzuführen. Anstatt der Daten der Produktivumgebung könnte eine Kopie dieser oder der vorher benutzten lokalen Testdaten in einem zweiten Hosted Storage Account erfolgen. Diese Vorgehensweise wurde innerhalb der Fallstudie nicht evaluiert.

Entwicklungsstufe 3

In Stufe 3 wird auch die Applikation in die Cloud geladen. Dies bedeutet, dass das Debugging nur noch über Log-Dateien möglich ist. Der Prozess des Hochladens eines Applikations-Paketes und dessen interne Verteilung in der Cloud bis zum Start dauert deutlich länger als lokal in der Development Fabric. Dazu muss er manuell durchgeführt werden. Zum Ende der Entwicklung des Prototypen dauerte dieser Prozess eine halbe Stunde (komplettes JDL integriert); anfangs ca. 15min. Der Schritt sollte also erst bei einem rechtausgereiften Softwarestand passieren. Die Applikation läuft jedoch schon quasi produktiv, da sich weder Laufzeitumgebung noch Daten oder die physikalische Umgebung von der Produktionsumgebung unterscheiden.

Entwicklungsstufe Produktion

Nachdem die in der Staging-Umgebung laufende Applikation ausreichend getestet wurde, kann mittels Klick auf einen Button im Azure Services Developer Portal die Produktionsumgebung mit der Stagingumgebung getauscht werden. Da dies intern nur durch das Ändern eines DNS-Eintrages passiert, gibt es während dieses Vorganges keine Einschränkung beim Zugriff auf die Anwendung. Greift ein Kunde genau während des Tausches auf die Applikation zu, wird ihm entweder noch die alte Version oder bereits die Neue angezeigt.

6.5 Angewandte Design-Prinzipien

In diesem Abschnitt sollen die während der Entwicklung des Prototypen angewandten Prinzipien des Software-Designs erläutert werden. Dabei geht es rein um Strategien, die benötigt wurden, um Problemen zu begegnen, die bei der Arbeit mit der Windows Azure Plattform auftraten und für diese spezifisch sind.

6.5.1 Skalierbarkeit

Die hohe Skalierbarkeit von Windows Azure Applikation entsteht dadurch, dass eine beliebige Anzahl von Instanzen einzelner Roles parallel gestartet werden kann, um Verarbeitungen durchzuführen oder Anfragen zu beantworten. Je nach aktueller Lastsituation kann die Anzahl von Instanzen einer beliebigen Role angepasst werden. Dazu gibt es zwei theoretische Möglichkeiten, die deklarative und die automatische Skalierung. Diese sollen im Folgenden kurz vorgestellt werden.

6.5.1.1 Deklarative Skalierung

Jede auf Azure lauffähige Applikation wird in einem Paket ausgeliefert, das eine XML Datei namens ServiceConfiguration.cscfg beinhaltet (siehe Abbildung 15).

Abbildung 15: Konfigurationsdatei: ServiceConfiguration.cscfg

In dieser Datei wird für jede im Paket enthaltene Role festgelegt, wieviele Instanzen gleichzeitig laufen sollen. Dazu dient das Attribut "count" des XML-Element Instances. Wird das Paket in die Staging- oder Production-Umgebung hochgeladen und gestartet, wird dieser Wert ausgelesen und anhand dessen die Anzahl der zu startenden Instanzen bestimmt. Die deklarative Skalierung legt also die Anzahl der Rollen für alle im Paket enthaltenen Rollen schon zur Entwicklungszeit fest. Um die Anzahl der Instanzen für eine Rolle, z.B. aufgrund von aktuellen Laständerungen zu steuern, gibt es zwei Möglichkeiten. Erstens kann die Konfigurationsdatei verändert und mit dem kompletten Paket erneut auf Azure hochgeladen werden. Dieser Ansatz sollte jedoch nicht gewählt werden, da der Umweg über die Staging-Umgebung genommen werden sollte, um die Applikation während des Vorgangs unterbrechungsfrei online zu halten. Zusätzlich kann das Hochladen größerer Pakete sehr lange dauern, da diese intern von Azure verteilt werden müssen. Die zweite Möglichkeit besteht darin die Konfigurationsdatei online zu editieren. Die Änderung wird von der Azure-Plattform interpretiert und die Anzahl der laufenden Roles daraufhin angepasst, ohne die Anwendung stoppen zu müssen. Beide Schritte sind momentan nur manuell durchführbar, was bedeutet, dass nicht auf sehr kurzfristige Lastspitzen reagiert werden kann. Wird die Anzahl der Roles jedoch von vorneherein recht hoch eingestellt und z.B. bei einem über die Zeit wachsenden Kundenaufkommen des Buchungssystems regelmäßig erhöht, ist diese Vorgehensweise ausreichend.

6.5.1.2 Automatische Skalierung

Das Anpassen einer Applikation an die aktuelle Lastsituation ohne vorheriges Festlegen der Anzahl von Rollen-Instanzen kann als automatische Skalierung bezeichnet werden. Da es bislang auf der Windows Azure Plattform keinerlei API gibt, welche es ermöglicht, programmgesteuert die Anzahl der Instanzen eine Role zu verändern, ist automatische Skalierung nicht möglich^[45]. Laut einem Microsoft-Mitarbeiter wird jedoch eine Management-API entwickelt, die dies ermöglichen soll^[46].

6.5.1.3 Umsetzungsmöglichkeit

Im folgenden wird kurz eine mögliche Umsetzungsvariante für manuelles oder automatisiertes Skalieren aufgezeigt. Dieser Ansatz wurde allerdings im Rahmen der Fallstudie nicht evaluiert.

Worker-Roles

Da Worker-Roles im Prototyp ausschließlich über Queues Arbeit zugewiesen wird, ist die Lastmessung einfach anhand der Queue-Einträge möglich. Wenn die Anzahl von Einträgen einen kritischen Wert übersteigt wird die Anzahl vorhandener Instanzen der Worker-Role erhöht. Der kritische Wert hängt dabei von der Funktionalität und in welcher Zeit die Bearbeitung eines Eintrages abgeschlossen sein sollte ab. Ist über einen bestimmten Zeitraum die Anzahl der Instanzen unter einem definierten zweiten Wert, so kann die Anzahl der Instanzen wieder reduziert werden. Die Anzahl der vorhandenen Queue-Einträge, also die Messung der aktuellen Last, kann in einer zusätzlichen Worker-Role implementiert werden. Sobald eine Management-API mit ausreichender Funktionalität bereitsteht, kann diese dann auch die Veränderung der Instanz-Anzahl übernehmen. Solange nur die deklarative Skalierung möglich ist, besteht die Möglichkeit eine Nachricht per Email an den zuständigen Administrator zu senden, der die Veränderung dann manuell vornimmt. Wird die deklarative Skalierung angewandt, sollten die Schritte, in welchen skaliert wird, und die kritischen Werte größer gewählt werden, da der manuelle Aufwand zu hoch wird. Dies gilt insbesondere für das Reduzieren der Instanz-Anzahl.

Web-Roles

Zum aktuellen Stand der CTP gibt es keine Möglichkeit die Auslastung von Web-Roles zu messen, außer durch Lasttests welche von außerhalb der Cloud ausgeführt werden. Da diese die Anwendung jedoch nur zusätzlich verlangsamen und dadurch Traffic Kosten verursachen, sollte davon abgesehen werden. Die Dimensionierung der Instanz-Anzahl muss also manuell erfolgen.

6.5.2 Nebenläufiger Storage Zugriff

Die Azure Queues, Blobs und Tables, sind vor nebenläufigen Zugriffen mithilfe eines E-Tags geschützt. Das E-Tag ist ein einzigartiger Bezeichner, der bei jedem lesenden Zugriff auf den Azure Storage mit an die Applikation zurückgeliefert wird. Bei jedem Schreibzugriff auf einen Datensatz im Azure Storage ändert sich das E-Tag. Will ein Prozess schreibend auf einen Eintrag im Azure Storage zurückgreifen, muss das E-Tag mitübergeben werden. Bevor die Schreiboperation durchgeführt wird, wird das übergebene E-Tag mit dem des Datensatzes verglichen. Nur wenn beide identisch sind, wird die Operation durchgeführt. Unterscheiden sich beide, hat bereits ein anderer Prozess den Datensatz verändert und es wird eine Exception geworfen. Es besteht jedoch die Möglichkeit diese Prüfung zu unterdrücken, um die Performance zu steigern^[47],[48].

6.5.3 Erwarten von Fehlern

Windows Azure besitzt intern eine hochverteilte Architektur um genügend Leistung und Ausfallsicherheit für große und skalierende Applikationen liefern zu können^[49]. Die Instanzen aller Roles einer Applikation laufen deswegen eventuell entfernt voneinander auf verschiedenen Rechnern. Es gibt mehrere Gründe, welche diese Architektur anfällig für Fehler machen. Beispielsweise kann das die einzelnen Instanzen und den Cloud Storage verbindende Netzwerk ausfallen. Es kann auch passieren, dass aus Lastverteilungsgründen, aufgrund eines Systemupdates oder einem lokalen Hardwaredefekt eine Instanz auf einem Rechner beendet und auf einem anderen neu gestartet wird. Dies führt dazu, dass die auf Windows Azure laufende Software sehr robust implementiert werden muss.

6.5.3.1 Startup-Status

Tritt in der Instanz einer Role ein Fehler auf oder fällt die Hardware aus, so wird diese, wenn möglich, neugestartet bzw. auf eine andere Hardware verteilt und dort neugestartet. Dies bedeutet für den Entwickler einer Role, dass er sicherstellen muss, dass diese bei Start alle notwendigen Konfigurationen selber beziehen kann oder bereits enthält. Bei einem möglichen zweiten Start einer Role-Instanz muss eventuell darauf geachtet werden, dass diese keine Daten der vorherigen überschreibt. Der Prototyp kam komplett ohne statusbehaftete Roles aus. Die einzelnen Roles bezogen ihre Konfiguration ausschließlich aus der Konfigurationsdatei ServiceConfiguration.cscfg.

6.5.3.2 Das Worker-Queue-Muster

Durch das Worker-Queue-Muster wird sichergestellt, dass jede Message einer Queue mindestens einmal und so oft wie nötig verarbeitet werden kann^[50]. Dies sei durch das folgende Pseudocode-Beispiel einer Worker-Role verdeutlicht:

A Buchungsanfrage von Queue holen
B Buchungsanfrage verarbeiten
C Buchungsanfrage von Queue entfernen

Wird eine Message, in diesem Fall die Buchungsanfrage, von einer Queue gelesen, so muss ein Timeout bestimmt werden, nachdem diese wieder sichtbar wird. Am konkreten Beispiel bedeutet dies, dass die Message nachdem sie in Zeile A aus der Queue gelesen wurde, für andere Prozesse unsichtbar ist. Dies gilt solange, bis das Timeout^[51] abgelaufen ist oder die Message in Zeile C aus der Queue entfernt wurde. Bricht die Verarbeitung z.B. durch einen Hardwaredefekt ab, so wird die Nachricht nach Ablauf des Timeouts wieder sichtbar und von einer anderen Instanz der Worker-Role erneut verarbeitet. Das Worker-Queue-Muster ermöglicht zusätzlich die Entkopplung der verschiedenen Roles sowie der Front- und Backend-Systeme. Desweiteren verbessert es die Skalierbarkeit von Applikationen^[52],[53].

6.5.3.3 Idempotente Worker-Roles

Microsoft empfiehlt Entwicklern, aufgrund der unter 6.5.3 beschriebenen Problematik, idempotente Worker-Roles zu implementieren^[54].

Idempotente Operationen

Idempotente Operationen können einmal oder mehrfach auf die gleichen Daten angewendet werden ohne dabei das Ergebnis zu verändern^[55]. Übertragen auf Worker-Roles bedeutet das, dass diese jede Message aus einer Queue beliebig oft bearbeiten können, ohne dass dadurch ungewollte Nebeneffekte oder Probleme auftreten.

Falls eine Worker-Role also idempotent implementiert wurde, ist es nicht relevant, ob eine Role-Instanz bei der Verarbeitung einer Queue-Message aufgrund eines Fehlers abbricht, sobald sichergestellt ist, dass die Message erneut verarbeitet wird. Im folgenden sollen erläutert werden, wie man eine Worker-Role idempotent implementiert. Dabei treten zwei grundsätzliche Arten von Problemen auf.

Einfaches Problem der Idempotenzumwandlung

Am Beispiel der Worker-Role des Prototypen, welche Neuigkeiten auf Twitter veröffentlicht, soll deutlich gemacht werden, wie man eine Worker-Role verändern muss, um sie idempotent zu machen. Zugunsten der Verständlichkeit wurde der Funktionalitätsumfang um die Prüfung der Buchung reduziert. Diese wird unter B als erfolgreich und bereits idempotent angenommen.

A  Buchungsanfrage von Queue holen
B  Buchung erfolgreich verarbeiten
C  Wenn Grenzwert nicht überschritten wurde =>E

D  Auf Twitter verbleibende Kartenanzahl veröffentlichen
E  Buchungsanfrage von Queue entfernen

A  Buchungsanfrage von Queue holen
B  Buchung erfolgreich verarbeiten
C  Wenn Grenzwert nicht überschritten wurde =>E
 a Wenn identische Meldung bereits auf Twitter vorhanden =>E
D  auf Twitter verbleibende Kartenanzahl veröffentlichen
E  Buchungsanfrage von Queue entfernen

Bricht die Verarbeitung der nicht idempotenten Anweisungsfolge nach Zeile D ab, so wird die Anfrage nocheinmal bearbeitet, da sie noch nicht aus der Queue entfernt wurde. Bei der zweiten Verarbeitung entsteht dann eine doppelte Neuigkeiten-Meldung auf Twitter. Durch das Hinzufügen der Prüfung in Zeile a wird dies verhindert. Die zweite Anweisungsfolge ist somit idempotent.

Komplexeres Problem der Idempotenzumwandlung

Die Umwandlung einer Worker-Role zu einer idempotenten ist komplexer, falls das Verarbeiten einer Nachricht zu einer Datenmanipulation führt, die nicht mehr nachprüfbar ist. Dieses Problem trit beispielsweise innerhalb der Prüfung von Buchungsanfragen auf. Bei der Lösung dieses Problems musste beachtet werden, dass nur das Update einer einzigen Zeile im Table-Storage atomar ist und keinerlei Transaktionen existieren^[56],[57]. Im Code-Beispiel wird zuerst geprüft, ob genug Karten verfügbar sind, um die Buchungsanfrage zu bedienen. Je nach Prüfungsergebnis wird die Anzahl der Karten um die gerade Verkauften reduziert. Auch in dieses Beispiel wurde der Verständlichkeit halber um weitere Schritte, wie dem Benachrichtigen des Kunden, reduziert.

A  Buchungsanfrage von Queue holen
B  Entsprechenden Artikel-Datensatz aus Table-Storage laden




C  Prüfen ob genug Artikel vorhanden sind
D  Datensatz veränden und in Table-Storage zurückschreiben



E  Buchungsanfrage von Queue entfernen

A   Buchungsanfrage von Queue holen
B   Entsprechenden Artikel-Datensatz aus Table-Storage laden
 a  Prüfen ob der Artikel nicht gesperrt ist =>C
 b  Wenn Artikel durch die aktuelle Buchungsanfrage gesperrt ist =>f
 c  Wenn der Artikel durch einee andere Buchungsanfrage gesperrt ist
    => Abbruch der Verarbeitung
C   Prüfen ob genug Artikel vorhanden sind
 d1 Anzahl der vorhandenen Artikel verringern
 d2 Artikel Datensatz-sperren
 d3 ID der aktuellen Buchungsanfrage in den Artikel-Datensatz schreiben
 d4 Veränderten Datensatz in Table-Storage zurückschreiben
E   Buchungsanfrage von Queue entfernen
 f  Table-Zeile entsperren

Wenn der Prozess zwischen Zeile D und E der nicht idempotenten Version abbricht, wird im nächsten Verarbeitungsschritt wiederholt die Anzahl der noch vorhandenen Veranstaltungskarten reduziert. Da anhand der Kartenanzahl auch nicht feststellbar ist, ob die Subtraktion schon vorgenommen wurde, kann die Anweisungsfolge nicht wie bei der Behebung des einfachen Problems verändert werden.

Das Problem kann nicht gelöst werden, indem die ID der Buchungsanfrage geloggt wird. Passiert dies beim Schreiben des veränderten Artikel-Datensatzes in einer zusätzlichen Spalte der Table-Zeile, ist dies eine atomare Aktion. Bricht der Prozess aber daraufhin ab, bevor die Anfrage aus der Queue entfernt wurde, kann bereits ein parallel laufender Prozess die Zeile verändert haben. In diesem Fall könnte wieder nicht festgestellt werden, ob die Anfrage bereits bearbeitet wurde. Wird die ID der Buchungsanfrage in einer zweiten Logging-Table gespeichert, so ist diese vor parallelen Zugriffen geschützt, der Zugriff geschieht aber nicht mehr atomar und löst deshalb das Problem nicht.

Um dieses Problem zu lösen, muss mithilfe des einzigen atomaren Storage-Zugriffs, dem Schreiben einer Table-Zeile, eine Transaktion implementiert werden. Nachdem die Prüfung in Zeile C erfolgreich war, werden neben der veränderten Anzahl Artikel zwei weitere Werte in einem atomaren Zugriff in die Table-Row geschrieben. Dieser Schreibzugriff wurde, der besseren Lesbarkeit halber, in die Code-Zeilen d1 bis d4 zerlegt. Um nach einem Abbruch des Prozesses die erneute Veränderung des Datensatzes zu verhindern, wird die ID der Buchungsanfrage mit in die Zeile geschrieben. Damit diese nicht von anderen parallelen Prozessen überschrieben werden kann, wird der Datensatz mithilfe eines Bitschalters gesperrt. Wenn nun eine Buchungsanfrage von einer Worker-Role aus der Queue geholt worden ist, wird geprüft, ob der entsprechende Artikel-Datensatz gesperrt ist (Zeile a). Ist er es nicht, fährt sie ganz normal fort. Wenn der Artikel bereits gesperrt ist, prüft sie, ob dies durch die aktuelle Buchungsanfrage geschehen ist. Ist dies nicht der Fall, wird die Verarbeitung abgebrochen; nachdem die Anfrage in der Queue wieder sichtbar ist, kann sie erneut versucht werden. Falls der Datensatz mit der ID der aktuellen Buchungsanfrage gesperrt ist, so muss nur noch die Buchungsanfrage aus der Queue gelöscht werden, da die Verarbeitung bereits stattgefunden hat.

Ein verbleibendes Problem ist es, dass eine Worker-Role bei der Verarbeitung einer Buchungsanfrage mit der ID X zwischen Zeile E und f abbricht. Die Buchungsanfrage ist bereits gelöscht, der entsprechende Artikel-Datensatz jedoch noch mit der ID X gesperrt. Dieser kann auch nicht mehr entsperrt werden, da dazu eine Worker-Role eine Buchungsanfrage mit der ID X bearbeiten müsste. Um auch dieses Problem zu lösen, kann folgendermaßen vorgegangen werden:

• Der RescueLock-Mechanismus: Der Lock-Bitschalter innerhalb eines Artikeldatensatzes wird durch einen Timestamp ersetzt. Dadurch können Worker-Roles gesperrte Artikeldatensätze selber entsperren, falls die Sperre älter als eine definierte Zeitspanne ist.
• Um diese Lösung weiter abzusichern, sendet die Worker-Role eine Nachricht an den Administrator, anstatt den Datensatz selbständig zu entsperren. Dieser kann den Datensatz überprüfen und dann manuell entsperren. Dieser Ansatz ist allerdings durch den hohen manuellen Aufwand in der Praxis nicht weiter relevant.

Durch den Transaktion-Mechanismus wird der Quellcode der Worker-Roles komplexer und schwerer zu lesen. Es ist für Entwickler auch leicht möglich Fehler zu machen, da die komplette Transaktions-Logik selber implementiert werden muss. Durch den RescueLock-Mechanismus ist die Transaktion trotzdem nicht vollständig sicher. Daher sollte der Einsatz dieses Musters nur wenn unbedingt notwendig erfolgen. Bei der Implementation des Prototypen konnte beispielsweise darauf verzichtet werden, da der Wert von einigen nicht verkauften Konzertkarten nicht hoch genug ist, diesen Aufwand zu rechtfertigen. Sobald die Datenkonsistenz jedoch wirtschaftlich bedeutender ist, sollte die Vorgehensweise in Betracht gezogen werden. Dies sollte z.B. bei dem Vertrieb von hochpreisigen Waren wie Autos erfolgen. Die Performance und Skalierbarkeit sollte jedoch nicht stark durch diesen Lösungsansatz beeinflusst werden. Dazu führen folgende Gründe:

• Eine Tabellenzeile ist nur für den Bearbeitungszeitraum zwischen den Zeilen d* und f für andere Prozesse gesperrt.
• Es findet pro Verarbeitung nur ein zusätzlicher Netzwerkzugriff auf den Azure Storage statt.

6.5.4 Software-Updates

Abbildung 16: Button zum Tausch von Staging- und Production-Umgebung im Azure Services Developer Portal

Dieser Abschnitt erläutert was bei der Softwareentwicklung beachtet werden muss, um eine neue Softwareversion im Betrieb zu veröffentlichen.

Da die Fehlersuche durch eine gleichzeitige Veränderung des Datenmodells und der Software erschwert wird, empfiehlt Microsoft Updates immer einzeln vorzunehmen. Dazu wird erst eine Softwareversion entwickelt, die sowohl mit dem alten wie auch dem neuen Datenmodell arbeiten kann. Anschließend wird das Datenmodell geändert^[58].

Da im Azure Table Storage kein festes Schema für eine Table existiert, ist es möglich verschiedene Datenobjekte in dieser abzulegen^[59]. Bei der Entwicklung des Prototypen waren beispielsweise anfangs nur Sitzplatzkarten für die Veranstaltung vorgesehen. Später wurde eine Erweiterung um Stehplatzkarten vorgenommen. Dies geschah in folgenden Schritten:

1. Änderung des Datenmodells
   1. Die Datenhaltungsklasse wurde um eine Variable für Stehplätze erweitert (siehe Tabelle 4).
   2. Die Webseite zum Anlegen einer Veranstaltung wurde angepasst, sodass Datensätze der neuen Datenhaltungsklasse angelegt werden und das neue Feld gefüllt wird.
2. Die neue Version wurde in die Staging-Umgebung geladen.
3. Die Staging und Production-Umgebung wurden getauscht.

Zu diesem Zeitpunkt konnten schon Datensätze der aktuellen Version angelegt werden. Die Datenbindung an den TableStorage ist durch die Microsoft-Bibliotheken so implementiert, dass nicht bekannte Felder von der Anwendung ignoriert werden (Stehplätze) und nicht vorhandene Felder bei der Datenabfrage mit null gefüllt werden. Für die Webseiten, welche die neue Version des Datenmodells noch nicht kennen, existiert das zusätzliche Attribut noch nicht. Es können also noch keine Kunden Stehplätze buchen, auch wenn bereits welche hinterlegt wurden^[60]. Falls ein Fehler auf der Seite zum Neuanlegen von Veranstaltungsdatensätzen auftritt, können die Staging- und Produktion-Umgebungen zurückgetauscht werden. Im nächsten Schritt wird die komplette Logik des Buchungssystems umgestellt, um die zusätzliche Funktionalität bieten zu können:

1. Änderung der Software
   1. Die Webseiten zur Buchung und Anzeige der Veranstaltungen wurden erweitert, sodass sie das zusätzliche Feld anzeigen.
   2. Die Logik der Worker Roles wurde erweitert, sodass sie die Verfügbarkeit der Stehplätze prüft und diese bebuchen kann.
2. Die neue Version wurde in die Staging-Umgebung geladen.
3. Die Staging und Production-Umgebung wurden getauscht.

Tritt durch diese neue Softwareversion ein Fehler auf, können die Staging- und Produktion-Umgebungen wiederum zurückgetauscht werden. Hierdurch folgt, dass diese kleinschrittige Vorgehensweise eine zusätzliche Sicherheitsebene in den Softwareentwicklungsprozess einzieht.

Title|Seats|Date

Title|Seats|StandingRoom|Date

Versionierung

Um dieses Problem auch in komplexeren Situationen zu lösen, bietet es sich an, zusätzlich eine Versionsnummer in das Datenmodell zu integrieren. So kann eine Softwareversion durch eine Fallunterscheidung ermitteln, wie sie mit welchen Datensätzen umgehen muss. Nach einer vollständigen Datenmigration kann diese Fallunterscheidung dann wieder entfernt werden^[61].

Performancebetrachtung Versionierung

Die Versionsnummer, sollte immer in den PartitionKey oder zumindest RowKey einer Tabellenzeile integriert werden. Ein gleicher PartitionKey sorgt für die Speicherung im gleichen Cluster in der Cloud, wodurch die Zugriffe auf mehrere Daten einer Version nicht verteilt stattfinden müssen. Der RowKey ist der einzige Teil eines Table-Storage-Eintrages, auf den ein Index abgelegt ist. Wird eine Versionsnummer außerhalb des RowKeys abgelegt, so müssten somit bei der Suche nach allen Datensätzen einer Versionsnummer intern alle Datensätze der Table durchsucht werden^[62].

7 Reflexion/Evaluierung der Umsetzungsansätze

7.1 Softwareunterstützung bei der Entwicklung

7.1.1 Entwicklungsumgebung

Zur Entwicklung von Applikationen kann das .NET-Entwicklern vertraute Visual-Studio mit sämtlichen Tools weiterbenutzt werden. Dazu wird zum Stand der aktuellen CTP das Visual-Studio 2008 um Templates und einige neue Funktionen erweitert. Diese sollen im noch nicht erschienenen Visual Studio 2010 schon integriert sein^[63]. Alle Tools, welche zur Entwicklung einer Azure-Anwendung notwendig sind, sind jedoch Konsolen-Programme, welche komplett ohne das Visual Studio lauffähig sind. Microsoft hat auf der PDC08 angekündigt, intern bereits eine Plugin-Version für die OpenSource Entwicklungsumgebung Eclipse fertiggestellt zu haben. Es wurden jedoch keine Angaben über eine eventuelle Veröffentlichung dieser Software gemacht. Dies zeigt jedoch die prinzipielle Wahlfreiheit bei der Entwicklungsumgebung^[64]. Während der Implementation des Prototypen wurde der Java Quelltext in Eclipse und der C# Quelltext in Visual Studio 2008 entwickelt. Diese Vorgehensweise hat sich während der Fallstudie als unproblematisch und durch die gute Softwareunterstützung als produktiv herausgestellt.

7.1.2 Zugriff auf Cloud Storage

Zur Vereinfachung des Zugriffs auf den Cloud-Storage von der .NET Umgebung aus, stellt Microsoft die Bibliothek StorageClient.dll zur Verfügung. Diese kapselt den Zugriff via REST und liefert direkt Objekte des gespeicherten Typs zurück. Die Bibliothek vereinfacht auch einige weitere Aspekte des Datenzugriffs. So wird z.B. bei einem Zugriff auf den TableStorage immer nur ein Teil der Ergebnisse geliefert, um die HTTP-Antworten kurz zu halten^[65]. Der nächste Datenblock kann manuell mittels eines continuation-token abgerufen werden. Benutzt man die Bibliothek nicht, so muss man bei der Entwicklung selber für die Einhaltung dieser Logik sorgen^[66]. Für die Entwicklung in Java stehen bisher keine fertigen Bibliotheken zur Verfügung, sodass der Aufwand bei der Entwicklung etwas höher ist.

7.1.3 Administration des Storage in der Cloud

Um sich die Daten in einem der drei Cloud-Storage Bereiche Blob-, Table- oder Queue-Storage anzusehen oder die enthaltenen Einträge verändern und modifizieren zu können, stellt Microsoft ein Plugin für die Microsoft Powershell-Shell zur Verfügung. Mit diesem ist es unter Windows möglich einen Blob-Storage-Account als virtuelles Festplattenlaufwerk zu mappen. Danach kann auf diesen zugegriffen werden, um BlobStorage-Einträge zu löschen oder neu anzulegen. Microsoft stellt keine weitergehenden Werkzeuge zur Administration des Storage zur Verfügung. Mittlerweile gibt es allerdings Tools von Drittanbietern, wie z.B. den kostenlosen Azure-Storage-Explorer, der Einträge aller drei Speicherarten anzeigen kann. Mit Hilfe dieser Tools ist es auch möglich Einträge in Queues, Tables und Blobs anzulegen, sowie zu editieren, was eine wesentliche Erleichterung während der Entwicklung und des Debuggings darstellt^[67].

7.2 Möglichkeiten zur Integration in die Unternehmensumgebung

Nicht immer ist es möglich bestehende Applikationen komplett abzulösen, um von den Möglichkeiten einer Cloud Computing Plattform zu profitieren. Gründe dafür können deren Komplexität oder bereits getätigte Investitionen sein. Im folgenden wird ein Überblick darüber gegeben, wie eine mögliche Integration bestehender Systemen mit Windows-Azure funktionieren könnte. Dabei wird von einer Drei-Schichtentrennung der Systeme ausgegangen.

Anbindung bestehender Systeme

Grundsätzlich kann ein Teil der bestehenden Applikation durch eine Neuentwicklung, welche in der Cloud läuft, ersetzt werden, falls das bestehende System in der Lage ist, per HTTP oder HTTPS zu kommunizieren. Das gilt auch für die Datenhaltung, welche auf der Azure Plattform neu entwickelt und dann per HTTPS angebunden werden kann. Eventuell lässt sich aber auch die Neuentwicklung eines Teils umgehen und die bestehende Anwendung direkt auf der Azure Plattform hosten. Dort können prinzipiell alle Anwendungen laufen, die auch unter Windows laufen. Dafür gelten zwei Einschränkungen. Erstens müssen diese ohne Installation lauffähig sein, da sie in einem Paket mit einer Worker-Role hochgeladen und dann gekapselt in dieser gestartet werden. Zweitens dürfen keine Administrator-Berechtigungen zu ihrem Start notwendig sein.^[68] Dieser Ansatz wurde während der Entwicklung der Fallstudie erfolgreich evaluiert (siehe 6.2.3.2 Mailversand).

.NET

Bestehende .NET-Systeme können schichtenweise auf die Azure-Plattform migriert werden. Eine in ASP.NET implementierte Präsentationsschicht und eine mittels .NET-Sprachen implementierte Anwendungsschicht können direkt auf der Azure-Plattform laufen. Externe binäre DLLs können dabei einfach mit in das hochzuladende Paket integriert werden. Die notwendigen Änderungen für diese beiden Schichten besteht also nur darin die ASP-Seiten in eine Web-Role einzufügen und, um die Skalierbarkeit der Azure-Plattform auszunutzen, Teile der Logik in Worker-Roles auszulagern. Die Datenhaltungsschicht kann nur dann weiterbenutzt werden, wenn die Datenquelle bereits über HTTP/HTTPS angesprochen wird. Dies ist wahrscheinlich selten der Fall. Soll die Storage Lösung der Azure Plattform benutzt werden, so ist ein großer Aufwand wahrscheinlich.

Java EE

Die Windows Azure Plattform ist momentan nicht für den Betrieb von Java Enterprise Systemen zu empfehlen. Da die Hosted Services nicht direkt einen Applikationsserver für Java zur Verfügung stellen, müsste dieser mitsamt einem JRE, wie das Java Programm, welches im Prototypen für den Mailversandt sorgt, in das Applikations-Paket integriert werden^[69]. Dies würde bedeuten, dass für jede kleine Konfigurationsänderung der komplette Applikationsserver neu in die Cloud geladen werden müsste. Auch der Zugriff auf dessen Management- und Monitoring-Funktionen wäre nicht möglich. Da pro Worker-Role-Instanz ein Applikationsserver gestartet werden würde, könnte dies eventuell Auswirkungen auf die Performance der Java-Anwendung haben. Desweiteren müsste eventuell die Funktionsweise angepasst werden, damit verschiedene Applikationsserver auf die gleichen Daten zugreifen können. Bestehende Java EE Applikationen sollten also nur Dienste der Azure Plattform benutzen, aber nicht selber auf diese migriert werden.

7.2.1 Möglichkeiten bei Neuentwicklungen

7.2.1.1 Sprachwahl

Da es sich bei Windows Azure um eine Komponente des .NET Frameworks handelt, eignen sich zunächst alle Programmiersprachen, die Microsofts Visual Studio unterstützt. Dabei handelt es sich um die Microsoft .NET Programmiersprachen. Die wichtigsten .NET Programmiersprachen sind: C++.NET, C#.NET, VB.NET. Microsoft gibt jedoch auch an, dass sich außer den proprietären Techniken auch Programmiersprachen und Werkzeuge von Drittherstellern einsetzen lassen. Microsoft führt hier immer wieder Eclipse als IDE eines Drittherstellers, sowie Ruby, Python und PHP als Programmiersprachen außerhalb des .NET-Frameworks als Beispiele an^[70].

Interoperabilität

Möglich wird diese hohe Interoperabilität dadurch, dass Microsoft innerhalb von Azure Branchenstandards wie XML, REST und SOAP für die Schnittstellen einsetzt. Durch diese einheitlichen Techniken ist es auch aus anderen Programmiersprachen und Plattformen heraus möglich, Windows Azure Services zu nutzen und in den Webservices zu implementieren^[71].

PHP

So gibt es zum Beispiel das PHP SDK für Windows Azure. Das PHP SDK beinhaltet PHP Klassen für den Zugriff auf Funktionen wie Azure Blobs, Queues und Tables. Zudem werden Hilfsklassen für die Authorisierung, Authentifizierung sowie der Fehlerbehandlung HTTP-basierter Aufrufe bereitgestellt^[72].

JAVA

Ähnliche SDK's finden sich bereits für JAVA und für Ruby. Für JAVA ist das jdotnetservices SDK erhältlich. Die Entwickler dieser OpenSource Lösung haben das SDK mit den zugehörigen Bibliotheken, Werkzeugen, Mustern und Anleitungen entwickelt, damit JAVA Entwickler die Vorteile der .NET-Services sowie der Microsoft Cloud Computing Plattform für ihre JAVA Anwendungen nutzen können. Die jdotnetservices bieten die Möglichkeit per SOAP oder per REST mit den .NET Services zu kommunizieren^[73].

RUBY

Für Ruby ist ".NET-Services für Ruby" erhältlich. Hier ist der Gedanke sehr ähnlich zu den jdotnetservices in JAVA. Ruby Entwickler sollen ebenfalls mit Hilfe des SDKs auf .NET Services und Azure zurückgreifen, um ihre Anwendungen zu erweitern und um ihre Produktivität zu erhöhen. Im Gegensatz zu den jdotnetservices unterstützen die .NET Services für Ruby jedoch kein SOAP, sondern kommunizieren ausschließlich per REST über das HTTP-Protokoll mit den .NET Services ^[74].

7.2.1.2 Skalierbarkeit

Wenn eine neue Applikation entwickelt werden soll, die durch starke Zugriffsschwankungen oder aufgrund einer zeitlich starken Veränderung der Last in der Lage sein muss sehr gut zu skalieren, bietet es sich deshalb an für diese die Windows Azure Platform zu wählen. Beim Entwurf einer gut skalierenden Applikation muss erstens die Infrastruktur auf Skalierbarkeit ausgelegt sein. Zweitens muss auch die Geschäftslogik darauf angepasst implementiert werden, um die Möglichkeiten der Infrastruktur auszureizen. Wird die komplette Windows Azure Plattform benutzt, also Web- und Worker-Roles sowie Azure Storage, ist nicht nur die Infrastruktur gegeben, welche extrem hoch skalierbare Anwendungen unterstützt. Durch die schon vorab vorgenommene Strukturierung in die eben genannten Rollen ist auch ein Grundgerüst für das Design der Geschäftslogik gegeben. Ein Entwickler muss noch immer darauf achten diese richtig zu teilen, um die einzelnen Teile separat skalieren zu können. So könnte z.B. von einem Entwickler die komplette Logik des Buchungsprozesses in einer Web-Role hinterlegt werden. Werden viele Instanzen dieser gestartet, ist die gesamte Rechenleistung des Buchungssystems genauso hoch, als wenn der Buchungsprozess, wie in Abschnitt 6.2 beschrieben, sinnvoll in mehrere Roles geteilt worden wäre. Der Kunde würde jedoch viel länger auf eine Rückmeldung des Systems warten, da seine Anfrage erst nach Abschluss des kompletten Vorgangs vom Server beantwortet wird, anstatt an eine Queue übergeben zu werden. Dieses Beispiel zeigt, dass auch eine Plattform, die von vorneherein auf Skalierbarkeit angelegt wurde, durch falsches Software-Design ihre Stärken verliert. Die Azure Plattform bietet Entwicklern jedoch durch vorhandene Templates für Web- und Worker-Roles und einer fertigen Implementierung von Queues eine Abstraktionsebene, auf der er sich darauf konzentrieren kann diese Bausteine zur Modellierung seiner Geschäftslogik einzusetzen, ohne sich um die darunter liegenden Prinzipien kümmern zu müssen. Während der Fallstudie hat sich herausgestellt, dass die Aufteilung des Buchungsprozesses in mehrere Prozesse mit einem geringen Mehraufwand machbar war. In realen Softwaresystemen kann also auch im Nachhinein leicht ein Prozess gesplittet werden, um die einzelnen Teile getrennt skalieren zu lassen.

8 Ausblick

Alle Ergebnisse dieser Arbeit stellen den aktuellen Stand der CTP dar. Es ist somit leicht möglich, dass bis zum offiziellen Start der Plattform noch einige Änderungen und Erweiterungen seitens Microsoft durchgenommen werden.

Problematisch ist zum derzeitigen Zeitpunkt die Verfügbarkeit von neutralen Informationen bezüglich Microsoft Azure. Deshalb war die Wahl der wissenschaftlichen Methode des Prototypings eine gute Wahl, um das Zusammenspiel der Technologien zu verifizieren. Die rege Veröffentlichung von Artikeln in Entwickler-Blogs leistete dabei eine gute Hilfe und zeigt, dass die Plattform von diesen positiv angenommen bzw. deren Veröffentlichung zumindest erwartet wird.

Die Implementierung des Prototyps ist erfolgreich verlaufen, da alle zu Beginn der Fallstudie festgelegten Anwendungsfälle auf der Azure-Plattform abgebildet werden konnten. Bei der Implementierung konnte ein gründlicher Einblick in viele mit der Plattform in Zusammenhang stehender Technologien genommen werden. Besonders auf das Testen der Interoperabilität mit anderen Programmiersprachen am Beispiel von Java wurde im Prototypen erfolgreich verifiziert. Bei dabei aufgetretenen Problemen wurden Muster-Lösungen erarbeitet, die Entwicklern eine Hilfe bei der Entwicklung von Microsoft Azure-Applikationen bieten. So wurde ein Ansatz geschaffen, um idempotente Roles zu implementieren und die grobe Version eines Entwicklungsprozess erarbeitet.

Auch wenn im Funktionsumfang der Microsoft Cloud Plattform noch einige Lücken sind, die essentiell sind, um Unternehmensanwendungen zu betreiben, so macht die Lösung einen guten Gesamteindruck und läuft stabil. Lücken gibt es z.B. bei der Unterstützung von Transaktionen und einer API, um eine automatisierte Skalierung zu implementieren. Erstere soll durch die SQL-Services geschlossen werden; letztere ist bereits angekündigt. Microsoft dürfte somit nach einigen Nachbesserungen am Ende des Jahres in der Lage sein, ein Produkt auszuliefern, dass dem Bedürfnis der Entwickler entspricht, dem Cloud Computing Trend zu folgen.

Nachdem in dieser Arbeit ein Überblick über die technologischen Aspekte geschaffen wurde, bieten sich zwei Bereiche besonders für weitere Forschung an. Als wichtiges Entscheidungskriterium, über die technische Machbarkeit hinaus, müssen die wirtschaftlichen Aspekte der Microsoft Cloud Plattform untersucht werden^[75]. Zweitens sollte, sobald die Plattform den Stand der CTP verlassen hat, durch eine Performancemessung die versprochene Skalierbarkeit geprüft werden.

9 Fußnoten

1. ↑ Vgl. Gartner (2009)
2. ↑ Vgl. Gartner (2008)
3. ↑ ^{3,0 3,1} Vgl. Guertler et al. (2009), 00:03h
4. ↑ ^{4,0 4,1} Vgl. Miller (2008), Seite 8f.
5. ↑ ^{5,0 5,1 5,2} Vgl. Miller (2008), Seite 16
6. ↑ ^{6,0 6,1 6,2 6,3} Vgl. Sirtl (2008), 00:05h
7. ↑ ^{7,0 7,1 7,2} Vgl. Fischer (2008a), 00:24h
8. ↑ Vgl. Miller (2008), Seite 17
9. ↑ ^{9,0 9,1 9,2 9,3} Vgl. Sirtl (2009b)
10. ↑ ^{10,0 10,1 10,2 10,3} Vgl. Guertler et al. (2009), 00:01h
11. ↑ Vgl. Sirtl (2009a), Kap. 1 Seite 10
12. ↑ ^{12,0 12,1 12,2 12,3 12,4} Vgl. Guertler et al. (2009), 00:15h
13. ↑ Vgl. Sirtl (2008), 00:02h
14. ↑ ^{14,0 14,1 14,2} Vgl. Sirtl (2008) 00:12h
15. ↑ Vgl. Sirtl (2008) 00:15h
16. ↑ ^{16,0 16,1} Vgl. Fischer (2008a) 00:18h
17. ↑ Vgl. Sirtl (2008) 00:03h
18. ↑ Vgl. Sirtl (2008) 00:04h
19. ↑ ^{19,0 19,1} Vgl. Sirtl (2008), 00:09h
20. ↑ Vgl. Sirtl (2008), 00:06h
21. ↑ Vgl. Fischer (2008a), 00:29h
22. ↑ Vgl. Guertler et al. (2009), 00:24h
23. ↑ Vgl. Sirtl (2009a), Kap. 2 Seite 7
24. ↑ Vgl. Fischer (2008a), 00:27h
25. ↑ Vgl. Calder (2008)
26. ↑ ^{26,0 26,1} Vgl. Microsoft (2009j)
27. ↑ Vgl. Sirtl (2009a), Kap. 2 Seite 21
28. ↑ Vgl. Parys (2008b), 00:09h
29. ↑ ^{29,0 29,1 29,2 29,3} Vgl. Microsoft (2009f)
30. ↑ Vgl. Microsoft (2009g)
31. ↑ Vgl. Parys (2008a)
32. ↑ Vgl. Trennhaus(2004) S.19-22
33. ↑ Vgl. Goodman (2007) S.98-99
34. ↑ Vgl. Reinheimer(2006) S.98
35. ↑ Vgl. Microsoft(2009b)
36. ↑ Vgl. Microsoft (2008c)
37. ↑ Vgl. Microsoft (2009c)
38. ↑ Vgl. Microsoft (2009d)
39. ↑ Vgl. Smith et al. (2008) 0:06h
40. ↑ ^{40,0 40,1} Vgl. Krishnan (2009)
41. ↑ Vgl. Microsoft (2009h)
42. ↑ Vgl. Nakashima (2008)
43. ↑ Vgl. Day (2008)
44. ↑ Vgl. Krishnan (2008) 0:45h
45. ↑ Vgl. Marx (2008b) 1:06h
46. ↑ Vgl. Gershaft(2008)
47. ↑ Vgl. Microsoft (2008a) S. 11ff
48. ↑ Vgl. Nilakantan et al. (2008) 0:55h
49. ↑ Vgl. Smith et al. (2008) 0:14h
50. ↑ Vgl. Khalidi (2008) 0:09h
51. ↑ Das Default-Timeout beträgt 30 Sekunden
52. ↑ Vgl. Microsoft (2008b)
53. ↑ Vgl. Stelting et al. (2002)
54. ↑ Vgl. Microsoft (2008b)
55. ↑ Vgl. Richardson et al. (2007)
56. ↑ Vgl. Nilakantan et al. (2008) 1:02h
57. ↑ Das ist nur der Vereinfachung halber richtig, es sind auch Transaktionen zwischen mehreren Table-Zeilen atomar, wenn diese den gleichen PartitionKey besitzen; Dies ist irrelevant, da Transaktionen mit Queues oder Blobs trotzdem nicht möglich sind.
58. ↑ Vgl. Krishnan (2008) 0:28h
59. ↑ Vgl. Microsoft (2008a)
60. ↑ Vgl. Marx (2008a)
61. ↑ Vgl. Krishnan (2008) 0:30h
62. ↑ Vgl. Nilakantan et al. (2008) 0:05h
63. ↑ Vgl. Microsoft (2009a)
64. ↑ Vgl. Marx (2008b) 0:10h
65. ↑ Vgl. Nilakantan et al. (2008) 1:00h
66. ↑ Vgl. Microsoft (2008a)
67. ↑ Vgl. ASE (2009)
68. ↑ Vgl. Marx (2009a)
69. ↑ Vgl. Marx (2009b)
70. ↑ Vgl. Microsoft (2009e)
71. ↑ Vgl. Microsoft (2009i)
72. ↑ Vgl. PHPSDK (2009)
73. ↑ Vgl. Schakra (2008)
74. ↑ Vgl. Thought Works (2008)
75. ↑ Microsoft hat bislang noch keine Angaben zu den Kosten für die Nutzung der Plattform gemacht.

10 Literatur- und Quellenverzeichnis