Ich beschäftige mich gerad etwas näher mit Entfernten Funktionsaufrufen. Hierzu hab ich mal eine Frage an euch.
Außer das RMI speziell nur für Java ist, worin könnte der heutige Vorteil des Einsatzes von Corba gegenüber RMI bestehen, denn soweit ich gelesen habe ist Corbe heutzutage von der Performance her mit RMI gleichwertig.
P.S.
… und das Corba natürlich heterogene ist.
Corba wurde auch deshalb entwickelt um Sprach übergreifende Kommunikation zwischen Client und Server haben. Die Idee ist es die Transportobjekte in eine zwischen Sprache zu kompelieren, die einfach in die spezifische Sprache zurück gewandelt werden können.
Es macht Corba nichts aus einen Client in Java und einen Server in C++ zu haben.
In der Praxis ist das leider sehr unflexible, fehleranfällig und auch nicht gerade trivial einzurichten (wird verwenden hier jedoch ein relativ altes Corba weiß nicht ob das sich seit dem verbessert hat)
Edit:
Eine RMI alternative wäre noch SIMON
Corba war mal ein sprachunabhänger Standard für entfernte Methodenaufrufe übers Netz (also Java - C/C++ - Mainframe verbindend).
Vor zehn Jahren hat man da noch viel drüber gelesen, scheint mittlerweile mausetot zu sein. Ganz vereinfacht gesagt von Webservices/WSDL und vielen anderen Sachen (REST,…) abgelöst.
Kann mir nicht vorstellen, dass das heute überhaupt noch bei Neuimplementierungen in Betracht gezogen wird. Oder kennt hier im Forum noch einen, der neue CORBA-Software schreibt?
Unis & Schulen scheinen noch nicht mitbekommen zu haben das CORBA nur noch historisch relevant ist…
Danke für den Hinweis. Ich hab mir das über Simon mal in Wikipedia durchgelesen. Was ich nur nicht rausgelesen habe, ob SIMON jetzt heterogen oder java-spezifisch eingesetzt wird.
[QUOTE=Bleiglanz]Corba war mal ein sprachunabhänger Standard für entfernte Methodenaufrufe übers Netz (also Java - C/C++ - Mainframe verbindend).
Vor zehn Jahren hat man da noch viel drüber gelesen, scheint mittlerweile mausetot zu sein. Ganz vereinfacht gesagt von Webservices/WSDL und vielen anderen Sachen (REST,…) abgelöst.
Kann mir nicht vorstellen, dass das heute überhaupt noch bei Neuimplementierungen in Betracht gezogen wird. Oder kennt hier im Forum noch einen, der neue CORBA-Software schreibt?[/QUOTE]
Wir pflegen leider immer noch unsere 10 Jahre alte Corba Anwendung.
SIMON ist Java spezifisch und eigentlich ein besserer ERsatz für RMI.
RMI baut auf Corba auf so wie EJBs auf RMI aufbauen. Wenn du es dir aussuchen kannst, tauch nicht in das gruslige Zeug ab …
SIMON ist meines Wissens auch rein Java auch wenn es ein paar Probleme löst die RMI hat. (Verwendung bei verteilten Anwendungen über’s Internet z.B.)
Wenn du heterogene Systeme hast sind vielleicht Message Queues etwas für dich. (z.B. mit RabbitMQ), dann gibt’s noch Apache Thrift oder von @Bleiglanz schon angesprochene Webservie-Implementierungen.
@tuxedo ist der Entwickler von SIMON, er kann dazu sicherlich Detailinfos geben.
Hier der Link zu einem Announce-Thread hier im Forum: http://forum.byte-welt.net/threads/1868-SIMON-0-3-stable-kurz-vor-dem-Release
Jepp, SIMON ist Pure-Java. Theoretisch ließe sich auch eine andere Sprache an SIMON anbinden. Die Schnittstellen sind dafür vorhanden. Gemacht hat das aber noch keiner.
Ich werfe mal Remote Actors in die Runde, z.B. in Akka
Nicht dass ich das schonmal benutzt hätte…
[QUOTE=schlingel]RMI baut auf Corba auf so wie EJBs auf RMI aufbauen. Wenn du es dir aussuchen kannst, tauch nicht in das gruslige Zeug ab …
SIMON ist meines Wissens auch rein Java auch wenn es ein paar Probleme löst die RMI hat. (Verwendung bei verteilten Anwendungen über’s Internet z.B.)
Wenn du heterogene Systeme hast sind vielleicht Message Queues etwas für dich. (z.B. mit RabbitMQ), dann gibt’s noch Apache Thrift oder von @Bleiglanz schon angesprochene Webservie-Implementierungen.[/QUOTE]
Jetzt brauche ich aber mal eine Einordnung der Begrifflichkeiten, glaub das ich es bis jetzt immer falsch Verstanden habe
Danke für eure Hilfe
Ich glaube es geht jetzt ein bisschen durcheinander.
1) RPC
CORBA/RMI hat erst mal nichts mit dem Thema Messaging zu tun - es handelt sich im binäre Protokolle, die es dir erlauben
auf Rechner A ein Programm zu installieren, dass irgendwas kann (sagen wir eine Zahl (die PLZ) in einen String (den Ortsnamen) zu verwandeln)
von einem Rechner B die Daten (PLZ) an Rechner A zu schicken und das Ergebnis wieder abzuholen
dazu braucht man ein Verständigungsprotokoll (binär, SOAP, REST, Webservices, …) damit beide Rechner ihre Daten richtig interpretieren. CORBA spielt wirklich nur auf diesem Spielfeld (bzw. hat gespielt), auch wenn es natürlich als i-Tüpfelchen einer superkomplizierten Technik CORBA Messaging gab - was den Elefanten dann weiter aufgebläht hat. Kein Wunder dass er irgendwann geplatzt ist.
2) Messages
das setzt auf RPC in gewissem Sinn auf, nur hat man viel komplexere “Nachrichten”, die verschickt werden, die Bearbeitung erfolgt asynchron, es gibt Queues und Listener etc.
Zur Koordination gibt es eigene Middleware (eben Message-Server), und natürlich gibt es auch eigene Protokolle (http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol)
3) EJBs
sind Softwarekomponenten, die in sog. Anwendungsservern installiert werden. Ansprechen kann man sie per RPC, mit Messages usw. Haben primär erst mal nichts
mit dem ganzen zu tun, es gibt auf viele EJBs die einfach nur “innerhalb” ihres Servers miteinander direkt kommunizieren
Akka ist in Scala geschrieben, hat aber auch eine Java API
Ist zwar jetzt fast einen Monat her, aber eine Frage hätte ich doch noch zu diesem Thema. Mir sind zwar jetzt die einzelnen RMI, Corba, Rest, Soap etc einiger massen klar. Aber was mir noch nicht so ganz klar ist wann sollte man lieber REST und wann lieber SOAP bzw. Webservices nehmen?
REST ist hipp, SOAP ist alt.
REST ist simpel aber primitiv. SOAP ist mächtig aber komplex.
REST beschreibt den Zugang zu Resourcen. SOAP beschreibt den Zugang zu einem Service.
Defacto verwendet heute fast jeder der es sich aussuchen kann REST. Von der “Mächtigkeit” her bringt SOAP mehr Security-Features mit, für die meisten ist das XML-Security-Zeugs allerdings egal.
Vielleicht etwas hilfreicher: http://www.differencebetween.info/difference-between-rest-and-soap-web-services
In Banken und Versicherungen, Clients mit Java und C#: SOAP (besser kontrollierbar was Typen, Sicherheit, Interop usw. betrifft, leider sehr komplex). Wird aber von vielen IDEs per Drag und Drop automatisch der ganze riesige Sourcecode erzeugt.
Der Rest der Welt, Hipster, insbesondere Clients mit Javascript: immer REST
Man sollte noch ergänzen, dass die REST-Prinzipien oft recht frei interpretiert werden, und damit einiges, was unter dieser Bezeichnung läuft, nicht unbedingt als Vorbild geeignet ist.
[QUOTE=Bleiglanz]In Banken und Versicherungen, Clients mit Java und C#: SOAP (besser kontrollierbar was Typen, Sicherheit, Interop usw. betrifft, leider sehr komplex). Wird aber von vielen IDEs per Drag und Drop automatisch der ganze riesige Sourcecode erzeugt.
Der Rest der Welt, Hipster, insbesondere Clients mit Javascript: immer REST[/QUOTE]
REST mit JSON wird auch viel mobilen Anwendungen benutzt, weil der Overhead viel kleiner ist als bei SOAP