„Dieser Blog Post ist Teil der Serie „Cloud Computing mit Windows Azure“, alle bisher erschienenen Artikel finden Sie im ersten Posting der Serie!“
Mit dem Windows Azure SDK kann man Anwendungen für Windows Azure entwickeln. Hierfür gibt es verschiedene Anwendungstypen, welche erstellt werden können. Will man Windows Azure Anwendungen in Visual Studio erstellen, so müssen die Windows Azure Tools for Visual Studio installiert sein.
Mit dem SDK kommen auch verschiedene Tools mit. Diese sind die Development Fabric und die Development Storage. Erstere ist für das verwalten der Rollen zuständig und simuliert eine Windows Azure Umgebung am lokalen Rechner. Mit der Development Fabric kann man die eigenen Anwendungen debuggen bevor man diese live schaltet. Die Development Storage ist nun für das speichern der Daten zuständig. Wenn wir uns zurück errinnern, gibt es drei verschiedene Möglichkeiten: Blobs, Tables und Queues.
Für den Development Account ist eine SQL Server oder SQL Server Express Installation notwendig. Windows Azure erfordert eine Anmeldung am Storage Account. Hierfür ist der Account Name und der Account Key für den Windows Azure Development Storage Account notwendig. Diese sind:
Account name: devstoreaccount1
Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
Für jede mögliche Speicherart (Blob, Queue, Tabelle) gibt es nun einen gewissen Endpunkt. Dies ist eine URI in einem definierten Format. Zu Beginn kommt entweder http oder https, gefolgt von dem Kontonamen und dem Servicenamen. Danach kommt „.core.windows.net/“ gefolgt von dem Ressourcen-Pfad.
Einfach dargestellt sieht dies folgendermaßen aus:
<http|https>://<accountname>.<servicename>.core.windows.net/<ressourcenpfad>
Hierbei ist der „accountname“ der Name des eigenen Services, „servicename“ entweder „blob“, „queue“ oder „table“. Der Ressourcenpfad ist auch wieder unterschiedlich, je nach Verwendungszweck.
Bei einem Fotoalbum könnte das folgendermaßen aussehen:
http://photostore.blob.core.windows.net/brasil/carnaval.jpg
Diese Endpunkte müssen wir für die Development Storage jedoch nicht per Hand eingeben. Im nächsten Posting werden wir sehen wie das einfach konfiguriert werden kann.
Wenn man nun ein neues Windows Azure Service erstellt und dieses startet, so werden die Development Fabric und Development Storage gestartet.
Im Systray wird nun ein bläuliches Windows Zeichen angezeigt, mit wessen Hilfe man zu den Management Tools der Storage und Fabric kommt.
In der Development Storage kann man die einzelnen Services deaktivieren, neustarten oder beenden.
In der Development Fabric UI hat man die Möglichkeit, die einzelnen Rollen zu überwachen.
Das SDK ist nun in drei Hauptbereiche gegliedert:
Diagnostics kümmert sich hierbei um die Rollendiagnose. Dies ist vor allem bei Abstürzen, Memory Leaks und so weiter wichtig. Hierfür gibt es zwei wichtige Namespaces: Microsoft.WindowsAzure.Diagnostics und Microsoft.WindowsAzure.Diagnostics.Management.
Im Namespace „Microsoft.WindowsAzure“ befinden sich allgemeine Klassen für den Storage Account und die Credentials (welche für die Verbindung notwendig sind).
Storage deckt im SDK die Blobs, Tabellen und Queues ab. Hierfür sind zwei Namespaces wichtig: Microsoft.WindowsAzure.StorageClient und Microsoft.WindowsAzure.StorageClient.Protocol.
ServiceRuntime ist nun für die Rollen und die Umgebung dessen zuständig. Hier befinden sich Klassen wie „RoleEntryPoint“ und „RoleEnvironment“.
Nun sind auch die wichtigsten Grundlagen für die Arbeit mit dem Client geklärt und wir können uns im nächsten Post !!!ENDLICH!!! an den Quellcode wagen :)
Mario Meir-Huber
Web: www.meirhuber.de
Twitter: www.twitter.com/mario_mh
