Answer 1, authority 100%
Imagine that you have implemented or are implementing a certain system that must be accessible from the outside. Those. 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 his well-known scenario (i.e. according to the developers’ scenario). A person is not interested in communicating with such a server, because he may not be able / not willing to give beautiful pages with pictures and other user-friendly content. It is written and works in order 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, referring to this server, can already dispose of the data received from this server at their own discretion – to process, accumulate, issue to their clients, etc.
Well, one of the options for communicating with such servers is SOAP. SOAP xml messaging protocol.
A web service (this is the name of what the server provides and what the clients use) makes it possible to communicate with the server in clearly structured messages. The fact is that the web service does not accept any data. Any message that does not comply with the rules will be answered by the web service with an error. By the way, the error will also be in the form of xml with a clear structure (which is not true about the text of the message).
WSDL (Web Services Description Language). The rules by which messages for a web service are composed are also described using xml and also have a clear structure. Those. if a web service provides the ability to call a method, it should let clients know what parameters are used for this method. If a web service expects a string for the Method1 method as a parameter and the string must have the name Param1, then these rules will be specified in the web service description.
As parameters, not only simple types can be passed, but also objects, collections of objects. The description of the object is reduced to the description of each component of the object. If an object consists of several fields, then each field is described what type, name (what possible values). Fields can also be of a complex type, and so on until the description of types ends with simple ones – string, boolean, number, date … However, some specific types may turn out to be simple, it is important that clients can understand what values may be contained in them.
For clients, it is enough to know the url of a web service, wsdl will always be there, 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, methods and types are described automatically. Those. it is enough for the programmer on the server to say that this method can be called through a web service, and the wsdl description will be generated automatically.
A clearly structured description is readable by any soap client. Those. whatever the web service, the client will understand what data the web service is accepting. According to this description, the client can build his own internal structure of object classes, the so-called. binding. As a result, the programmer using the web service has to write something like (pseudocode):
NewUser: = TSoapUser.Create ('Vasya', 'Pupkin', 'odmin'); soap.AddUser (NewUser);
- xml validation. xml must be well-formed. invalid xml – immediately an error to the client, let him sort it out.
- schema validation. xml must have a specific structure. xml does not correspond to the scheme – immediately an error to the client, let him understand.
- data validation is performed by the soap-server so that data types, constraints match the description.
- Authorization and authentication can be implemented in a separate method. natively. or using http authentication.
- Web services can work both via the soap protocol and via http, that is, via get requests. That is, if the parameters are simple data (no structure), then you can simply call the usual get www.site.com/users.asmx/GetUser?Name=Vasia or post. However, this is not everywhere and not always.
- … see wikipedia
Cons are also full:
- Unreasonably 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 own 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 with some restrictions).
- Automatically changing the description of a web service can break all clients. Well, it’s like for any system, if backward compatibility with old methods is not supported, everything will fall off …
- Not a minus, but a disadvantage. All actions for calling methods must be atomic. For example, working with a subdivision, we can start a transaction, execute several requests, then rollback or commit. There are no transactions in soap. One request, one response, conversation ended.
- Understanding the description of what is on the server side (is everything correctly described by me?), what is on the client (what was written to me here?) is quite difficult. There were several times when I had to deal with the client side, and convince the server programmer that his data was incorrectly described, but he could not understand anything at all, because automatic generation and he, as it were, should not, this is a software business. Naturally, the error was in the code of the method, the programmer simply did not see it.
- Practice shows that web service developers are terribly far from the people using these web services. In response to any request (valid from the outside), an incomprehensible error “Error 5. Everything is bad” may come. It all depends on the conscience of the developers 🙂
- I probably haven’t remembered something yet …
As an example, there is an open web service belavia:
- http://126.96.36.199/TimeTable/Service.asmx – entry point, text description of methods for third party developers.
- http://188.8.131.52/TimeTable/Service.asmx?WSDL – wsdl description of methods and types of accepted and returned data.
- http://184.108.40.206/TimeTable/Service.asmx?op=GetAirportsList – description a specific method with an example of an xml request and an xml response.
You can manually create and send a request like:
POST /TimeTable/Service.asmx HTTP / 1.1 Host: 220.127.116.11 Content-Type: text / xml; charset = utf-8 Content-Length: length SOAPAction: "http://webservices.belavia.by/GetAirportsList" & lt;? xml version = "1.0" encoding = "utf-8"? & gt; & lt; 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/"> & lt; soap: Body & gt; & lt; GetAirportsList xmlns = "http://webservices.belavia.by/" & gt; & lt; Language & gt; ru & lt; / Language & gt; & lt; / GetAirportsList & gt; & lt; / soap: Body & gt; & lt; / soap: Envelope & gt;
will receive in response:
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 & lt;? xml version = "1.0" encoding = "utf-8"? & gt; & lt; 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"> & lt; soap: Body & gt; & lt; GetAirportsListResponse xmlns = "http://webservices.belavia.by/" & gt; & lt; GetAirportsListResult & gt; & lt; Airport IATA = "ADB" Name = "Izmir" / & gt; & lt; Airport IATA = "AER" Name = "Sochi (Adler)" / & gt; & lt;! - a bunch of airports are missing here - & gt; & lt; / GetAirportsListResult & gt; & lt; / GetAirportsListResponse & gt; & lt; / soap: Body & gt; & lt; / soap: Envelope & gt;
Shl Earlier, the Aeroflot web service was opened, but after 1C added soap support to 8k, a bunch of 1c beta testers successfully put it down. Now something has changed there (I don’t know the addresses, you can search if interested).
Answer 2, authority 28%
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 after clicking on a form button. It looks like this:
http://www.server.ru/page.php?name=Vasya&age=20&sex=male& street = Gagarin% 2013 & amp; city = Tashkent & amp; country = Uzbekistan
6 variables are passed here (name, age, sex, street, city and country) with their values. page.php, in turn, takes these values and processes them according to the given instructions. All these variables are equal in status in the chain and do not describe dependence on each other (you will understand below what this means). Moreover, even if just logically consider all 6 variables as one bundle, then they describe one object, i.e. some male individual, whose name is Vasya and who is 20 years old (and so on), although nowhere this URL does not say that all 6 variables together describe one object. We only guess intuitively and this is only suitable for this 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 hierarchy , something needs to be added …. And then it comes to the rescue XML.
XML, as you already know, provides a convenient syntax for describing a data hierarchy. The format is already familiar to you:
& lt; person & gt; & lt; id & gt; 1000 & lt; / id & gt; & lt; name & gt; Vasya & lt; / name & gt; & lt; age & gt; 20 & lt; / age & gt; & lt; sex & gt; male & lt; / sex & gt; & lt; address & gt; & lt; street & gt; Gagarin 13 & lt; / street & gt; & lt; city & gt; Tashkent & lt; / city & gt; & lt; country & gt; Uzbekistan & lt; / country & gt; & lt; / address & gt; & lt; / person & gt;
In the code above clearly you can see dependency and hierarchy . The unit of information describing 1 object is the space from
& lt; person & gt; to
& lt; / person & gt; , which has nested elements hierarchical relative to
& lt; person & gt; below . Nested elements, as seen from
& lt; address & gt; , can also have nested elements. Roughly speaking, the space
& lt; person & gt; describes an individual’s object (along with
& lt; address & gt; , etc., since it is senior in hierarchy), but
& lt; address & gt; inside
& lt; person & gt; also groups its subspace from
& lt; street & gt; ,
& lt ; city & gt; and
& lt; country & gt; . Those. if you symbolically ask the address, we get 3 values from the nested elements (note that this is just a symbolic explanation).
So, by passing just such a structure to SOAP , we can tell a certain server script not only variables and their values, but also their dependency and hierarchy. It is no coincidence that I gave an example with
& lt; address & gt; – after all, it is very easy for the server script to get the full address from three elements , seeing that the parent (combining ) the
& lt; address & gt; element has nested elements! How would you then group this dependency structure using the regular format (as shown in the example URL at the very beginning)? Ok, in this case, somewhere in the server script it should be indicated that a certain address must be formed from the values of street, city and country – this is also a way out, I do not argue.
Now let’s complicate the task: you need to transfer data at a time about several “Vasya”. SOAP gives us this opportunity:
& lt; customers & gt; & lt; person & gt; & lt; id & gt; 1000 & lt; / id & gt; & lt; name & gt; Vasya & lt; / name & gt; .... & lt; / person & gt; & lt; person & gt; & lt; id & gt; 1001 & lt; / id & gt; & lt; name & gt; Petya & lt; / name & gt; .... & lt; / person & gt; & lt; / customers & gt;
But here’s how to organize it with
name = Vasya & amp; age = 20 & amp; sex = male ? Twice the name of the variable (at least)
name (one for Vasya, the other for Petya) after all cannot be used in one line ..
Below is a working example of how SOAP is used in practice (from one of my working projects). It is not difficult to visually see the structure of the data and their hierarchy (I specifically cite a very simple example of two significant variables String_1 and String_2). Above you can see the top attributes and the corresponding syntax for SOAP messages (read the documentation).
Answer 3, authority 19%
Facts: It is immediately apparent that half of the respondents have little understanding of what SOAP is. SOAP is just an XML protocol, period.
Lyrics: was invented at one time for web services, but life has put everything in its place – now SOAP has a rather narrow niche precisely as a protocol for exchanging data in the form of XML, and initially as a transport protocol provided for HTTP, now they force it with might and main over any transport protocols.
Answer 4, authority 7%
Simple? .. well, ok: this is crap that was originally planned, as a piece that allows you to call methods of objects remotely (ROC will not be afraid of this word) … that is. only the interface is implemented on the client machine, and all work happens on the server. Now it is also used for data exchange, i.e. you send some
XML message, with a request, 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 over 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 response messages, SOAP allows you to sign messages using various means (crypto-providers), which is one of the main arguments for using “serious” web services (services of the FIU, FMS, appointment with a doctor, etc.).
From the point of view of the client developer, the advantage is the ability to generate classes according to the existing WSDL schema, and refer to the remote WS as to a regular 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 WSDL based on code (java, C #).
All have written about the minuses of SOAP above.
I can only correct:
Not a minus, but a disadvantage. All actions for calling methods must be atomic. For example, working with a subdivision, we can start a transaction, execute several requests, then rollback or commit. There are no transactions in soap. One request, one response, the conversation is over.
technology for receiving data by sending an envelope with a request. the 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, which will respond to the request.