Ja Bei der Verwendung von .NET Core können Client und Server auf unterschiedlichen Plattformen ausgeführt werden.
Ja Bei der Verwendung von .NET Core können Client und Server auf unterschiedlichen Plattformen ausgeführt werden.
Interoperabilität
Ja Client und Server können in unterschiedlichen Programmiersprachen erstellt worden sein.
Ja Client und Server können in unterschiedlichen Programmiersprachen erstellt worden sein.
Browser-Unterstützung
Ja
Optional Aktuell nur mit 3rd-Party-Bibliotheken möglich
Selbstbeschreibende Schnittstellen
Optional OpenAPI ist durch die Einbindung von 3rd- Party-Bibliotheken möglich.
Nein Die *.proto-Datei zur Beschreibung der Schnittstelle muss selbst erstellt werden.
Payload-Größe
Höher JSON, menschenlesbar
Geringer Binary-Format
Geschwindigkeit
Geringer
Höher
Zukunftsfähigkeit
Ja Web API wird aktuell als zukunftsfähige Alternative von Microsoft empfohlen.
Ja gRPC wird aktuell als zukunftsfähige Alternative von Microsoft empfohlen.
Debugging
Einfach möglich
Bedingt möglich Die übertragenen Daten können aufgrund der Komprimierung nicht eingesehen werden.
Vor- und Nachteile
Web API
gRPC
Vorteile
Übertragungsdaten lesbar
Weniger Code-Anpassung bei Migration nötig
Flexiblere Gestaltung der Endpunkte und Aufrufe in Bezug auf Über- und Rückgabe-Parameter
Schnellere Übertragung
Typisiert durch Protocol-Buffers-Schnittstellenbeschreibung
Einfache Generierung von Client-Klassen
Nachteile
Langsamere Übertragung im Vergleich zu gRPC
Generierung von Client-Klassen nur durch 3rd-Party-Bibliotheken
Keine Typisierung der Schnittstelle möglich
Übertragungsdaten nicht lesbar
Mapping-Code nötig, da keine Standard-.NET-Typen verwendet werden
Größerer Migrationsaufwand, da mehr Code-Anpassungen nötig
Fazit
In unserer Blogpostreihe zum Thema WCF haben wir sowohl ASP.NET Core Web API als auch gRPC vorgestellt. Dabei ist deutlich geworden, dass beide Varianten ihre Vor- und Nachteile haben.
Bei Web API können die Schnittstellen durch den Content-First-Ansatz sowie die Nutzung von HTTP sehr einfach von jedem verwendet werden. Dabei sind die übertragenen Daten jederzeit einsehbar und können gelesen werden.
Durch gRPC werden im Contract-First-Ansatz die Schnittstellenaufrufe abstrahiert, wodurch diese schneller sind und von Entwicklern sehr einfach angesprochen werden können. Dabei können die übertragenen Daten aber nicht eingesehen werden.
Grundsätzlich ist die Migration zu beiden Varianten möglich und beide werden auch von Microsoft empfohlen. Abschließend kann jedoch keine Empfehlung für eine der beiden Alternativen gegeben werden. Eine Entscheidung sollte immer projektspezifisch und nach verschiedenen Kriterien wie Projektgröße, Erfahrung in der jeweiligen Technologie oder bestehender Architektur getroffen werden.
Die Windows Communication Foundation (WCF) ist eine von Microsoft für das .NET Framework entwickelte Kommunikationsplattform zur Erstellung von verteilten Anwendungen. Sie wurde im Jahr 2006 mit dem .NET Framework 3.0 vorgestellt und löste damals .NET Remoting ab. Durch WCF werden die verschiedenen Aspekte einer verteilten Kommunikation logisch getrennt und dabei unterschiedliche Kommunikationstechnologien zu einer einheitlichen Programmierschnittstelle zusammengefasst. Dadurch ist es möglich, sich auf die Business-Logik zu fokussieren und sich nicht um die Anbindung der verschiedenen Kommunikationstechnologien kümmern zu müssen.
Der Aufbau von WCF
Mit der Veröffentlichung von WCF wurden die folgenden Kommunikationstechnologien vereinheitlicht.
Abbildung 1: Vereinheitlichung von Kommunikationstechnologien
Der Aufbau einer WCF Anwendung folgt dabei den 3-W‘s (Wo, Wie, Was).
Das erste W – „Wo“ beschreibt, unter welcher Adresse die Anwendung erreicht werden kann, um mit dieser zu kommunizieren, z. B.:
http://localhost:81/DataInputService
net.tcp://localhost:82/TcpDataInputService
net.pipe://localhost/PipeDataInputService
net.msmq://localhost/MsMqDataInputService
Das zweite W – „Wie“ beschreibt, mit welchen Protokollen und welchem Encoding, den sogenannten Bindings, die Kommunikation erfolgen soll. Diese werden in der *.config der Anwendung definiert und können somit jederzeit, ohne die Anwendung neu erstellen zu müssen, geändert werden. Von WCF werden neun verschiedene Bindings unterstützt:
Basic Binding (BasicHttpBinding)
TCP Binding (NetTcpBinding)
Peer Network Binding (NetPeerTcpBinding)
IPC Binding (NetNamedPipeBinding)
Web Service Binding (WSHttpBinding)
Federated WS Binding (WSFederationHttpBinding)
Duplex WS Binding (WSDualHttpBinding)
MSMQ Binding (NetMsmqBinding)
MSMQ Integration Binding (MsmqIntegrationBinding)
Mit dem letzten W – „Was“ wird durch verschiedene Contracts definiert, welche Endpunkte und Datentypen bereitgestellt werden. Dabei werden durch ServiceContracts die Endpunkte und in DataContracts die Datentypen definiert.
Beispiel eines WCF ServiceContract und DataContract:
[ServiceContract]
public interface IDataInputService
{
[OperationContract]
int CreateUser(User user);
[OperationContract]
int Login(User user);
[OperationContract]
List<Time> GetTimes(int userId);
[OperationContract]
void AddTime(Time time, int userId);
[OperationContract]
List<string> Projects();
}
[DataContract]
public class User
{
[DataMember]
public string Name { get; set; }
[DataMember]
public string Passwort { get; set; }
}
[DataContract]
public class Time
{
[DataMember]
public DateTime Start { get; set; }
[DataMember]
public DateTime End { get; set; }
[DataMember]
public string Project { get; set; }
[DataMember]
public int uId { get; set; }
[DataMember]
public int Id { get; set; }
}
Die durch die Aufteilung geschaffene Flexibilität und auch Vielseitigkeit machen WCF sehr beliebt, wodurch die Plattform in vielen Projekten gern eingesetzt wird.
Warum wird eine Migration notwendig?
Schon bei der ersten Ankündigung von .NET Core im Jahr 2016 war WCF nicht mehr enthalten. Auch in den folgenden .NET Core Releases sowie dem zuletzt vorgestellten .NET 5.0 ist WCF kein Bestandteil mehr.
Für Microsoft wäre sicher das „W“ aus WCF, welches für Windows steht, die größte Herausforderung bei einer Portierung. Hier müsste, um .NET Core gerecht zu werden, eine plattformübergreifende Lösung gefunden werden. Ein Problem dabei sind die aktuell genutzten Windows-spezifischen Betriebssystembibliotheken für z. B. Socket Layer oder Kryptographie.
Auch wenn sich die Entwickler-Community eine Integration von WCF in .NET Core wünscht, so wird diese von Microsoft wohl in absehbarer Zeit nicht erfolgen.
Die Zukunft mit gRPC und Web API
Um ein Bestandsprojekt zukunftssicher zu machen oder generell die Vorteile von .NET Core zu nutzen, sollte eine Portierung auf .NET Core angestrebt werden. Besonders sinnvoll ist dies bei Projekten, welche sich in einer aktiven und kontinuierlichen Weiterentwicklung befinden. Kommt bei einem Projekt WCF zum Einsatz, stellt dies die Portierung vor eine zusätzliche Herausforderung. Hier muss zunächst eine Alternative gefunden und eine vorbereitende Umstellung von WCF erfolgen. Microsoft empfiehlt zur Ablösung von WCF hauptsächlich zwei Alternativen, gRPC und Web API.
In einer Blogpostreihe zu diesem Thema wollen wir die beiden Alternativen vorstellen und dabei auf die Besonderheiten und Herausforderungen der Migration eingehen. Weitere Artikel folgen in Kürze.
Mit Application Insights liefert Microsoft einen Dienst zur Anwendungsüberwachung für Entwicklung und DevOps. Damit kann so gut wie alles erfasst werden – von Antwortzeiten und -raten über Fehler und Ausnahmen, Seitenaufrufe, Benutzer (-Sitzungen), Backend bis hin zu Desktop-Anwendungen.
Die Überwachung beschränkt sich keinesfalls nur auf Webseiten. Application Insights lässt sich auch bei Webdiensten sowie im Backend einsetzen. Sogar Desktop-Anwendungen lassen sich überwachen. Anschließend können die Daten über unterschiedliche Wege analysiert und ausgewertet werden (siehe Abbildung 1).
Als Ausgangsbasis wird eine Azure Subscription mit einer Application-Insights-Instanz benötigt. Ist diese angelegt, findet man in der Übersicht den sogenannten Instrumentation Key – dieser fungiert als Connection String.
Sobald die Instanz bereitgestellt wurde, kann auch schon mit der Implementierung begonnen werden. Programmiertechnisch ist man hier keinesfalls auf Azure-Ressourcen oder .Net beschränkt. Microsoft unterstützt eine Vielzahl an Sprachen und Plattformen.
Als Beispiel dient hier eine kleine .Net-Core-Konsolenanwendung. Dazu muss lediglich das NuGet-Paket Microsoft.ApplicationInsights eingebunden werden und schon kann es losgehen.
Als erstes wird ein Telemetry Client erstellt. Hier wird einfach der passende Instrumentation Key aus der eigenen Application-Insights-Instanz eingefügt und schon ist die Anwendung bereit für die ersten Log-Einträge.
Mit Trace erzeugt man einen einfachen Trace-Log-Eintrag mit entsprechender Message und passendem Severity Level.
Events eignen sich für strukturierte Logs, welche sowohl Text als auch numerische Werte enthalten können.
Metrics sind dagegen ausschließlich numerische Werte und dienen daher vor allem zur Erfassung regelmäßiger Ereignisse.
static void Main(string[] args)
{
Console.WriteLine("Schau mir in die Augen");
var config = TelemetryConfiguration.CreateDefault();
config.InstrumentationKey = "INSTRUMENTATIONKEY";
var tc = new TelemetryClient(config);
// Track traces
tc.TrackTrace("BlogTrace", SeverityLevel.Information);
// Track custom events
var et = new EventTelemetry();
et.Name = "BlogEvent";
et.Properties.Add("Source", "console");
et.Properties.Add("Context", "Schau mir in die Augen");
tc.TrackEvent(et);
// Track custom metric
var mt = new MetricTelemetry();
mt.Name = "BlogMetric";
mt.Sum = new Random().Next(1,100);
tc.TrackMetric(mt);
tc.Flush();
}
Als Hinweis sei noch erwähnt, dass die Log-Einträge mit bis zu fünf Minuten Verzögerung im Application Insights erscheinen.
Zusammenspiel mit NLog
Application Insights lässt sich mit wenigen Schritten auch in eine bestehende NLog-Konfiguration einbinden.
Dazu müssen das NuGet-Paket Microsoft.ApplicationInsights.NLogTarget installiert und danach die NLog-Konfiguration um folgende Einträge erweitern werden:
Extensions mit dem Verweis auf die Application Insights Assembly hinzufügen
Neues Target vom Typ Application Insights Target (hier wieder den eigenen Instrumentation Key angeben)
Neue Regel mit Ziel auf das Application Insights Target
Die Auswertung erfolgt anschließend über das Application-Insights-Portal. Sämtliche Logs finden sich anschließend unter Protokolle in der jeweiligen Tabelle (siehe Abbildung 2).
Abbildung 2: Auswertungen mit Application Insights
Die in der Konsolenanwendung erzeugten Trace-Logs können der Tabelle traces entnommen werden. Abfragen werden mit der Kusto Query Language (KQL) formuliert. Die Traces aus dem obigen Beispiel können über folgende Query abgefragt werden:
traces
| where message contains "BlogTrace"
Die geloggten Metriken lassen sich mit folgender Abfrage auch grafisch als Liniendiagramm darstellen (siehe Abbildung 3):
customMetrics
| where timestamp >= ago(12h)
| where name contains "Blog"
| render timechart
Abbildung 3: Grafische Darstellung der geloggten Metriken
Dashboards & Warnungsregeln
Um Unregelmäßigkeiten frühzeitig zu erkennen, können individuelle Dashboards und Warnungsregeln angelegt werden. Im Falle der oben verwendeten Metriken kann man das Diagramm an ein freigegebenes Dashboard anheften. Dies lässt sich mit weiteren Abfragen beliebig fortsetzen, bis die gewünschten Informationen zu einer Übersicht zusammengetragen sind.
Das folgende Dashboard zeigt die Metrik der Konsolenanwendung. Gleichzeitig sind darin auch exemplarisch Informationen über Serveranfragen, fehlerhafte Anfragen, Antwortzeiten sowie Leistung und Verfügbarkeit enthalten (siehe Abbildung 4).
Abbildung 4: Informationen auf einen Blick auf dem Dashboard
Hat man das Dashboard mal nicht im Blick und es kommt zu Anomalien, kann man sich auch über Warnungsregeln direkt per E-Mail oder SMS informieren lassen.
Einzelne Warnungsregeln lassen sich über den Menüpunkt Warnungen im Application-Insights-Portal anlegen und verwalten. Eine Warnungsregel besteht aus einer Signallogik (Bedingung) sowie einer Aktionsgruppe.
Bei der Bedingung wird ein Signal, z. B. eine Metrik, ausgewählt und mit einem Schwellwert versehen: „traces größer als 80“. Erhält man nun innerhalb eines definierten Zeitraumes mehr als 80 trace-Einträge, wird die Warnung ausgelöst.
Die Aktionsgruppe legt abschließend fest, was im Falle einer Warnung zu tun ist. Hier lassen sich einfache Hinweis-E-Mails oder SMS an festgelegte Personen verschicken oder komplexere Handlungen programmatisch über Runbooks, Azure Functions, Logik-Apps oder Webhooks abbilden (siehe Abbildung 5).
Abbildung 5: Verschiedene Aktionstypen in einer Aktionsgruppe
REST API
Besteht der Bedarf, die Daten auch außerhalb von Application Insights zu verarbeiten, können diese über eine REST API abgefragt werden.
Die URL für die API-Aufrufe setzt sich aus einem Basis-Teil und der gewünschten Operation zusammen. Operationen sind metrics, events oder query. Dazu muss noch ein API-Key als „X-API-Key“ HTTP-Header übergeben werden:
Um bei den oben beschriebenen Metriken zu bleiben, hier der API-Aufruf mit query-Operation für die Anzahl aller Einträge der letzten 24 Stunden:
https://api.applicationinsights.io/v1/apps/{}app-id}/query?query=customMetrics | where timestamp >= ago(24h) | where name contains „Blog“ | summarize count()
Wie anhand dieses kleinen Beispiels zu sehen ist, lässt sich ein zentralisiertes Logging mit Hilfe von Application Insights in wenigen Schritten aufbauen und verwalten. Neben der schnellen und einfachen Integration ist auch die automatisierte Infrastruktur von Vorteil. Man muss sich um kein Hosting kümmern und sollte die Last einmal steigen, skaliert Application Insights automatisch.
Auch dieses Jahr war die Saxonia Systems AG (seit 03/2020 ZEISS Digital Innovation) wieder auf der Developer Week in Nürnberg vertreten. Mit insgesamt fünf Vorträgen und einer Abendveranstaltung widmeten wir uns Themen wie „agiles Testen“, „Testautomatisierung“ und „agilen Architekturen“. Zeitgleich haben wir die Chance genutzt, um ein aktuelles Meinungsbild der Besucher zu erhalten.
In diesem Zusammenhang haben von den mehr als 1600 Besuchern 131 Personen auf unsere Fragen geantwortet. Die Umfrage ist demnach nicht repräsentativ für die gesamte Branche, gibt aber eine gewisse Aussicht und Einschätzung innerhalb der Microsoft Community.
Unsere erste Frage lautete: „Entwickeln Sie Endkunden- oder Businesssoftware?“. Die Mehrheit der Befragten gab an, dass sie an Software für Geschäftskunden arbeitet.
Abbildung 1: Welche Art von Software entwickeln Sie?
Die nächste Frage lautete: „Wie lange besteht die Software, an der Sie arbeiten?“. Die Umfrage brachte folgende Ergebnisse:
Abbildung 2: Alter von Softwaresystemen
Anhand des Ergebnisses sieht man, dass bestehende Software meist bis zu 20 Jahre alt ist. 68% der Systeme besitzen ein maximales Alter von bis zu 10 Jahren. Dies kann zum einen damit zusammen hängen, dass Version 2.0 von .Net, welche den breiten Durchbruch einläutete, erst 2006 veröffentlicht wurde und somit das Gros der heute noch genutzten .Net Anwendungen kaum älter sein kann. Auch wenn nicht danach gefragt wurde, so zeigt sich in Gesprächen, dass viele der noch älteren Anwendungen ehemalige C++ Desktopanwendungen auf Basis von MFC sind, die nach und nach zu .Net migriert wurden.
Damit sind wir auch bei der nächsten Frage: Welche Art von Technologien verwenden Sie eher?
Abbildung 3: Welche Technologien verwenden Sie eher?
Hierbei ging es insbesondere darum, zwei Vermutungen auf den Grund zu gehen. Erstens sind Webanwendungen im Durchschnitt jünger als Desktopanwendungen und zweitens finden Desktopanwendungen mehr Einsatz im Geschäftskundenumfeld.
Auch wenn nur 33 der 48 befragten Webentwickler diese Frage beantworteten, so zeigt sich zumindest ein klarer Trend zu jüngerer Software im Web. Dies lässt sich natürlich leicht darauf zurückführen, dass die Nutzung des Webs vor 20 Jahren nicht ansatzweise dem heutigen Stand entsprach und somit auch nicht annähernd die Bedeutung innerhalb von Geschäftsprozessen hatte.
Abbildung 4: Alter von Webapplikationen
Um Vermutung zwei zu untersuchen, müssen wir nun die bisherigen Zahlen gegenüberstellen. Hierbei kann man, allein schon wegen der geringen Stichprobe, nicht von einem eindeutigen Trend sprechen. Wenig überraschend ist natürlich, dass man im Geschäftskundenumfeld eine Art Mischbetrieb eher verfolgt, als bei reiner Endkundensoftware. Ansonsten sind die Zahlen so nah beieinander, dass der Trend zumindest für Microsoft basierte Anwendungen nicht nachzuweisen ist.
Abbildung 5: Gegenüberstellung des Technologie-Stacks bei Business-Software und Endkunden-Software
Der weite Einsatz von Desktoptechnologien ist auch insofern verständlich, da Microsoft basierte Technologien ihre Ursprünge auf dem Desktop haben. Lange Zeit galt es daher als gesetzt, dass man Desktopanwendungen am besten mit Microsoft Tools entwickelt. Das Web wurde erst einige Jahre später in Angriff genommen und hier ist Microsofts Konkurrenz mit Java, Ruby oder PHP auch ungleich größer.
Wenn das Web nun aber so bedeutsam ist und die Desktopanwendungen vergleichbar alt sind, dann liegt der Schluss nahe, dass zukünftig auch vom Desktop in das Web migriert werden soll. Auf diesen Gedankengang zielte dann auch unsere nächste Frage ab.
Abbildung 6: Ist es geplant Desktoptechnologien auf Webtechnologien zu migrieren?
Eine so klare Aussage hat uns stark überrascht. Natürlich ist der Trend ins Web in aller Munde, immerhin schwächelt der Absatz des Desktops seit Jahren. Wenn nun aber bei 46 von 96 Entwicklern zukünftig die Desktopclients durch Webclients ersetzt werden sollen, ist dies ein mehr als deutliches Zeichen. Hier wird auch offensichtlich, wie wichtig Microsofts Trend zur Cloudplattform Azure ist, da die Akzeptanz ihres früheren Stammgeschäfts dramatisch sinkt.
Vergleichen wir nun noch die eingesetzten Sprachen, welche uns eventuell einen zukünftigen Trend aufzeigen könnten.
Abbildung 7: Eingesetzte Sprachen im aktuellen Hauptprojekt
Deutlich an erster Stelle und mit Nennung durch fast alle Teilnehmer ist die Sprache C#. Dies wundert nicht, wenn man die Bedeutung der Sprache für das Ökosystem kennt. Viel interessanter ist das schlechte Abschneiden von Visual Basic im Vergleich. Dies wird von noch weniger Personen eingesetzt als C++ und Java. Wobei deren geringe Nennung natürlich damit zu tun hat, dass es sich bei der Developer Week um eine Konferenz handelt, die einen sehr großen Anteil von Microsoftthemen besitzt. Auch der Einsatz von Javascript ist wenig verwunderlich, wohingegen die deutliche Nennung von Type Script als ein Ausblick auf dessen zukünftige Bedeutung darstellen könnte.
Hier könnten wir etwas in die Glaskugel schauen, denn aus den bisherigen Auswertungen lässt sich durchaus folgendes Szenario konstruieren: Während reine Desktopclients an Bedeutung verlieren, ziehen Webtechnologien mit Angular und der Laufzeitumgebung Electron durchaus auch auf dem Desktop ein. Angular wiederum bietet vieles von dem, was WPF einst einzigartig gemacht hat und weniger von dem, wodurch sich AngularJS 1 für Desktopentwickler doch vergleichsweise unangenehm angefühlt hat. Gerade auch mit der nahtlosen Integration von Type Script gewinnt Angular viele der Sicherheitsmechanismen, die skalierbare Großanwendungen benötigen. Es könnte also durchaus passieren, dass so mancher Desktop Client seinen Weg über das Web zurück auf den Desktop schafft, nur in neuem Gewand.
Abbildung 8: Gegenüberstellungen der Sprachen bei Business-Software und Endkunden-Software
Abschließend betrachten wir noch den Einsatz der verwendeten Frameworks. Auch hier muss man Vorsicht walten lassen, da die geringe Teilnehmerzahl natürlich eine deutliche Unschärfe bedeuten kann.
Abbildung 9: Eingesetzte Frameworks im Hauptprojekt
Nichtsdestotrotz ist dabei interessant, wie häufig Angular 2 bereits in Hauptprojekten eingesetzt wird und dass diese Zahl fast den 17 Personen entspricht, die Typescript als Sprache angegeben haben. Dem gegenüber haben im Web die ASP.Net WebForms im Verhältnis zu ASP.Net MVC weit deutlicher verloren, als es die Windows Forms gegenüber der WPF getan haben.
Auch hier zeigten sich in den Gesprächen auf der Konferenz einige deutliche Einschätzungen: WebFroms haben gegenüber MVC keine Vorteile, wohingegen WinForms gegenüber WPF eine geringere Lernkurve und eine höhere Performanz aufweisen. Dem gegenüber bietet die WPF wiederum ein schwerer zu meisterndes Architekturmuster, welches auf Dauer aber besser wartbare Software erlaubt. Darüber hinaus kann sie weitaus einfacher gestylt werden und ermöglicht eine bessere Parallelisierung innerhalb des Teams.
Genau hier könnte sich ein Hindernis für das Glaskugel-Szenario herauskristallisieren, denn gerade auch durch die Einbindung von Win32 Applikationen in die Universal App Plattform und durch den hohen Reifegrad der Desktopapplikationen, weisen sie Vorteile gegenüber den schnelllebigen Webtechnologien auf, welche in langfristig orientierten Umgebungen nicht einfach außer Acht gelassen werden können. Hinzu kommt noch, dass Angular 2 ebenfalls eine sehr steile Lernkurve aufweist, die erst einmal gemeistert werden möchte.
