Dieser Artikel ist Tag #17 der Serie 31 Tage Mango von Jeff Blankenburg.
Der Originalartikel befindet sich hier: Day #17: Using Windows Azure.
Dieser Artikel wurde in der Originalserie von Gastautor Michael Collier geschrieben. Bei Twitter kann Michael unter @michaelcollier erreicht werden.
Windows Phone + Windows Azure = ein starkes Team
Einige der interessantesten Windows Phone Anwendungen nutzen Services der ein oder anderen Art. Solche Services könnten z.B. Webservices sein, die Zugriff auf eine Geschäftslogik bieten — so wie wir das auch mit traditionellen ASP.NET Anwendungen machen würden. Es könnten aber auch Datenservices sein, die Zugriff auf strukturierte oder unstrukturierte Daten bieten. Oder es könnten Identitätsdienste sein, welche die Authentifizierung für unsere Anwendung übernehmen.
Bisheriger Ansatz
Typischerweise stellen wir einen oder mehrere Server auf und stellen dann unsere Services oder Daten dort bereit. Das kann relativ teuer sein — sowohl in Bezug auf Geld als auch was den Zeitaufwand betrifft. Wir müssen Zeit darauf verwenden, die Server zu installieren, sie zu konfigurieren und zu sichern. Während des Betriebs müssen wir uns weiterhin um die Wartung kümmern (Hardwareausfälle, Systemupdates, etc.). Auch die Vorhersage, wie viele und was für Server wir brauchen, ist nicht gerade einfach. Kaufen wir zu viel, haben wir Geld verschwendet. Kaufen wir zu wenig, werden die Kunden (und die Chefs) auch nicht begeistert sein. Alle diese Faktoren zwingen uns als Anwendungsentwickler, uns mit Infrastrukturfragen auseinanderzusetzen, wo wir doch viel besser die nächste Killeranwendung entwickeln könnten.
Moderner Ansatz
Ein aktueller Trend ist, in der Cloud bereitgestellte Services (wohlgemerkt „Services“ und nicht „Server“) zu nutzen. Die Plattform Windows Azure stellt Compute Services zur Verfügung, die wir zur Bereitstellung unserer Webservices nutzen können. Wir schreiben nur noch die Anwendung und stellen diese bereit. Den Rest überlassen wir Windows Azure. Windows Azure bietet weiterhin Zugriff auf hochverfügbare und skalierbare Speicherdienste in der Form von Tabellen, Blobs und Queues („Warteschlangen“).
- Tabellen sind ein semi-strukturierter Speichermechanismus, der in der Lage ist, riesige Datenmengen zu verwalten (denken Sie dabei an NoSQL, nicht an eine relationale Datenbank).
- Blobs verhalten sich im Wesentlichen wie ein riesiges Dateisystem. Hier können Sie ablegen, was immer Sie wollen (Bilder, Filme, Dokumente, etc.).
- Queues sind ein leichtgewichtiger Mechanismus, um Nachrichten zwischen nicht gekoppelten Systemen auszutauschen.
Windows Azure bietet zusätzlich einen Identitäsverwaltungsdienst, die Access Control Services (ACS), die eine einfache Möglichkeit bieten, Nutzer über verschiedene Identitätsprovider zu authentifizieren. ACS ist so vorkonfiguriert, dass es mit den großen sozialen Netzwerken, wie Facebook, Yahoo!, Windows Live ID und Google, funktioniert. ACS kann auch verwendet werden, um die Identitätsverwaltung eines Unternehmens über Active Directory Federation Services (ADFSv2) zu realisieren. ACS ist besonders für mobile Anwendungen geeignet, da die Anwender solcher Anwendungen meist schon ein Profil bei einem der Dienste haben. Windows Phone Benutzer haben z.B. schon eine Windows Live ID.
Es gibt zahlreiche Vorteile durch die Verwendung einer Plattform wie Windows Azure bei der Entwicklung einer Windows Phone Anwendung. Erstens geht es schnell! Sie können das Visual Studio sowohl für die Programmierung der Anwendung als auch zur Entwicklung der Windows Azure Services verwenden. Wenn der Code einmal geschrieben ist, ist die Bereitstellung im Internet eine Sache von Minuten. Windows Azure kann außerdem billig sein. Sie können so viele Daten ablegen, wie sie möchten — für 0,14 $ pro Gigabyte und Monat. Da die ganze Enwicklung lokal auf Ihrer Entwicklungsmaschine stattfinden kann, müssen Sie nichts bezahlen, bis Ihr Service tatsächlich in der Cloud läuft. All das ermöglicht uns, großartige Windows Phone Anwendungen zu entwickeln, ohne uns um die Infrastruktur zu kümmern.
Packen wir’s an
Lassen Sie uns kurz durch die Entwicklung einer einfachen Windows Phone Anwendung gehen, welche auf Services in der Windows Azure Plattform zugreift.
Einige entscheidende Aspekte dieser Architektur (und der eingezeichneten Datenflüsse) sind:
- Anwender der Windows Phone Anwendung sollen sich authentifizieren. Große soziale Dienste wie Facebook, Windows Live, Yahoo! und Google sind hierfür sicher die logische Wahl. Diese Arbeit werden uns die Windows Azure Access Control Services (ACS) abnehmen (dazu später mehr).
- Ein WCF REST Service wird unsere Geschäftslogik enthalten und sicheren Zugriff auf unsere Daten erlauben.
Wichtig hierbei ist, wie das Telefon auf Tabellen- und Blob-Daten in Windows Azure zugreift. Die native API für Windows Azure ist eine REST API. Das umfasst auch die Tabellen und Blobs. Alle Zugriffe auf Windows Azure Storage sind dabei durch Zugriffsschlüssel gesichert. Ein Zugriffsschlüssel muss bei jeder Anfrage (also jedem REST Aufruf) an Windows Azure mit übergeben werden. Die Zugriffsschlüssel sollten natürlich vor unbefugtem Zugriff sicher sein. Es ist deshalb keine gute Idee, die Zugriffsschlüssel im Telefon abzulegen. Würden wir das tun, hätten wir unsere geheimen Schlüssel in die freie Wildbahn gegeben, mit möglicherweise schlimmen Folgen für uns. Es ist natürlich möglich, die Zugriffsschlüssel zu ändern (wenn einer beispielsweise kompromittiert wurde). Wenn die Schlüssel im Telefon liegen, müssten wir in diesem Fall die Anwendung aktualisieren. Um sicher zu gehen, erstellen wir einen Proxy Webservice, durch den alle Zugriffe auf die in der Cloud gespeicherten Daten geleitet werden. Damit bleiben unsere geheimen Schlüssel geheim und wir können die Services „nach SOA Art“ entwickeln.
Es gibt prinzipiell zwei Wege, wie wir unseren Proxy Webservice entwickeln können. Wir können dafür das von Microsoft zur Verfügung gestellte Windows Azure Toolkit for Windows Phone verwenden. Dieses ist eine Fundgrube für Quellen und Beispiele zur Entwicklung von Windows Phone Anwendungen, die Windows Azure Services verwenden. Es enthält z.B. Projektvorlagen zur Verwendung von ACS, Beispiele zum Zugriff auf Storage (Tabellen, Blobs und Queues) und Best Practices für Push Notifications.
In unserem Artikel werden wir allerdings einfach einen kleinen WCF REST Service entwickeln. Diesen können wir leicht aus unserer Windows Phone Anwendung verwenden. Der Service wird nicht nur als Proxy beim Zugriff auf Windows Azure Storage dienen, er wird auch unsere Geschäftslogik enthalten. Wenn wir wollten, könnten wir den Service noch so ausbauen, dass er beispielsweise eine ASP.NET Webanwendung befeuert, oder auch andere mobile Plattformen bedient. Im heutigen Artikel werden wir nicht zu tief in die verschiedenen Aspekte der Windows Azure Storage einsteigen. Das wird im Detail im Windows Azure Platform Training Kit behandelt (siehe dort Exploring Windows Azure Storage).
Table Storage
Zu Beginn brauchen wir eine einfache Entität, die wir im Windows Azure Table Storage ablegen werden.
public sealed class Car : TableServiceEntity
{
/*
* PartitionKey = make
* RowKey = current date/time in UTC
*/
public Car()
{}
public Car(string make, string model, int year, string description, string imageUrl)
{
PartitionKey = make;
RowKey = DateTime.UtcNow.Ticks.ToString();
Make = make;
Model = model;
Year = year;
Description = description;
ImageUrl = imageUrl;
}
public string Make { get; set; }
public string Model { get; set; }
public int Year { get; set; }
public string Description { get; set; }
public string ImageUrl { get; set; }
}
Jetzt können wir eine Methode in unserem WCF Service schreiben, die irgendwelche Geschäftslogik beinhaltet (vielleicht die Überprüfung eines Zugriffsschlüssels o.ä.) und unsere Entität im Table Storage ablegt (Achtung: die CarDataSource ist eine simple Wrapper-Klasse, die uns Teile des Codes etwas vereinfacht — die komplette Klasse kann im unten zum Download bereitstehenden Code angeschaut werden.)
public class CarService : ICarService
{
public void AddCar(Car car)
{
try
{
var key = ValidateApplicationKey();
if (key)
{
var carDataSource = new CarDataSource();
carDataSource.CreateCar(car);
}
}
catch (Exception)
{
throw new WebFaultException<string>("Failed to create a new car.", HttpStatusCode.InternalServerError);
}
}
}
Jetzt, wo der Service bereit ist, können wir ihn aus unserer Windows Phone Anwendung aufrufen — genau wie wir jeden anderen RESTful Webservice aufrufen würden. Der gesamte Code kann unten heruntergeladen werden.
Blob Storage
Wir zuvor erwähnt, dient Windows Azure Blob Storage dazu, beliebige Inhalte, wie z.B. PDF Dokumente, Bilder, Filme oder jede andere Datei abzulegen. Jede Datei stellt dabei einen „Blob“ dar. Blobs wiederum leben in Containern. Container (und damit die beinhalteten Blobs) sind normalerweise nur zugreifbar, wenn man den entsprechenden Zugriffsschlüssel hat (der selbe Schlüssel, der auch für Table Storage verwendet wird). Wenn wir den Zugriffsschlüssel haben, können wir beliebige Operationen ausführen (lesen, schreiben, löschen, etc.). Man kann die Zugriffsrechte auch so ändern, dass anonymer Lesezugriff erlaubt ist — beispielsweise, wenn wir jedem erlauben wollen, Bilder aus einer Windows Phone Anwendung zu betrachten.
Was, wenn wir jemandem den Zugriff nur für einen bestimmten Zeitraum und nur mit bestimmten Rechten erlauben möchten? Die Antwort ist die Verwendung einer Shared Access Signature (SAS). Eine Shared Access Signature ist ein speziell erzeugter URL Query String, welcher die gewährten Rechte (nur erstellen, nur löschen, erstellen und löschen, etc.) und den Gültigkeitszeitraum beinhaltet. Wir können eine SAS erzeugen und diese demjenigen zur Verfügung stellen, dem wir Zugriff auf unsere Blob Storage gewähren möchten. In unserem Beispiel können wir von unserem WCF REST Service eine Shared Access Signature beantragen und diese SAS URL dann verwenden, um Bilder direkt vom Telefon im Windows Azure Blob Storage zu speichern.
Der Prozess zur Erzeugung einer Shared Access Signature geht wie folgt:
public Uri CreateCarImageSharedAccessSignature()
{
Uri signatureUri = null;
var key = ValidateApplicationKey();
if (key)
{
try
{
CloudBlobContainer container = CreateContainer("cars");
// Set permissions on the container.
var sas = container.GetSharedAccessSignature(
new SharedAccessPolicy
{
Permissions =
SharedAccessPermissions.Write |
SharedAccessPermissions.List,
SharedAccessStartTime = DateTime.UtcNow,
SharedAccessExpiryTime = DateTime.UtcNow + TimeSpan.FromMinutes(5)
});
// Trim the leading '?' to prevent there from being two in the resulting URI.
var uriBuilder = new UriBuilder(container.Uri) {Query = sas.TrimStart('?')};
signatureUri = uriBuilder.Uri;
}
catch (Exception ex)
{
throw new WebFaultException<string>(ex.Message, HttpStatusCode.InternalServerError);
}
}
return signatureUri;
}
Access Control
Wir haben jetzt die grundlegenden Mechanismen fertig, um auf die Storage Dienste von Windows Azure zuzugreifen. Lassen Sie uns jetzt eine Authentifizierungsmöglichkeit für die Anwender einbauen. Wir sind vorhin schon kurz auf die Access Control Services (ACS) von Windows Azure eingegangen. ACS erlaubt uns die Authentifizierung von Benutzern über Facebook, Yahoo!, Windows Live ID und Google ohne eine Zeile Code schreiben zu müssen. Wenn der Benutzer authentifiziert ist, bekommen wir eine Reihe von Aussagen über den Benutzer zurück (typischerweise seinen Namen und seine Email-Adresse). Diese Daten können wir verwenden, um die Anwendung zu personalisieren oder um eine Art Registrierung durchzuführen (in der wir beispielsweise weitere Informationen abfragen). Welchen Identitätsprovider wir verwenden, liegt in unserer Hand — das ist nur eine Frage der Konfiguration.
ACS ist ein mächtiger, aber einfach zu verwendender Dienst. Um mehr über ACS zu erfahren, besuchen Sie http://www.microsoft.com/windowsazure/learn/control-access/#introductory.
Microsoft hat vor kurzem ein NuGet Paket herausgebracht, welches die Verwendung von ACS ziemlich simpel macht. Durch das NuGet Paket können wir ACS schnell und mit minimalen Abhängkeiten zu unserem Projekt hinzufügen. Sie finden das NuGet Paket, wenn Sie im Manage NuGet Packages Werkzeug des Visual Studios nach „Access Control Service“ suchen.
Alternativ können Sie das NuGet Paket über die NuGet package management Konsole installieren.
PM> Install-Package Phone.Identity.AccessControl.BasePage
Beide Wege werden die nötigen Controls und Platzhalter zur Verwendung von ACS in Ihrer Windows Phone Anwendung installieren. Nach der Installation können Sie der mitgelieferten Anleitung zur Konfiguration der Windows Phone Anwendung für ACS folgen. Die Verwendung des NuGet Pakets zur Verwendung von ACS in Windows Phone ist immer noch vergleichsweise fortgeschritten, da die ACS Konfiguration uns überlassen wird. Es gibt aber eine detaillierte Anleitung hier, die uns Schritt für Schritt durch die Erstellung eines neuen ACS Namespaces und die nötige Konfiguration führt. Aufgabe 2 in dieser Anleitung ist möglicherweise ein guter Einstiegspunkt, wobei die ganze Anleitung sehr lesenswert ist.
Push Notifications
Wenn wir wollen, ist es auch sehr einfach, Unterstützung für Push Notifications hinzuzufügen. Wieder gibt es ein NuGet Paket, welches die nötigen Schritte stark vereinfacht — ähnlich wie bei der Einbindung der Access Control Services. Der Prozess ist in diesem Channel 9 Video anschaulich demonstriert.
Die NuGet Pakete zur Unterstützung von Push Notifications sind:
PM> Install-Package Phone.Notifications.BasePage (Client/Telefon-seitige Bibliotheken — diese machen die Registrierung mit dem Push Notification Cloud Service)
PM> Install-Package CloudServices.Notifications (Server-seitige Bibliotheken — diese kümmern sich um die Kommunikation mit dem Microsoft Push Notification Service)
Microsoft hat kürzlich einige NuGet Pakete herausgebracht, die die Arbeit mit Windows Azure aus unseren Windows Phone Anwendungen zum Kinderspiel machen. Es gibt Pakete für ACS, Push Notifications und Membership (traditionell über Benutzername und Kennwort). Schauen Sie sich diese Pakete an, da sie sich leicht mit der vorhandenen Funktionalität Ihrer Anwendung ergänzen.
Zusammenfassung
Wir haben jetzt unsere eigene kleine Cloud-befeuerte Windows Phone Anwendung. Wir haben in diesem Artikel gesehen, wie wir einige Dienste der Windows Azure Cloud Plattform für unsere Anwendungen nutzen können. Wir haben gesehen, wie wir einen Webservice entwickeln können, der unsere Geschäftslogik enthält und der als Proxy für die Windows Azure Storage Dienste fungiert. Wir haben ebenfalls gesehen, wie einfach wir Facebook, Yahoo!, Windows Live ID oder Google Authentifizierung mit Hilfe eines NuGet Pakets in unsere Anwendung integrieren können.
Um den kompletten Quellcode dieses Artikels herunterzuladen, klicken Sie auf den Download Code Button unten.
Um mit Windows Azure zu starten, können Sie ein 90-tägiges, kostenloses Testabo abschließen: http://www.microsoft.com/windowsazure/free-trial/.
Weitere Informationen
- Windows Azure
- Windows Azure SDK
- Windows Azure Platform Training Kit
- Windows Azure Toolkit for Windows Phone 7
- NuGet Packages for Windows Azure and Windows Phone
- Windows Azure Access Control Services
- How to Create a Windows Azure Storage Account
- Scenarios for Using Windows Azure with your Mobile Applications
- Windows Azure Architekturdarstellung mit Genehmigung von David Pallmann.
Morgen werden wir Beispieldaten diskutieren und wie wir diese mit Expression Blend sehr einfach erzeugen können.
Bis dahin!