Diskussion:SOAP

Textqualität

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)

weitere nachteile

Ein weiterer gravierender Nachteil ist die fehlende datentransparenz beim übertragen von strings. Der komplette string muss erst geparsed werden, > in > etc. umgewandelt werden. binärdaten können so garnicht übertragen werden, da ein \0 im stream nicht vorgesehen ist. Und das alles nur weil die herren damals meinten ein size feld bei dem string würde zuviel daten verbrauchen, well, ehm ? -- ?

diverse anmerkungen

In der Einleitung steht dieser Satz: "Die Daten müssen nicht zwingend in XML gesendet werden, andere Formate wie CSV sind auch möglich." Als Beleg wird diese Quelle angeführt: https://www.w3.org/TR/soap12-part1/#soapenv Ich finde da nichts zu den möglichen Übertragungswegen und Sendeformaten. "A SOAP message is specified as an XML infoset..." ist m.E. eine eindeutige Aussage. Dass man XML-Dokumente grundsätzlich auch in andere Formate konvertieren und diese anderen Formate senden kann, sind an dieser Stelle keine hilfreichen Informationen sondern tragen eher zur Verwirrung bei. Der Satz kann m.E. ersatzlos gestrichen werden. (nicht signierter Beitrag von 87.128.224.171 (Diskussion) 09:44, 4. Mär. 2016 (CET))

Wäre hier nicht SOAP besser? Ist immerhin nicht mehr als Abk. definiert, und Simple Object Access Protocol nicht die einzige "Übersetzung". Und eine nicht zutreffende zudem. --OliD 14:45, 27. Apr 2004 (CEST)

Finde ich auch. Wenn SOAP (oder Soap?) jetzt wie im Artikel erklärt von der definierenden Instanz als Eigenname und nicht als Abkürzung definiert wird, müßte der Artikel eigentlich verschoben werden. --HoHun 18:17, 26. Nov 2004 (CET)

"Eine wichtige Änderung ist, dass SOAP keine Abkürzung mehr ist,.." Gibt es noch weitere Unterschiede? 80.128.80.236 14:25, 15. Mär 2005 (CET)

Was soll das hier konkret ausdruecken?: "Zudem ist es so möglich, SOAP als Namen in den USA anzumelden, eine Abkürzung könnte nicht geschützt werden." -- ?

Es geht wohl um die Eintragung als Marke (Rechtsschutz) bzw. Warenzeichen. Der Autor wollte wohl damit sagen, dass Abkürzungen in den USA nicht als Marke eingetragen werden können, daher sieht man SOAP als Eigenname ohne weitere Bedeutung an, der dann doch geschützt werden kann. --Matthäus Wander 15:38, 1. Apr 2005 (CEST)

Gibt es vielleicht irgendwo einen offiziellen Schrieb, der das ganze bekräftigt (ab Version 1.2 wurde die Bedeutung als Abkürzung aufgehoben blablabla oder so?) Nicht das ich das nicht glauben würde, aber ein Zitat in einer Diplomarbeit macht sich von einer offiziellen Quelle einfach besser. --Techi22 09:38, 27. Apr 2005 (CEST)

Bist mit Deiner Arbeit bestimmt fertig, aber für alle anderen sei auf http://www.w3.org/TR/soap12-part1/#intro verwiesen. Da heißt es in einer Note "In previous versions of this specification the SOAP name was an acronym. This is no longer the case.".

Aussicht

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)

Satz

"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)

Aufblähfaktor

Im Artikel: An diesem einfachen Beispiel wird bereits deutlich, dass SOAP die Menge der zu übertragenden Daten erheblich (ca. Faktor 25 beim Request und Faktor >500 bei der Antwort) aufbläht.

Faktor >500 scheint mir nicht richtig zu sein. 4 von 453 Textzeichen im Codebeispiel gehören zu den effektiven Nutzdaten, wäre ca. Faktor 110. Auch bei Betrachtung der Dateigröße dürfte sich das nicht auf >500 steigern. Habs daher geändert, hoffe ich hab nicht irgendwas dabei übersehen.

Nun ich denke, als minimal notwendiger Responsewert wäre 1 Zeichen nötig; damit sind wir Faktor 500 schon sehr nahe oder ? -- IP

ja und? wen stört's? -- Simplicius - ☺ 15:19, 6. Jun 2006 (CEST)

wen stört was?--THEthe 08.08.2006 15:55

Ich finde das Rechenbeispiel etwas unrealistisch. Wir oft ist eine Antwort wirklich nur 4 Zeichen groß? Ich würde lieber ergänzend hinweisen, daß das Datenvolumen nicht nur durch XML aufbläht, sondern auch durch HTTP(s)

Einige offene Fragen

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

Toter Weblink

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

Abschnitt Implementierungen

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)

Etwas unlogisch

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)

"Datenbankabfrage"?

"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))

Fehler in "Arbeitsweise"

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

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.theserverside.de/webservice-in-java/
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Serverproblem (HTTP-Statuscode 500) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/http://www.theserverside.de/webservice-in-java/
  • Artikel mit gleicher URL: Webservice (aktuell)

– GiftBot (Diskussion) 02:26, 27. Nov. 2015 (CET)

kleiner Fehler in SOAP

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) (ohne Benutzername signierter Beitrag von Wiki lofi (Diskussion | Beiträge))

Anwendungen

"Beispielsweise nutzen eBay oder auch Amazon diese Technik zur Abwicklung von Suchanfragen."

Quelle?

--77.20.233.225 15:37, 6. Jul. 2021 (CEST)