Hm, würde sagen das RPC wie auch RMI den Vorteil bietet sich aus Sicht der Programmierung weder um den Layer der Kommunikation noch um das Marshalling/Unmarshalling kümmern zu müssen.
Von der Sicht der Programmierung kann ich einfach meinen Methoden oder Funktionsaufruf durchführen und um alles andere kümmert sich dann das Framework oder die Implementierung. Unabhängig ob ich eine lokale oder entfernte Methode/Funktion aufrufe. Der Aufruf ist dabei meist sync. Kann natürlich auch async. über call back arbeiten.
Okay, RMI ist halt „nur“ in JAVA … ja ich weiß, geht Dank der GraalVM jetzt auch mit anderen Sprachen (geiles Zeug ;-)). Dafür ist es sehr komfortabel da beim Zugriff auf Objekte und deren Instanzen man sich fast keine Gedanken darum machen muss wo diese entstehen und Initialisiert werden. Und zusätzlich funktioniert das Ganze auch über normale http Proxy Systeme. Nicht schlecht das alte RMI Framework
Das gute alte OSF DCE/RPC hat viele Väter oder Mütter und ist von seiner Architektur Sprachneutral ausgelegt. Zudem gibt es im Gegensatz zu CORBA kein wirklich eigenes Transport Protokoll sondern setzt im Falle von TCP direkt auf den Socket auf. Grundsätzlich ist aber RPC nicht an TCP gebunden.
Wie RMI ist auch RPC oder CORBA für den Programmierer quasi transparent was Aufruf von Funktionen und die Auswirkungen in Bezug auf die Verteilung der Anwendungslogik auf die unterschiedlichen Systeme angeht. Aus diesem Grund ist m.E. RMI und RCP oder CORBA für die Entwicklung von verteilten, eng gekoppelten Anwendungen besser geeignet als REST.
REST eignet sich m.M. sehr gut für den Einsatz in Microservice Architekturen und in Bereich von lose gekoppelten Service Infrastrukturen. Natürlich kann ich auch REST als Ersatz für RPC, RMI oder CORBA nutzen aber genauso gut kann ich auch auf REST verzichten und einfach mein eigenes Protokoll z.B. auf Basis von XML basteln und den HTTP Body als Transport nutzen. Funktioniert bestens
Aber ist alles nur meine Meinung und letztendlich Geschmacksache für was man sich begeistern kann oder was Projektauftraggeber vorgibt
Hm, würde sagen das RPC wie auch RMI den Vorteil bietet sich aus Sicht der Programmierung weder um den Layer der Kommunikation noch um das Marshalling/Unmarshalling kümmern zu müssen.
Von der Sicht der Programmierung kann ich einfach meinen Methoden oder Funktionsaufruf durchführen und um alles andere kümmert sich dann das Framework oder die Implementierung. Unabhängig ob ich eine lokale oder entfernte Methode/Funktion aufrufe. Der Aufruf ist dabei meist sync. Kann natürlich auch async. über call back arbeiten.
Okay, RMI ist halt „nur“ in JAVA … ja ich weiß, geht Dank der GraalVM jetzt auch mit anderen Sprachen (geiles Zeug ;-)). Dafür ist es sehr komfortabel da beim Zugriff auf Objekte und deren Instanzen man sich fast keine Gedanken darum machen muss wo diese entstehen und Initialisiert werden. Und zusätzlich funktioniert das Ganze auch über normale http Proxy Systeme. Nicht schlecht das alte RMI Framework
Das gute alte OSF DCE/RPC hat viele Väter oder Mütter und ist von seiner Architektur Sprachneutral ausgelegt. Zudem gibt es im Gegensatz zu CORBA kein wirklich eigenes Transport Protokoll sondern setzt im Falle von TCP direkt auf den Socket auf. Grundsätzlich ist aber RPC nicht an TCP gebunden.
Wie RMI ist auch RPC oder CORBA für den Programmierer quasi transparent was Aufruf von Funktionen und die Auswirkungen in Bezug auf die Verteilung der Anwendungslogik auf die unterschiedlichen Systeme angeht. Aus diesem Grund ist m.E. RMI und RCP oder CORBA für die Entwicklung von verteilten, eng gekoppelten Anwendungen besser geeignet als REST.
REST eignet sich m.M. sehr gut für den Einsatz in Microservice Architekturen und in Bereich von lose gekoppelten Service Infrastrukturen. Natürlich kann ich auch REST als Ersatz für RPC, RMI oder CORBA nutzen aber genauso gut kann ich auch auf REST verzichten und einfach mein eigenes Protokoll z.B. auf Basis von XML basteln und den HTTP Body als Transport nutzen. Funktioniert bestens
Aber ist alles nur meine Meinung und letztendlich Geschmacksache für was man sich begeistern kann oder was Projektauftraggeber vorgibt
lle, member of team Sheldon