Cloud basierte WebServices sind inzwischen ein valider Bestandteil moderner Systemlandschaften. Typischerweise werden solche WebServices in Java oder C# entwickelt und auf Apache oder IIS Webservern gehostet. Ich möchte hier ein anderes Modell vorstellen, welches alleine auf JavaScript setzt und mittels der Microsoft Azure Cloud gehostet wird.
Dazu werden folgende Voraussetzungen benötigt:
Als erstes wird ein Node JS Projekt in Visual Studio mittels der Blank Azure Node.js Web Application Vorlage angelegt:
Über das Template wird die folgende Projektstruktur angelegt:
Im bin Verzeichnis befinden sich Batch Dateien zum automatischen Start des Node Servers unter Azure. Die server.js beinhaltet den eigentlichen Server Code und wird beim Start des Node Servers ausgeführt. Die Web.config enthält die IIS Konfiguration für den Einsatz des IISNode Moduls unter Azure.
<handlers> <add name="iisnode" path="server.js" verb="*" modules="iisnode" /> </handlers>
Als nächstes folgt die Installation des Express Moduls (http://expressjs.com/de/) mittels NPM mit dem später die HTTP Requests verarbeitet werden.
Hier sollte die aktuellste Version des Express Web Frameworks installiert werden. Das Laden der Paketdefinitionen benötigt 1-2 Minuten – an dieser Stelle ist etwas Geduld notwendig.
Nach erfolgreicher Installation findet man das Express Paket im Solution-Browser unter dem NPM Folder.
Nun geht es ans Eingemachte: die server.js. Der vorhandene Code kann gelöscht werden und muss unserem Express basierten REST WebService weichen.
Als erstes wird das Express Web Framework geladen und die App initialisiert:
'use strict';
var express = require('express');
var app = express();
Danach muss das app Objekt an den Webserver-Port gebunden werden:
app.set('port', process.env.PORT || 3000);
app.set('host', process.env.HOST || 'localhost');
app.listen(app.get('port'), app.get('host'), function () {
console.log("Express server listening on " + app.get('host') +":"+ app.get('port'));
});
Hierzu werden zunächst die Konfigurationssettings der App für ‚port‘ und ‚host‘ über die app.set Funktion gesetzt. Diese werden auf den Wert der Umgebungsvariablen process.env.PORT bzw. HOST oder einen Defaultwert (localhost und Port 3000) gesetzt. Das process.env Objekt wird vom IISNode Modul automatisch gesetzt. Dieser Schritt ist wichtig, da Azure beim Deployment auf einen App-Service hierdurch einen Port vorgibt.
Damit sind die Grundlagen für den WebServer geschaffen.
Der Demo WebService soll Adressdaten liefern. Dazu wird zunächst ein einfaches Array mit Adressobjekten angelegt.
var accounts = [
{
id: "1",
name: "Max Mueller GmbH",
street: "Bahnhofstr. 100",
zip: "99998",
city: "Irgendwo"
},
{
id: "2",
name: "Schuster AG",
street: "Bachstr. 5",
zip: "99099",
city: "Woanders"
}
];
In einer Real-Life Anwendung werden diese Daten natürlich aus einer Datenbank ausgelesen. Für den Demo Webservice muss das Array reichen.
Als nächstes folgen die Service Endpoints für den REST Webservice. Typischerweise verfügt ein REST Webservice über eine Reihe von Endpoints die mittels unterschiedlicher HTTP Methoden angesprochen werden. Zum Beispiel:
Die Funktion zum Auflisten aller vorhandenen Accounts ist recht einfach:
app.get("/account", function (req, res) {
res.json(accounts);
});
Express bietet für jede HTTP Methode eine entsprechende Funktion an (http://expressjs.com/de/4x/api.html#app.METHOD). Zum Beispiel ein app.get zur Beantwortung eines HTTP-GET Requests und ein app.post zur Beantwortung eines HTTP-Post Requests usw..
Diese Funktionen erwarten als Parameter den Endpoint auf den reagiert werden soll sowie eine Callback-Funktion, die aufgerufen wird wenn der entsprechende Endpoint einen Request enthält.
Die Callback Funktion erhält zwei Parameter: das Request und das Response Objekt.
Das Ergebnis wird nun einfach mittels der json Funktion des Response Objekts in den Antwortstream geschrieben. Die res.json Funktion sorgt dabei für die Objekt Serialisierung und dafür, dass der passende HTTP Header „application/json“ gesetzt wird.
Für den zweiten Endpoint funktioniert das nicht ganz so einfach. Hier muss die ID als Bestandteil der Endpoint URL erkannt und extrahiert werden. Aber auch dazu bietet Express eine elegante Lösung: Ein Endpoint Pfad kann nicht nur als String, sondern auch als Regular Expression angegeben werden. In diesem Fall muss die Regular Expression auf eine beliebige ganze Zahl zwischen den Klammern matchen: \/account\(([0-9]+)\)
Die Capture Groups dieser Regular Expression werden im Request Objekt in dem Array params gespeichert.
app.get(/\/account\(([0-9]+)\)/, function (req, res) {
var id = req.params[0];
...
});
Damit kann die Accout ID bequem identifiziert werden.
Danach folgt eine einfache For-Schleife, um den erfragten Account zu identifizieren. In der Response wird neben dem angefragten Account Objekt auch der Status der Anfrage zurück geliefert. In dem Fall, dass Daten gefunden wurden, wird der Statuscode 200 zurückgegeben. Werden keine Daten gefunden, sollte entsprechend der Statuscode 204 – No Content zurück geliefert werden.
var responseObject = null;
var responseStatus = 204;
if (id) {
for (var i = 0; i < accounts.length; i++) {
if (accounts[i].id === id) {
responseStatus = 200;
responseObject = accounts[i];
break;
}
}
}
res.status(responseStatus).json(responseObject);
Weitere Endpoints können nun nach Belieben hinzugefügt werden. Das Schema bleibt dabei jeweils das Gleiche.
Mittels der Project-Properties kann nun der Endpoint für den Start des WebBrowsers festgelegt werden:
Der WebService kann nun lokal ausgeführt und getestet werden. Hierzu reicht es aus, die Run-Schaltfläche des Debuggers anzuklicken.
Dabei empfiehlt es sich beispielsweise den Chrome Browser zu nutzen, um das Ergebnis, den JSON String, direkt im Browser sehen zu können.
Gegebenenfalls muss auch vor dem Start des Node Servers die Einrichtung einer Firewallregel bestätigt werden:
Danach wird der Node.js Server gestartet und der Debugger mit Visual Studio verbunden. Das heißt, dass der Serverseitige JavaScript Code wie gewohnt mit Visual Studio debuggt werden kann.
Mit dem Node Server wird dann auch der WebBrowser gestartet und die in den Project-Properties eingestellte URL aufgerufen. Als Ergebnis wird hier das Account Array in JSON Notation angezeigt:
Nachdem der WebService erfolgreich lokal getestet wurde kann er in der Azure Cloud bereitgestellt werden. Hierzu muss ein neues Publishing Profil erstellt werden:
Im folgenden Dialogfenster kann nun als Publishing-Target Microsoft Azure App Service ausgewählt werden.
Als nächstes muss eine Azure Subscription ausgewählt und ein neuer App Service mit einem Klick auf „New…“ angelegt werden.
Hier wird nun der Name und damit die URL für den Service festgelegt:
Weiterhin muss ein entsprechender ServicePlan mit einem Klick auf den „New…“ Button unter dem Abschnitt App Service Plan bereitgestellt werden:
Das Ergebnis ist ein neues Publishing Profil für den Node.js Service:
Mit einem Klick auf den „Publish“ Button wird dann das Deployment auf den Azure Service gestartet.
…
Nach erfolgreichem Deployment wird der Node.js Service automatisch gestartet und ein WebBrowser mit der WebService URL aufgerufen. Hier wird jedoch nicht der Service-Endpoint mit übergeben, dieser muss dann noch in der URL im WebBrowser ergänzt werden.
Das Ergebnis ist nun wieder, wie auch schon bei dem lokalen Test, das Account Array in JSON Notation. Allerdings dieses mal vom Azure Service gehostet:
Über den Server Explorer kann man jetzt mittels der Service Settings noch weitere Einstellungen zum Debugging oder Logging einstellen oder Application Settings festlegen:
Schlagwörter: Azure, Cloud, Express, JavaScript, Node.JS, WebService
Haben Sie Fragen zu diesem Artikel oder brauchen Sie Unterstützung?
Nehmen Sie mit uns Kontakt auf!
Wir unterstützen Sie gerne bei Ihren Vorhaben!
