What is SOAP?

The lyrical part.

Imagine that you have implemented or are implementing a certain system that should be accessible from the outside. I.e. there is a certain server with which you need to communicate. For example, a web server.

This server can perform many actions, work with the database, perform some third-party requests to other servers, do some calculations, etc. live and possibly develop according to its known scenario (i.e., according to the scenario of developers). With this it is not interesting for a person to communicate with a server, because he may not be able/not want to give beautiful pages with pictures and other user-friendly content. It is written and works to work and issue data to requests to it, without caring that they are human-readable, the client will deal with them himself.

Other systems, accessing this server, can already dispose of the data received from this server at their own discretion - process, accumulate, issue to their clients and etc.

Well, one of the options for communicating with such servers is SOAP. SOAP is an xml message exchange protocol.

The practical part.

A web service (this is the name of what the server provides and what the clients use) allows you to communicate with the server in clearly structured messages. The fact is that the web service does not accept any data. The web service will respond with an error to any message that does not comply with the rules. The error will be, by the way, also in the form of xml with a clear structure (which is not true about the message text).

WSDL (Web Services Description Language). The rules for creating messages for a web service are also described using xml and also have a clear structure. That is, if a web service provides the ability to call a method, it should allow clients to find out what parameters are used for this method. If the web service is waiting for a string for Method1 as the parameter and string must have the name Param1, then these rules will be specified in the description of the web service.

Not only simple types can be passed as parameters, but also objects and collections of objects. The description of an object is reduced to a description of each component of the object. If an object consists of several fields, it means that each field is described by what type and name it has (what possible values). Fields can also be of complex type and so on until the description of the types ends with simple ones - string, boolean, number, date... However, some specific types may be simple, it is important that customers can understand what values they may contain.

For clients, it is enough to know the url of the web service, the wsdl will always be nearby, by which you can get an idea of the methods and their parameters that this web service provides.

What are the advantages of all these bells and whistles:

• In most systems, the description of methods and types occurs in In other words, it is enough for the programmer on the server to say that this method can be called via a web service, and the wsdl description will be generated automatically.

• The description, which has a clear structure, is read by any soap client. I.e., whatever the web service is, the client will understand what data the web service accepts. According to this description, the client can build its own internal structure of object classes, the so-called binding. As a result, the programmer using the web service is left with write something like (pseudocode):

  NewUser:=TSoapUser.Create('Вася','Пупкин','odmin'); soap.AddUser(NewUser);
  

• Automatic validation.

  • xml validation. the xml must be well-formed. invalid xml-immediately an error to the client, let it be sorted out.
  • schema-validation. the xml must have a specific structure. xml does not match the schema - immediately an error to the client, let it be sorted out.
  • data validation is performed by the soap server to ensure that the data types and constraints match the description.
• Authorization and authentication can be implemented by a separate method. native. or, using http authorization.
• Web services can work both over the soap protocol and over http, that is, through get requests. That is, if the parameters are simple data (without structure), then you can just call the usual get www.site.com/users.asmx/GetUser?Name=Vasia or post. However, this is not everywhere and not always.
• ... see in wikipedia

Cons are also full:

• Unnecessarily large message size. Well, here the very nature of xml is such that the format is redundant, the more tags, the more useless information. Plus, soap adds its redundancy. For intranet systems, the issue of traffic is less acute than for the Internet, so soap for local networks is more in demand, in particular, Sharepoint has a soap web service, with which you can successfully (and with some restrictions) communicate.
• Automatically changing the description of a web service can break all clients. Well, it's like for any system, so if backward compatibility with the old methods is not supported, everything will fall off ...
• Not a minus, but a disadvantage. All method invocation actions must be atomic. For example, working with a DBMS, we can start a transaction, execute several requests, then roll back or commit. There are no transactions in soap. One request-one response, conversation finished.
• Deal with the description of what is on the server side (is everything correctly described by me?), what is on the client (what was described to me here?) it can be quite difficult. There were several times when I had to deal with the client side, and convince the server programmer that he had incorrectly described the data, and he could not understand anything in them at all, because automatic generation and he, as it were, should not, is a matter of software. And the error was naturally in the code of the method, the programmer did not see it simply.
• Practice shows that the developers of web services are terribly far from the people who use these web services. In response to any request (valid from the outside), you may receive an unintelligible error " Error 5. Everything is bad." It all depends on the conscience of the developers :)
• still probably didn't remember something...

As an example, there is an open web service belavia:

• http://86.57.245.235/TimeTable/Service.asmx - entry point, there is also a text description of the methods for third-party developers.
• http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl description of methods and types of received and returned data.
• http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - description of a specific method with an example of the type of xml request and xml response.

You can manually create and send a request of the type:

POST /TimeTable/Service.asmx HTTP/1.1
Host: 86.57.245.235
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://webservices.belavia.by/GetAirportsList"

<?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>
    <GetAirportsList xmlns="http://webservices.belavia.by/">
      <Language>ru</Language>
    </GetAirportsList>
  </soap:Body>
</soap:Envelope>

The answer will come:

HTTP/1.1 200 OK
Date: Mon, 30 Sep 2013 00:06:44 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 2940

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Body>
    <GetAirportsListResponse xmlns="http://webservices.belavia.by/">
      <GetAirportsListResult>
        <Airport IATA="ADB" Name="Измир" />
        <Airport IATA="AER" Name="Сочи(Адлер)" />
        <!-- тут пропущено куча аэропортов -->
      </GetAirportsListResult>
    </GetAirportsListResponse>
  </soap:Body>
</soap:Envelope>

ZY was previously opened aeroflot's web service, but after 1C added soap support to 8ku, a bunch of 1C beta testers successfully put it down. Now something has been changed there (I don't know the address, you can look for it if you are interested).
ZZY Disclaimer. I told them at the household level. You can kick it.

For example, you need to pass the names and values of variables to some server script - this happens almost every time you click on a link or click on a form button. It looks like this:

http://www.server.ru/page.php?name=Vasya&age=20&sex=male&street=Gagarin%2013&city=Tashkent&country=Uzbekistan

6 variables are passed here (name, age, sex, street, city, and country) with their own values. page.php In turn, accepts these values and processes them according to the specified instructions. All these variables are equal in status in the chain and do not they describedependence on each other (you will understand what this means later). Moreover, even if we only logically consider all 6 variables as one bundle, they describe one object - i.e., some male individual, whose name is Vasya and who is 20 years old (etc.), although nowhere in this URL does it say that all 6 variables together describe one object. Only intuitively do we guess and this is only suitable for this an example.

It is clear that these 6 variables do not have a description of the dependence on each other - but in order to show the dependence and the hierarchy, you need to add something.... And then XML comes to the rescue.

XML, as you already know, provides a convenient syntax for describing a data hierarchy. The format is already familiar to you:

<person>
    <id>1000</id>
    <name>Vasya</name>
    <age>20</age>
    <sex>male</sex>
    <address>
        <street>Gagarin 13</street>
        <city>Tashkent</city>
        <country>Uzbekistan</country>
    </address>
</person>

In the code above clearly the dependency and hierarchy are visible. A unit of information describing 1 an object, is a space from <person> to </person> that has nested elements arranged in a hierarchy relative to <person> below. Nested elements, as can be seen from <address>, can also have their own nested elements. Roughly speaking, the space <person> describes an individual object (together with <address> , etc., since it is the highest in the hierarchy), but <address> inside <person> also groups its subspace from <street>, <city> and <country>. I.e. if symbolically ask for the address, then we get 3 values from the nested elements (note that this is just a symbolic explanation).

So, passing in SOAP just such a structure, we can tell a certain server script not only variables and their values, but also their dependence and hierarchy. It's no coincidence that I gave an example with <address> - after all, it's very easy for a server script to get the full address of the three elements, seeing that is the parent (combining) the <address> element has nested elements! How would you then group this dependency structure using the regular format (as shown in the URL example at the very beginning)? OK, in this case, somewhere in the server script it should be specified that a certain address must be formed from the values street, city and country - also an exit, I do not argue.

And now let's complicate the task: you need to pass at a time data about several "Vasya". SOAP gives us this possibility:

<customers>
    <person>
        <id>1000</id>
        <name>Vasya</name>
        ....
    </person>
    <person>
        <id>1001</id>
        <name>Petya</name>
        ....
    </person>
</customers>

But here's how to organize this using the name=Vasya&age=20&sex=male construct? Twice the variable name (at least) name (one for Vasya, the other for Petya) because it is impossible to use in one line..

Here is a working example below of how SOAP is used in practice (from one of my working projects). It is not difficult to visually see the data structure and its hierarchy (I specifically give a very simple example of two significant variables String_1 and String_2). Above the top attributes and the corresponding syntax adopted for SOAP messages are visible (read the documentation).

P.S. It is written very conventionally and symbolically - the goal was set by the level specifically for the reader, who, having read it, will go in the right direction.

Facts: it is immediately clear that half of the respondents have a weak idea of what SOAP is. SOAP is just a protocol for exchanging data in the form of XML and period.

Lyrics: was invented at one time for web services, but life has put everything in its place - now SOAP has a fairly narrow niche as a data exchange protocol in the form of XML, and initially HTTP was provided as a transport protocol, but now it is being pushed with all its might over any transport protocols.

Future: very vague. Most likely, simpler and more cost-effective protocols will displace SOAP from the web service niche. 10 years ago, everyone excitedly talked only about SOAP, and now there are already people who need to explain what kind of beast it is.

Simple?..well, OK: this is crap that was originally planned as a thing that allowed you to call object methods remotely (ROC is not afraid of this word)...that is, only the interface is implemented on the client machine, and all the work takes place on the server. Now it is also used for data exchange, i.e. you send a XML message with a request, and you get a XML message with a response.

But this is all very rude.

Many government services and payment systems (QIWI, cyberplat, Sberbank) provide services using the SOAP protocol. These systems are very "tight" for development, so the future of SOAP is not vague - it will not go anywhere yet. In addition to the rigid structure of messages-responses, SOAP allows you to sign messages using various means (crypto-providers), which is one of the main arguments for using "serious" web services (FIU, FMS, doctor's appointment, etc.). From the point of view of For the client developer, the advantage is the ability to generate classes according to the existing WSDL scheme, and access the remote WS as a normal object (by calling methods). For a WS developer, two approaches are also convenient - generating a WS implementation from an existing WSDL, or creating a WS using annotations and generating a WSDL based on code (java, C#).

About the disadvantages of SOAP above all wrote. I can only correct it:

Not a minus, but a disadvantage. All method invocation actions must be atomic. For example, working with a DBMS, we can start a transaction, execute several requests, then roll back or commit. There are no transactions in soap. One request-one response, the conversation is over.

It can be bypassed by using logic on the server and client. We implemented "dialogues" for a single payment system between the client and the server via SOAP. The communication protocol is simply located at a level above the SOAR.

Technology for obtaining data by sending an envelope with a request. the envelope with the received data may contain an error code, and this should be taken into account. the wsdl file describes the structure of the request and response envelope, and the address of the handler on the server that will respond to the request.