Leitfaden zu OData in Windows Azure

Das Open Data Protocol (OData) ist ein Protokoll, das auf Representational State Transfer (REST) basiert. Wenn Sie Cloud-basierte Datendienste erstellen, können die Daten von jedem Client genutzt werden, der HTTP-Messaging unterstützt und das XML- oder JSON-Format verarbeiten kann. OData macht Daten als Ressourcen verfügbar, die durch URIs adressierbar sind. Der Zugriff auf Daten und deren Änderung erfolgt mithilfe der Standard-HTTP-Verben GET, PUT, POST und DELETE. OData verwendet die Entitätsbeziehungskonventionen von Entity Data Model, um Ressourcen als Sätze von Entitäten verfügbar zu machen, die durch Zuordnungen verknüpft sind.

Da es auf Internetstandards basiert, ist OData eine gute Wahl zum Erstellen von REST-basierten Datendiensten in der Cloud, die von verschiedenen internetfähigen Clientplattformen und Geräten genutzt werden. Deshalb wird OData von vielen Funktionen der Windows Azure Platform verwendet, einschließlich der folgenden Funktionen:

Tabellendienst für Windows Azure-Speicher

Die Programmierschnittstelle, die verwendet wird, um auf den Windows Azure-Tabellendienst zuzugreifen, ist OData. Sie können auf den Tabellendienst zugreifen, indem Sie HTTP-Anforderungen manuell erstellen. Weitere Informationen finden Sie unter Table Service REST API. Sie können auch mithilfe eines OData-Clients, beispielsweise Windows Azure-Speicherclient oder WCF Data Services-Client, auf den Tabellendienst zugreifen. Weitere Informationen finden Sie unter Using the .NET Client Library with the Table Service.

Windows Azure Marketplace

Bei Windows Azure Marketplace handelt es sich um einen Onlinemarkt für Anwendungen und abonnementbasierte Informationen, die die Veröffentlichung und das Nutzen von Daten aus verschiedenen Quellen vereinfachen. Marketplace veröffentlicht Daten als OData-Feeds, damit diese in den OData-fähigen Anwendungen leicht verwendet werden können. Weitere Informationen finden Sie unter Windows Azure Marketplace.

ACS-Verwaltungsdienst

Der Zugriffssteuerungsdienst (ACS) 2.0 für Windows Azure stellt eine OData-basierte API für den ACS-Verwaltungsdienst zur Verfügung. Weitere Informationen finden Sie unter ACS Management Service API Reference.

Sie können auch einen eigenen OData-Dienst auf Windows Azure erstellen und bereitstellen. In diesem Fall ist der Datendienst eine .NET Framework-basierte Webanwendung, die von einer ASP.NET-Webrolle gehostet wird. Im Folgenden sind Funktionen und Toolkits aufgeführt, mit denen Sie OData-Dienste auf Windows Azure erstellen und bereitstellen können:

WCF Data Services

WCF Data Services ist eine Komponente von .NET Framework, die verwendet wird, um Datendienstanwendungen zu erstellen, die OData implementieren. Weitere Informationen finden Sie unter WCF Data Services. WCF Data Services ermöglicht es Ihnen, benutzerdefinierte Windows Azure-basierte Datendienste zu erstellen, die als ASP.NET-Webrollen gehostet werden. Mit WCF Data Services können Sie Daten verfügbar machen, die aus verschiedenen Windows Azure-Quellen stammen, einschließlich SQL-Datenbank- und Windows Azure-BLOB-Speicher. Der Datendienstanbieter, mit dem Sie das Datenmodell des Datendiensts definieren, hängt von der Datenquelle ab. Weitere Informationen finden Sie unter Data Services Providers (WCF Data Services).

Windows Azure Tools für Visual Studio enthalten einen integrierten Satz von Tools zum Entwickeln von Windows Azure-basierten Datendiensten in Visual Studio. Ein Beispiel zum Verwenden von Visual Studio Tools, um einen Datendienst zu erstellen und bereitzustellen, sodass OData-Feeds aus einer SQL-Datenbank verfügbar gemacht werden, finden Sie im Artikel Datendienste in der Cloud. Einen allgemeinen Leitfaden zum Erstellen und Bereitstellen von OData-Diensten mithilfe von WCF Data Services finden Sie unter Defining WCF Data Services.

Sync Framework Toolkit

Das Sync Framework Toolkit erweitert Microsoft Sync Framework, um Ihnen zu ermöglichen, einen WCF Data Services-basierten Synchronisierungsdienst zu erstellen, der auf Windows Azure bereitgestellt werden kann. Dieser spezialisierte OData-Dienst ermöglicht es Ihnen, Daten zwischen einer SQL-Datenbank und verschiedenen Clientanwendungen und Geräten zu synchronisieren, die OData-Feeds nutzen können. Weitere Informationen finden Sie auf der Microsoft Sync Framework Toolkit-Projektseite in MSDN Code Gallery.

Allgemeinere Informationen zum OData-Protokoll, einschließlich einer Liste von OData-Producern und -Consumern sowie Clientbibliotheken, die OData unterstützen, finden Sie auf der OData.org-Website.

Sie können den Entity Framework-Anbieter in WCF Data Services verwenden, um einen Datendienst zu erstellen, der SQL-Datenbankdaten als OData-Feeds veröffentlicht. Ein Beispiel hierzu finden Sie unter How to: Connect to Windows Azure SQL Database Through WCF Data Services. Wenn Sie das Datenmodell für den Datendienst mithilfe des Entity Framework-Anbieters definieren, nutzt WCF Data Services die bereitgestellte Klasse, die von ObjectContext erbt, um Abfragen für die Datenbank zu erstellen und auszuführen. Weitere Informationen finden Sie unter Entity Framework Provider (WCF Data Services).

Die folgenden Richtlinien sind gültig, wenn Sie mithilfe des Entity Framework-Anbieters WCF Data Services aktivieren, um Daten aus einer SQL-Datenbank zu veröffentlichen.

Verwenden eines Entity Framework-Code-First-Anbieters

Verhindern von SQL-Datenbankverbindungsfehlern

partial void OnContextCreated()
{
    int MaxRetries = 10; 
    int DelayMS = 100; 
    RetryPolicy policy = 
        new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(
            MaxRetries, TimeSpan.FromMilliseconds(DelayMS)); 

    // Invoke the query in an inline delegate using the lambda operator.
    policy.ExecuteAction(() =>
    {
        try
        {
            // Try to open the connection.
            Connection.Open();
            var storeConnection = 
            (SqlConnection)((EntityConnection)Connection)
            .StoreConnection;

            // Send a quick query to the SQL database to test the connection.
            new SqlCommand("declare @i int", storeConnection).ExecuteNonQuery();
        }
        catch (Exception ex)
        {
            // If we fail, close the connection.
            Connection.Close(); 
            throw ex;
         }
      });
}

using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure;
using Microsoft.Practices.TransientFaultHandling;
using System.Data.EntityClient;
using System.Data.SqlClient;

// You must override CreateDataSource to manually return an ObjectContext,
// otherwise the runtime tries to use the built-in reflection provider instead of 
// the Entity Framework provider.
protected override ObjectContext CreateDataSource()
{
    // Create a new Code First Northwind DbContext.
    NorthwindContext nw = new NorthwindContext();
    nw.Configuration.ProxyCreationEnabled = false;
    
    // Define a retry policy for our query to the SQL database.
    int MaxRetries = 10;
    int DelayMS = 100;
    RetryPolicy policy =
        new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(
            MaxRetries, TimeSpan.FromMilliseconds(DelayMS));

    
    // Invoke the query in an inline delegate using the lambda operator.
    policy.ExecuteAction(() =>
    {
        try
        {
            // Try to open the connection.
            nw.Database.Connection.Open();
            var storeConnection = (SqlConnection)(nw.Database.Connection);

            // Send a quick query to the SQL database to test the connection.
            new SqlCommand("declare @i int", storeConnection).ExecuteNonQuery(); 
        }
        catch (Exception ex)
        {
            // If we fail, close the connection.
            nw.Database.Connection.Close();
            throw ex;
         }
    });

    // Configure DbContext before we provide it to the 
    // data services runtime.
    nw.Configuration.ValidateOnSaveEnabled = false;

    // Get the underlying ObjectContext for the DbContext.
    var context = ((IObjectContextAdapter)nw).ObjectContext;

    // Return the underlying context.
    return context;
}

Ein OData-Dienst kann Binary Large Object (BLOB)-Daten verfügbar machen. Das Open Data Protocol (OData) definiert einen Mechanismus zum Abrufen von Binärdaten – unabhängig von der Entität, zu der es gehört. Dies wird erreicht, indem die Binärdaten in einem separaten Datenstrom von der Entität getrennt werden. Bei WCF Data Services definieren Sie durch das Implementieren der IDataServiceStreamProvider-Schnittstelle einen binären Ressourcendatenstrom, um einen Streamingdatenanbieter zu definieren. Durch die Streaminganbieterimplementierung wird der Datendienst mit dem Datenstrom zur Verfügung gestellt, der einer bestimmten Entität als Stream-Objekt oder URI zugeordnet ist, der bzw. das zum Aufrufen der Binärdaten verwendet wird. Weitere Informationen finden Sie unter Streaming Provider (WCF Data Services).

Wenn ein Streamingdatendienstanbieter für einen in Windows Azure gehosteten Datendienst erstellt werden soll, verwenden Sie den Windows Azure-BLOB-Dienst beim Implementieren von GetWriteStream und GetReadStream. Für die optimale Leistung sollte die GetReadStreamUri-Implementierung den URI des Blobs zurückgeben, damit Clients diesen direkt vom BLOB-Dienst anfordern können.

Es gibt Situationen, in denen es sinnvoll ist, einen Windows Azure-basierten OData-Dienst zu veröffentlichen, der anonymen Zugriff zulässt. In vielen Fällen müssen Sie jedoch bestimmen, wer auf den Datendienst zugreift. Hinsichtlich der Sicherheit ist dieses "wer" als Prinzip bekannt. Sie müssen auch bestimmen, ob ein bestimmtes Prinzip auf Ressourcen zugreifen und (möglicherweise) die Ergebnisse von Abfragen filtern kann, die auf dem Prinzip basieren, das die Anforderung stellt. Sie müssen möglicherweise auch die vom Datendienst zurückgegebenen Daten sichern, um die Weitergabe an Dritte auszuschließen. Allgemeine Informationen zum Sichern von WCF Data Services finden Sie unter Securing WCF Data Services.

Authentifizierung

WCF Data Services führt keine Authentifizierung von Clientanforderungen aus. Stattdessen ist die Hostplattform erforderlich, um die Authentifizierung auszuführen und Informationen zum anfordernden Prinzip zur Verfügung zu stellen. Wenn Sie die Authentifizierung für einen Datendienst implementieren, der in Windows Azure gehostet wird, sollten Sie die OAuth 2.0-Authentifizierung verwenden. In der Windows Azure Platform wird vom Zugriffssteuerungsdienst (ACS) Unterstützung für dieses Authentifizierungsschema bereitgestellt. Ein Beispiel zum Verwenden des ACSs, um die OAuth 2.0-Authentifizierung für den Datendienst zu implementieren, finden Sie im Artikel OData und OAuth – Schützen eines OData-Diensts mit OAuth 2.0.

Ein Beispiel zum Herstellen einer Verbindung mit einem OData-Dienst mithilfe von OAuth 2.0 finden Sie im Artikel Verbinden mit einem durch OAuth 2.0 geschützten OData-Dienst.

Autorisierung

Es empfiehlt sich, dass Sie Regeln definieren, die den Zugriff auf Datenmodellressourcen auf die Mindestprivilegien beschränken, die erforderlich sind, um Clientanwendungen zu unterstützen. Weitere Informationen finden Sie unter Configuring the Data Service (WCF Data Services). Sobald ein Client authentifiziert wurde, können Informationen, wie beispielsweise Benutzername, von der Identität des Prinzips abgerufen werden. Abhängig vom Datenmodell können diese clientspezifischen Informationen verwendet werden, um Daten zu filtern, bevor dem Client diese vom Datendienst zurückgegeben werden. Definieren Sie dazu Abfrage-Interceptors für bestimmte Entitätssätze, die gefiltert werden müssen. Weitere Informationen finden Sie unter Interceptors (WCF Data Services).

Durch das Definieren von Abfrage-Interceptors, die nur Daten zurückgeben, die zu einem bestimmten Prinzip oder einer bestimmten Rolle gehören, können WCF Data Services mehrinstanzfähige Anwendungen unterstützen. Beim mehrinstanzfähigen Modell kann ein einzelner Datendienst zahlreiche Clients bedienen, während die zugehörigen Daten getrennt gehalten werden. Weitere Anleitungen zum Erstellen von mehrinstanzfähigen Windows Azure-basierten Anwendungen finden Sie unter Entwerfen von mehrinstanzfähigen Anwendungen unter Windows Azure. Sie können auch Änderungs-Interceptors definieren, um die Geschäftslogik einzubinden, wann eine Änderung an den Datendienst gesendet wird. Diese Logik kann auch das Prinzip der authentifizierten Anforderung überprüfen und möglicherweise auch Rücknahmeänderungen, die von einem Benutzer vorgenommen wurden, der nicht autorisiert ist, die Änderung vorzunehmen.

Die TableServiceContext-Klasse, die verwendet wird, um auf den Windows Azure-Tabellendienst zuzugreifen, basiert auf dem WCF Data Services-Client. Es ist möglich, dass Tabellendienst-OData-Feeds erneut mithilfe des Reflektionsanbieters bei TableServiceContext veröffentlicht werden. Die WCF Data Services-Clientbibliothek unterstützt jedoch nicht den vollständigen Satz von LINQ-Abfragen (Language Integrated Query), der von einem OData-Dienst verwendet wird. Aus diesem Grund wird davon abgeraten, dass Sie den Tabellendienst mithilfe von WCF Data Services erneut veröffentlichen.

Dieser Abschnitt enthält andere Hinweise zu in Windows Azure gehosteten WCF Data Services. Dieser Leitfaden kann verwendet werden, um Verbesserungen für Clients bereitzustellen, die auf einen OData-Dienst zugreifen.

Definieren der Seitenbegrenzung bei großen Entitätssätzen

Wenn Sie mithilfe von WCF Data Services große Datensätze verfügbar machen, sollten Sie die Seitenbegrenzung festlegen, um die Anzahl von Entitäten einzuschränken, die Clients bei einer einzelnen Abfrage zurückgegeben werden. Ohne die Seitenbegrenzung könnten einige Clients zusätzliche Ressourcen auf einfache Weise beanspruchen, indem einfache Anforderungen für Feeds ausgegeben werden, die viele Entitäten enthalten. Die Seitenbegrenzung dient dazu, umfangreiche Abfragen in eine Reihe von kleineren partiellen Abfragen zu unterteilen, die die Auswirkungen von umfangreichen Abfragen auf die Gesamtantwortzeit des Systems reduzieren. Rufen Sie die Methode SetEntitySetPageSize bei allen Entitätssätzen auf, die vom Datendienst verfügbar gemacht wurden, um die Seitenbegrenzung festzulegen. Weitere Informationen finden Sie unter How to: Enable Paging of Data Service Results (WCF Data Services).

Aktivieren der Option zur Systemabfrage bei WCF Data Services

WCF Data Services unterstützt sowohl das Atom-XML- als auch das JSON-Format, das für OData erforderlich ist. Wenn WCF Data Services eine Anforderung empfängt, wird der Anforderungsheader für die Annahme überprüft, um das Format der Antwort zu bestimmen. OData stellt auch eine $format-Abfrageoption bereit, die von Clients verwendet werden kann, die nicht in der Lage sind, die Anforderungsheader festzulegen, z. B. einige JavaScript-Clients und der Browser. Standardmäßig wird diese Systemabfrageoption von WCF Data Services ignoriert. Weitere Informationen finden Sie unter WCF Data Services Protocol Implementation Details.

Wird die Unterstützung für die $format-Abfrageoption aktiviert, wird auch die Unterstützung für JavaScript Objection Notation mit Auffüllung (JSONP) bei clientseitigem JavaScript-Webseitencode aktiviert, wenn ein OData-Dienst aufgerufen wird. Sie können dem Datendienst diese Funktionalität hinzufügen, indem Sie das Beispielprojekt Unterstützung des JSONP- und URL-gesteuerten Formats für WCF Data Services von der MSDN Code Gallery-Website herunterladen und es dem Datendienstprojekt hinzufügen.

In diesem Abschnitt wird die Ebene der Clientunterstützung zum Zugreifen auf OData-Dienste beschrieben. Darüber hinaus ist ein Leitfaden für Clients enthalten, die auf einen OData-Dienst zugreifen.

Clientunterstützung zum Zugreifen auf OData-Dienste

Da OData auf Standardinternetprotokollen basiert, ist ein OData-Dienst für alle Clients zugänglich, die in der Lage sind, HTTP-Nachrichten zu senden und zu empfangen sowie XML oder JSON zu erstellen und zu analysieren. Um den Arbeitsaufwand zu reduzieren, der erforderlich ist, um auf einen OData-Dienst zuzugreifen, gibt es verschiedene Clientbibliotheken und Clientanwendungen, die verwendet werden können, um OData-Dienste zu nutzen, darunter auch:

• WCF Data Services Client Library
  
  Wird verwendet, um in einer .NET Framework-Anwendung auf einen OData-Dienst zuzugreifen.
  
  
• OData client for Windows Phone
  
  Wird verwendet, um in einer Windows Phone-Anwendung auf einen OData-Dienst zuzugreifen.
  
  
• WCF Data Services Client Library for Silverlight
  
  Wird verwendet, um in einer Silverlight-Anwendung auf einen OData-Dienst zuzugreifen.
  
  
• OData-Client für Objective-C
  
  Wird verwendet, um mit iOS-Geräten (iPhone und iPad) und MacOS auf einen OData-Dienst zuzugreifen.
  
  
• Microsoft-AJAX-Bibliothek für OData
  
  Wird verwendet, um in einer JavaScript-basierten Anwendung auf einen OData-Dienst zuzugreifen.
  
  
• PowerPivot für Excel 2010
  
  Wird verwendet, um OData-Feeds in Excel zu importieren.
  
  
• Marketplace-Dienst Explorer
  
  Wird verwendet, um Daten in Marketplace-Abonnements anzuzeigen.
  
  

Eine umfassende Liste der OData-Clientbibliotheken finden Sie unter OData-SDK. Eine Liste der Anwendungen, die OData-Feeds nutzen, finden Sie auf der Consumer-Seite auf der OData-Website.

Überlegungen zu mobilen Clients

Beim Zugreifen auf OData-Feeds mit einer Anwendung für mobile Geräte gelten die folgenden Überlegungen:

• Aktivieren Sie stets die clientseitige Auslagerung, sodass der Client steuern kann, wie viele Daten vom Dienst gesendet werden. Zu diesem Zweck werden die Abfrageoptionen $skip und $top im Anforderungs-URI verwendet.
  
  
• Seien Sie stets darauf vorbereitet, eine ausgelagerte Antwort vom Server zu verarbeiten. Bei WCF Data Services wird die nächste Seite mit der Abfrageoption $skiptoken in einem Abfrage-URI angefordert. Weitere Informationen finden Sie unter How to: Load Paged Results (WCF Data Services).
  
  
• Wenn Sie nur eine Anzahl der Elemente im Feed benötigen, fordern Sie lediglich den Anzahlwert und nicht den gesamten Feed an. Diese Anzahl kann durch das Anfordern des $count-Endpunkts oder Einschließen von $inlinecount=allpages in den Anforderungs-URI ermittelt werden. Weitere Informationen finden Sie unter How to: Determine the Number of Entities Returned by a Query (WCF Data Services).
  
  
• Verwenden Sie zum Reduzieren der Netzwerkbandbreite ggf. das JSON-Format statt des Atom-XML-Formats.
  
  

  Hinweis
  WCF Data Services-Clients, einschließlich des OData client for Windows Phone, unterstützen momentan nicht das JSON-Format.

• Verwenden Sie zum Reduzieren der Netzwerkbandbreite ggf. die Komprimierung. Die Komprimierung erfordert zusätzliche Verarbeitungsschritte mithilfe des Datendiensts und des Clientgeräts. Diese zusätzlichen Verarbeitungsschritte können sich negativ auf die Akkulaufzeit des Geräts auswirken.
  
  
• Verwenden Sie ggf. Strategien, z. B. Clientprojektionen, die die Abfrageoption $select verwenden, um die an den Client gesendete Datenmenge zu reduzieren. Weitere Informationen finden Sie unter Query Projections (WCF Data Services).
  
  
• Führen Sie eine Zwischenspeicherung der Verweisdaten auf dem Client durch, oder verwenden Sie eine andere Synchronisierungsstrategie, um die Menge an überlappenden Daten zu reduzieren, die vom Datendienst heruntergeladen wird. Weitere Informationen finden Sie unter Datensynchronisierung zwischen Windows Azure und mobilen Clients.
  
  

Einen Leitfaden für die Windows Phone-Plattform finden Sie unter Verwenden von Windows Phone mit Windows Azure.