XML-RPC versus SOAP versus RMI
-
Hallo zusammen!
Was denkt Ihr?
Welche der 3 Technologien ist schneller?
Und wann würdet ihr denn welchen Ansatz verwenden?Ich hab bisher nur Erfahrung mit XML-RPC und bin mit der Performance eigentlich recht zufrieden. (Man muss natürlich die Datentypen etwas einfacher strukturieren!)
Grüße,
TS++
-
Was die Geschwindigkeit anbelangt, gilt offensichtlich folgender Zusammenhang:
XML-RPC schneller als SOAP schneller als RMI
-
Ich kenne XML-RPC persönlich nicht ... scheint aber etwas ähnliches wie SOAP zu sein.
Aber SOAP schneller als RMI, warum
Weil SOAP zahlen, etc. als Text und nicht binär durch die gegend versendet und diese auch noch beim Namen nennt?
Weil SOAP alles mögliche an zusätzlichen Encoding, Standards Informationen mitversenden?
Und nicht zuletzt, weil SOAP Nachrichten erst mit einem aufwändigem XML-Parsing in ein brauchbares Objekt gewandelt werden müßen um ausgewertet werden zu können?Oder weil RMI ein Objekt "fast" so nimmt, wie es im Speicher steht und es über die Leitung jagt?
Einzige Vorteile von SOAP IMHO sind:
- Programmiersprachen unabhängig, da alles im klartext und in einem definiertem Format übertragen wird
- einfach über HTTP zu versenden (Wegen firewall, etc.)Naja jedenfalls alles andere als die Geschwindigkeit
Wie gesagt, ich kenne XML-RPC nicht.
Kann mir aber auch nicht vorstellen, dass das schneller als RMI sein soll ... das XML deutet darauf hin
-
TS++ schrieb:
Was die Geschwindigkeit anbelangt, gilt offensichtlich folgender Zusammenhang:
XML-RPC schneller als SOAP schneller als RMI
Ziemlich sicher ist RMI das schnellste
-
Ist XML-RPC nicht eher die Aufruf-Technik? Das wäre ja was ganz anderes als SOAP, da SOAP nur die Datenstruktur ist, wie sie über die Leitung geht.
Jedenfalls würde ich die Finger von RMI lassen, wenn ich ein neues Projekt anfange. RMI ist nicht mal zwischen den Java-Versionen kompatibel. Wir hatten einen J2EE-1.3-Dienst wo alles über RMI ging und dann hatten wir auf einmal einen J2SE-1.4-Client. Nix ging mehr! Binär-inkompatibel!!!
:p 
Also, SOAP ist einfach unerlässtlich, wenn man nicht auf solche Probleme stossen will. Und pfeif darauf, das XML-WebServices langsamer sind. Hardware ist billiger als ein Reimplementierung. Vom Nervenfaktor ganz zu schweigen.
-
@Artchi: Wow! Ist das wirklich so schlimm?
Ich sehe in RMI gar nicht mal die Geschwindigkeit als Vorteil, sondern den geringeren overhead. Ihr arbeitet wahrscheinlich nur im Lan, oder? Ich finde die Redundenz von XML einfach zu hoch um solche Anwendung auch über WAN(VPN) strecken benutzen zu können.
Oder hat deine Firma auch mehrere Niederlassungen, wo die gleichen Dienste laufen? Falls dem so sein sollte wär ich dir super dankbar, wenn du kurz ein bischen zu dem Lösungsansatz erwähnen könntest!
-
Artchi schrieb:
Jedenfalls würde ich die Finger von RMI lassen, wenn ich ein neues Projekt anfange. RMI ist nicht mal zwischen den Java-Versionen kompatibel. Wir hatten einen J2EE-1.3-Dienst wo alles über RMI ging und dann hatten wir auf einmal einen J2SE-1.4-Client. Nix ging mehr! Binär-inkompatibel!!!
:p Also, SOAP ist einfach unerlässtlich, wenn man nicht auf solche Probleme stossen will. Und pfeif darauf, das XML-WebServices langsamer sind. Hardware ist billiger als ein Reimplementierung. Vom Nervenfaktor ganz zu schweigen.
Im LAN und mit Desktop-PCs magst du recht haben!
Bei WLAN und mit PDAs sieht die sache schon anders aus. Webservices und PDAs ... soll gehen, hab ich aber noch nicht hinbekommen (also was den Nervenfaktor anbelankt ...)Ich nutze die Objektserialisierung (die auch RMI nutzt) zur Kommunikation. Und ich weiss auch, dass es ein paar problemchen gibt, wenn man 2 unterschiedliche Java-Versionen verwendet.
Aber mir ist nicht bekannt, dass es inkompatibilitäten gibt, wenn man nur eigene Java-Klassen überträgt.
Das Problem hatte ich nur, als ich eine Exception von Java1.4 Server zu einen Java1.3.1 Clienten gesendet habe. Dann gibt es diesen tollen Fehler, dass die SUID des Stacktraces unterschiedlich wären oder so.
"Einfache" Lösung: Die Message der Exception in eine eigene Klasse packen und dann versenden.Die eigenen Klassen müssen dann aber alle mit einem Kompiler kompeliert worden sein... dabei sollte es egal sein ob Java 1.4 oder 1.3 ... solange keine 1.4 eigenen Erneuerungen verwendet werden.
Dennoch würde ich auch gerne auf den Web Service Zug aufspringen ... doch irgendwie habe ich bisher für PDAs keine aktzeptable Lösung gefunden.
(Die Lösung mit der Objektserialisierung funktioniert bei den Java Versionen 1.3 und 1.4 ... wer weiss was da später noch alles kommt ...)
-
Ich muß sagen, das es eigentlich egal sein sollte ob Intranet oder Internet, wenn es um XML-WebServices geht. Man muß dann halt umdenken. Z.B. das man nach Möglichkeit immer so viel Daten auf einmal abholt, wie nur möglich. D.h. als Bsp.: nicht 10x 5 KByte reine Daten abholen sondern 1x 50 KB abholen. Dann hast du sozusagen den XML-Overhead relativiert. OK, den XML-Overhead wirst du prinzipiell gegenüber reiner binärer Serialisierung nicht weg bekommen. Aber du kannst es vermindern.
XML-WebServices haben auch noch so ein paar Einschränkungen, die unschön sind. Muß man dann umplanen.
Wir haben hier einen Ritch-Client der immer gegen einen WebService geht (im Intranet-LAN). Funktioniert prinzipiell performant, und man merkt bei Anfragen und Antworten keinen nennswerten Unterschied. Auch wenn wir noch nicht so viele User haben, das wir von Auslastung reden können, da unser Projekt im Konzern erst an Fahrt gewinnt. Mit langsamer ist ja nicht gemeint, das der Server 1 Sek. für eine SOAP-Verarbeitung benötigt. Das würde erst bei Massenrequests bemerkbar werden.
Wir haben allerdings auch nen IBM WebSphere Applicatio Server auf einem normalen P4-PC laufen. (vorerst) Und IBMs WAS ist mit der schnellste WebService-Server auf dem Markt.
Im Intranet würde ich WebServices für die nächsten Projekte aber wieder auf Client-Server umschwenken und WebServices nur noch für ausgewählte Prozesse und für fremde Systeme (als Schnittstelle) anbieten.
Bei PDAs würde ich sagen, das moderne PDAs locker mit WebServices auskommen MÜSSEN. Das sind ja Powermaschinen ohne Ende: mind. 16 MB RAM und 200 MHz, hat selbst mein Palm Zire31 für 150 EUR. So ein PocketPC mit 400 MHz und 32 MB kann doch locker XML-Dokumente verarbeiten.
-
Artchi schrieb:
Im Intranet würde ich WebServices für die nächsten Projekte aber wieder auf Client-Server umschwenken und WebServices nur noch für ausgewählte Prozesse und für fremde Systeme (als Schnittstelle) anbieten.
Und was verwendest du dann stattdessen? RMI over IIOP?
Hab mir das in bezug auf inkompatibilitäten nicht genauer angesehen, aber gibt es da nicht ein ähnliches Problem wie bei RMI?Artchi schrieb:
Bei PDAs würde ich sagen, das moderne PDAs locker mit WebServices auskommen MÜSSEN. Das sind ja Powermaschinen ohne Ende: mind. 16 MB RAM und 200 MHz, hat selbst mein Palm Zire31 für 150 EUR. So ein PocketPC mit 400 MHz und 32 MB kann doch locker XML-Dokumente verarbeiten.
Naja, sie sollten es können ... ich hab bloss noch nicht rausfinden können wie
und das frustriert ganz schön, wenn man ein paar möglichkeiten ausprobiert und nichts funktioniert... das fängt bei merkwürdigen Stub-Generator-Fehlermeldungen an und hört bei fehlendem Encodierungen auf ...Kann mir aber vorstellen, dass diese XML-Dokumente schon recht lang werden können und String-Verarbeitung kostet nun mal einiges mehr an Ressourcen.
Von dem restlichen parsen mal abgesehen. Das summiert sich halt alles...Prinzipiell sehe ich die Vorteile von Web Services.
Ich bekomme sie nur nicht zum Laufen, um mal richtige Tests machen zu können.Was ich sagen kann ist, dass mal eine verschlüßelte Verbindung via Secure Sockets von dem PDA zu einem Server aufgebaut habe und da hat eine Anfrage ungefähr ca. 4-8 mal so lange gedauert. Hier kommt aber hinzu, dass die CPU nicht auf mathematische Berechnungen ausgelegt ist...
-
Ingo aka Desert Hawk schrieb:
Artchi schrieb:
Im Intranet würde ich WebServices für die nächsten Projekte aber wieder auf Client-Server umschwenken und WebServices nur noch für ausgewählte Prozesse und für fremde Systeme (als Schnittstelle) anbieten.
Und was verwendest du dann stattdessen? RMI over IIOP?
Wie gesagt Client/Server für die Datenbankabfragen, also keine Mittelschicht mehr. Noch deutlicher: Client <-> Datenbank-Server.
WebServices wie gesagt nur noch für bestimmte Prozesse und um fremden Systemen eine Schnittstelle anzubieten.
So das ich flexibel die Infrastruktur und Technik nutze. Und nicht sage: Hey, NUR WebServices. Oder: Hey, nur C/S!
Im aktuellen Projekt haben wir ersteres gemacht. Und ich sehe bisher keinen Vorteil.
Ingo aka Desert Hawk schrieb:
Naja, sie sollten es können ... ich hab bloss noch nicht rausfinden können wie
und das frustriert ganz schön, wenn man ein paar möglichkeiten ausprobiert und nichts funktioniert... das fängt bei merkwürdigen Stub-Generator-Fehlermeldungen an und hört bei fehlendem Encodierungen auf ...Kann dir da keine Hilfe geben. Welche Libs benutzt du denn? Wenn du auf PocketPC entwickelst, könnte es evtl. was im Compact-.NET Framework geben? Aber da wir hier im Java-Forum sind, vermute ich mal benutzt du Java?
Ingo aka Desert Hawk schrieb:
Was ich sagen kann ist, dass mal eine verschlüßelte Verbindung via Secure Sockets von dem PDA zu einem Server aufgebaut habe und da hat eine Anfrage ungefähr ca. 4-8 mal so lange gedauert. Hier kommt aber hinzu, dass die CPU nicht auf mathematische Berechnungen ausgelegt ist...
Ja, weil der StrongARM und Nachfolger XScale keine FPU haben. Die haben glaub ich nicht mal einen Divisionsbefehl. Der StrongARM hat definitiv kein DIV! Xscale dürfte auch noch keinen haben. Halt RISC pur!
-
Wie gesagt Client/Server für die Datenbankabfragen, also keine Mittelschicht mehr. Noch deutlicher: Client <-> Datenbank-Server.
Hmm.. bei manchen Projekten sicherlich kein Problem.
Bei anderen Projekten ist IMHO eine Middleware "fast" unverzichtbar.WebServices wie gesagt nur noch für bestimmte Prozesse und um fremden Systemen eine Schnittstelle anzubieten.
Das macht auf jeden Fall Sinn.
Welche Libs benutzt du denn? Wenn du auf PocketPC entwickelst, könnte es evtl. was im Compact-.NET Framework geben? Aber da wir hier im Java-Forum sind, vermute ich mal benutzt du Java?
Mit dem .NET CF hab ich das auch schon versucht.
.NET macht das anstandslos. .NET CF wirft mir eine unglaublich informative Fehlermeldung: "SoapException"
Mehr nicht ... ich bin der Meinung, dass eine SoapException 2^32 Möglichkeiten haben kann, darum hab ich da nicht mehr viel weiter nachgeforscht.Momentan nutze ich halt IBMs-J9 und der Appserver ist jedenfalls ein BEA-Weblogic-Server 8.1 oder so.
Zu dem XScale (den ich momentan hier stehen habe):
Soweit ich informiert bin, werden solche Befehle komplett emuliert ... mit den entsprechenden Perfomanceeinbußen