Login
Newsletter
Werbung

Thema: RPC-Framwork Dubbo wird Toplevel-Projekt von Apache

3 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von wurzel am Di, 21. Mai 2019 um 13:15 #

das kann nur schief gehen.
Software aus China und in Java
Trumpeltier wird die Verwendung verbieten und die Java-Hater-Allianz den Rest erledigen.

[
| Versenden | Drucken ]
0
Von Falk am Mi, 22. Mai 2019 um 00:22 #

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?

[
| Versenden | Drucken ]
  • 0
    Von lle am Do, 23. Mai 2019 um 12:17 #

    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

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung