SOAP auf Apache installieren

[Markus (Gast)]

Hallo Zusammen,

ich suche eine einfache Möglichkeit auf einen Apache Server einen SOAP 
zu installieren um über XML Daten zu tauschen.

Momentan hänge ich extrem am PERL Modul SOAP::Lite fest.

Es gibt aber auch einige Möglichkeiten diesen in PHP zu realisieren.

Hat jemand von euch einen Tipp für mich wie ich sowas einfach und 
schnell realisieren kann.

mfg
Markus

[Peter II (Gast)]

Markus schrieb:
> Hat jemand von euch einen Tipp für mich wie ich sowas einfach und
> schnell realisieren kann.

soap setzt doch auf http auf, wo hast du das Problem? Einfach die Daten 
nach dem Soapstandard verarbeiten und dann die Passendene Antwort 
zurücksenden. Das geht mit PHP, CGI, PERL .

[Markus (Gast)]

Peter II schrieb:
> soap setzt doch auf http auf, wo hast du das Problem?

Ich komme irgendwie mit der Doku des PERL Moduls nicht zurecht.
Vielleicht braucht man auch einfach länger bis man das Versteht.

Peter II schrieb:
> Einfach die Daten
> nach dem Soapstandard verarbeiten und dann die Passendene Antwort
> zurücksenden.

Ich wollte das halt nicht selber schreiben. Da ich noch den Client 
selber schreiben wollte evtl. in Java.

[Peter II (Gast)]

Markus schrieb:
> Ich wollte das halt nicht selber schreiben. Da ich noch den Client
> selber schreiben wollte evtl. in Java.

warum denn dan soap? Soap ist eigentlich viel zu kompliziert. Selbst 
googel wendent sich davon an.

Warum nicht einfach per json übertragen?

[Markus (Gast)]

Peter II schrieb:
> Warum nicht einfach per json übertragen?

Ich schau mir das mal an.

Peter II schrieb:
> warum denn dan soap?

hab ich halt irgendwo gehört das so toll sein soll und wollte halt ein 
fertiges soap modul nutzen.

Client Server Programmierung wäre auch ok, warum ich genau soap nutzen 
will weiss ich auch nicht. Suche halt eine Gute Möglichkeit über HTTPS 
daten zu kommunizieren.

[randy (Gast)]

hi,

ich nutze die SOAP routinen von PHP auf apache; das ist eigentlich recht 
easy:

(client)

<?php
  $sClient = new SoapClient('http://<server>:5080/soap/soap.wsdl');

  $params = array(
                  'Paramter1' => 'yyy'
                  );

  try{
    $response = $sClient->MySOAPMethod($params);
    var_dump($response);
  } catch(SoapFault $e) {
    print "ERROR: \n";
    var_dump($e);
  }
?>

(server)

<?php
$wsdlfile="soap.wsdl";
function MySOAPMethod($params) {
  return array ('code' => 200, 'msg' => "MySOAPMethod() called");
}

$server = new SoapServer($wsdlfile);
$server->AddFunction("MySOAPMethod");
$server->handle();

?>

in der wsdl ist dann halt MySOAPMethod mit in- und outputmessages 
definiert etc..



HTH,
-- randy

[Markus (Gast)]

randy schrieb:
> ich nutze die SOAP routinen von PHP auf apache; das ist eigentlich recht
> easy:

danke randy das probier ich gleich mal aus

[Georg A. (georga)]

> Ich komme irgendwie mit der Doku des PERL Moduls nicht zurecht.
> Vielleicht braucht man auch einfach länger bis man das Versteht.

Ja, ist so ;) Inzwischen ist die Doku eigentlich richtig gut. Ich hatte 
vor 10 Jahren aber schon mächtig Spass damit... Das Modul ist unheimlich 
intelligent und macht von selbst schon extrem viel, meistens denkt man 
zu kompliziert. Schau dir bei Encoden unbedingt immer den XML-Output an 
bzw. nach dem Parsen die Struktur mit Data::Dumper an. Das klärt schon 
eine Menge auf.

Problematisch ist häufig, dass von irgendwoher ein WSDL kommt, nach dem 
man sich richten soll. Das braucht man in Perl eigentlich nicht 
dringend, wenn überhaupt nur beim Serialisieren, da ist AFAIK der 
Support etwas mau. Beim De-Serialisieren landet alles in den Hashes von 
Hashes. Und im Gegensatz zu anderen Sprachen (zB. Java...) kackt da auch 
nix ab, wenn sich jemand nicht exakt ans WSDL hält.

> Soap ist eigentlich viel zu kompliziert. Selbst googel wendent
> sich davon an.

Nuja, SOAP war doch im wesentlichen von MS. An sich war es nicht ganz 
verkehrt, auf XML eine definierte Struktur/Schema für RPC aufzusetzen...

> Warum nicht einfach per json übertragen?

Das macht doch eigentlich kein Unterschied in der Komplexität auf 
Server/Client-Seite. Ob ich jetzt das SOAP oder das JSON-Modul nehm, es 
kommt aus Hashes von Hashes und es geht nach Hashes von Hashes ;) Und ob 
in der Übertragungschicht jetzt <> oder {} sind, ist auch egal...

[Peter II (Gast)]

Georg A. schrieb:
> Das macht doch eigentlich kein Unterschied in der Komplexität auf
> Server/Client-Seite. Ob ich jetzt das SOAP oder das JSON-Modul nehm, es
> kommt aus Hashes von Hashes und es geht nach Hashes von Hashes ;) Und ob
> in der Übertragungschicht jetzt <> oder {} sind, ist auch egal...

aber der overhead bei xml ist eigentlich nicht mehr vertretbar. 10% 
Daten der rest struktur. Damit kann man eigentlich nur kleine dinge 
sinnvoll übertragen.

[xyz (Gast)]

Peter II schrieb:
> Georg A. schrieb:
>> Das macht doch eigentlich kein Unterschied in der Komplexität auf
>> Server/Client-Seite. Ob ich jetzt das SOAP oder das JSON-Modul nehm, es
>> kommt aus Hashes von Hashes und es geht nach Hashes von Hashes ;) Und ob
>> in der Übertragungschicht jetzt <> oder {} sind, ist auch egal...
>
> aber der overhead bei xml ist eigentlich nicht mehr vertretbar. 10%
> Daten der rest struktur. Damit kann man eigentlich nur kleine dinge
> sinnvoll übertragen.

Der vorteil von soap gegenüber json ist, das man binär-daten übertragen 
kann ohne diese z.b. in base64 encodieren zu müssen, z.b. mit MTOM 
(http://de.wikipedia.org/wiki/SOAP_Message_Transmission_Optimization_Mechanism).

[Georg A. (georga)]

... und prinzipiell kann SOAP auch mehrmals auftauchende Strukturen per 
Referenz komprimieren, das macht das Perl-Modul auch.

Mal ganz davon abgesehen, dass nach einer gzip-Komprimierung (die die 
meisten Server/Clients ja auch können), der Unterschied XML/json auch 
nicht mehr messbar ist.

[Peter II (Gast)]

Georg A. schrieb:
> Mal ganz davon abgesehen, dass nach einer gzip-Komprimierung (die die
> meisten Server/Clients ja auch können), der Unterschied XML/json auch
> nicht mehr messbar ist.

dazu kommt noch die zeit zum parsen von XML. Diese ist westentlich höher 
als bei json. Macht sich bei Server auf jeden Fall bemerkbar.

[Läubi .. (laeubi)]

Peter II schrieb:
> aber der overhead bei xml ist eigentlich nicht mehr vertretbar. 10%
> Daten der rest struktur. Damit kann man eigentlich nur kleine dinge
> sinnvoll übertragen.

So ein Quatsch... da das ganze auch über HTTP geht kannst du sogar im 
Zweifel Komprimierung einschalten dann wird (völlig transparent) die 
Redundanz wieder entfernt.
Wie du auf deine 10% kommst ist auch schleierhaft, theoretisch kann man 
auch im rootelement eine Megabyte großen Textstring übertragen dann ist 
der Overhead << 1%

Markus schrieb:
> auf einen Apache Server einen SOAP zu installieren um über
> XML Daten zu tauschen.
Höchstwarscheinlich suchst du Webservices welche das SOAP Protokoll 
nutzen: http://www.php.net/manual/de/soapserver.construct.php

Das geht sehr gut auch im Zusammenspiel mit Java. Das PERL Modul ist 
wieder eine andere Baustelle!

[Peter II (Gast)]

Läubi .. schrieb:
> Wie du auf deine 10% kommst ist auch schleierhaft, theoretisch kann man
> auch im rootelement eine Megabyte großen Textstring übertragen dann ist
> der Overhead << 1%

Einfach nur erfahrung. Ich darf regelmässig XML verarbeiten. Nach einer 
umwandlung in CSV sind die daten 90% geschrumpt.

Und selbst mit komprimierung, muss sie auf dem Server und client 
entpackt vorliegen. Und dort spielt dann der Platz doch wieder eine 
rolle.

[Peter II (Gast)]

Nachtrag:

ich bin scheinbar nicht der einzigste der es so sieht

http://de.wikipedia.org/wiki/JavaScript_Object_Notation
[...]
Ersatz für XML in Bereichen, wo Ressourcen (Speicherplatz, CPU-Leistung) 
sparsam eingesetzt werden sollen. Dies gilt im Besonderen bei der 
Entwicklung von desktopähnlichen Webanwendungen.
[...]

[Läubi .. (laeubi)]

Peter II schrieb:
> Nach einer umwandlung in CSV sind die daten 90%

Wenn sich all deine XML-Daten in CSV umwandeln lassen und CSV deine 
Anforderungen erfüllt ist das doch schön, davon aber auf die 
Allgemeinheit aller XML-Dateien zu schließen halte ich für gewagt.

Peter II schrieb:
> Und selbst mit komprimierung, muss sie auf dem Server und client
> entpackt vorliegen

Mit einem Stream-Kompressionsalgorithmus und z.B. einem SAX-Parser 
stimmt das auch nicht, es schadet nicht mal über den Tellerrand zu 
schauen und nicht nur seine eigene kleine Welt zu sehen.

Peter II schrieb:
> ich bin scheinbar nicht der einzigste der es so sieht

JSON hat wieder andere Nachteile, und da er keine "desktopähnlichen 
Webanwendungen" schreiben will auch hier nur bedingt vom Vorteil. Ein 
(SOAP/WSDL) Webservice kann sehr viel mehr leisten als simples JSON/XML 
zurückliefern.

Peter II schrieb:
> Ersatz für XML in Bereichen

Ist auch nur halb wahr, ein Ersatz kann es gar nicht sein, bestenfalls 
eine Alternative...

[Peter II (Gast)]

Läubi .. schrieb:
> Peter II schrieb:
>> Und selbst mit komprimierung, muss sie auf dem Server und client
>> entpackt vorliegen
>
> Mit einem Stream-Kompressionsalgorithmus und z.B. einem SAX-Parser
> stimmt das auch nicht, es schadet nicht mal über den Tellerrand zu
> schauen und nicht nur seine eigene kleine Welt zu sehen.

schön in der Theorie.  Aber wie sie denn die Praxis aus?

Der webserver dekomprimiert vorher die Daten damit sie der Applikation 
(PHP,PERL) zur verfügung gestellt werden können. Und dabei gibt es in 
den meisten fällen gar keinen Stream. Oder kennst du eine Möglichkeit 
wie man im Apache mit PHP die Daten ohne sie komplett im RAM zu halten 
als Steam varbeiten kann?

Ich will doch niemand SOAP oder XML ausreden, ich habe selber damit 
schon ein paar Tests gemacht und fand es einfach nicht passend für mich. 
Ich habe nur gezeigt es es auch noch Alternativen gibt, die sogar 
vorteile haben.

Ich verwende JSON/REST mit javascript und finde das recht angnehm auf 
Server und clientseite.

[Läubi .. (laeubi)]

Peter II schrieb:
> Oder kennst du eine Möglichkeit wie man im Apache
> mit PHP die Daten ohne sie komplett im RAM zu halten
> als Steam varbeiten kann?

Dafür gibt es die den Stream php://input (siehe 
http://php.net/manual/de/wrappers.php.php) wenn du 
always_populate_raw_post_data=false in der PHP ini setzt wird dir da 
direkt der Body zur Verfügung gestellt.