What is SOAP?

Lyrical part.

Imagine that you have implemented or is implementing some kind of system that should be accessible from the outside. Those. there is a 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 a well-known scenario (that is, according to the scenario of the developers). It is not interesting for a person to communicate with such a server, because he may not be able / not willing to give up beautiful pages with pictures and other user-friendly content. It is written and works in order to work and give out requests for data to it, not 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, give to their customers, etc.

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

The practical part.

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

WSDL (Web Services Description Language). The rules according to which messages for a web service are composed are also described using xml and also have a clear structure. Those. if the web service provides the ability to call a method, it should allow clients to know which parameters are used for this method. If the web service waits for a string for Method1 as a parameter and the string must be named Param1, then these rules will be specified in the description of the web service.

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

For clients, it is enough to know the web service url, wsdl will always be close 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 automatically. Those. It is enough for a 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 readable by any soap client. Those. Whatever the web service, 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'i. As a result, a programmer using a web service is left to write something like (pseudo-code):

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

• Automatic validation.

  • xml validation. xml should be well-formed. invalid xml - immediately the error to the client, let him understand.
  • schema validation. The xml must have a specific structure. xml does not conform to the scheme - immediately an error to the client, let him understand.
  • The data is checked by the soap server so that the data types and restrictions match the description.
• Authorization and authentication can be implemented by a separate method. natively. or using http authorization.
• Web services can work both via the soap protocol and http, that is, via get requests. That is, if simple data (without a structure) is used as parameters, then you can simply call the usual get www.site.com/users.asmx/GetUser?Name=Vasia or post. But it is not everywhere and not always.
• ... see Wikipedia

There are plenty of cons too:

• Unreasonably large message size. Well, the very nature of xml is such that the format is redundant, the more tags, the more unhealthy information. Plus soap adds to 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 communicate with success (and some restrictions).
• Automatically changing the description of a web service can break all clients. Well, it is as if for any system so, if backward compatibility with old methods is not supported, everything will fall off ...
• Not a minus, but a disadvantage. All actions to invoke methods must be atomic. For example, working with subd, we can start a transaction, execute several requests, then roll back or commit. There are no transactions in soap. One request, one answer, the conversation is over.
• Dealing with the description of what is on the server side (is everything properly described in me?), What is on the client (what have I written here?) Is 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 data, but he could not understand anything at all, because automatic generation and he, as it were, should not, this is 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 using these web services. In response to any request (valid from the outside), an unintelligible error "Error 5. Everything is bad." It all depends on the conscience of the developers :)
• for certain still did not remember something ...

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

• http://86.57.245.235/TimeTable/Service.asmx - entry point, there is a text description of 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 - a description of a specific method with an example of the type of xml-request and xml-response.

You can manually create and send a query 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> 

in response 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> 

Threat Previously, the aeroflot web service was opened, but after 1C added support for soap in 8k, a bunch of 1c-beta testers successfully laid it out. Now something has changed there (I don’t know the addresses, you can search if you are interested).
ZZY Disclaimer. Told at the household level. You can kick.

Here, for example, you need to transfer the names and values ​​of variables to some server-side script — this happens almost every time you click a link or click 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 

There are 6 variables (name, age, sex, street, city and country) with their values. page.php, in turn, accepts these values ​​and processes in accordance with the specified instructions. All these variables are equal in status in the chain and do not describe dependence on each other (below you will understand what this means). Moreover, even if it is only logical to consider all 6 variables as one bundle, then they describe one object, - that is, some individual male, whose name is Vasya and who is 20 years old (and so on), although nowhere in this URL does it say that all 6 variables together describe one object. Only intuitively we guess and this is suitable only for this example.

It is clear that these 6 variables have no description of dependency on each other - but in order to show dependency and 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, dependency and hierarchy are clearly visible. The unit of information describing 1 object is the space from <person> to </person> , which has nested elements arranged in a hierarchy relative to <person> below . Nested elements, as can be seen from <address> , can also have their nested elements. Roughly speaking, the <person> space describes an individual's object (along with <address> , etc., since it is the highest in the hierarchy), but <address> inside <person> also groups its subspace from <street> , <city> and <country> . Those. If you symbolically ask for an address, you will get 3 values ​​from the nested elements (I note that this is just a symbolic explanation).

So, by passing such a structure to SOAP, we can inform not only variables and their values, but also their dependencies and hierarchy to a certain server-side script. It was no coincidence that I gave an example with <address> - it’s very easy for the server-side script to get the full address of three elements , seeing that the parent (unifying) element <address> has nested elements! How would you group this dependency structure using the usual format (as shown in the example URL at the very beginning)? Ok, in this case, somewhere in the server scenario, it should be stated that a certain address needs to be formed from the values ​​of street, city and country is also a way out, I do not argue.

Now let's complicate the task: you need to transfer data for several "Vasyakh" at once. SOAP gives us this opportunity:

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

But how to organize it with the help of the construction name=Vasya&age=20&sex=male ? Twice the variable name (at least) name (one for Vasya, the other for Petit) is impossible to use on one line ..

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

PS It was written very conditionally and symbolically - the goal was to set a level specifically for the reader, who, having familiarized himself, would follow the right course.

Facts: it’s immediately apparent that half of the respondents have little idea what SOAP is. SOAP is just an XML protocol for exchanging data and a dot.

Lyrics: was invented at the time for web services, but life put everything in its place - now SOAP has quite a narrow niche as an protocol for exchanging data in the form of XML, and initially HTTP was provided as a transport protocol, now it is being forced to do so transport protocols.

Future: very foggy. Most likely, simpler and more economical protocols will force SOAP out of the web service niche. About 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 methods of objects remotely (the ROC will not be afraid of this word) ... i.e. on the client machine, only the interface is implemented, and all work happens on the server. Now it is also used for data exchange, i.e. You send an XML message with a request; you receive an XML message with a response.

But this is all very rude.

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

About the cons of SOAP above, everything was written. I can only correct:

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

can be bypassed using logic on the server and client. Implemented "dialogs" for one payment system between the client and the server via SOAP. The communication protocol is simply located above the SOAP level.

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