Hvorfor SOAP?

http://en.wikipedia.org/wiki/SOAP

Advantages

    * Using SOAP over HTTP allows for easier communication behind proxies and firewalls than previous remote execution technology.
    * SOAP is versatile enough to allow for the use of different transport protocols. The standard stacks use HTTP as a transport protocol, but other protocols are also usable (e.g. SMTP).
    * Unlike its predecessor XML-RPC which presents a finite set of invokable function calls, SOAP has support for the serialisation of objects and / or their references over the connection. This allows one object oriented application to invoke methods of a remote object directly, without the requirement of the remote side having a hand written block of code to find the correct object before invoking the method.

[edit] Disadvantages

    * Because of the verbose XML format, SOAP can be considerably slower than competing middleware technologies such as CORBA. This may not be an issue when only small messages are sent[5]. On the other side, SOAP has Message Transmission Optimization Mechanism. In addition, there are emerging non-extractive XML processing models (such as VTD-XML) that promises to significantly boost SOAP processing performance.
    * When relying on HTTP as a transport protocol and not using WS-Addressing or an ESB, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other. Developers must use polling instead of notification in these common cases.
    * Many SOAP implementations limit the amount of data that can be sent.
    * Most uses of HTTP as a transport protocol are done in ignorance of how the operation would be modelled in HTTP. This agnosticism is by design (with analogy to how different protocols sit on top of each other in the IP stack) but the analogy is imperfect (because the application protocols used as transport protocols are not really transport protocols). Because of this, there is no way to know if the method used is appropriate to the operation. This makes good analysis of the operation at the application-protocol level problematic at best with results that are at least sub-optimal (if the POST-based binding is used for an application which in HTTP would be more naturally modelled as a GET operation), and which may be buggy (if, for example, the GET based binding were used for an operation which did not have the idempotency required of GET).

Ja - du har misforstået noget.

SOAP er XML.

Ved brug af SOAP sender man (normalt) ikke XML pakket ind i XML.

Ved brug af SOAP sender man (normalt) et objekt pakket ind i XML.

*) Og hvis du undrer dig over "normalt", så er en String med XML jo også et objekt.

Lad os tage et lille C# eksempel (du kan nemt læse det selvom du koder i C++ eller Java).

    [Serializable]
    public class Rec
    {
        private int f1;
        private string f2;
        public Rec() : this(0, "")
        {
        }
        public Rec(int f1, string f2)
        {
            this.f1 = f1;
            this.f2 = f2;
        }
        public int F1
        {
            get
            {
                return f1;
            }
            set
            {
                f1 = value;
            }
        }
        public string F2
        {
            get
            {
                return f2;
            }
            set
            {
                f2 = value;
            }
        }
    }

    public class DataGateway
    {
        [WebMethod]
        public Rec[] GetAll()
        {
          // implementationen er mindre vigtig
        }
    }

vi kalder en metode GetAll som returnerer et array af en klasse Rec med 2 properties F1 og F2.

SOAP request ser ud som:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetAll xmlns="http://tempuri.org/" />
  </soap:Body>
</soap:Envelope>

SOAP response ser ud som:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetAllResponse xmlns="http://tempuri.org/">
      <GetAllResult>
        <Rec>
          <F1>1</F1>
          <F2>A</F2>
        </Rec>
        <Rec>
          <F1>2</F1>
          <F2>BB</F2>
        </Rec>
      </GetAllResult>
    </GetAllResponse>
  </soap:Body>
</soap:Envelope>

Og den store fordel ved SOAP er supporten i diverse værktøjer.

Det er stort set ikke vanskelige at kalde en web service end det er at kalde
noget af ens egen kode.

Tak for svarene, som bestemt giver mig en helt anden vinkel på SOAP.

Har jeg forstået det rigtigt, hvis jeg påstår at..

SOAP er ikke bare en header der pakker de "originale" data ind.
Alle data der sendes frem og tilbage, er blevet konverteret til SOAP (XML), som så er den fælles protokol, begge programmer kan læse?

I hvert fald giver det en langt bedre mening, end den opfattelse jeg havde før, hvor SOAP blot var en "konvolut" (hvilket jeg stadig opfatter HTTP at være)
Hvis det lyder rigtigt, så smider arne_v blot et svar.

Endnu engang tak for hjælpen.

SOAP bruges til at lave et kald med.

Client skriver request SOAP XML
Server læser request SOAP XML og skriver response SOAP XML
Client læser response SOAP XML.

HTTP er transport som flytter en payload der består af SOAP XML.

WSDL XML er en beskrivelse af de mulige kald.

og et svar

Mange tak for hjælpen