Laden...

Zum Austausch von Daten: Remoting oder REST?

Erstellt von toxic vor 6 Jahren Letzter Beitrag vor 6 Jahren 3.142 Views
T
toxic Themenstarter:in
64 Beiträge seit 2010
vor 6 Jahren
Zum Austausch von Daten: Remoting oder REST?

Hi,

wir haben hier verschiedene Geschäftsanwendungen (GUI-Anwendungen) die Daten miteinander austauschen sollen. Einfaches Beispiel: Öffne Produkt XYZ im Befundsystem etc.

Ich hab sowas eigentlich immer über Remoting gemacht. (RemotingConfiguration.RegisterWellKnownServiceType)


using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Ipc;

In letzter Zeit habe ich auch ein paar Services geschrieben (OWIN REST) und hab mir die Frage gestellt ob das nicht ein einfacherer Weg wäre.

Macht das jemand schon so? Gibt es was, was dagegen spricht. So könnte ich halt Objekte etc sehr einfach von einer in die andere Anwendung schupsen. Beide Anwendungen würden dann über einen Port, ein REST API zu Verfügung stellen (Self hosted) und gut ist...

Oder ist Remoting doch noch die Richtige Wahl dafür...

P
1.090 Beiträge seit 2011
vor 6 Jahren

Ich würde den Austausch über einen Zentralen Server machen. Dann brauchen sich die Clients nicht untereinander kennen. Bei der Implementierung kannst du vielleicht SignalR verwenden. Oder Sachen aus dem IoT bereich wie MQTT könnten da ganz interessant sein.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

L
21 Beiträge seit 2015
vor 6 Jahren

Ich frage mich warum du überhaupt die Notwendigkeit hast ganze Objekte von einen in den anderen Client zu schieben. Der Client sollte sich seine Informationen die er braucht selber laden und nicht von außen reingereicht bekommen. Wenn du solche Usecases hast das wenn in Client A etwas getan wird in Client B eine aktion folgen muss nutzt man dafür irgend ein Eventsystem.

T
toxic Themenstarter:in
64 Beiträge seit 2010
vor 6 Jahren

Nein das mein ich nicht.
Ich habe in einem CAD System z.B. ein Bauteil geöffnet und möchte aus diesem einer anderen Anwendung (z.B. einem Befundsystem) sagen, mach bitte den Befund von dem im CAD geöffneten Teil auf.

Ich möchte also nur einen Befehl an die andere Software übergeben...mit einem simplen Parameter wie einer Materialnummer.

Für so Kleinigkeiten.
Bei Word kann ich ja über die Befehlzeile mitgeben, welches Dokument geöffnet werden soll.
So was ähnliches, nur das eben die Anwendung schon offen ist, und es auch nur eine Instanz von ihr gibt.

Die Anwendung laufen auch auf dem selben Client. Ich möchte keine Daten über einen zentralen Server verschieben sondern einfach nur einer anderen Anwendung sagen, mach was...

5.657 Beiträge seit 2006
vor 6 Jahren

Hi toxic,

wäre das dann nicht eher ein Anwendungsfall für ein Plugin für die CAD-Anwendung?

Weeks of programming can save you hours of planning

P
441 Beiträge seit 2014
vor 6 Jahren

Hast du dir deine Antwort nicht schon selber gegeben?

Bei Word kann ich ja über die Befehlzeile mitgeben, welches Dokument geöffnet werden soll.
So was ähnliches, nur das eben die Anwendung schon offen ist, und es auch nur eine Instanz von ihr gibt.

Warum machst du nicht genau das?

Deine zweite Anwendung (wenn es eine zweite sein muss..) wird mit einem Parameter aufgerufen. Von dieser zweiten Anwendung kann es nur eine Instanz geben. Google spuckt dazu eine ganze Menge aus. Ist schon eine Weile her, dass ich genau sowas auch implementiert habe.

3.825 Beiträge seit 2006
vor 6 Jahren

Ist das hier für Dich interessant ?

[FAQ] mehrere Programminstanzen verhindern (inkl. Parameterübergabe)

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

T
toxic Themenstarter:in
64 Beiträge seit 2010
vor 6 Jahren

Hi toxic,

wäre das dann nicht eher ein Anwendungsfall für ein Plugin für die CAD-Anwendung?

Ja es ist ein Plugin für eine CAD Anwendung, dass etwas an eine andere Geschäftsanwendung übergeben soll...

Ist das hier für Dich interessant ?

[FAQ] mehrere Programminstanzen verhindern (inkl. Parameterübergabe)

Grüße Bernd

Bis jetzt hab ich es ja so mit Remoting Mutex etc. realisiert. Ich frage mich ob es per REST und Selfhosted nicht einfacher, "besser", aktueller wäre...

16.806 Beiträge seit 2008
vor 6 Jahren

Ja, REST ist für sowas aktueller und besser (inhaltlich: Security, Erweiterbarkeit, Hosting...).

T
toxic Themenstarter:in
64 Beiträge seit 2010
vor 6 Jahren

Ja, REST ist für sowas aktueller und besser (inhaltlich: Security, Erweiterbarkeit, Hosting...).

Danke Abt, dass wollte ich hören 😁

16.806 Beiträge seit 2008
vor 6 Jahren

Ist ganz einfach: Remoting über TCP kommt i.d.R. nicht durch Firewalls.
Das heisst: super für die aktuelle Kiste, aber nicht so wirklich was in Sachen Zukunft und mehrere (externe) Ziele.
Zudem eben die Bindung an .NET.

Remoting über HTTP: da kannste gleich einfach REST nehmen.
Damit biste direkt auf ner modernen, schlanken, sicheren, unabhängigen Plattform

Mach dazu ne API und lass dazu das Client-SDK von Refit automatisch erstellen (https://github.com/paulcbetts/refit)

Dazu: Remoting ist .NET Framework-only.
Wird keinen Port für die anderen Runtimes geben.

Messaging (lieber AMQP statt MQTT, wenn möglich - MQTT eignet sicht eigentlich nur für Telemetrie-Daten im Mio-Bereich, weil schlankere Pakete. AMQP für Logic Messaging) sehe ich hier jetzt nicht zur Service-Kommunikation.
Das würde man eher für die Skalierung im Hintergrund verwenden, aber nicht für Bounded-Communication wie in diesem Fall.