Datenhaltungsserver in Python, Verbindung zu anderen Sprache

[keppla]

Hi!

Die Situation ist zZ die, dass es einen Datenbankserver (mysql5) gibt, auf den ein ganzer Haufen Programme direkt zugreifen: PHP, PERL und noch viele, die ich noch nicht kennengelernt habe.

Das führt dazu, dass vieles doppelt gemacht wird - in jeder sprache mindestens einmal, teilweise dann für verschiedene Programme in der gleichen Sprache mehrfach. Ist alles etwas "organisch".

Ich habe nun die Hoffnung, dass man das ganze verbessern könnte, indem man das ganze etwas mehr n-Tierig macht.
Der erste Ansatz wäre ein Datenhaltungsserver, um den vielen SQL-Krams aus den Anwendungen zu holen, und um durch Änderungen an der Datenbank nicht jedesmal riesige Brüche zu hinterlassen.

Ich habe nun Interesse an Vorschlägen, wie die Kommunikation zu den anderen Anwendungen am geschicktesten realisiert werden könnte.
Voraussetzungen dafür:
-Kommunikation mit PHP, PERL, Python muss möglich sein
-Kommunikation sollte wenig zusätzliche Programmierarbeit auf der Clientseite verursachen
-Kommunikation sollte effizient sein (Ungern sowas wie SOAP)

Danke schonmal im voraus.

[gerold]

Ich habe nun Interesse an Vorschlägen, wie die Kommunikation zu den anderen Anwendungen am geschicktesten realisiert werden könnte.
Voraussetzungen dafür:
-Kommunikation mit PHP, PERL, Python muss möglich sein
-Kommunikation sollte wenig zusätzliche Programmierarbeit auf der Clientseite verursachen
-Kommunikation sollte effizient sein (Ungern sowas wie SOAP)

Hi keppla!

Einfach und für die meisten Dinge ausreichend --> XMLRPC
Einfach und schnell --> Json-RPC

Hier einige Links zu diesem Thema:
http://json-rpc.org/
http://undefined.org/python/#simplejson
http://search.cpan.org/dist/JSON/
http://sourceforge.net/projects/json-py/
http://www.aurore.net/projects/php-json/
http://www.json.org/

mfg
Gerold

[keppla]

Einfach und für die meisten Dinge ausreichend --> XMLRPC
Einfach und schnell --> Json-RPC

was kann JSon denn, was XMLRPC nicht kann? Wenn ich das richtig verstanden habe, haben beide primitive Datentypen, Dictionaries (object, struct) und Tupel (array).

Kannst du mir was beruhigendes zur Geschwindigkeit sagen? Ich hab irgendwie immer so ein schlechtes Gefühl, wenn für einfache Operationen erstmal menschenlesbarer Text geparsed werden muss...

[gerold]

was kann JSon denn, was XMLRPC nicht kann? Wenn ich das richtig verstanden habe, haben beide primitive Datentypen, Dictionaries (object, struct) und Tupel (array).

Kannst du mir was beruhigendes zur Geschwindigkeit sagen? Ich hab irgendwie immer so ein schlechtes Gefühl, wenn für einfache Operationen erstmal menschenlesbarer Text geparsed werden muss...

Hi keppla!

XMLRPC ist einfach und fast jede Programmiersprache kann damit umgehen. Allerdings produziert XMLRPC einen extremen Overhead. Wie viel das ist, kannst du aus diesem Beitrag von Jens herauslesen. http://www.python-forum.de/post-33093.html#33093

Der Overhead beim Übertragen von JSON ist viel geringer. Also ist auch die Datenübertragung schneller. Natürlich ist eine Datenübertragung in Binärform immer/meistens schneller als in Textform, aber es ist um ein Vielfaches komplizierter, mehrere Programmiersprachen bei der Datenübertragung binärkompatibel zu halten. Der Aufwand steht nur dann dafür, wenn das ***WICHTIGSTE*** bei der ganzen Sache die Geschwindigkeit ist. Wenn nicht, dann würde ich mir das niemals antun.

Zu diesem Thema können dir andere Mitglieder in diesem Forum vielleicht noch mehr schreiben.

mfg
Gerold

[keppla]

XMLRPC ist einfach und fast jede Programmiersprache kann damit umgehen. Allerdings produziert XMLRPC einen extremen Overhead

Dann hab ich das nur falsch verstanden. Das klang für mich so, als hätte JSON andere Features als XMLRPC, ich fand aber keine, deshalb die Frage. Ich hatte das nicht auf Performance bezogen.

Wie viel das ist, kannst du aus diesem Beitrag von Jens herauslesen. http://www.python-forum.de/post-33093.html#33093

Ok, das ist sehr überzeugend.
Geschwindigkeit ist nicht das wichtigste (ich komme ja nicht aus der c/assembler-fraktion ), ich hatte mir nur sorgen gemacht, dass es daran scheitern würde, wenn man mehr als ab und an mal einen high-level-request á la 'alle_kunden' abschickt.

Danke für die Antworten.

[Leonidas]

Ice ist warscheinlich schneller als die ganzen auf HTTP-basierenden RPC-Protokolle und zumindest einmal für (mindestens) Python und PHP verfügbar. Das Perl Bindung müsstest du aus C++ wrappen. Wie einfach das zu integireren ist, kann ich dir nicht sagen.

Wenn du einen - wie heißt das lustige Wort - industial strenght RPC willst, dann solltest du dir CORBA ansehen, das ist schnell und es gibt viele ORBs für alle möglichen Sprachen (Fnorb, ORBit2, omniORB für Python, für Perl auch, Universe für PHP).

Dazu noch ein Python-Beispielcode. Allerdings ist das IDL-komplieren etwas nervend wobeiORBit2 das auch dynamisch können soll.

[Leonidas]

Geschwindigkeit ist nicht das wichtigste (ich komme ja nicht aus der c/assembler-fraktion ), ich hatte mir nur sorgen gemacht, dass es daran scheitern würde, wenn man mehr als ab und an mal einen high-level-request á la 'alle_kunden' abschickt.

Nein, das sollte warscheinlich auch mit XML-RPC nicht so schlimm sein (XML-RPC ist etwa ähnlich schnell wie SOAP, unterschiede betreffen eigentlich nur die Implementationen wenn überhaupt, da SOAP und XML-RPC sich sehr ähneln. Nur ist XML-RPC im Gegensatz zu SOAP besser spezifiziert und deswegen auch besser unterstüzt).

Davon abgesehen kann man auch die XML-Sachen noch durch Komprimierung laufen lassen, auch wenn ich davon eher abraten würde.

Die repräsentativsten Ergabnisse bekommst du natürlich, wenn du das selbst mal im laufenden Betrieb bei möglichst realistischen Testbedingungen ausprobierst.

[keppla]

XML-RPC ist etwa ähnlich schnell wie SOAP

Sicher? zb bei wikipedia gibt es einen Overheadvergleich, bei dem Soap deutlisch schlechter abschneidet. Ist der Overhead der entscheidende Faktor?

Nur ist XML-RPC im Gegensatz zu SOAP besser spezifiziert und deswegen auch besser unterstüzt)

Soap ist total gut spezifiziert, ich hab noch nie so viele Spezifikationen wie zu Soap gesehen

Ice werd ich mir ansehen, danke für den Tipp.
Corba scheint mir Overkill zu sein.

[Leonidas]

XML-RPC ist etwa ähnlich schnell wie SOAP

Sicher? zb bei wikipedia gibt es einen Overheadvergleich, bei dem Soap deutlisch schlechter abschneidet. Ist der Overhead der entscheidende Faktor?

Wie gesagt, die Implementation spielt hier auch noch rein. Für Python kenne ich zum Beispiel keine, die ich für SOAP empfehlen könnte.
Aber wo wir bei JSON-RPC waren, es gibt auch noch YAML-RPC.

Nur ist XML-RPC im Gegensatz zu SOAP besser spezifiziert und deswegen auch besser unterstüzt)

Soap ist total gut spezifiziert, ich hab noch nie so viele Spezifikationen wie zu Soap gesehen

Stichwort überspezifizierung. Ich habe einige Horrorstorys über SOAP Spezifikationen gelesen.

Probleme von SOAP

Weighing in at 40 pages the SOAP spec is complex and filled with little gems like, "Using SOAP for RPC is orthogonal to the SOAP protocol binding." If you ask me, it isn't even remotely something I would call "lightweight" and they threw out the most important feature of XML-RPC, its ease of use.

Du siehst also, dass wenn du die Wahl zwischen XML-RPC hast oder SOAP es oft sinnvoller ist, XML-RPC zu nehmen. Sei es wegen der Performance, sei es wegen der Qualität der XML-RPC-Libs. Außer du hast irgendwelche speziellen Ansprüche die XML-RPC einfach nicht erfüllen kann.

[keppla]

zu soap vs. xmlrpc: ich kenne soap (leider) und xmlrpc.
Der Kommentar zum "total gut spezifiziertem" soap kommt aus meinem letzten Ausflug in diese Richtung. Es war im Sinne von "The nice thing about standards is that there are so many to choose from" gemeint, deshalb der Smiley.
Mir war bisher nur noch nicht klar, dass textbasierte Protokolle zur Kommunikation bei n-Tier-modellen geeignet sind, ich hab die bisher für eine Art computerverständlicher Webseitenaufruf gehalten (also ganz high-level).

Wobei ich zZ stark zu JSON-Rpc tendiere, so wie es sich mir zZ darstellt, überträgt es ausser den nutzdaten kaum etwas und kommt ohne http aus. Ausserdem dürfte ein Parser recht schnell selbst zu schreiben sein, sollte irgendwer auf die Idee kommen, das wir Fortran oder ähnlich komisches unterstützen sollen.