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.
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.
Dieser Beitrag wurde verfasst von:
