WCF-Alternativen (Teil 4) – Eine Zusammenfassung

Im letzten Blogpost der Artikelreihe zu den Alternativen der Windows Communication Foundation (WCF) wollen wir diese noch einmal zusammenfassend gegenüberstellen.

Entscheidungsmatrix

EigenschaftWeb APIgRPC
Bidirektionale KommunikationBedingt möglich
Diese muss mit SignalR realisiert werden.
Bedingt möglich
Es wird nur Stream Response unterstützt.
Aufwand Änderung in BestandscodeGering
Durch die Übernahme der Service-Methoden in die Controller und die Generierung des Clients sind nur geringe Anpassungen nötig.
Groß
Das Mapping ist nötig, da teilweise eigene Datentypen
vorgegeben sind: Es muss ein Über- und Rückgabe-Parameter existieren.
Notwendiges VorwissenTechnologiespezifisch
Web-API-Wissen zu Controller und Action-Verwendung, HTTP-Verben
Technologiespezifisch
gRPC-Besonderheiten, Erstellung *.proto-Datei
PlattformunabhängigkeitJa
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ätJa
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ützungJaOptional
Aktuell nur mit 3rd-Party-Bibliotheken möglich
Selbstbeschreibende SchnittstellenOptional
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ößeHöher
JSON, menschenlesbar
Geringer
Binary-Format
GeschwindigkeitGeringerHöher
ZukunftsfähigkeitJa
Web API wird aktuell als zukunftsfähige Alternative von Microsoft empfohlen.
Ja
gRPC wird aktuell als zukunftsfähige Alternative von Microsoft empfohlen.
DebuggingEinfach möglichBedingt 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.

WCF-Alternativen (Teil 1) – Eine Einführung

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.