Normalerweise würde ich ja sagen, dass gerade für Java mit Jakarta EE und Spring zusammen mit Webservices incl. ESB, Rest und EJBs + JMS genug standardisierte Lösungen existieren, um nicht wieder auf RPCs, Corba (klar hat Corba in Nischen - vor allem in Altsystemen - noch seine Berechtigung) und DOM zurückgreifen zu müssen.
Denn ich würde mal sagen, dass auch bei der Performance Rest gut genug ist. Spielt die Zustandslosigkeit der obigen Verfahren eine Rolle? Wird bei Dubby die Verbindung permanent gehalten?
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
das kann nur schief gehen.
Software aus China und in Java
Trumpeltier wird die Verwendung verbieten und die Java-Hater-Allianz den Rest erledigen.
Normalerweise würde ich ja sagen, dass gerade für Java mit Jakarta EE und Spring zusammen mit Webservices incl. ESB, Rest und EJBs + JMS genug standardisierte Lösungen existieren, um nicht wieder auf RPCs, Corba (klar hat Corba in Nischen - vor allem in Altsystemen - noch seine Berechtigung) und DOM zurückgreifen zu müssen.
Denn ich würde mal sagen, dass auch bei der Performance Rest gut genug ist. Spielt die Zustandslosigkeit der obigen Verfahren eine Rolle? Wird bei Dubby die Verbindung permanent gehalten?
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