SOAP auf Apache installieren

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 .

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.

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?

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.

hi,

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

(client)

1

<?php

2

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

3

4

  $params = array(

5

                  'Paramter1' => 'yyy'

6

                  );

7

8

  try{

9

    $response = $sClient->MySOAPMethod($params);

10

    var_dump($response);

11

  } catch(SoapFault $e) {

12

    print "ERROR: \n";

13

    var_dump($e);

14

  }

15

?>

(server)

1

<?php

2

$wsdlfile="soap.wsdl";

3

function MySOAPMethod($params) {

4

  return array ('code' => 200, 'msg' => "MySOAPMethod() called");

5

}

6

7

$server = new SoapServer($wsdlfile);

8

$server->AddFunction("MySOAPMethod");

9

$server->handle();

10

11

?>

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



HTH,
-- randy

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. 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.

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. 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 .. 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.

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 .. 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.