Optionen für einen Umstieg von WCF, Teil 3
16.12.2019, 00:00 Uhr
Umdenken ist gefragt
Bisher wurden drei Technologien für die WCF-Nachfolge vorgestellt – alle nah am Original. Die heutigen zwei Kontrahenten kommen auf anderen Wegen zum selben Ziel.
Im dritten Teil der Serie rund um die Nachfolge von WCF gehen ASP.NET Core Web API und ServiceStack an den Start. Wie alle Technologien werden sie anhand der Kriterien aus Tabelle 1 bewertet. Der Quellcode zu den vorhergehenden Teilen und diesem Teil befindet sich wieder auf GitHub [1].
Tabelle 1: Übersicht der Vergleichseigenschaften
| Eigenschaft | Beschreibung | WCF | ASP.NET Web API | ServiceStack |
| Serverseitige Architektur | ||||
| Sprache | In welcher Sprache kann ein Dienst in der Technologie implementiert werden? | C#/.NET | C#/.NET | C#/.NET |
| Plattform | Welche Plattform (SDK, Runtime) in welcher minimalen Version wird benötigt, um Dienste zu implementieren? | .NET 3.0 | .NET 4.0, .NET Core 1.0 | .NET 4.5, .NET Core 2.0 |
| Architekturstil (RMM-Level) | Handelt es sich um ein RPC-Framework oder um ein RESTful-basiertes System, und welche RMM-Level können maximal erreicht werden? | RPC (0) | RESTful (1-3) | RPC (0), RESTful (1–3) |
| Adressierung (verwendete HTTP-Verben) | Wie wird der Dienst adressiert? Gibt es nur einen Endpunkt für alle Aktionen, oder können Aktionen separat adressiert werden? Im Fall eines HTTP-Transports: Welche Verben können genutzt werden? | Single Endpoint, oft SVC-Datei (POST) | URI pro Controller/Action (alle) | URI pro Controller/Action (alle), Message Queues |
| Service Definition: Service Contract | Wie, wenn überhaupt, wird die Gesamtmentde der unterstützten Operationen des Dienstes definiert? | C#-Interface mit ServiceContract-Attribut | Keine explizite Definition | Request/Response DTOs |
| Service Definition: Operation Contract | Wie wird eine einzelne Operation des Dienstes im Rahmen des Service Contract definiert? | Methode mit OperationContract-Attribut | Methoden mit Attributen für Verben/Routing | Request/Response DTOs |
| Service Definition: Data Contract | Wie werden die Datenstrukturen des Dienstes definiert? | POCOs mit DataContract-/DataMember Attributen | POCO | Request/Response DTOs |
| Service-Implementierung | Wie wird ein Service konkret implementiert, also wie wird die Service-Definition in lauffähige Software überführt? | Interface-Implementierung des Service Contract | Ableitung von Basisklasse Controller, Implementierung der Actions als Methoden | Ableitung von Basisklasse Service, Implementierung von Methoden, die Request-DTOs akzeptieren und Response-DTOs liefern |
| Metadaten | Ist der Dienst in der Lage, sich selbst zu beschreiben, und wenn ja, in welchem Format? | WSDL | Keine, OAS | Proprietär, OAS |
| Bindungen | ||||
| Transporte | Über welche Kanäle kann der Dienst angeboten werden? | HTTP[S], TCP, Named Pipes, Message Queues | HTTP[S] | HTTP[S], Message Queues |
| Protokoll | Wie müssen Nachrichten, die zwischen Client und Server ausgetauscht werden, gestaltet sein? | SOAP | HTTP | HTTP [SOAP, aber nicht in .NET Core] |
| Serialisierung | Wie werden Nachrichten für den Versand über den Transport serialisiert? | XML, binär | JSON, XML, weitere Content-Types sind möglich | JSON, XML |
| Kommunikationsmuster | Welche Anwendungsszenarien unterstützt eine Technologie durch verschiedene Austauschmuster von Nachrichten? | One Way, Request/Response, Publish/Subscribe, Streaming | One Way, Request/Response, Pub/Sub (Web Sockets, SSE) | One Way Request/Response, Pub/Sub (Server Send Events) |
| Clientseitige Architektur | ||||
| Sprache | In welcher Sprache kann ein Dienst angesprochen werden, das heißt, in welcher Sprache lässt sich das vom Dienst verwendete Transport/Protokoll gut ansprechen? | C#/.NET, JS/TS nur bedingt, Cross-Plattform | C#/.NET/JavaScript/TypeScript, Cross-Platform | C#/.NET, JavaScript/TypeScript, Cross-Platform |
| Einsatzgebiet | Wo werden die Clients dieses Diensts überwiegend eingesetzt? | Fat Client, Backend | Fat Client, Backend, Browser | Fat Client, Backend, Browser |
| Aufruf | Über welchen Weg ruft eine Applikation den Service auf, das heißt, wie ist der Client implementiert? | Auto-generated Proxy, Generischer Proxy | HTTP-Request | Generischer Proxy, HTTP-Request |
Tabelle 1: Übersicht der Vergleichseigenschaften
| Eigenschaft | Beschreibung | WCF | ASP.NET Web API | ServiceStack |
| Serverseitige Architektur | ||||
| Sprache | In welcher Sprache kann ein Dienst in der Technologie implementiert werden? | C#/.NET | C#/.NET | C#/.NET |
| Plattform | Welche Plattform (SDK, Runtime) in welcher minimalen Version wird benötigt, um Dienste zu implementieren? | .NET 3.0 | .NET 4.0, .NET Core 1.0 | .NET 4.5, .NET Core 2.0 |
| Architekturstil (RMM-Level) | Handelt es sich um ein RPC-Framework oder um ein RESTful-basiertes System, und welche RMM-Level können maximal erreicht werden? | RPC (0) | RESTful (1-3) | RPC (0), RESTful (1–3) |
| Adressierung (verwendete HTTP-Verben) | Wie wird der Dienst adressiert? Gibt es nur einen Endpunkt für alle Aktionen, oder können Aktionen separat adressiert werden? Im Fall eines HTTP-Transports: Welche Verben können genutzt werden? | Single Endpoint, oft SVC-Datei (POST) | URI pro Controller/Action (alle) | URI pro Controller/Action (alle), Message Queues |
| Service Definition: Service Contract | Wie, wenn überhaupt, wird die Gesamtmentde der unterstützten Operationen des Dienstes definiert? | C#-Interface mit ServiceContract-Attribut | Keine explizite Definition | Request/Response DTOs |
| Service Definition: Operation Contract | Wie wird eine einzelne Operation des Dienstes im Rahmen des Service Contract definiert? | Methode mit OperationContract-Attribut | Methoden mit Attributen für Verben/Routing | Request/Response DTOs |
| Service Definition: Data Contract | Wie werden die Datenstrukturen des Dienstes definiert? | POCOs mit DataContract-/DataMember Attributen | POCO | Request/Response DTOs |
| Service-Implementierung | Wie wird ein Service konkret implementiert, also wie wird die Service-Definition in lauffähige Software überführt? | Interface-Implementierung des Service Contract | Ableitung von Basisklasse Controller, Implementierung der Actions als Methoden | Ableitung von Basisklasse Service, Implementierung von Methoden, die Request-DTOs akzeptieren und Response-DTOs liefern |
| Metadaten | Ist der Dienst in der Lage, sich selbst zu beschreiben, und wenn ja, in welchem Format? | WSDL | Keine, OAS | Proprietär, OAS |
| Bindungen | ||||
| Transporte | Über welche Kanäle kann der Dienst angeboten werden? | HTTP[S], TCP, Named Pipes, Message Queues | HTTP[S] | HTTP[S], Message Queues |
| Protokoll | Wie müssen Nachrichten, die zwischen Client und Server ausgetauscht werden, gestaltet sein? | SOAP | HTTP | HTTP [SOAP, aber nicht in .NET Core] |
| Serialisierung | Wie werden Nachrichten für den Versand über den Transport serialisiert? | XML, binär | JSON, XML, weitere Content-Types sind möglich | JSON, XML |
| Kommunikationsmuster | Welche Anwendungsszenarien unterstützt eine Technologie durch verschiedene Austauschmuster von Nachrichten? | One Way, Request/Response, Publish/Subscribe, Streaming | One Way, Request/Response, Pub/Sub (Web Sockets, SSE) | One Way Request/Response, Pub/Sub (Server Send Events) |
| Clientseitige Architektur | ||||
| Sprache | In welcher Sprache kann ein Dienst angesprochen werden, das heißt, in welcher Sprache lässt sich das vom Dienst verwendete Transport/Protokoll gut ansprechen? | C#/.NET, JS/TS nur bedingt, Cross-Plattform | C#/.NET/JavaScript/TypeScript, Cross-Platform | C#/.NET, JavaScript/TypeScript, Cross-Platform |
| Einsatzgebiet | Wo werden die Clients dieses Diensts überwiegend eingesetzt? | Fat Client, Backend | Fat Client, Backend, Browser | Fat Client, Backend, Browser |
| Aufruf | Über welchen Weg ruft eine Applikation den Service auf, das heißt, wie ist der Client implementiert? | Auto-generated Proxy, Generischer Proxy | HTTP-Request | Generischer Proxy, HTTP-Request |
Jetzt 1 Monat kostenlos testen!
Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde.
- + Digitales Kundenkonto,
- + Zugriff auf das digitale Heft,
- + Zugang zum digitalen Heftarchiv,
- + Auf Wunsch: Weekly Newsletter,
- + Sämtliche Codebeispiele im digitalen Heftarchiv verfügbar
