Optionen für einen Umstieg von WCF, Teil 4
13.01.2020, 00:00 Uhr
Der Microsoft-Favorit
In dieser abschließenden Folge der Reihe über technische Erben von WCF schicken wir das von Microsoft empfohlene Schwergewicht gRPC in den Ring.
In diesem vierten Teil der Serie rund um die Nachfolge von WCF nehmen wir das von Microsoft empfohlene und von Google entwickelte RPC-Framework gRPC [1] unter die Lupe. Wie alle Technologien wird das Framework anhand der Kriterien aus Tabelle 1 bewertet. Der Quellcode zu den vorhergehenden Teilen und zu diesem Teil befindet sich wieder auf GitHub [2].
Tabelle 1: Übersicht der Vergleichseigenschaften
| Eigenschaft | Beschreibung | WCF | gRPC | ASP.NET Web API | ServiceStack | Core WCF | IpcServiceFramework | Soap Core |
| Serverseitige Architektur | ||||||||
| Sprache | In welcher Sprache kann ein Dienst in der Technologie implementiert werden? | C#/.NET |
C#/.NET, Java, C++, Ruby, Go |
C#/.NET | C#/.NET | 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 Core 3.0 | .NET 4.0, .NET Core 1.0 | .NET 4.5, .NET Core 2.0 | .NET Core 2.2 | .NET 4.6.1, .NET Core 2.0 | .NET 4.6.1, .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) | RPC (1) | RESTful (1-3) | RPC (0), RESTful (1–3) | RPC (0) | RPC (0) | RPC (0) |
| 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 Service/Action (POST) | URI pro Controller/Action (alle) | URI pro Controller/Action (alle), Message Queues | Single Endpoint (POST) | Single Endpoint (-) | Single Endpoint (POST) |
| Service-Definition: Service Contract | Wie, wenn überhaupt, wird die Gesamtmenge der unterstützten Operationen des Dienstes definiert? | C#-Interface mit ServiceContract-Attribut | Protocol Buffers | Keine explizite Definition | Request/Response-DTOs | C#-Interface mit ServiceContract-Attribut | C#-Interface | C#-Interface mit ServiceContract-Attribut |
| Service-Definition: Operation Contract | Wie wird eine einzelne Operation des Dienstes im Rahmen des Service Contract definiert? | Methode mit OperationContract-Attribut | Protocol Buffers | Methoden mit Attributen für Verben/Routing | Request/Response-DTOs | Methode mit OperationContract-Attribut | Methode | Methode mit OperationContract-Attribut |
| Service-Definition: Data Contract | Wie werden die Datenstrukturen des Dienstes definiert? | POCOs mit DataContract-/DataMember- Attributen | Protocol Buffers | POCO | Request/Response-DTOs | POCOs mit DataContract-/DataMember-Attributen | POCO | POCOs mit DataContract-/DataMember- Attributen |
| 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 aus der .proto-Definition generierter Basisklasse, Implementierung der überschreibbaren Methoden | Ableitung von Basisklasse Controller, Implementierung der Actions als Methoden | Ableitung von Basisklasse Service, Implementierung von Methoden, die Request-DTOs akzeptieren und Response-DTOs liefern | Implementierung des Service Contract | Implementierung des Service Contract | Interface-Implementierung des Service Contract |
| Metadaten | Ist der Dienst in der Lage, sich selbst zu beschreiben, und wenn ja, in welchem Format? | WSDL | Keine Laufzeit-Metadaten, stattdessen .proto-Datei | Keine, OAS | Proprietär, OAS | Keine (WSDL noch nicht unterstützt) | Keine | WSDL |
| Bindungen | ||||||||
| Transporte | Über welche Kanäle kann der Dienst angeboten werden? | HTTP[S], TCP, Named Pipes, Message Queues | HTTP[S]/2 | HTTP[S] | HTTP[S], Message Queues | HTTP[S], TCP | TCP, Named Pipes | HTTP[S] |
| Protokoll | Wie müssen Nachrichten, die zwischen Client und Server ausgetauscht werden, gestaltet sein? | SOAP | gRPC over HTTP/2 | HTTP | HTTP [SOAP, aber nicht in .NET Core] | SOAP | Proprietär | SOAP |
| Serialisierung | Wie werden Nachrichten für den Versand über den Transport serialisiert? | XML, binär | Protobuf | JSON, XML, weitere Content-Types sind möglich | JSON, XML | XML, binär | JSON/byte[] | XML |
| Kommunikationsmuster | Welche Anwendungsszenarien unterstützt eine Technologie durch verschiedene Austauschmuster von Nachrichten? | One Way, Request/Response, Publish/Subscribe, Streaming | Request/Response, Streaming (Server, Client, bidirektional) | One Way, Request/Response, Pub/Sub (WebSockets, SSE) | One Way Request/Response, Pub/Sub (Server-Sent Events) | One Way, Request/Response, Publish/Subscribe (nur via TCP) | One Way, Request/Response | One Way, Request/Response |
| Clientseitige Architektur | ||||||||
| Sprache | In welcher Sprache kann ein Dienst angesprochen werden, das heißt, in welcher Sprache lässt sich der vom Dienst verwendete Transport und das Protokoll gut ansprechen? | C#/.NET, JS/TS nur bedingt, Cross-Plattform | C#/.NET, JS/TS nur bedingt, Cross-Plattform | C#/.NET, JavaScript/TypeScript, Cross-Plattform | C#/.NET, JavaScript/TypeScript, Cross-Plattform | C#/.NET, JS/TS nur bedingt, Cross-Plattform | C#/.NET | C#/.NET, JS/TS nur bedingt, Cross-Plattform |
| Einsatzgebiet | Wo werden die Clients dieses Dienstes überwiegend eingesetzt? | Fat Client, Backend | Fat Client, Backend | Fat Client, Backend, Browser | Fat Client, Backend, Browser | Fat Client, Backend | Fat Client, Backend | Fat Client, Backend |
| Aufruf | Über welchen Weg ruft eine Applikation den Service auf, das heißt, wie ist der Client implementiert? | Auto-generated Proxy, generischer Proxy | Auto-generated Proxy (aus .proto) | HTTP-Request | Generischer Proxy, HTTP-Request | Generischer Proxy | Generischer Proxy | Auto-generated Proxy, Generischer Proxy |
Tabelle 1: Übersicht der Vergleichseigenschaften
| Eigenschaft | Beschreibung | WCF | gRPC | ASP.NET Web API | ServiceStack | Core WCF | IpcServiceFramework | Soap Core |
| Serverseitige Architektur | ||||||||
| Sprache | In welcher Sprache kann ein Dienst in der Technologie implementiert werden? | C#/.NET |
C#/.NET, Java, C++, Ruby, Go |
C#/.NET | C#/.NET | 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 Core 3.0 | .NET 4.0, .NET Core 1.0 | .NET 4.5, .NET Core 2.0 | .NET Core 2.2 | .NET 4.6.1, .NET Core 2.0 | .NET 4.6.1, .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) | RPC (1) | RESTful (1-3) | RPC (0), RESTful (1–3) | RPC (0) | RPC (0) | RPC (0) |
| 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 Service/Action (POST) | URI pro Controller/Action (alle) | URI pro Controller/Action (alle), Message Queues | Single Endpoint (POST) | Single Endpoint (-) | Single Endpoint (POST) |
| Service-Definition: Service Contract | Wie, wenn überhaupt, wird die Gesamtmenge der unterstützten Operationen des Dienstes definiert? | C#-Interface mit ServiceContract-Attribut | Protocol Buffers | Keine explizite Definition | Request/Response-DTOs | C#-Interface mit ServiceContract-Attribut | C#-Interface | C#-Interface mit ServiceContract-Attribut |
| Service-Definition: Operation Contract | Wie wird eine einzelne Operation des Dienstes im Rahmen des Service Contract definiert? | Methode mit OperationContract-Attribut | Protocol Buffers | Methoden mit Attributen für Verben/Routing | Request/Response-DTOs | Methode mit OperationContract-Attribut | Methode | Methode mit OperationContract-Attribut |
| Service-Definition: Data Contract | Wie werden die Datenstrukturen des Dienstes definiert? | POCOs mit DataContract-/DataMember- Attributen | Protocol Buffers | POCO | Request/Response-DTOs | POCOs mit DataContract-/DataMember-Attributen | POCO | POCOs mit DataContract-/DataMember- Attributen |
| 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 aus der .proto-Definition generierter Basisklasse, Implementierung der überschreibbaren Methoden | Ableitung von Basisklasse Controller, Implementierung der Actions als Methoden | Ableitung von Basisklasse Service, Implementierung von Methoden, die Request-DTOs akzeptieren und Response-DTOs liefern | Implementierung des Service Contract | Implementierung des Service Contract | Interface-Implementierung des Service Contract |
| Metadaten | Ist der Dienst in der Lage, sich selbst zu beschreiben, und wenn ja, in welchem Format? | WSDL | Keine Laufzeit-Metadaten, stattdessen .proto-Datei | Keine, OAS | Proprietär, OAS | Keine (WSDL noch nicht unterstützt) | Keine | WSDL |
| Bindungen | ||||||||
| Transporte | Über welche Kanäle kann der Dienst angeboten werden? | HTTP[S], TCP, Named Pipes, Message Queues | HTTP[S]/2 | HTTP[S] | HTTP[S], Message Queues | HTTP[S], TCP | TCP, Named Pipes | HTTP[S] |
| Protokoll | Wie müssen Nachrichten, die zwischen Client und Server ausgetauscht werden, gestaltet sein? | SOAP | gRPC over HTTP/2 | HTTP | HTTP [SOAP, aber nicht in .NET Core] | SOAP | Proprietär | SOAP |
| Serialisierung | Wie werden Nachrichten für den Versand über den Transport serialisiert? | XML, binär | Protobuf | JSON, XML, weitere Content-Types sind möglich | JSON, XML | XML, binär | JSON/byte[] | XML |
| Kommunikationsmuster | Welche Anwendungsszenarien unterstützt eine Technologie durch verschiedene Austauschmuster von Nachrichten? | One Way, Request/Response, Publish/Subscribe, Streaming | Request/Response, Streaming (Server, Client, bidirektional) | One Way, Request/Response, Pub/Sub (WebSockets, SSE) | One Way Request/Response, Pub/Sub (Server-Sent Events) | One Way, Request/Response, Publish/Subscribe (nur via TCP) | One Way, Request/Response | One Way, Request/Response |
| Clientseitige Architektur | ||||||||
| Sprache | In welcher Sprache kann ein Dienst angesprochen werden, das heißt, in welcher Sprache lässt sich der vom Dienst verwendete Transport und das Protokoll gut ansprechen? | C#/.NET, JS/TS nur bedingt, Cross-Plattform | C#/.NET, JS/TS nur bedingt, Cross-Plattform | C#/.NET, JavaScript/TypeScript, Cross-Plattform | C#/.NET, JavaScript/TypeScript, Cross-Plattform | C#/.NET, JS/TS nur bedingt, Cross-Plattform | C#/.NET | C#/.NET, JS/TS nur bedingt, Cross-Plattform |
| Einsatzgebiet | Wo werden die Clients dieses Dienstes überwiegend eingesetzt? | Fat Client, Backend | Fat Client, Backend | Fat Client, Backend, Browser | Fat Client, Backend, Browser | Fat Client, Backend | Fat Client, Backend | Fat Client, Backend |
| Aufruf | Über welchen Weg ruft eine Applikation den Service auf, das heißt, wie ist der Client implementiert? | Auto-generated Proxy, generischer Proxy | Auto-generated Proxy (aus .proto) | HTTP-Request | Generischer Proxy, HTTP-Request | Generischer Proxy | Generischer Proxy | Auto-generated Proxy, Generischer Proxy |
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
