Alternative zu suds

[Damaskus]

Hallo Zusammen,

ich hab jetzt endgültig die Schnauze voll von Suds...! *auskotz*
Andauernd muss ich irgendwas fixen und am Client ändern damit Suds vernünftig mit SOAP arbeitet.
Und zudem ist es elendig langsam... es braucht bis zu 7 Sekunden um ein popeliges PDF File zu übertragen von einer VM auf den HOST.
Deswegen suche ich jetzt endgültig eine Alternative zum Suds Client die auch SOAP beherrscht!

Und nein, SOAPpy ist auch keine brauchabre alternative.
Ich will ja nicht ausschließen, dass der SOAP Server unsauber programmiert ist, aber darauf hab ich leider keinen Einfluss dank Zend Guard.

Vielleicht hat ja jemand von euch eine Idee für einen besseren SOAP Client.

Gruß
Damaskus

[mkesper]

HTTP
SNCR

[deets]

Willkommen in der wunderbaren Welt von SOAP! Das S steht fuer "simpel"!

Wenn du kannst, stell um auf ein alternatives HTTP-basiertes Protokoll. XMLRPC, oder JSONRPC, oder REST.

Wenn nicht, dann versuch dir einen Client zu besorgen, der funktioniert. Es sollte bei einem PHP-SOAP-Server ja auch einen PHP-Client geben, und mit dem solltest du dann requests vernuenftig ausfuehren koennen.

Wenn das geht, dann schaltest du einen Proxy dazwischen, und schneidest das XML fuer die entsprechenden Aufrufe einfach mit. Dann nimmst du das, und machst daraus zB ein Genshi-Template (oder eine andere Template-Engine deiner Wahl, die vll. schneller ist).

Und baust jeden Call basierend auf dem mitgeschnittenen nach.

Hoert sich krank an? Ja. Aber ist manchmal wirklich der einzige Weg. Wir betreiben so eine .NET-Schnittstelle.

Und zum Abschluss noch was erheiterndes:

http://wanderingbarque.com/nonintersect ... or-simple/

[lunar]

@Damaskus: Vielleicht hilft die entsprechende Frage auf StackOverflow. Zumindest lässt sich daraus eine Liste der existierenden Bibliotheken entnehmen, die allerdings allesamt für mehr oder weniger unbrauchbar befunden werden. "suds" wird dabei allerdings noch für die am wenigsten unbrauchbare Bibliothek gehalten.

SOAPpy ist ungeachtet dessen vielleicht trotzdem noch einen Blick wert. Es hat zumindest den Anschein, als würde sie mittlerweile wieder gewartet.

Ansonsten kann man nur dazu raten, die Angelegenheit zum Anlass zu nehmen, auf eine moderne RPC-Schnittstelle hinzuarbeiten.

[Damaskus]

Danke für die Hinweise und Gedanken von euch,
aber leider kann ich nicht auf RPC oder von mir aus auch XML wechseln.
Es muss SOAP sein... was anderes wird als Schnittstelle nicht angeboten.

Der Gedanke mit dem PHP-Proxy ist nicht schlecht aber ehrlich gesagt ist es mir zu viel Aufwand.
Da kann ich mich auch gleich an den suds Client setzen und ihn fixen...

Diesmal muss ich mich auch bei suds entschuldigen, ich hab inwzischen den "aktuellen" Fehler gefunden.
Ich sag nur "Wer lesen kann ist klar im Vorteil"... denn wenn man die Fehlermeldung aufmerksam und mit klarem Kopf liest

Code: Alles auswählen

Type not found: '(boolen, http://www.w3.org/2001/XMLSchema, )'

fällt einem auf, dass diesmal nicht der Client sondern der Server den Mist baut.

So und jetzt steh ich wieder an dem Problem mit dem Zend Guard der den PHP Code des Servers verschlüsselt...

Gruß
Damaskus

[sma]

Kannst du nicht vielleicht dem Client beibringen, das "boolen" ein Alias für "boolean" sein soll? Das ist vielleicht einfacher als PHP zu reverse-engineeren.

Stefan

[Damaskus]

Kannst du nicht vielleicht dem Client beibringen, das "boolen" ein Alias für "boolean" sein soll? Das ist vielleicht einfacher als PHP zu reverse-engineeren.

Bin schon dabei, aber gleichzeitig hab ich noch dem Maintainer des Servers einen Bug-Report geschrieben.
Ich hoffe mal die reagieren recht schnell...

Der Bug zieht sich über x Funktionen die alle als Return Wert einen Boolean Datentyp ausliefern.
Klar, dass es bei den Release-Tests nie aufgefallen ist, PHP prüft die Typen nicht sondern gibt das Ergebniss ungeprüft zurück (korrigiert mich bitte falls ich falsch liege).

Gruß
Damaskus