Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Migration von .NET (mit WCF) zu .NET Core
markl
myCSharp.de - Member

Avatar #avatar-4095.gif


Dabei seit:
Beiträge: 77

Themenstarter:

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

beantworten | zitieren | melden

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).
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von markl am .
http://dotnet-paderborn.azurewebsites.net/
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3062
Herkunft: Thüringen

beantworten | zitieren | melden

Ist ein bisschen unklar, was du vor hast.
Zitat
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)
private Nachricht | Beiträge des Benutzers
markl
myCSharp.de - Member

Avatar #avatar-4095.gif


Dabei seit:
Beiträge: 77

Themenstarter:

beantworten | zitieren | melden

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.
Zitat
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.
Zitat
Oder verwechselst du da Anwendungsprotokoll (SOAP) mit API-Architektur (REST)?

Nein verwechsel ich nicht.
Zitat
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/
private Nachricht | Beiträge des Benutzers
BhaaL
myCSharp.de - Member

Avatar #erP6yAFiewXrJTqrvg6R.jpg


Dabei seit:
Beiträge: 656

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3062
Herkunft: Thüringen

beantworten | zitieren | melden

Zitat von markl
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.
Zitat
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)
    private Nachricht | Beiträge des Benutzers
    markl
    myCSharp.de - Member

    Avatar #avatar-4095.gif


    Dabei seit:
    Beiträge: 77

    Themenstarter:

    beantworten | zitieren | melden

    Zitat
    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. [/quote]

    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.
    Zitat
    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.
    Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von markl am .
  • http://dotnet-paderborn.azurewebsites.net/
    private Nachricht | Beiträge des Benutzers
    markl
    myCSharp.de - Member

    Avatar #avatar-4095.gif


    Dabei seit:
    Beiträge: 77

    Themenstarter:

    beantworten | zitieren | melden

    @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/
    private Nachricht | Beiträge des Benutzers
    BhaaL
    myCSharp.de - Member

    Avatar #erP6yAFiewXrJTqrvg6R.jpg


    Dabei seit:
    Beiträge: 656

    beantworten | zitieren | melden

    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.
    private Nachricht | Beiträge des Benutzers
    LaTino
    myCSharp.de - Experte

    Avatar #avatar-4122.png


    Dabei seit:
    Beiträge: 3062
    Herkunft: Thüringen

    beantworten | zitieren | melden

    Zitat von markl
    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)
    private Nachricht | Beiträge des Benutzers
    markl
    myCSharp.de - Member

    Avatar #avatar-4095.gif


    Dabei seit:
    Beiträge: 77

    Themenstarter:

    beantworten | zitieren | melden

    Zitat
    .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/
    private Nachricht | Beiträge des Benutzers
    T-Virus
    myCSharp.de - Member



    Dabei seit:
    Beiträge: 1892
    Herkunft: Nordhausen, Nörten-Hardenberg

    beantworten | zitieren | melden

    @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.
    private Nachricht | Beiträge des Benutzers
    markl
    myCSharp.de - Member

    Avatar #avatar-4095.gif


    Dabei seit:
    Beiträge: 77

    Themenstarter:

    beantworten | zitieren | melden

    @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 ?
    Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von markl am .
    http://dotnet-paderborn.azurewebsites.net/
    private Nachricht | Beiträge des Benutzers
    markl
    myCSharp.de - Member

    Avatar #avatar-4095.gif


    Dabei seit:
    Beiträge: 77

    Themenstarter:

    beantworten | zitieren | melden

    @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/
    private Nachricht | Beiträge des Benutzers
    LaTino
    myCSharp.de - Experte

    Avatar #avatar-4122.png


    Dabei seit:
    Beiträge: 3062
    Herkunft: Thüringen

    beantworten | zitieren | melden

    Zitat von markl
    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)
    private Nachricht | Beiträge des Benutzers
    markl
    myCSharp.de - Member

    Avatar #avatar-4095.gif


    Dabei seit:
    Beiträge: 77

    Themenstarter:

    beantworten | zitieren | melden

    @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/
    private Nachricht | Beiträge des Benutzers
    Abt
    myCSharp.de - Team

    Avatar #avatar-4119.png


    Dabei seit:
    Beiträge: 16109

    beantworten | zitieren | melden

    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.
    Zitat
    .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
    - performance is a feature -

    Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
    private Nachricht | Beiträge des Benutzers
    markl
    myCSharp.de - Member

    Avatar #avatar-4095.gif


    Dabei seit:
    Beiträge: 77

    Themenstarter:

    beantworten | zitieren | melden

    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
    Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von markl am .
    http://dotnet-paderborn.azurewebsites.net/
    private Nachricht | Beiträge des Benutzers
    LaTino
    myCSharp.de - Experte

    Avatar #avatar-4122.png


    Dabei seit:
    Beiträge: 3062
    Herkunft: Thüringen

    beantworten | zitieren | melden

    Zitat von Abt
    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
    Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von LaTino am .
    "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)
    private Nachricht | Beiträge des Benutzers
    weismat
    myCSharp.de - Member



    Dabei seit:
    Beiträge: 878
    Herkunft: Frankfurt am Main

    beantworten | zitieren | melden

    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.
    Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von weismat am .
    private Nachricht | Beiträge des Benutzers
    markl
    myCSharp.de - Member

    Avatar #avatar-4095.gif


    Dabei seit:
    Beiträge: 77

    Themenstarter:

    beantworten | zitieren | melden

    @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/
    private Nachricht | Beiträge des Benutzers
    weismat
    myCSharp.de - Member



    Dabei seit:
    Beiträge: 878
    Herkunft: Frankfurt am Main

    beantworten | zitieren | melden

    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.
    Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von weismat am .
    private Nachricht | Beiträge des Benutzers
    Entwickelt mit ♥ und ASP.NET Core. Version 0.1.330+146e2a9f7d vom Uhr. Betrieben auf Azure App Service (debian.10-x64 mit .NET 5.0.9)
    Copyright 2003-2021 myCSharp.de - Alle Rechte vorbehalten. Benutzerinhalte unterliegen cc-by-sa 4.0