Laden...

Migration von .NET (mit WCF) zu .NET Core

Erstellt von markl vor 5 Jahren Letzter Beitrag vor 5 Jahren 4.126 Views
markl Themenstarter:in
78 Beiträge seit 2016
vor 5 Jahren
Migration von .NET (mit WCF) zu .NET Core

Moin,

ich hätte da mal eine Migrationsfrage.

Aktuell habe ich mehrere .NET Fullframework-Anwendungen.
Diese werde ich nach .NET Core bzw. Standard migrieren. Die Kommunikation der Anwendungen erfolgt mit WCF (SOAP).
Folgende Anforderungen werden durch die .NET Applikation aktuell erfüllt:*WCF-Kommunikation (teilweise hochfrequent – so viel eben WCF mit SOAP zulässt) *Callbacks (nicht nur unidirektionale calls, sondern die Server senden an die Clients) _[edit 22.05.2018] _ *Die Schnittstelle soll nicht direkt vom Endanwender verwendet werden. *Die Schnittstellen sind aktuell synchron implementiert – starkes request/response-Verhalten

Die schnelle Antwort war unter anderem:
*WebApi + SignalR (ich brauche Callbacks) *nanomsg oder ZeroMQ *MQTT oder AMPQ *gRPC (…Callbacks machen da kein Spaß)

Jetzt könnte man pauschal WebApi (REST) rufen. Und für das Callback-Problem SignalR verwenden.

Was ist eure Meinung? Würde das gerne mal mit euch diskutieren.

Btw.: Ja die Anwendung soll unter Linux und unter Windows laufen (und ein wenig im Docker).

http://dotnet-paderborn.azurewebsites.net/

3.003 Beiträge seit 2006
vor 5 Jahren

Ist ein bisschen unklar, was du vor hast.

Callbacks (nicht nur unidirektionale calls, sondern die Clients senden an den Server)

Das ist kein Callback, sondern normale Client-Server-Kommunikation. Client benutzt API.

Du möchtest, dass der Server von sich aus den Client anspricht? -> SignalR

Möchtest du den Application Layer gleich mit wechseln? Oder soll der Austausch so passieren, dass die Clients das nicht merken? Und wenn ja, verstehe ich das richtig, dass du auf SOAP+REST möchtest (exotisch, geht aber)? Oder verwechselst du da Anwendungsprotokoll (SOAP) mit API-Architektur (REST)?

Und was haben deine Stichpunkte unter "schnelle Antwort" mit deinem Wunsch zur Migration nach .NET Core zu tun?

Bitte etwas ausführlicher, so wird kein Mensch schlau draus. Ich jedenfalls nicht.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

markl Themenstarter:in
78 Beiträge seit 2016
vor 5 Jahren

Natürlich möchte ich kein "SOAP+REST" ... um Gottes willen.

Vielleicht habe ich das nicht deutlich genug beschrieben.
Ziel ist es natürlich WCF (und somit auch SOAP) zu ersetzen.

Ich wollte nur eine Diskussion anregen, ob es immer pauschal WebAPI sein muss, wenn man eine alte SOAP-Implementierung loswerden will.

Möchtest du den Application Layer gleich mit wechseln? Oder soll der Austausch so passieren, dass die Clients das nicht merken?

Der Client soll auch auf .NET Core/Standard migriert werden.
Beim "Client" ist übrigens keine GUI-Anwendung mit gemeint.

Oder verwechselst du da Anwendungsprotokoll (SOAP) mit API-Architektur (REST)?

Nein verwechsel ich nicht.

Und was haben deine Stichpunkte unter "schnelle Antwort" mit deinem Wunsch zur Migration nach .NET Core zu tun?

Wir diskutieren das gerade im Team. Eine RPC-technik (oder ähnliches) die wir als Ersatz für WCF einsetzen können.

http://dotnet-paderborn.azurewebsites.net/

656 Beiträge seit 2008
vor 5 Jahren

Welche Transports/Encodings ("Bindings") hast du zur Zeit im Einsatz?

Für die clientseitige Nutzung gäbe es dotnet/wcf, aber soweit ich weiß ist davon noch kein wirklicher Server-Teil verfügbar.

3.003 Beiträge seit 2006
vor 5 Jahren

Natürlich möchte ich kein "SOAP+REST" ... um Gottes willen.

Als Roy Fielding REST das erste mal beschrieben hat, tat er das als SOAP+REST, keine Rede von "um Gottes Willen". Es wäre eine (inzwischen) seltene, aber gangbare Variante.

Vielleicht habe ich das nicht deutlich genug beschrieben.
Ziel ist es natürlich WCF (und somit auch SOAP) zu ersetzen.

Wenn ihr .net core einsetzen wollt, fällt WCF sowieso weg, und es muss eine WebAPI sein, weil ALLE .net core-Anwendungen im Grunde eine WebAPI sind*. Die Diskussion könnt ihr euch also sparen.

(@BhaaL: ja, hin und wieder wird mal öffentlich erwogen, auch die serverseitigen Aspekte von WCF zu portieren. Glaub ich erst dran, wenn ich es sehe, zumal sowas aus meiner Sicht der Zielstellung von .net core widerspräche.)

Das Design der API RESTful oder als RPC hängt im Wesentlichen davon ab, ob die durch die API integrierten Prozesse als Statuswechsel beschrieben werden sollen oder nicht. Also keine Frage des Geschmacks, sondern der Anwendung.

Parallel fallen auch einige der genannten message-Protokolle weg, schlicht weil sie .net Standard nicht unterstützen. Unklar ist darüber hinaus, welche Notwendigkeit für diese Protokolle überhaupt besteht. Der Einsatz sollte schon gut begründet sein, sonst hat man nur einen Komplexitätsgewinn ohne Nutzen.

LaTino

  • i.e. eine API, die auf HTTP(s) und TCP basiert.

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

markl Themenstarter:in
78 Beiträge seit 2016
vor 5 Jahren

Wenn ihr .net core einsetzen wollt, fällt WCF sowieso weg, und es muss eine WebAPI sein, weil ALLE .net core-Anwendungen im Grunde eine WebAPI sind
. Die Diskussion könnt ihr euch also sparen.

Das WCF weg fällt ist gekauft. Allerdings, dass es immer eine WebAPI sein muss, würde ich nicht so stehen lassen (bzw. würde ich das gerne mich euch diskutieren - wenn Ihr Zeit und Lust dazu habt).

Nur weil ich .NET Core verwende, heißt das ja nicht, dass ich zwangsweise WebAPI machen muss.

Parallel fallen auch einige der genannten message-Protokolle weg, schlicht weil sie .net Standard nicht unterstützen

Im Fall von MQTT gibt es eine ordentliche.NET Core Lib.

Aber ich gebe dir natürlich recht, es kommt auf den Use Case an.
In meinem Fall heißt dass, ich werde mehrere .NET Core Applikationen haben, die unter Umständen hochfrequent Daten austauschen wollen.

http://dotnet-paderborn.azurewebsites.net/

markl Themenstarter:in
78 Beiträge seit 2016
vor 5 Jahren

@BhaaL: WCF möchte ich in der migrierten Anwendung nicht mehr haben.
Auch wenn es Client-Libs für WCF in .NET Core gibt, und auch wenn es Bestrebungen gibt WCF-Server in .NET Core zu betreiben. WCF soll raus.

http://dotnet-paderborn.azurewebsites.net/

656 Beiträge seit 2008
vor 5 Jahren

Das war ja auch nicht die Frage 😃
Wenn du zb. NetTcpBinding oder so drin hast (und keine *HttpBinding) dann ist das natürlich auch keine HTTP-basierte Kommunikation (was WebAPI nunmal hauptsächlich wenn nicht sogar ausschließlich ist).

Kann aber auch sein dass dir das schon so bewusst war; und ich deinen Post einfach falsch interpretiert hatte.

3.003 Beiträge seit 2006
vor 5 Jahren

Das WCF weg fällt ist gekauft. Allerdings, dass es immer eine WebAPI sein muss, würde ich nicht so stehen lassen (bzw. würde ich das gerne mich euch diskutieren - wenn Ihr Zeit und Lust dazu habt).

Um ganz ehrlich zu sein, sehe ich da wenig Raum für Diskussion. .net core unterstützt per sé erst einmal nur http-basierte Kommunikation. Wenn man das diskutieren möchte, ist das gleichbedeutend damit, dass man gern seinen eigenen Kommunikationsstack in .net core implementieren möchte. Dafür sehe ich weder eine Notwendigkeit, noch einen Nutzen.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

markl Themenstarter:in
78 Beiträge seit 2016
vor 5 Jahren

.net core unterstützt per sé erst einmal nur http-basierte Kommunikation

Das stimmt so nicht.

https://apisof.net/catalog/System.Net.Sockets

Ich verwende seit längerem MQTT in .NET Core

Kann es sein, dass ein ASP bei deiner Aussage fehlt?

http://dotnet-paderborn.azurewebsites.net/

T
2.219 Beiträge seit 2008
vor 5 Jahren

@markl
Denke auch, dass er ASP .NET Core meinte.
Aber gefummel mit den Sockets sollte man lieber lassen, dafür gibt es schon passende Wrapper Klassen.
Gerade bei deinen Anforderungen würde ich SignalR nehmen.
MQTT wäre auch möglich, wenn du auf Rückmeldungen vom Server warten willst.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

markl Themenstarter:in
78 Beiträge seit 2016
vor 5 Jahren

@BhaaL:

Hatte deine letzte Frage ganz übersehen. Sorry 😃

In diesem Produkt wird sowohl "NetTcpBinding" als auch "NetNamedPipeBinding" verwendet.

In dem zweiten Fall wurde eine Interprozesskommunikation benötigt, die ein Ersatz für eine ältere COM/DCOM-Implementierung darstellt. Im Zuge der Migration wird ein RPC-Technologie gesucht, die sowohl den IPC als auch den RPC-Fall abdeckt.

I know: Auf pauschale Fragen gibt es häufig die pauschale Antwort "it depends"
Auch ich würde bei so einem Thread Antworten: "Kommt auf den Use case an"

Mich würde aber eure Erfahrungen mit RPC/IPC-Framworks in .NET Core interessieren.
Und zwar in den Fällen, in den es nicht pauschal heißt WebAPI mit ASP.NET Core (natürlich mit dem Architekturstil REST)

Zum Thema REST und ASP.net Core gibt es nun (auch in diesem Forum) genug Meinungen, Informationen und Austausch.

Zur Info:

  • Ich habe erfolgreiche Produkte mit gRPC (auch mit .NET Core)
  • MQTT zur Backend-Kommunikation läuft auch sehr stabil mit .NET Core
  • Json-RPC habe wir auch Prototypen.
  • propertitäre Socket, TCP und UDP-Implementierungen kenn ich auch genug - will sie aber nicht mehr.

Hier meine konkrete Frage und/oder Erfahrungsaustausch-Anfrage:

Was ist eure Erfahren mit RPC/IPC und/oder MessageBus-based Kommunikations-"Frameworks" in .NET Core ?

http://dotnet-paderborn.azurewebsites.net/

markl Themenstarter:in
78 Beiträge seit 2016
vor 5 Jahren

@T-Virus: Danke für deine Rückmeldung.

Mit MQTT und .NET Core (wir oben von mir beschrieben) habe ich gute Erfahrungen gemacht - wenn publish/subscriber für die Applikation ausreicht.

Für mit Mitleser 😉 :

Sehr funktionale Lib (MQTT-Client als auch MQTT-Server - wenn es mal nicht mosquitto sein soll)
https://github.com/chkr1011/MQTTnet

Hier ist ja leider nicht mehr soviel los:
https://www.eclipse.org/paho/clients/dotnet/

http://dotnet-paderborn.azurewebsites.net/

3.003 Beiträge seit 2006
vor 5 Jahren

Was ist eure Erfahren mit RPC/IPC und/oder MessageBus-based Kommunikations-"Frameworks" in .NET Core ?

Wir haben in einem Anwendungsfall ein bisschen evaluiert (zeroMQ, netMQ, Rabbit) und die Versuche zugunsten von asp.net core eingestampft. Zu unausgereift, zu unvollständig, teils überkomplexe Lösungen für einfache Probleme war das Fazit in etwa. Nun war das vor fast einem Jahr, mag sein, dass sich seitdem was getan hat.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

markl Themenstarter:in
78 Beiträge seit 2016
vor 5 Jahren

@LaTino: Danke für deine Rückmeldung

Bei NetMQ stören mich nur die Lizenzbedingungen (Angepasste LGPL v3).
Dies bedeutet immer ein erhöhter juristischer Aufwand (open source compliance).

Selber finde ich, dass zeroMQ bzw. NetMQ eine interessante Alternative ist.

http://dotnet-paderborn.azurewebsites.net/

16.806 Beiträge seit 2008
vor 5 Jahren

Ich verwende ausschließlich (aufgrund der vielen Nachteile von MQTT, vor allem MQTT is Publish/Subscribe-only - passt für IoT einfach nicht) ausschließlich AMQP via AMQPNetLite - dahinter steht steht Microsoft und das Azure Team.

.net core unterstützt per sé erst einmal nur http-basierte Kommunikation

Nein.

Es ist sogar so, dass Microsoft selbst HTTP nur als Middleware in ASP.NET Core implementiert hat und in Zukunft (sehr sehr wahrscheinlich) weitere Middlewares (zB grpc) anbieten wird.
ASP.NET Core selbst ist ja aber keine eigene Technologie mehr, sondern steckt einfach drüber und bietet im Endeffekt "nur" eine verdammt gute DI Pipeline.

Dazu hat Glenn Condron auch Samples zur Verfügung gestellt (sind zwar für MVPs, aber Public)
https://github.com/glennc/mvp/tree/master/MVPPrototypes

markl Themenstarter:in
78 Beiträge seit 2016
vor 5 Jahren

Auf AMQP hab ich eigentlich nur gewartet 😃

Dies scheint in unserem Use Case mit unter auch eine sinnvolle Lösung zu sein.

Setzt einer von euch erfolgreich gRPC ein? Wie sind hier so die Erfahrungen?
Ich weiß: Inhaltlicher Sprung von MessageBus zu rein RPC

http://dotnet-paderborn.azurewebsites.net/

3.003 Beiträge seit 2006
vor 5 Jahren

Es ist sogar so, dass Microsoft selbst HTTP nur als Middleware in ASP.NET Core implementiert hat

Daher "per sé". Von MS selbst ist die Implementierung in ASP.NET Core die einzige (edit: mir bekannte).

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

W
872 Beiträge seit 2005
vor 5 Jahren

Ich benutze schon recht lange gRPC.
Funktioniert sehr stabil - benutze es mittlerweile auch mit Python zusammen für eine externe statistische Bibliothek.
Ist wirklich narrensicher meiner Meinung nach und sehr performant.
Finde es schön, dass die API synchron und asynchron anbietet - so das man beides je nach Anwendungsfall mischen kann.
Was meinst Du mit Callbacks - das gRPC API bietet async Methoden, wo Du mit await arbeiten kannst und streaming, so dass zu einem Request mehrere Antworten kommen können.
Ich bin gerade auch bei der .NET Core Migration von bestimmten Komponenten, aber da wird es noch 1-2 Monate dauern, bis ich dort produktive Erfahrungen gemacht habe.

markl Themenstarter:in
78 Beiträge seit 2016
vor 5 Jahren

@weismat: Danke für deine Rückmeldung

Bezüglich deiner Frage "Was meinst Du mit Callbacks...":

Im Fall der existierenden Anwendungen mit WCF wird teilweise duplex contract (two-way) verwendet.

http://dotnet-paderborn.azurewebsites.net/

W
872 Beiträge seit 2005
vor 5 Jahren

Two-way wäre streaming von Client und Server - das habe ich bisher noch nicht gemacht, da ich das bisher nicht gebraucht habe. Ich streame rein vom Server her
Der Server wird in jedem Fall rein mit Async Methoden implementiert - dafür benutze ich den BufferBlock aus TPL Dataflow - da die BlockingCollection kein Methode mit await anbietet.