© best_vector/Shutterstock.com
Windows Developer
Teil 1: Azure Storage als Zwischenspeicher für den Datenaustausch

Real World Windows Azure

Mit der Microsoft-Cloud Windows Azure lassen sich hoch skalierbare, weltweit verteilte Anwendungen für Millionen von Endnutzern erstellen. Da aber die wenigsten von uns am nächsten Facebook mitentwickeln, wird Windows Azure im Alltag der Softwareentwicklungsteams selten verwendet. Zu Unrecht, wie sich zeigen wird.

Roland Krummenacher


Windows Azure – Architektur global skalierbarer und verfügbarer Services

ArtikelserieTeil 1: Azure Storage als Zwischenspeicher für den DatenaustauschTeil 2: Fernüberwachung via CloudTeil 3: Aufbereitung von Daten als JSON-Read Models in der CloudTeil 4: Taktgeber aus der CloudTeil 5: Sammeln von Client-Log-Dateien in der Cloud

Die Dienste der Azure-Plattform können für jede Art von Software sinnvoll eingesetzt werden – egal, ob es sich um eine Web-, Desktop-, Service- oder Embedded-Applikation handelt. In den fünf Artikeln dieser Serie zeige ich anhand von Beispielen aus meinem Projektalltag, wie Windows Azure in Nicht-Cloud-Applikationen verwendet werden kann. Mein Ziel ist es, dass Sie, liebe Leserin, lieber Leser, die Möglichkeiten der Azure-Plattform auch für Ihr aktuelles Projekt entdecken.

Die einzelnen Artikel dieser Serie sind so aufgebaut, dass ich jeweils ein konkretes Problem vorstelle und eine Lösung dazu aufzeige. Dann werde ich diese Lösung beurteilen und gegebenenfalls ein wiederverwendbares Muster daraus ableiten. Die Serie ist bewusst allgemein gehalten, aber zu jedem Artikel finden Sie in meinem Blog [1] Informationen und Beispiele, wie Sie die Lösung in Ihrem Projekt umsetzen können, sowie die Möglichkeit, mit mir Fragen und Ideen zu diskutieren.

Abb. 1: Wie übertragen wir größere Datenmengen vom Client zum Server?

Das Problem

Beim heutigen Problem beschäftigen wir uns mit einer klassischen Client-Server-Architektur, wie sie in Abbildung 1 gezeigt wird. Der Client möchte dem Server Daten senden. Als Schnittstelle zwischen Client und Server kommt bei einem Webclient HTTP, bei einem Desktopclient typischerweise SOAP via WCF oder HTTP via Web-API zum Einsatz. Diese Architektur funktioniert so lange gut, bis der Client auf die Idee kommt, größere Datenmengen an den Server zu senden. Sendet der Client nämlich Anfragen an den Server, die größer als 4 Megabyte sind, erhält er vom Server die Meldung „Maximum request length exceeded“, da die maximale Request-Größe standardmäßig auf 4 Megabyte limitiert ist [2]. Mit einer kurzen Websuche findet man rasch die entsprechende Web.config-Einstellung, um diese Limitierung anzuheben und kann weiterarbeiten. Was bei den praktischen Antworten auf Stack Overflow und Co. jedoch selten beschrieben wird: Diese Limitierung ist durchaus sinnvoll. Zum einen kann es sein, dass der ASP.NET-Worker-Prozess aufgrund technischer Limits nicht mit großen Dateien umgehen kann und dadurch der Webserver plötzlich nic...

Windows Developer
Teil 1: Azure Storage als Zwischenspeicher für den Datenaustausch

Real World Windows Azure

Mit der Microsoft-Cloud Windows Azure lassen sich hoch skalierbare, weltweit verteilte Anwendungen für Millionen von Endnutzern erstellen. Da aber die wenigsten von uns am nächsten Facebook mitentwickeln, wird Windows Azure im Alltag der Softwareentwicklungsteams selten verwendet. Zu Unrecht, wie sich zeigen wird.

Roland Krummenacher


Windows Azure – Architektur global skalierbarer und verfügbarer Services

ArtikelserieTeil 1: Azure Storage als Zwischenspeicher für den DatenaustauschTeil 2: Fernüberwachung via CloudTeil 3: Aufbereitung von Daten als JSON-Read Models in der CloudTeil 4: Taktgeber aus der CloudTeil 5: Sammeln von Client-Log-Dateien in der Cloud

Die Dienste der Azure-Plattform können für jede Art von Software sinnvoll eingesetzt werden – egal, ob es sich um eine Web-, Desktop-, Service- oder Embedded-Applikation handelt. In den fünf Artikeln dieser Serie zeige ich anhand von Beispielen aus meinem Projektalltag, wie Windows Azure in Nicht-Cloud-Applikationen verwendet werden kann. Mein Ziel ist es, dass Sie, liebe Leserin, lieber Leser, die Möglichkeiten der Azure-Plattform auch für Ihr aktuelles Projekt entdecken.

Die einzelnen Artikel dieser Serie sind so aufgebaut, dass ich jeweils ein konkretes Problem vorstelle und eine Lösung dazu aufzeige. Dann werde ich diese Lösung beurteilen und gegebenenfalls ein wiederverwendbares Muster daraus ableiten. Die Serie ist bewusst allgemein gehalten, aber zu jedem Artikel finden Sie in meinem Blog [1] Informationen und Beispiele, wie Sie die Lösung in Ihrem Projekt umsetzen können, sowie die Möglichkeit, mit mir Fragen und Ideen zu diskutieren.

Abb. 1: Wie übertragen wir größere Datenmengen vom Client zum Server?

Das Problem

Beim heutigen Problem beschäftigen wir uns mit einer klassischen Client-Server-Architektur, wie sie in Abbildung 1 gezeigt wird. Der Client möchte dem Server Daten senden. Als Schnittstelle zwischen Client und Server kommt bei einem Webclient HTTP, bei einem Desktopclient typischerweise SOAP via WCF oder HTTP via Web-API zum Einsatz. Diese Architektur funktioniert so lange gut, bis der Client auf die Idee kommt, größere Datenmengen an den Server zu senden. Sendet der Client nämlich Anfragen an den Server, die größer als 4 Megabyte sind, erhält er vom Server die Meldung „Maximum request length exceeded“, da die maximale Request-Größe standardmäßig auf 4 Megabyte limitiert ist [2]. Mit einer kurzen Websuche findet man rasch die entsprechende Web.config-Einstellung, um diese Limitierung anzuheben und kann weiterarbeiten. Was bei den praktischen Antworten auf Stack Overflow und Co. jedoch selten beschrieben wird: Diese Limitierung ist durchaus sinnvoll. Zum einen kann es sein, dass der ASP.NET-Worker-Prozess aufgrund technischer Limits nicht mit großen Dateien umgehen kann und dadurch der Webserver plötzlich nic...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang