Diskussion:SOAP

message: ich möchte hier nur darauf hinweisen, dass ich leider selten so gut geschriebene, sauber ausformulierte und damit verständliche Artikel in Wikipedia lese. Kudos an die Beteiligten! --Zettberlin (Diskussion) 12:18, 8. Jun. 2021 (CEST)
thread_title:  Textqualität 

message: Also ich trau mich jetzt nicht, den einfach rauszulöschen. Aber eigentlich find ich den Absatz ein wenig stumpfsinnig. SOAP war als solches (nach meinen bescheidenen Infos) noch nie an ein Transportmedium gekoppelt. Dass haupstächlich HTTP benutzt wird, weils so schön einfach ist, ist was anderes. Was is mit SMTP? Wäre genauso, wie zu sagen, dass XML an HTTP gekoppelt ist.... bitte korrigiert mich. -cljk 15:44, 4. Mai 2005 (CEST)
thread_title:  Aussicht 

message: "Wir sehen daran also auch, daß der Name SOAP=Seife passend gewählt ist, die ja dann auch oft aufschäumt, wenn sie benutzt wird."
was soll denn das?
Darf ich den Satz löschen? -cljk 17:36, 10. Jun 2005 (CEST)
thread_title: Satz 

message: Weiß jemand was zu möglichen Implementationen von SOAP?
Ist SOAP abhängig von einer bestimmten Hardware-Architektur (wahrschl. nicht, wegen XML), von einem bestimmten Betriebssystem, von einer bestimmten Programmiersprache?
Irgendwo hab ich gelesen, daß SOAP "stateful" ist, XML-RPC dagegen nicht... weiß da jemand genaueres?
.
Hier wird doch weitesgehend SOAP 1.2 beschrieben. Sollte man nicht in den Beispielen auch den Namensraum auf SOAP 1.2 Recommendation setzen (http://www.w3.org/2003/05/soap-envelope/)?
=== Leider nicht nur offene Frage, sondern großes Problem ===
Ich schreibe mal aus der Sicht eines Praktikers, der Anbindungen an WebServices realisieren muss. Da werden gefühlt 99% aller Neuimplementierungen in der Welt noch mit dem Standard Saop1.1 neu implementiert. Diesen Konflikt müsste bitte mal jemand beleuchten, und dabei ausdrücklich darauf hinweisen, dass beide Standards zueinander inkompatibel sind. Ich meine im Jahr 2017 (14 Jahre nach Verabschiedung SOAP1.2) müßte eine Entwicklungsumgebung nur noch Soap1.2 anbieten. Aus welchen grottenalten Frameworks kommen da ständig die Neuimplementierungen mit Soap1.1?
Nun zu stateful oder stateless: Soap wird über HTTP(S) transportiert und HTTP(S) an sich ist erst einmal stateless. Stateful Services, die einen Session-Status brauchen, lassen sich nur mit Session-Cookies oder JSessionID realisieren und sind noch einmal eine weitere Komplikation. In dem WSDL gibt es einen Bindings-Abschnitt, z.B.:
<soap:binding style="document" .... />
Der Style "document" bedeutet, dass der Service keinen Status braucht, also stateless ist, weil ein Request alle Informationen enthält, die zur Verarbeitung des Prozesses nötig sind. Das Gegenstück "rpc" ist ein "feinkörniger" Service, wo der Client durch mehrere Aufrufe in einer definierten Reihenfolge mehrere Methoden/Funktionen des WebService aufrufen muss. Leider werden die meisten Services mit style="rpc" implementiert (ich meine entweder gedankenlos oder böswillig), obwohl es möglich wäre ein vollständiges Document mit allen nötigen Informationen zu senden. Bei Diesem "rpc" werden auch immer irgendwelche Token in einem ersten Aufruf aus einem Benutzernamen und einem Passwort generiert und der Zugriff zu den eigentlichen funktionalen Methoden ist dann nur mit dem kryptischen Token möglich. Dabei werden User und Password im ersten Call unverschlüsselt über das Netz gesendet. Das ist ein Schildbürgerstreich. Dann könnte man auch auf den Token verzichten und entweder mit HTTP-Basic Authentication arbeiten, oder Benutzer und Passwort in das Request-XML einsetzen und damit im style="document" statuslos arbeiten.
Gibt es in der ganzen Wikipedia irgendjemanden, der mal Klarheit schaffen kann und einfach mal darauf hinweisen kann, dass die Steinzeit vorüber ist? (nicht signierter Beitrag von 188.195.22.186 (Diskussion) 11:00, 8. Mär. 2017 (CET)
thread_title:  Einige offene Fragen 

message: Ich schreibe mal aus der Sicht eines Praktikers, der Anbindungen an WebServices realisieren muss. Da werden gefühlt 99% aller Neuimplementierungen in der Welt noch mit dem Standard Saop1.1 neu implementiert. Diesen Konflikt müsste bitte mal jemand beleuchten, und dabei ausdrücklich darauf hinweisen, dass beide Standards zueinander inkompatibel sind. Ich meine im Jahr 2017 (14 Jahre nach Verabschiedung SOAP1.2) müßte eine Entwicklungsumgebung nur noch Soap1.2 anbieten. Aus welchen grottenalten Frameworks kommen da ständig die Neuimplementierungen mit Soap1.1?
Nun zu stateful oder stateless: Soap wird über HTTP(S) transportiert und HTTP(S) an sich ist erst einmal stateless. Stateful Services, die einen Session-Status brauchen, lassen sich nur mit Session-Cookies oder JSessionID realisieren und sind noch einmal eine weitere Komplikation. In dem WSDL gibt es einen Bindings-Abschnitt, z.B.:
<soap:binding style="document" .... />
Der Style "document" bedeutet, dass der Service keinen Status braucht, also stateless ist, weil ein Request alle Informationen enthält, die zur Verarbeitung des Prozesses nötig sind. Das Gegenstück "rpc" ist ein "feinkörniger" Service, wo der Client durch mehrere Aufrufe in einer definierten Reihenfolge mehrere Methoden/Funktionen des WebService aufrufen muss. Leider werden die meisten Services mit style="rpc" implementiert (ich meine entweder gedankenlos oder böswillig), obwohl es möglich wäre ein vollständiges Document mit allen nötigen Informationen zu senden. Bei Diesem "rpc" werden auch immer irgendwelche Token in einem ersten Aufruf aus einem Benutzernamen und einem Passwort generiert und der Zugriff zu den eigentlichen funktionalen Methoden ist dann nur mit dem kryptischen Token möglich. Dabei werden User und Password im ersten Call unverschlüsselt über das Netz gesendet. Das ist ein Schildbürgerstreich. Dann könnte man auch auf den Token verzichten und entweder mit HTTP-Basic Authentication arbeiten, oder Benutzer und Passwort in das Request-XML einsetzen und damit im style="document" statuslos arbeiten.
Gibt es in der ganzen Wikipedia irgendjemanden, der mal Klarheit schaffen kann und einfach mal darauf hinweisen kann, dass die Steinzeit vorüber ist? (nicht signierter Beitrag von 188.195.22.186 (Diskussion) 11:00, 8. Mär. 2017 (CET)
thread_title:  Leider nicht nur offene Frage, sondern großes Problem 

message: Der Link "Soap Fight: RPC vs. Document Gegenüberstellung verschiedener SOAP-Nachrichtenstile" enthält nicht mehr den erwarteten Inhalt. (nicht signierter Beitrag von 194.25.238.250 (Diskussion) 08:27, 19. Apr. 2011 (CEST)
thread_title:  Toter Weblink 

message: Hier halte ich eine Tabelle für sinnvoll; table headers z.B. Name, zugrunde liegende Sprache, Anmerkungen, da die bestehende Liste doch recht unübersichtlich ist. --Hamburger 05:06, 15. Feb. 2009 (CET)
thread_title:  Abschnitt Implementierungen 

message: Als Weiterentwicklung daraus entstand SOAP, das Ende 1999 in Version 0.9 veröffentlicht wurde. Die Reaktion der Entwickler war jedoch noch sehr zurückhaltend. Später im Jahr 1999 wurde die Version 1.0 veröffentlicht. 
im Abschnitt Geschichtliches. Einerseits wird Ende 1999 Version 0.9 veröffentlicht und danach noch Version 1.0. Auch wenn möglich irgendwie schlecht formuliert. Wenn etwas Ende eines Jahres veröffentlicht wird erwarte ich nicht das danach noch etwas veröffentlicht wird was eigentlich ein viel grösserer Schritt ist weil 1.0 oft 'stable'-Releases ankündigt. --Think!! 20:26, 28. Jan. 2010 (CET)
thread_title:  Etwas unlogisch 

message: "SOAP wird zur Datenbankabfrage über eine Internet-Schnittstelle genutzt."
Ich finde dass diese Formulierung nicht alle Anwendungsfälle von SOAP darstellt, damit unvollständig, und damit falsch ist. Oder verstehe ich sie falsch? (nicht signierter Beitrag von 217.87.150.243 (Diskussion) 15:36, 9. Aug. 2011 (CEST)
thread_title:  "Datenbankabfrage"? 

message: Dort steht "(...) können beliebige Transportprotokolle verwendet werden, beispielsweise FTP, SMTP, HTTP oder auch JMS. (...)".
Der Link "Transportprotokolle" ist mit Schicht 4 aus dem OSI-Modell verlinkt. "FTP, SMTP, HTTP" sind aber definitiv nicht Schicht 4. (nicht signierter Beitrag von 134.3.105.248 (Diskussion) 22:41, 26. Feb. 2015 (CET)
thread_title:  Fehler in "Arbeitsweise" 

message: – GiftBot (Diskussion) 02:26, 27. Nov. 2015 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekter Weblink 

message: SOAP ist eine nicht ganz korrkte XML-Anwendung.
Während in der W3C-Empfehlung ausdrücklich seht, das XML-Namensräume (namespaces) sich ausschließlich auf Element- und Attributnamen beziehen, benutzt SOAP bspw. beim faultcode den Namensraum auch im Inhalt eines Elementes (siehe http://effbot.org/zone/elementsoap-3.htm).
<soap:Envelope xmlns:soap='...'>
  <soap:Body>
    <soap:Fault soap:encodingStyle='...'>
      <faultcode>soap:Server</faultcode>
      <faultstring>Argument must be 100 or less.</faultstring>
      <faultactor>/system</faultactor>
      <detail xmlns:xsi='...' xmlns:xsd='...' >
        <argument xsi:type='xsd:integer'>200</argument>
        <version xsi:type='xsd:string'>2.0 beta 1</version>
      </detail>
      ...
    </soap:Fault>
  </soap:Body>
</soap:Envelope>
Und sogar im Inhalt von Attributen:
<detail xmlns:xsi='...' xmlns:xsd='...' >
  <argument xsi:type='xsd:integer'>200</argument>
</detail>
Deswegen funktionieren die XML-Tools auch nicht hundertprozentig für SOAP.
--lfix 09:37, 24. Feb. 2016 (CET)
thread_title:  kleiner Fehler in SOAP 

message: "Beispielsweise nutzen eBay oder auch Amazon diese Technik zur Abwicklung von Suchanfragen."
Quelle?
--77.20.233.225 15:37, 6. Jul. 2021 (CEST)
thread_title:  Anwendungen