Штирлиц — Сеть печатных салонов в Перми

Весь комплекс печатных услуг в Перми. Общирная сеть печатных салонов в Перми. Цифровая печать, цветное и черно-белое копирование документов, сканирование документов, ризография в Перми

Soap что это: Различия REST и SOAP / Хабр

Содержание

Различия REST и SOAP / Хабр

Эта вторая статья в серии постов о разработке REST API:
В этой статье рассматриваются некоторые аспекты основных различий между REST и SOAP.

Упс… на самом деле, сравнивать их немного похоже на сравнение яблок с апельсинами, поскольку SOAP — это формат протокола, основанный на XML, тогда как REST — это архитектурный подход.



Вы изучите


  • Что такое REST?
  • Что такое SOAP?
  • Чем отличаются REST и SOAP?

REST и SOAP


REST и SOAP на самом деле не сопоставимы. REST — это архитектурный стиль. SOAP — это формат обмена сообщениями. Давайте сравним популярные реализации стилей REST и SOAP.
  • Пример реализации RESTful: JSON через HTTP
  • Пример реализации SOAP: XML поверх SOAP через HTTP

На верхнем уровне SOAP ограничивает структуры ваших сообщений, тогда как REST — это архитектурный подход, ориентированный на использование HTTP в качестве транспортного протокола.
  • Специфика SOAP — это формат обмена данными. С SOAP это всегда SOAP-XML, который представляет собой XML, включающий:
    — Envelope (конверт) – корневой элемент, который определяет сообщение и пространство имен, использованное в документе,
    — Header (заголовок) – содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации,
    — Body (тело) – содержит сообщение, которым обмениваются приложения,
    — Fault – необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений. И запрос, и ответ должны соответствовать структуре SOAP.
  • Специфика REST — использование HTTP в качестве транспортного протокола. Он подразумевает наилучшее использование функций, предоставляемых HTTP — методы запросов, заголовки запросов, ответы, заголовки ответов и т. д.

Формат обмена сообщениями

  • В SOAP вы используете формат SOAP XML для запросов и ответов.
  • В REST такого фиксированного формата нет. Вы можете обмениваться сообщениями на основе XML, JSON или любого другого удобного формата. JSON является самым популярным среди используемых форматов.

Определения услуг

  • SOAP использует WSDL (Web Services Description Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML.
  • REST не имеет стандартного языка определения сервиса. Несмотря на то, что WADL был одним из первых предложенных стандартов, он не очень популярен. Более популярно использование Swagger или Open API.

Транспорт

SOAP не накладывает никаких ограничений на тип транспортного протокола. Вы можете использовать либо Web протокол HTTP, либо MQ.

REST подразумевает наилучшее использование транспортного протокола HTTP

Простота реализации

RESTFful веб-сервисы, как правило, гораздо проще реализовать, чем веб-сервисы на основе SOAP.
  • REST обычно использует JSON, который легче анализировать и обрабатывать. В дополнение к этому, REST не требует наличия определения службы для предоставления веб-службы.
  • Однако в случае SOAP вам необходимо определить свой сервис с использованием WSDL, и при обработке и анализе сообщений SOAP-XML возникают большие накладные расходы.

По этому вопросу также имеется авторское видео.

Резюме


В этой статье мы подробно рассмотрели различия между REST и SOAP.

Дополнительное чтение


5 Courses to Learn RESTful Web Services With Java and Spring in 2019

10 API Testing Tips for Beginners (SOAP and REST)

Введение в SOAP

[Disclaimer: Данная статья была переведена в рамках «Конкурса на лучший перевод статьи» на сервисе Quizful. Ссылка на оригинал находится внизу страницы.]

Что такое SOAP?

SOAP расшифровывается как Simple Object Access Protocol (Простой Протокол Доступа к Объектам). Надеюсь по прочтении статьи вам останется только недоумевать: «Что за странное название?»

SOAP в теперешней его форме – это метод удаленного вызова (RPC, Remote procedure Call) по сети. (Да, он также используется для передачи документов в виде XML, но мы это пока опустим).

Давайте разбираться. Представьте, что у вас есть сервис, который возвращает биржевую котировку (stock quote) для заданного тикера (stock symbol). Он посылает данные на сайт Nasdaq и формирует на основе возвращенного HTML нужный результат. Дальше, чтобы позволить другим разработчикам использовать его внутри своих приложений, вы делаете из этого сервиса компонент, который через Интернет находит информацию о котировках. Работает он отлично, пока в один прекрасный день Nasdaq не меняет разметку своих страниц. Вам приходится пересмотреть всю логику работы компонента и разослать обновления всем разработчикам, использующим его. А им в свою очередь необходимо разослать обновления всем своим пользователям. Если это происходит на более-менее постоянной основе, вы можете нажить немало врагов среди коллег-разработчиков. А с программистами, как известно, шутки плохи. Вы же не хотите завтра доставать фотографию любимого кота из офисного шредера, правда?

Что же делать? Посмотрим… все, что вам нужно, это предоставить одну функцию, которая будет принимать на вход тикер (типа string) и возвращать биржевую котировку (типа float или double). Так не проще ли было бы просто позволить вашим разработчикам каким-то образом вызвать эту функцию через Интернет? Отлично! Тоже мне новость, есть же COM и Corba, и Java, которые этим занимаются уже годами… что правда – то правда, но эти методы не без изъяна. Удаленная настройка COM не тривиальна. Кроме того, нужно открыть столько портов в брандмауэре, что на системного администратора пива не напасешься. Да, и придется забыть о пользователях всех операционных систем кроме Windows. Но ведь позьзователи Linux тоже иногда интересуются биржей.

Хотя, похоже, что не все потеряно для пользователей Linux, если они используют DCOM, больше здесь: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.

На счет Corba и Java я много сказать не могу, так что в качестве упражнения предлагаю читателям найти минусы в этих подходах.

SOAP – это стандарт, который позволяет вам описать такой удаленный вызов и вид, в котором будет возвращаться результат. Таким образом вам нужно разместить вашу функцию в приложении, доступном по сети и получать вызовы в виде SOAP пакетов. После этого вы валидируете входные данные, запускаете вашу функцию и возвращаете результат в новом SOAP пакете. Весь процесс может работать через HTTP, так что вам не придется открывать кучу портов в брандмауэре. Правда просто?

О чем эта статья

Это первая из серии статей о SOAP, которые мы пишем в Agni Software. В этой статье я постараюсь дать вам представление о том, что такое SOAP и как написать приложение, общающееся с SOAP сервером.

Soap и XML

Если вам SOAP пока еще кажется простым, добавим XML. Теперь вместо имени функции и параметров мы получаем довольно сложный XML-конверт, как будто созданный для того, чтобы сбить вас с толку. Но не спешите пугаться. Дальше – больше, и вам нужно увидеть всю картину, чтобы оценить всю сложность SOAP.
Если вы не знаете, что такое XML, для начала прочтите мою статью об XML здесь: http://www.agnisoft.com/white_papers/xml_delphi.asp.

Все SOAP пакеты имеют XML формат. Что это значит? Посмотрим. Взгляните на эту функцию (Pascal):

function GetStockQuote( Symbol : string ) : double;
Выглядит отлично, но проблема в том, что это – Pascal. Какая польза от этого простого определения для Java-разработчика? Или для кого-то, кто работает с VB? Нам нужно что-то, что будет понятно всем, даже VB-программистам. Так дайте им XML, содержащий одну и ту же инфрмацию (параметры, значения биржевых котировок и т.д.). Вы создаете SOAP пакет, который по сути является вызовом вашей функции, обернутый в XML, чтобы любое приложения на любой платформе могло его понять. Теперь посмотрим, как выглядит наш SOAP вызов:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:GetStockQuote xmlns:ns1="urn:xmethods-quotes">
<SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<symbol xsi:type="xsd:string">IBM</symbol> 
</ns1:GetStockQuote> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope>
Информативно, правда? SOAP упрощается на глазах. Ладно, шутки в сторону. Теперь я постараюсь объяснить вам, как разобраться в этом SOAP вызове.

Расшифровка тегов

Первый тег, который бросается в глаза – это . Этот тег – внешняя оболочка SOAP пакета, содержащая несколько объявлений пространств имен, которые нас особо не интересуют, но очень важны для любого языка программирования или парсера. Пространства имен определяются для того, чтобы последующие префиксы, такие как «SOAP-ENV:» или «xsd:» воспринимались парсером.

Следующий тег – <SOAP-ENV:Body>. (Мы пропустили тег, не представленный здесь – <SOAP-ENV:Header>. Его нет в этом конкретном примере, но если вы хотите почитать о нем больше, обратитесь к спецификации SOAP здесь: http://www.w3.org/TR/SOAP/). Тег <SOAP-ENV:Body> собственно и содержит SOAP вызов.

Следующий тег в списке – <ns1:GetStockQuote …>. Имя тега, GetStockQuote и есть вызываемая функция. Согласно терминологии SOAP, это называется операцией. Таким образом GetStockQuote – операция, которая должна быть выполнена. ns1 – это пространство имен, указывающее на urn:xmethods-quotes в нашем случае.

Лирическое отступление на счет пространств имен: Пространство имен дает возможность квалифицировать XML тег. Нельзя, к примеру, иметь две переменные с одинаковым именем в одной процедуре, но если они в двух разных процедурах, проблем не возникает. Таким образом процедура – это пространство имен, так как все имена в ней уникальны. Точно так же XML теги имеют свою область видимости внутри пространств имен, так что имея пространство имен и имя тега, можно однозначно его идентифицировать. Мы определим пространство имен как URI, чтобы отличать наш NS1 от подражателей. В приведенном выше примере NS1 – это алиас, указывающий на urn:xmethods-quotes.

Обратите внимание также на атрибут encodingStyle – этот атрибут определяет каким образом сериализуется SOAP вызов.

Внутри тега <GetStockQuote> содержатся параметры. В нашем простейшем случаи у нас есть только один параметр – тег <symbol>. Обратите внимание на эту строку возле тега:

xsi:type="xsd:string"
Приблизительно так в XML и определяются типы. (Обратите внимание на то, как хитро я использовал слово «приблизительно», делая обобщение о технологии, которая может измениться как только статья будет опубликована). Что конкретно это означает: тип, определенный в пространстве имен xsi, который, как вы заметили, определен в теге – xsd:string. А это в свою очередь string, определенный в пространстве имен xsd, опять-таки, определенном ранее. (Уверен, юристы бы от этого всего просто млели).

Внутри тега <symbol> указано «IBM». Это – значение параметра symbol функции GetStockQuote.

Ну и в конце, как порядочные люди, мы закрыли все теги.

Вот и разобрались с SOAP пакетом, определяющим вызов к SOAP серверу. А SOAP сервер с помощью XML парсеров, красной кнопки и космической станции «МИР» декодирует этот вызов и определяет, что вам нужна биржевая котировка. Он тут же находит нужную котировку и возвращает вам ее в таком виде:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetStockQuoteResponse xmlns:m="urn:xmethods-quotes">
<Price>34.5</Price>
</m:GetStockQuoteResponse>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
После разворачивания SOAP конверта, срывания ленточек и шуршания оберткой, мы узнаем, что цена акции IBM – 34.5.

Большинство коммерческих серверов вернуло бы гораздо больше информации, например, в какой валюте и за какую цену была куплена последняя акция. Да и цена акции, пожалуй, была бы поточнее.

Таким образом мы знаем, чего ожидает SOAP сервер и что он вернет. Так КАК же отправить эту информацию? Использовать можно любой транспорт. Самым освещенным является HTTP. Я не стану вдаваться в подробности HTTP, для тех, кто не знает – это то, что использует ваш браузер, чтобы общаться с сайтами, на которые вы заходите.

Нужный HTTP запрос будт выглядеть приблизительно так:

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
...the soap request packet here...
Единственное, что еще стоит отметить – это заголовок SOAPAction. Этот заголовок указывает на цель запроса и является обязательным. Каждый SOAP сервер может иметь неограниченное количество функций и может использовать заголовок SOAPAction чтобы определить какую функцию вызывают. Брандмауэры и мультиплексоры также могут фильтровать контент на основании этого заголовка.

SOAP ответ от HTTP сервера будет выглядеть следующим образом:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
...Soap Response packet here...
Почему HTTP? Во-первых, сетевым администраторам не придется открывать уйму отдельных портов для SOAP вызовов… веб-сервер может спокойно обрабатывать вызовы, т.к. 80-й порт обычно открыт для всех для приема входящих запросов. Еще одним преимуществом является расширяемость веб-серверов с помощью CGI, ISAPI и других нативных модулей. Эта расширяемость позволяет написать модуль, обрабатывающий SOAP запросы не задевая другого веб-контента.

Вот и все

Надеюсь, эта статья помогла пролить немного света на SOAP. Если вы еще здесь и хотите почитать больше на эту тему, посетите сайт авторов: http://www.agnisoft.com/soap

———-
Оригинальный текст статьи: Introduction to SOAP

SOAP — Википедия с видео // WIKI 2

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

SOAP является одним из стандартов, на которых базируются технологии веб-служб.

Энциклопедичный YouTube

  • 1/3

    Просмотров:

    891 028

    4 456 951

    2 376 255

  • ✪ SOAP Web Services 01 — Introduction To Web Services

  • ✪ How it’s Made: Soap Bars

  • ✪ Super Easy Soap for beginners.

Содержание

Структура протокола

Структура SOAP-сообщения

Структура SOAP-сообщения

Сообщение SOAP выглядит так:

Envelope – Корневой элемент, который определяет сообщение и пространство имен, использованное в документе.

Header – Содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации.

Body – Содержит сообщение, которым обмениваются приложения. 

Fault – Необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений.

Пример

Пример SOAP-запроса на сервер интернет-магазина:

<?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>
     <getProductDetails xmlns="http://warehouse.example.com/ws">
       <productID>12345</productID>
     </getProductDetails>
   </soap:Body>
</soap:Envelope>

Пример ответа:

<?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>
     <getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
       <getProductDetailsResult>
         <productID>12345</productID>
         <productName>Стакан граненый</productName>
         <description>Стакан граненый. 250 мл.</description>
         <price>9.95</price>
         <currency>
             <code>840</code>
             <alpha3>USD</alpha3>
             <sign>$</sign>
             <name>US dollar</name>
             <accuracy>2</accuracy>
         </currency>
         <inStock>true</inStock>
       </getProductDetailsResult>
     </getProductDetailsResponse>
   </soap:Body>
</soap:Envelope>

Недостатки

  • Использование SOAP для передачи сообщений увеличивает их объём и снижает скорость обработки. В системах, где скорость важна, чаще используется пересылка XML-документов через HTTP напрямую, где параметры запроса передаются как обычные HTTP-параметры.

См. также

Ссылки

Структура SOAP-сообщения Эта страница в последний раз была отредактирована 7 мая 2020 в 19:24.

REST vs SOAP. Часть 1. Почувствуйте разницу / Хабр

Некоторое время назад я гуглил интернет по поводу “REST vs SOAP”, прочитал пару статей и вроде бы все понял, но не почувствовал от этого никакого удовлетворения. Что-то было не так, то ли я не почувствовал основную идею, то ли просто читал, одновременно слушая новый музон и думая о новой фиче в проекте. Как появилось время, решил восполнить этот пробел, заодно написав полезную статью по этому поводу.

Оглавление цикла статей:

REST vs SOAP. Часть 1. Почувствуйте разницу.
REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?

Пару месяцев назад при беглом изучении вопроса я понял о REST примерно следующее:

  • Все является ресурсами с уникальным идентификатором (URL)
  • Все операции клиента с сервером stateless, т.е. сервер не должен хранить вообще никакой информации о клиенте – никакой сессии
  • Все запросы можно поделить на 4 типа в соответствии с CRUD, причем каждому типу сопоставляется HTTP метод – Post, Get, Put и Delete
  • Вся логика крутится вокруг ресурсов, а не операций

Вот с такими воспоминаниями я начал бороздить просторы интернета. Первой мыслью было, а почему выбрано название REST? Representational State Transfer, в переводе википедии «передача состояния представления»… Никакой картинки в голове не вырисовывается даже при четвертом вчитывании. Здесь пытаются ответить на мой вопрос и даже приводят то, как Рой Филдинг (человек, сформулировавший принципы REST) сам объяснял происхождение названия. Мысль сводится к тому, что запрос ресурса с сервера переводит клиентское приложение в определенное состояние (state), а запрос следующего ресурса меняет состояние приложения (transfer). А “Representational” означает то, что ресурс возвращается не просто так, а в каком-то представлении, например в представлении для машины или в представлении для человека. Сложно, как по мне, и сбивает с толку, т.к. состояние – это как раз то, что отсутвует в отношениях клиент-сервер в архитектуре REST. Я бы назвал как-то вроде «Стандартизированное оперирование данными», вот только сначала надо что-то придумать, а потом уже яркое название выбирать. А Филдинг в своей диссертации признается, что название придумано не для того, чтобы было понятно, о чем речь, а «is intended to evoke an image of how a well-designed Web application behaves». Но это ничего, не будем обижаться на уважаемого человека, мы тоже в дипломных работах часто формулировали все так, чтобы было как можно непонятнее и нельзя было придраться. Нашлась и неплохая формулировка идеи по-русски – «представление данных в удобном для клиента формате». Справедливости ради надо отметить, что пока я формулировал свои доводы о нелогичности названия, я увидел в нем некоторую логику, по крайней мере в английском варианте.

Важно понимать, что REST – это не протокол и не стандарт, а архитектурный стиль. У этого стиля есть свои принципы. Позволю себе скопировать их с понравившегося источника и прокомментировать:

  1. Give every “thing” an ID.
    Очччень желательно.
  2. Link things together.
    Например, в страницу (представление) о Mercedes C218 хорошо бы добавить ссылку на страницу конкретно о двигателе данной модели, чтобы желающие могли сразу туда перейти, а не тратить время на поиск этой самой страницы.
  3. Use standard methods.
    Имеется в виду, экономьте свои силы и деньги заказчика, используйте стандартные методы HTTP, например GET
    http://www.example.com/cars/00345
    для получения данных вместо определения собственных методов вроде getCar?id=00345.
  4. Resources can have multiple representations.
    Одни и те же данные можно вернуть в XML или JSON для программной обработки или обернутыми в красивый дизайн для просмотра человеком.
  5. Communicate statelessly.
    Да, RESTful сервис должен быть как идеальный суд – его не должно интересовать ни прошлое подсудимого (клиента), ни будущее – он просто выносит приговор (отвечает на запрос).

Только что употребленный термин RESTful (веб-)сервис всего лишь означает сервис, реализованный с использованием принципов REST. Так что же нам дает следование этим самым принципам REST? Для начала я бы назвал простоту основным преимуществом архитектуры REST. Простоту идеи, простоту разработки и добавления функциональности к RESTful приложениям. Идея настолько проста и универсальна, что ее даже сложно сначала уловить. Мы не добавляем никакого нового слоя в наш и без того многослойный программерский пирог, а просто используем уже давно признанные стандарты. Поэтому чтобы ответить на вопрос о преимуществах и недостатках и чтобы анализ имел больше смысла, предлагаю перейти к сравнению подходов SOAP и REST.
  1. SOAP – это целое семейство протоколов и стандартов, откуда напрямую вытекает, что это более тяжеловесный и сложный вариант с точки зрения машинной обработки. Поэтому REST работает быстрее.
  2. SOAP используют HTTP как транспортный протокол, в то время как REST базируется на нем. Это означает, что все существующие наработки на базе протокола HTTP, такие как кеширование на уровне сервера, масштабирование, продолжают так же работать в REST архитектуре, а для SOAP необходимо искать другие средства. Взамен этого SOAP сервисы получают такое мифическое свойство, как возможность работать с любым протоколом транспортного уровня вместо HTTP, однако практической пользы от него зачастую не больше, чем сотрудникам Челябинского трубопрокатного завода от большого количесва статей в википедиях на мертвых языках.
  3. Есть мнение, что разработка RESTful сервисов намного проще. Наверное, это правда, если использовать Notepad в качестве основной среды разработки, но вот с использованием наших чудесных средств разработки, я позволю себе усомниться в верности этого утверждения.
  4. В первом гугловском результате по запросу «REST vs SOAP» акцентируется внимание на том, что ответ REST может быть представлен в различных форматах, а SOAP привязан к XML. Это действительно важный фактор, достаточно представить себе вызов сервиса из javascript, ответ на который мы определенно хотим получать в JSON.
  5. «REST vs SOAP» можно перефразировать в «Простота vs Стандарты», что проявляется в том, что для SOAP мы имеем протокол WSDL для исчерпывающего описания веб-сервиса, который с использованием все тех же чудесных средств разработки прото-таки волшебным образом делает почти всю работу за нас. Со стороны REST мы имеем загадочный и неиспользуемый протокол WADL, который, в принципе, и не нужен – он мешает простоте.
  6. Второй аспект предыдущего пункта – обработка ошибок. В SOAP она полностью стандартизована, а REST может использовать давно известные коды ошибок HTTP (если здесь Вас посетила мысль, что это же очевидно и зачем я это пишу, то значит Вы внимательно читаете статью).
  7. То, с чего можно было бы начать, но я припас напоследок. Это одна из ключевых мыслей. SOAP работает с операциями, а REST – с ресурсами. Этот факт в совокупности с отсутствием клиентского состояния у RESTful сервисов приводит нас к тому, что такие вещи как транзакции или другая сложная логика должна реализовываться «SOAP-но».

Приведу пару примеров на понимание разницы между подходами. Букмекерская контора заказала сервис для работы с футбольной статистикой. Пользовательский функционал – получить список матчей, получить детали о матче. Для редакторов – редактировать (Create, Edit, Delete) список матчей, редактировать детали матча. Для такой задачи однозначно надо выбирать подход REST и получать бенефиты от его простоты и естественности во взаимодействии с HTTP. Не нужны нам здесь SOAP-конверты, SOAP-главпочтамты и SOAP-авиапочта, которая может использовать любую марку самолета. Нам всего лишь надо реализовать следующее:

Все очень просто! Теперь пример посложнее. Та же букмекерская контора захотела API для ставок на live матчи. Эта процедура включает в себя многочисленные проверки, например, продолжает ли ставка быть актуальной, не изменился ли коэффициент, не превышена ли максимальная сумма ставки для маркета. После этого происходит денежная транзакция, результаты которой записываются в основную и в резервные базы данных. Лишь после этого клиенту приходит ответ об успешности операции. Здесь явно прослеживается ориентация на операции, имеются повышенные требования к безопасности и устойчивости приложения, поэтому целесообразно использовать SOAP.

И еще пару задач для того, чтобы почувствовать тему:


  • Футбольный клуб заказывает CMS для подробных сведений об игроках команды-неприятеля. Нужен функционал добавления характеристик игрока простыми пользователями прямо во время матча с последующей интеграцией с табло стадиона, на котором необходимо в реальном времени отображать комментарии.
  • Мексиканский наркобарон Педро Гонсалес заказывает API для учета продаж героина в Юго-Западных штатах США. Он особо просит мобильное приложение под эту задачу, т.к. его бизнес часто проходит на открытом воздухе, где нету других вариантов выхода в сеть.
  • Анонимный миллиардер очень хочет такую программу, которая бы ему показывала всех его любовниц в городе, в котором он сейчас находится и то, какой текущий статус отношений. Он хочет интегрировать эту программу с уже существующим его личным десктопным приложением для подбора мест для отдыха, он очень хочет большую красную надпись о возможных неприятностях в окошке, где предлагаются варианты авиаперелета.

Какие подходы Вы бы использовали в данных задачах?

Хотел я еще написать про то, что это все дает .NET разработчику и как это использовать в своих целях, однако вижу, что индекс нудности статьи приближается к критическому, поэтому буду закругляться. С целью понижения все того же показателя я намеренно избегал аспектов безопасности и, например, ответа на вопрос ”А как вообще возможна аутентификация в архитектуре REST, если читателю на протяжении всей этой статьи внушалось, что RESTful сервис должен быть stateless?”.

А выводы статьи будут следующими:

  1. Филдинг со своими принципами REST ничего не изобрел, а просто собрал в одну диссертацию то, что уже существовало в каком-то виде и изложил то, как можно получать максимальную выгоду из уже сформировавшейся архитектуры сети.
  2. SOAP и REST – не конкуренты. Они представляют разные весовые категории и вряд ли найдется задача, для которой будет сложно сказать, какой подход рациональнее использовать – SOAP или REST. Поэтому «религиозные» убеждения в вопросах выбора архитектуры для веб-сервиса вряд ли будут полезны. Для тех, кто не знает, с чего начать анализ задачи, могу порекомендовать эту презентацию. У них чаще побеждает REST.

SOAP — это… Что такое SOAP?

Структура SOAP сообщения

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам; вплоть до спецификации 1.2) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

SOAP является одним из стандартов, на которых базируются технологии веб-служб.

Структура протокола

Сообщение SOAP выглядит так:

SOAP-конверт

Пример

Пример SOAP-запроса на сервер интернет-магазина:

 
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetails xmlns="http://warehouse.example.com/ws">
       <productID>12345</productID>
     </getProductDetails>
   </soap:Body>
 </soap:Envelope>

Пример ответа:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
       <getProductDetailsResult>
         <productID>12345</productID>
         <productName>Стакан граненый</productName>
         <description>Стакан граненый. 250 мл.</description>
         <price>9.95</price>
         <currency>
             <code>840</code>
             <alpha3>USD</alpha3>
             <sign>$</sign>
             <name>US dollar</name>
             <accuracy>2</accuracy>
         </currency>
         <inStock>true</inStock>
       </getProductDetailsResult>
     </getProductDetailsResponse>
   </soap:Body>
 </soap:Envelope>

Недостатки

  • Использование SOAP для передачи сообщений увеличивает их объём и снижает скорость обработки. В системах, где скорость важна, чаще используется пересылка XML-документов через HTTP напрямую, где параметры запроса передаются как обычные HTTP-параметры.
  • Хотя SOAP является стандартом, некоторые программы часто генерируют сообщения в несовместимом формате. Например, запрос, сгенерированный AXIS-клиентом, не будет понят сервером WebLogic.

См. также

Ссылки

Отличия между SOAP и REST Web-сервисами

В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО, например: сайт на 1С-Битрикс, CRM 1С-Битрикс24, учетная система на базе 1С. Одни системы “из коробки” умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:

  1. Обмен файлами по FTP.

  2. Неструктурированные HTTP-запросы, договорённости между разработчиками.

  3. Веб-сервисы.

  4. Экзотика: сокеты, порты, бинарные объекты.

В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.

Что такое веб-сервисы?

Веб-сервисы (или веб-службы) — это технология, позволяющая системам обмениваться данными друг с другом через сетевое подключение. Обычно веб-сервисы работают поверх протокола HTTP или протокола более высокого уровня. Веб-сервис — просто адрес, ссылка, обращение к которому позволяет получить данные или выполнить действие.

Главное отличие веб-сервиса от других способов передачи данных: стандартизированность. Приняв решение использовать веб-сервисы, можно сразу переходить к структуре данных и доступным функциям. Например, В SOAP (как более строгом протоколе), уже решён вопрос уведомления об ошибках.

Самые известные способы реализации веб-сервисов:

  • XML-RPC (XML Remote Procedure Call) — протокол удаленного вызова процедур с использованием XML. Прародитель SOAP. Предельно прост в реализации.

  • SOAP (Simple Object Access Protocol) — стандартный протокол по версии W3C. Четко структурирован и задокументирован.

  • JSON-RPC (JSON Remote Procedure Call) — более современный аналог XML-RPC. Основное отличие — данные передаются в формате JSON.

  • REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети основанный на методах протокола HTTP.

  • Специализированные протоколы для конкретного вида задач, такие как GraphQL.

  • Менее распространенный, но более эффективный gRPC, передающий данные в бинарном виде и использующий HTTP/2 в качестве транспорта.

Остальные протоколы не так широко распространены. Подробно рассмотрены в статье будут SOAP и REST.

SOAP

SOAP (Simple Object Access Protocol) — Данные передаются в формате XML.

Преимущества:

  • отраслевой стандарт по версии W3C;

  • наличие строгой спецификации;

  • широкая поддержка в продуктах Microsoft,

  • однозначность.

Недостатки:

Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):

  • Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.

  • Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.

  • Body. Основной элемент, содержит основную информацию сообщения. Обязательный.

  • Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.

Пример SOAP запроса:

Пример SOAP ответа:

REST

REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.

REST не использует конвертацию данных при передаче, данные передаются в исходном виде — это снижает нагрузку на клиент веб-сервиса, но увеличивает нагрузку на сеть. Управление данными происходит с помощью методов HTTP:

  • GET — получить данные;

  • POST — добавить данные;

  • PUT — изменить данные;

  • DELETE — удалить данные.

Использование этих методов позволяет реализовать типичный CRUD (Create/Read/Update/Delete) для любой информации. Но это лишь соглашение: часто используются только 2 метода: GET для получения и POST для всего остального. Разобраться поможет такое понятие, как REST-Patterns . Паттерны связывают HTTP методы с тем, что они делают.

Преимущества:

  • простота реализации;

  • экономичность в плане ресурсов;

  • не требует программных надстроек (json_decode есть почти в каждом языке).

Недостатки:

Пример REST запроса:

Пример REST ответа:

Что же использовать?

Вопрос “Какой способ реализации использовать?” необходимо рассматривать в контексте реализуемой системы и ее ограничений. Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем. XML-RPC, пожалуй, устарел и не имеет смысла ввиду наличия собрата JSON-RPC. RPC-протоколы подойдут для совсем простых систем с малым количеством единиц информации и API-методов. 

Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.

Веб-сервисы в Битрикс

Подробное описание реализации веб-сервисов с помощью средств Битрикс можно найти в статье Веб-сервисы в Битриксе (пример) .

Веб-сервисы в живом производстве

Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами. 

Успешным примером внедрения веб-сервисов является проект Enterprise-уровня — Личный кабинет клиентов компании Евраз Металл Инпром . Все функции личного кабинета основываются на взаимодействии с удаленным SOAP веб-сервисом. Сайт выступает клиентом. В процессе эволюции в угоду безопасности сайт переквалифицировался в SOAP-сервер, а учетная система в SOAP-клиента.  

Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.

Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, обращайтесь к нам.

Подведем итог, выделив, два важных тезиса в пользу выбора веб-сервисов в качестве «рельс» для веб-интеграции.

  1. Наш опыт неоднократно демонстрировал, что создание веб-сервисов, в реальном времени передающих необходимые данные между сайтом и другим ПО — лучшее решение, чем классические обмены по расписанию. Такой подход проще сопровождать, вести его отладку, это более эффективная трата времени программиста, чем проектирование и разработка сложного двунаправленного обмена с кучей сущностей.

  2. Можно провести аналогию с эволюцией разработки сайтов. Когда-то, на заре сайтостроения, каждый разработчик делал сайт с нуля на той технологии, которую мог знать лишь он один. Это порождало проблемы в развитии таких сайтов. Как работали такие сайты — знал только автор кода. Со временем появлялись фреймворки и CMS. Разработку начинали не с нуля, а с известных широкой массе разработчиков “заготовок” — стандартных решений стандартных проблем с возможность расширения и углубления.
    Также и с обменом данными. Не нужно тратить месяцы на объяснение новому сотруднику и самому себе, как работает обмен. Есть стандарт, обмен работает по нему.

Оцените статью:

Спасибо, ваш голос успешно добавлен!

Обзор SOAP — JavaTutor.net

SOAP позволяет объектам любого вида, т.е. написанным под любую платформу и на любом языке, перекрестно взаимодействовать. В настоящее время SOAP реализован в более 60 языках и более 20 платформах. Неожиданно все объекты, локальные и удаленные, маленькие и большие, получили возможность взаимодействия друг с другом.

Том Клементс
Январь 2002

В фильме “Бойцовский клуб” Брэд Питт и Эдвард Нортон играют роль второго “я” — противоположные стороны психологического спектра – два парня, которые пытаются общаться друг с другом и с трудом заставляют себя это делать. Довольно интересно (и в этом вся соль), что основные события фильма развиваются вокруг производства мыла. Оказалось, что буквы английского слова soap (мыло) соединяются уникальным и неожиданным образом.

Теперь перейдем к сценарию другого рода, действие которого происходит в Internet и представителями второго “я” являются компании Microsoft и Sun. Каждая из этих компаний имеет свою четкую точку зрения, пытается ликвидировать разрыв и наладить контакты с другой. Узнайте о SOAP (Simple Object Access Protocol – Простой Объектный Протокол Доступа).

Содержание

Введение
Эволюция Web-сервисов
Сетевые уровни
XML: ключ к описанию Web-сервисов
Слабосвязанные системы
Второе пришествие CORBA
Публикация, нахождение, связывание
Создание Web-сервисов
SOAP клиенты и серверы
SOAP и Java технология
Так что же такое в действительности SOAP?
Формат сообщений
Анализ конверта SOAP
Пространства имен
Заголовок
Тело сообщения
SOAP-RPC
Случай использования SOAP
Заключение
Ссылки
Об авторе

Введение

Выражаясь просто, SOAP позволяет Java и COM объектам взаимодействовать друг с другом в распределенной, децентрализованной Web-среде.

В более общем смысле, SOAP позволяет объектам (или коду) любого вида, т.е. написанным под любую платформу и на любом языке, перекрестно взаимодействовать. В настоящее время SOAP реализован в более 60 языках и более 20 платформах. Неожиданно все объекты, локальные и удаленные, маленькие и большие, получили возможность взаимодействия друг с другом. Брэд Питт и Эдвард Нортон, как два объекта различных типов, в конце концов тоже стали способны взаимодействовать.

В данном обзоре SOAP будет первоначально представлен в более широком контексте Web-сервисов, как протокол, соединенный с UDDI (Universal Description, Discovery and Integration – Универсальное Описание, Открытие и Интеграция) с целью обеспечения регистрационных сервисов и сервисов передачи сообщений между предприятиями. Также будут обсуждаться Web обоснования появляющейся парадигмы “публиковать, находить, связывать”, и будут показаны механизмы организации пакетов, транспортировки и доставки в SOAP.

Эволюция Web-сервисов

Не смотря на все возражения, SOAP – это всего один компонент (хотя и центральный) в новом представлении Web, как структуры для бизнес-операций, основанной на стандартах и не зависящей от языка и платформы. Эти операции обычно собраны в универсальном понятии “Web-сервисы”, но Web-сервисы сами по себе хороши настолько, насколько хороша инфраструктура, поддерживающая их. Соответственно, мы имеем быстрый многоуровневый взгляд на основу Internet.

Сетевые уровни

В эволюции Web-сервисов ярко выражены три сетевых уровня: TCP/IP, HTTP/HTML и XML. Эти уровни надстроены последовательно друг над другом и по сегодняшний день остаются совместимыми.

Первый уровень, протокол TCP/IP, связан прежде всего с передачей данных в пакетах по кабелю. Будучи протоколом, который гарантирует пересылку данных по общественным сетям, TCP/IP придает особое значение надежности транспортировки данных и физическому обеспечению связи. Первоначально TCP/IP являлся “замазкой”, скрепляющей отдельные сети, тогда как сейчас это базовый протокол Web, на котором основаны высокоуровневые стандартные протоколы типа HTTP.

Второй уровень, HTML над HTTP, является уровнем представления и занимается поиском с броузерным интерфейсом, выборкой и совместным использованием информации. Здесь основное внимание уделяется GUI-навигации и манипуляции форматов представления. Во многих отношениях HTML носит больше демонстративный, чем функциональный характер, и испытывает недостаток как в расширяемости, так и в истинной программной мощности. Тем не менее, совместное использование гипертекстовых документов в среде с броузерным интерфейсом полностью реконструировало способ передачи текстовой информации между людьми. Сетевые настольные среды, обремененные собственными операционными системами и платформно-зависимым программным обеспечением, медленно но верно уступают основанной на стандартах, открыто-системной обработке данных в Internet.

Погружение в этот новый прекрасный стандартизованный мир возглавляет XML, третий и возможно наиболее неотразимый уровень в Internet. XML – формат обмена данными со строгим контролем типов – предоставляет новое измерение уровню HTTP/HTML, в котором осуществление межкомпьютерного взаимодействия возможно посредством стандартных интерфейсов. Этот уровень, описываемый как A2A (application to application), B2B (business to business) или C2C (computer to computer), позволяет программам обмениваться данными независимо от платформы и представления. Таблицы стилей XSLT могут быть добавлены как дополнительные компоненты представления и/или трансформации.

XML: ключ к описанию Web-сервисов

Ключом к осуществлению всех этих возможностей является межкомпьютерное взаимодействие – область, в которой преобладает XML. Будучи синтаксисом для описания данных, XML управляется определением (при помощи DTD или схем) и позволяет программно управлять информацией. Это означает, что большая часть предполагаемой работы может быть получена из B2B-взаимодействий. Теги могут быть согласованы, интерфейсы определены, а обработка данных стандартизована. Web-сервисы – это компонентные программы многократного пользования, которые используют XML как стандартную расширяемую сетевую структуру, с целью облегчения этого вида межкомпьютерного взаимодействия.

Web-сервисы предоставляют интерфейсы для передачи компонентных данных и бизнес-логики по HTTP. Огромное количество данных располагается сразу за скриптами, выполняемыми на стороне сервера, в традиционных репозиториях, ожидая доступа к данным из Web-броузеров и клиентских приложений. Web-сервисы обещают восстановить ценные свойства корпоративных приложений, неиспользуемые в настоящее время во многих областях предприятия.

XML играет ключевую роль в интеграции Web-резидентных данных в корпоративные приложения, а также в координировании бизнес-логики, соединяющей составные части. Определенные бизнес-задачи и услуги (включая логику автоматизации, бизнес-логику, логику упорядочения компонентов, логику формирования транзакций и т.д.) могут быть включены в XML-документ и интегрированы в существующие бизнес-среды. Это позволяет предприятиям усилить существующие ценные свойства и процессы, а также представить эту информацию в виде Web-сервисов, упрощая деловые операции и поддерживая цепное взаимодействие во всей сети WWW.

Поскольку XML удобен для чтения и основан на тексте, он идеально подходит в качестве транспортной структуры для слабосвязанных Web-сервисов. Основным моментом является то, что автоматизированные транзакции увеличивают производительность, уменьшают затраты и улучшают услуги. Присутствие стандартов в сети делают возможными автоматизированные транзакции, приводя к росту производительности.

SOAP – это технология, которая произошла от раннего XML-стандарта (XML-RPC) и, в некотором смысле, стремится к появляющемуся стандарту ebXML (electronic business XML). ebXML – это незавершенная технология, направленная на обеспечение всестороннего определения общедоступных бизнес-сообщений между торговыми партнерами. SOAP является менее обширным и менее сложным в выполнении.

Слабосвязанные системы

Web-сервисы отделяют объекты от связывающей их платформы. То есть Web-сервисы облегчают взаимодействие между платформно-независимыми объектами, способными обращаться к данным из любой точки Web. Осуществляя удаление от частных платформ, Web-сервисы полагаются скорее на слабые, чем сильные связи между Web-компонентами. Согласно Брайану Трэвису, консультанту и автору SOAP, системы, которые полагаются на специфичные для одной платформы объекты, называются сильносвязанными системами, т.к. они опираются на однозначный, но хрупкий интерфейс. Если какая-либо часть соединения между объектом-приложением и серверным объектом разорвана, или если вызов некорректен, это может привести к непредсказуемым результатам. EDI (Electronic Data Interchange – Электронный Обмен Данными) является примером сильносвязанной структуры для осуществления электронной коммерции. В свою очередь слабосвязанные системы учитывают гибкий и динамический обмен в открытых распределенных Web-средах.

Второе пришествие CORBA

В настоящее время многие компании (например, IBM, BEA, Sun и др.) совместно сотрудничают с теми же компаниями, с которыми они конкурируют. Стандартизованные сетевые транспортные протоколы, платформно-независимые языки программирования (такие как Java, XML, диалекты, характерные для той или иной промышленности) и открытые компонентные серверные архитектуры способствуют этой антисобственнической общедоступности. Сегодня Web-сервисы (с их обещаниями всеобъемлющей прикладной функциональной совместимости) представляются как окончательный “клей”, заставляющий взаимодействовать все эти технологии, если не без швов, то хотя бы без избыточного багажа, который сопровождал предыдущие технологии, такие как CORBA и RMI.

В каком-то смысле Web-сервисы представляют второе пришествие CORBA. Однако CORBA была объектно-ориентированной структурой бинарных IIOP коммуникаций, загруженной заглушками, скелетами программ и зависящими от поставщика брокерами объектных запросов. Web-сервисы в свою очередь являются легкими, основанными на HTTP, XML-управляемыми и полностью независящими от платформы и языка. Тогда как CORBA была 600-фунтовой полузапертой гориллой, Web-сервисы – это газель, легко скачущая по обширным просторам Internet.

Публикация, нахождение, связывание

Структура Web-сервисов состоит из цикла “публиковать-находить-связывать”, посредством которого поставщики сервисов делают данные, содержимое или услуги доступными для зарегистрированных запрашивающих сторон, потребляющих ресурсы, локализуя сервисы и соединяясь с ними. Запрашивающие приложения настраиваются на Web-сервисы при помощи WSDL (Web Services Definition Language – язык описания Web-сервисов), который предоставляет низкоуровневую техническую информацию о желаемом сервисе, допускает обращение приложений к информации XML Schema для кодировки данных и гарантирует, что правильные операции будут осуществлены по правильным протоколам.

Механизмы публикации, нахождения и связывания имеют соответствующие аналоги в трех отдельных (но отчасти эквивалентных) протоколах, которые составляют сетевой набор Web-сервисов: WSDL, SOAP и UDDI.

Погружаясь немного глубже в аналогию с CORBA, отметим, что SOAP играет роль IIOP в CORBA (или JRMP в RMI). Это связующий механизм между противоположными конечными точками. С другой стороны, WSDL играет роль IDL (Interface Definition Language – Язык Описания Интерфейсов). В этом смысле WSDL определяет Web-сервисы как совокупность портов и операций. WSDL-порт аналогичен интерфейсу, а WSDL-операция аналогична методу. WSDL публикует интерфейсы Web-сервисов сторонам, заинтересованным в коммуникации через гетерогенные платформы.

Однако WSDL не только является языком описания интерфейсов, он также включает конструкции, позволяющие описывать информацию об адресе и протоколе публикуемого Web-сервиса. Интересно то, что WSDL описывает абстрактный интерфейс для Web-сервиса, одновременно позволяя (в мучительных подробностях) связывать Web-сервис с определенным транспортным механизмом, таким как HTTP. Абстрагируя интерфейс, WSDL функционирует как технология многократно используемых Web-сервисов. Связывая Web-сервис с определенным транспортным механизмом, WSDL делает абстракцию конкретной. Если это покажется вам слегка шизофреничным, подумайте о космическом шатле: многократно используемая, полностью функциональная космическая капсула связана со специализированными, но одноразовыми стартовыми ракетными двигателями. Транспортный механизм может измениться, но полезный груз сохраняется.

Наконец, UDDI действует как реестр для публикации и локализации Web-сервисов. Выставляя информацию о сервисе и связывая интерфейсы в Web-реестре, UDDI предоставляет совместно используемую директорию для предпринимателей и клиентов, размещающих в этой директории Web-сервисы друг друга.

Создание Web-сервисов

SOAP позволяет создавать приложения, удаленно вызывая методы объектов. SOAP устраняет требование того, что две системы должны запускаться на одной платформе или быть написаны на одном языке программирования. Вместо вызова методов по определенному бинарному протоколу, пакет SOAP использует XML, основанный на тексте синтаксис для осуществления вызова методов. Вся информация между запрашивающим приложением и принимающим объектом пересылается в виде данных, заключенных между тегами, в XML-потоке по HTTP. С точки зрения Web-сервисов SOAP может быть реализован в качестве как клиента, так и сервера.

SOAP клиенты и серверы

Клиент SOAP – это программа, которая создает XML-документ, содержащий информацию, необходимую для удаленного вызова метода в распределенной системе. Клиенты SOAP не должны быть традиционными. В дополнение к тому, что они пополняют разнообразие ваших настольных приложений, клиенты SOAP могут служить Web-серверными или основанными на серверной технологии приложениями.

Сообщения и запросы от клиентов SOAP обычно пересылаются по HTTP. В результате документы SOAP способны обойти почти любой брандмауэр (firewall), допуская обмен информацией между разными платформами.

Сервер SOAP – это специальный код, который слушает SOAP сообщения и действует как распределитель и интерпретатор SOAP документов. Внешние Web-сервисы могут взаимодействовать с приложениями-серверами, основанными на технологии J2EE, которые обрабатывают запросы SOAP от множества клиентов.

Серверы SOAP гарантируют, что документы, полученные по HTTP соединению, преобразованы к языку, который понятен объекту и всем окружающим. Поскольку все коммуникации осуществляются в форме XML, объекты, написанные на одном языке (скажем, Java), могут связываться через SOAP с объектами, написанными на другом языке (например, C++). Работа SOAP сервера заключается в том, чтобы удостовериться, что конечные пункты понимают обслуживающий их SOAP.

SOAP и Java технология

Согласно спецификации SOAP 1.1, SOAP является легким протоколом для обмена информацией в децентрализованной, распределенной среде.

SOAP не устанавливает единую модель программирования, также как и не делает привязки к определенному языку программирования. В контексте языка программирования Java установление привязки к конкретному языку зависит от Java-сообщества. В настоящее время привязки к языку Java преследуются по инициативе JAX-RPC.

В недавнем обсуждении SOAP, состоявшемся на конференции разработчиков JavaOne(sm), инженеры компании Sun Роберто Чинници (Roberto Chinnici) и Рауль Шарма (Rahul Sharma) определили семейство технологий JAX как “дающее возможность создания Web-сервисов при помощи уже известных компонентных технологий JSP(tm) и EJB(tm) для платформы Java”. Сервлеты и сессионные компоненты, не имеющие состояния, были отмечены как две технологии, наиболее пригодные для инкапсулирования Web-сервисов.

Так что же такое в действительности SOAP?

Полностью подготовив платформу для изучения SOAP и описав решающую роль SOAP в создании Web-сервисов, рассмотрим более детально, что же такое в действительности SOAP, что и как делает этот протокол.

SOAP – это расширяемая, основанная на тексте структура для предоставления связи между разными сторонами (вообще говоря, объектами), которые не знают заранее друг о друге или о платформе, на которой работает противоположная сторона. С точки зрения объектов в сети SOAP – это изначально “свидание вслепую”. Клиентские приложения могут взаимодействовать в слабосвязанных средах, обнаруживать сервисы и динамически подсоединяться к ним без установления каких-либо предварительных соглашений.

SOAP является расширяемым, потому что SOAP клиенты, серверы и сам протокол могут развиваться, не разрушая уже существующие приложения. Более того, SOAP богат в плане поддерживаемых посредников и многоуровневых архитектур. Это означает, что узлы обработки могут находиться на пути запроса между клиентом и сервером. Эти промежуточные узлы обрабатывают части сообщений при помощи использования заголовков, которые позволяют клиентам определять, какая часть сообщения обрабатывается данным узлом. Такой метод обработки промежуточных заголовков выполняется по приватному соглашению между клиентским приложением и промежуточным узлом обработки. SOAP предоставляет заголовкам атрибут mustUnderstand, который позволяет клиенту определить, является обработка обязательной или опциональной. Если mustUnderstand установлен в 1, сервер должен либо выполнить промежуточную обработку, указанную в заголовке, либо выдать ошибку.

SOAP также устанавливает правила кодирования данных, называемые основными уровнями кодирования или кодированием “Section 5” (по названию раздела в спецификации SOAP, посвященного кодированию). Надо отметить, что кодирование в SOAP занимает большую часть сорокастраничной спецификации SOAP 1.1. Не слишком углубляясь в специфику типов данных XML, можно сказать, что кодирование SOAP может быть вкратце описано как коллекция простых или сложных значений.

Простые значения – это либо простые типы данных (например, int, float, string), либо встроенные типы, описанные в разделе 2 спецификации XML Schema. Сюда входят такие типы как байтовые массивы и перечисления.

Сложные значения включают структуры, массивы и сложные типы, определенные группой XML Schema. И последнее, однако немаловажное замечание: кодирование данных в SOAP определяет правила для сериализации объектов, т.е. для механизмов маршалинга и демаршалинга потоков данных. Стоит отметить, что кодирование “Section 5” необязательно, поэтому клиенты и серверы могут использовать различные соглашения по кодированию данных, если есть договоренность о формате.

И наконец, SOAP устанавливает набор правил, которые дают возможность клиентам и серверам осуществлять вызов удаленных процедур, используя SOAP как структуру коммуникаций. Будучи по сути протоколом, ориентированным на работу с сообщениями, SOAP может хорошо работать как RPC-протокол. Объектная сериализация – это механизм, обуславливающий эффективность SOAP-RPC.

Формат сообщений

Все вышеперечисленное выполняется в контексте стандартизованного формата сообщений. Основная часть сообщения имеет MIME тип “text/xml” и содержит SOAP конверт. Этот конверт является XML документом. Конверт содержит заголовок (опционально) и тело (обязательно). Тело конверта всегда предназначено конечному получателю сообщения, тогда как записи в заголовке могут быть адресованы узлам, выполняющим промежуточную обработку. К телу также могут быть присоединены бинарные или какие-либо другие вложения.

SOAP предоставляет клиенту возможность определить, какой из промежуточных узлов обрабатывает ту или иную запись заголовка. Поскольку заголовки ортогональны основному содержимому SOAP сообщения, они полезны для добавления к сообщению той информации, которая не влияет на обработку его тела.

Заголовки, к примеру, могут быть использованы для предоставления цифровой подписи к запросу, находящемуся в теле сообщения. В этом случае сервер аутентификации или авторизации может обработать запись заголовка (независящего от тела), разбирая информацию для проверки правильности подписи. Как только проверка правильности прошла успешно, остальная часть конверта будет передана на SOAP сервер, который обработает тело сообщения. Более детальное рассмотрение конверта SOAP поможет выяснить расположение и цель заголовка и элементов тела.

Анализ конверта SOAP

Спецификация SOAP 1.1 предоставляет следующий образец конверта:

<SOAP-ENV: Envelope
  xmlns: 
    SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV: 
    encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <SOAP-ENV:Header>
        <t:Transaction xmlns:t="some-URI">
                SOAP-ENV:mustUnderstand="1" 
                      5
        </t:Transaction>
      </SOAP-ENV:Header>
      <SOAP-ENV:Body>
        <m:GetLastTradePrice xmlns:m="some-URI">
                <symbol>DEF</symbol>
        </m:GetLastTradePrice>
      </SOAP-ENV:Body>
</SOAP-Envelope>

В этом примере запрос GetLastTradePrice посылается службе котировки акций на Web. Запрос принимает строковый параметр, аббревиатуру акции, и возвращает число с плавающей точкой в ответе SOAP.

Конверт SOAP – это верхний элемент XML документа, который представляет сообщение SOAP. Пространства имен XML используются для отделения идентификаторов SOAP от специфичных идентификаторов приложения. Пространства имен XML используются в основном для того, чтобы квалифицировать элементы в сообщении или отнести их к определенной области. Для понимания пространств имен SOAP необходимо быть знакомым со спецификацией пространств имен XML. Если же вы не знакомы с ней, представляйте себе пространство имен, как идентификатор некоторой окрестности элементов, который помогает уникально идентифицировать элементы SOAP, ассоциируя их с определенным местоположением, действительным или воображаемым.

Пространства имен

Первое пространство имен в примере указывает на схему SOAP, которая определяет элементы и атрибуты сообщения SOAP. Второе пространство имен ссылается на кодирование SOAP: типы данных “Section 5”, обсужденные ранее. Поскольку никакого дополнительного поэлементного кодирования не определено, данное кодирование применяется ко всему документу.

Заголовок

Первый элемент в заголовке нашего конверта SOAP является элементом транзакций, имеющим два атрибута: атрибут пространства имен и атрибут mustUnderstand со значением 1. Так как mustUnderstand установлен в 1, сервер, принимающий данное сообщение, должен выполнять промежуточную обработку на данном узле транзакций. Вы можете интерпретировать это следующим образом: сервер и клиент предварительно договорились о семантике, которая управляет обработкой данного элемента заголовка, поэтому сервер точно знает, что делать с содержимым элемента (в данном случае, со значением 5).

Если сервер, получающий сообщение, не понимает семантику обрабатываемого заголовка, он потребует полностью отменить запрос и выдаст ошибку. Элемент ошибки – это специальная часть тела сообщения SOAP и однозначный механизм отправки информации об ошибке клиенту.

Узлы промежуточной обработки, подобные данному, являются примером расширяемости SOAP. Клиенты включают такие узлы в сообщение SOAP, чтобы указать, что прежде чем обрабатывать тело сообщения, необходимо провести специальную обработку. Обеспечение обратной совместимости с серверами, неспособными осуществлять такую обработку, является всего лишь вопросом установки mustUnderstand в 0, что делает эту операцию необязательной.

Кроме того, SOAP сообщения могут содержать в заголовке записи, которые определяют узлы, осуществляющие авторизацию, шифрование, обработку персистенции состояния, обработку бизнес-логики и т.д. Заголовки помогают сделать SOAP модульной расширяемой моделью организации пакетов. Однако следует иметь в виду, что обработка заголовка полностью независима от тела сообщения SOAP.

Тело сообщения

Тело сообщения SOAP в примере содержит полезную нагрузку XML (XML payload), которая, предположим, выполняет RPC (Remote Procedure Calling – вызов удаленной процедуры). SOAP – это не только модульная, но также и довольно скрытая модель организации пакетов.

Здесь ничего явно не указывает на то, что был начат RPC. Все, что мы видим в теле, – это пара XML элементов, один из которых квалифицирован пространством имен. Задачей SOAP сервера является понимание семантики документа и осуществление правильных действий. В действительности, сервер предоставляет структуру для работы с полезной нагрузкой XML (XML payload) “значимым” способом. Слово “значимый” в данном случае подразумевает, что сервер осуществляет вызов удаленной процедуры в некоторой вспомогательной базе данных, чтобы получить готовую цену за элемент готового символа, содержащийся в теле сообщения. Вся магия происходит за занавесом SOAP RPC.

SOAP-RPC

Сообщения SOAP по существу являются односторонними пересылками информации от отправителя к получателю, однако SOAP сообщения часто объединяются для того, чтобы улучшить механизмы запроса и ответа. Для осуществления RPC в SOAP необходимо соблюдать некоторые соглашения. Прежде всего, сообщения запроса и ответа должны быть закодированы как структуры. Для каждого входного параметра операции должен существовать элемент (или член входной структуры) с таким же именем, как у параметра. И для каждого выходного параметра должен существовать элемент (или член выходной структуры) с соответствующим именем.

Далее следует укороченный вид SOAP-RPC сообщения, представленного ранее. Показаны только тела сообщений конвертов запроса и ответа SOAP.

Request (Запрос)
<SOAP-ENV:Body>
     <m:GetLastTradePrice xmlns:m="some-URI">
          <symbol>DEF</symbol>
     </m:GetLastTradePrice>
</SOAP-ENV:Body>

Response (Ответ)
<SOAP-ENV:Body>
     <m:GetLastTradePriceResponse xmlns:m="some-URI">
          <price>22.50</price>
     </m:GetLastTradePriceResponse>
</SOAP-ENV:Body>

Запрос вызывает метод GetLastTradePrice. Обратите внимание, что ответ определяет операцию GetLastTradePriceResponse. Общее соглашение SOAP требует, чтобы в конце операции запроса (Request) добавлялось слово Response для создания структуры ответа (Response). Данная выходная структура содержит элемент с названием price (цена), который возвращает результат вызова метода, возможно, в виде числа с плавающей точкой.

Важно отметить, что нигде в конверте SOAP не выражены явно типы данных, поэтому мы действительно не знаем тип символа или тип результирующего параметра цены, только лишь смотря на сообщение SOAP. Клиентские приложения определяют типы данных либо открыто посредством кодирования “Section 5”, либо частным образом через согласованные контакты с сервером. В обоих случаях эти определения не включены явно в SOAP сообщение.

И наконец, для осуществления RPC необходим низкоуровневый протокол, такой как HTTP. Хотя спецификация SOAP 1.0 предписывает использование HTTP, как транспортного протокола, SOAP 1.1 (а также спецификация “Сообщение SOAP с вложениями”) разрешает использовать FTP, SMTP и даже (возможно) TCP/IP сокеты. Все правила сериализации и кодирования SOAP относятся также и к RPC-параметрам.

Случай использования SOAP

Теперь, когда мы подробно рассмотрели конверт SOAP, сделаем небольшое отступление и рассмотрим SOAP с позиции случая использования, чтобы уловить смысл спускоподъемной обработки, которая имеет место в распределенном Web-окружении. Ниже приведено несколько основных итоговых суждений, формирующих концептуальную основу Web-сервисов и SOAP.

  • Клиентское приложение где-либо в Internet потребляет Web-сервисы.

  • Web-сервисы (через SOAP) выставляют объектные методы.

  • Объектные методы обращаются к удаленным данным где угодно на Web.

Применяя транзитивную логику к этим сетевым высказываниям, мы можем вывести итоговое суждение о Web-сервисах и SOAP: “Клиенты повсюду потребляют данные, находящиеся где угодно на Web”. Что и требовалось доказать.

Далее случай использования рассмотрен более детально.

  1. Клиент SOAP использует UDDI реестр для локализации Web-сервиса. В большинстве случаев, вместо управления WSDL напрямую, приложение SOAP будет сконструировано так, чтобы использовать специфичный тип порта и стиль связывания, и будет динамически конфигурировать адрес сервиса, вызываемого с целью согласования с сервисом, найденным посредством UDDI.

  2. Клиентское приложение создает сообщение SOAP, которое является XML документом, способным осуществлять необходимые операции запроса/ответа.

  3. Клиент посылает SOAP сообщение JSP или ASP странице на Web-сервере, слушающем запросы SOAP.

  4. Сервер SOAP анализирует пакет SOAP и вызывает соответствующий метод объекта в его области, передаваемой в параметрах SOAP документа. Перед принятием сообщения SOAP сервером узлы промежуточной обработки могут выполнять специальные функции, как указано в заголовках SOAP.

  5. Запрашиваемый объект выполняет обозначенную функцию и возвращает данные SOAP серверу, который запаковывает ответ в конверт SOAP. Затем сервер “кладет” конверт SOAP в объект ответа (например, сервлет или COM-объект), который посылается обратно запрашивающей машине.

  6. Клиент получает объект, “снимает” конверт SOAP и посылает ответный документ программе, первоначально запросившей его, завершая цикл запроса/ответа.

Заключение

SOAP – это основанный на XML протокол для отправки сообщений и осуществления вызовов удаленных процедур в распределенной среде. При использовании SOAP данные могут быть сериализованы безотносительно любого транспортного протокола, хотя обычно выбирается протокол HTTP.

SOAP хорошо подходит для создания взаимодействующих систем, не зависящих от платформы и языка. В целом SOAP и Web-сервисы отвечают за все необходимое при построении инфраструктуры распределенных приложений на вершине XML. SOAP минимизирует проблему межплатформенной совместимости в организации доступа к данным, разрешая конфликт между моделями компонентных объектов COM и Java.

Возвращаясь к метафоре, с которой начиналось обсуждение, отметим, что SOAP – это идеальная среда для объектов любых типов (даже голливудских: Брэда Питта и Эдварда Нортона), используемая в качестве коммуникационной среды. Ожидается, что результаты этой новой технологии (так же, как и в фильме) сотрясут землю.

Ссылки

“Структура для использования Web-сервисов”, Симеон Симонов, XML Journal, том 2, изд. 6.

“SOAP 1.1 и платформа Java: введение в технологию JAX-RPC”, Роберто Чинници и Рауль Шарма, из выступления на конференции разработчиков JavaOne, июнь 2001.

Понимание SOAP, Кеннард Скрайбнер и Марк К. Стайвер, издательство Sams, 2000. (Чрезвычайно подробное, низкоуровневое представление SOAP и сетевых технологий. Великолепная книга для опытных разработчиков XML и Web-сервисов, желающих стать экспертами в SOAP.)

“Написание вашего первого Web-сервиса”, Энди Маккрайт, Web Services Journal, 1-й выпуск, июнь 2001.

XML и SOAP программирование для серверов BizTalk, Брайан Е. Трэвис, издательство Microsoft, 2000. (Пусть название не отпугивает вас. Это превосходный обзор Web-сервисов и SOAP, блестяще написанный и чрезвычайно хорошо организованный. BizTalk отходит на задний план по сравнению с начальными сведениями, которые занимают большую часть текста. Великолепная книга для начинающих.)

Об авторе

Том Клементс является внештатным техническим писателем, специализирующимся на документации по Java API, XML/XSLT, драйверам устройств и беспроводной связи.

Что нужно знать о его преимуществах и использовании

Мы включаем продукты, которые, по нашему мнению, полезны для наших читателей. Если вы совершаете покупку по ссылкам на этой странице, мы можем получить небольшую комиссию. Вот наш процесс.

Мыло удаляет грязь и пот с вашего тела, делая вашу кожу чистой и свежей. Но ваше тело может не соглашаться с типом мыла, которое вы используете.

Некоторые традиционные или обычные мыла могут быть слишком жесткими. Эти продукты очистят вашу кожу, но могут сделать ее сухой или раздраженной.

В этом случае мягкое мыло может быть лучшим выбором. Этот тип мыла содержит нежные ингредиенты, которые делают вашу кожу не только свежей, но и более здоровой.

Некоторые люди считают, что все мыла одинаковы, но есть разница между традиционным и мягким мылом. Это различие напрямую связано с ингредиентами этих продуктов.

Многие мыла, продаваемые в магазинах, не являются «настоящим» мылом. Настоящее мыло — это сочетание натуральных жиров и щелочи (щелочи).Щелок также известен как гидроксид натрия, химическое вещество, получаемое из соли.

Однако сегодня многие традиционные или обычные мыла не содержат щелочь или натуральный жир. Это мыло на самом деле являются синтетическими моющими или очищающими средствами.

Они могут содержать ароматизаторы, лаурилсульфат натрия и другие ингредиенты, агрессивные для кожи. Это мыло может нарушить баланс pH (уровень кислотности) вашей кожи, вызывая дальнейшее раздражение.

Средний уровень pH в традиционном мыле составляет от 9 до 10.Однако нормальный уровень pH вашей кожи составляет всего от 4 до 5.

Мыло с высоким pH нарушает естественный pH кожи, делая ее менее кислой. Это может привести к появлению прыщей, сухости кожи и другим проблемам.

Мягкое мыло, напротив, не влияет на рН кожи.

Мягкое мыло отлично подходит для людей с чувствительной кожей, которым требуется мягкое очищающее средство. Эти продукты являются смягчающим средством, не являющимся косметическим увлажняющим средством.

Мягкое мыло смягчает и успокаивает кожу, поскольку не удаляет ее естественные питательные вещества и масла.Это может сделать кожу более молодой и здоровой, а также уменьшить симптомы кожных заболеваний, таких как псориаз и экзема.

Мягкое мыло может помочь улучшить следующие условия:

Угри

Угри включают в себя угри, белые точки и другие неровности, которые образуются, когда поры закупориваются грязью и омертвевшей кожей.

Прыщи поддаются лечению безрецептурными и рецептурными лекарствами. Кроме того, некоторые люди видят улучшение состояния своей кожи после использования мягких средств, таких как мягкое мыло или мыло от прыщей.

Эти очищающие средства не содержат агрессивных ингредиентов, таких как ароматизаторы и спирт, поэтому они могут эффективно очищать кожу, не вызывая и не усугубляя акне.

Чувствительная кожа

Чувствительная кожа может включать экзему, розацеа, псориаз и другие кожные заболевания, которые раздражают верхний слой кожи.

Не существует лекарства от некоторых состояний, вызывающих чувствительную кожу, но правильный уход за кожей может уменьшить выраженность покраснения, сухости и зуда.

Мягкое мыло оказывает успокаивающее действие на кожу, снимая воспаление.Он также может действовать как естественный увлажняющий крем, сохраняя кожу увлажненной.

Зуд кожи

Зуд кожи может быть вызван такими заболеваниями, как псориаз или экзема, а также сухостью. Жесткие очищающие средства, макияж, тоники и увлажняющие кремы могут вызвать дальнейшую сухость и продлить зуд.

Переход на мягкое мыло помогает минимизировать сухость, делая кожу гладкой и увлажненной.

Покраснение кожи

Даже если у вас нет проблем с кожей, у вас может появиться покраснение после использования традиционного мыла или очищающих средств.Это может произойти из-за того, что продукт слишком агрессивен для вашей кожи или у вас аллергия на какой-либо ингредиент продукта.

Переход на мягкое мыло может помочь уменьшить покраснение и раздражение кожи.

Хотя мягкое мыло мягкое и предназначено для чувствительной кожи, некоторые люди чувствительны к ингредиентам, содержащимся в некоторых из этих мыл.

Если вы используете мягкое мыло и продолжаете испытывать раздражение кожи, прекратите его использование и обратитесь к врачу или дерматологу. Признаки раздражения включают повышенное покраснение, зуд, сухость или шелушение кожи.

У вас могут быть лучшие результаты с гипоаллергенным мылом. Таким образом можно безопасно удалить лишнюю грязь без раздражения.

Врач также может направить вас к аллергологу, который определит, есть ли у вас аллергия на конкретный ингредиент мягкого мыла.

Мягкое мыло можно купить в аптеках, продуктовых магазинах и других магазинах.

Покупая мыло, ищите продукты без ароматизаторов и спирта или мыло, специально разработанное для людей с гиперчувствительной или аллергической кожей.

Ознакомьтесь с этим мягким мылом, доступным в Интернете.

Если у вас чувствительная кожа или вы ищете мыло, которое не лишает ваше лицо натуральных масел и питательных веществ, мягкое мыло помогает поддерживать естественный pH-баланс вашей кожи. В результате вы можете очистить кожу, сводя к минимуму риск раздражения.

.

Что означает SOAP?

14 9004 SOAP Стандарты академического прогресса

Академические науки и наука

9000anagan Business 7»

South Компании и фирмы


SOAP

Простой протокол доступа к объектам

Вычисления »Программное обеспечение — и многое другое …

 Оценить:
SOAP

Субъективная цель

Бизнес »Общий бизнес

 Оцените:
SOAP

Surrey, Incorporated (исключен из листинга)

Бизнес»

 Оцените:
SOAP

Сервисно-ориентированный протокол архитектуры

Академия и наука »Архитектура

 Оценить:
Оцените:
SOAP

State Of Art Paper

Академия и наука »Университеты

 900
SOAP

Точка доступа с защищенным оверлеем

Вычислительная техника »Кибербезопасность

 Оцените:
SOAP Оцените:
SOAP

Предотвращение ослабления операндов хранилища

Вычисления »Сборка
SOAP

Заявление о наблюдении за Священным Писанием и молитва

Сообщество

 Оцените его:
SOAP

Спасите наши удивительные растения

 Оцените:
SOAP

Sons Of A Preacherman

Сообщество »Религия

 Оцените:
SOAP Оцените:
SOAP

Вычеркните аббревиатуры, ПОЖАЛУЙСТА!

Разное »Приколы

 Оцените:
SOAP

Печать утвержденной упаковки

Бизнес» Общий бизнес

4

SOAP

Распространение Священных Писаний Отчетность и молитва

Сообщество »Религия

 Оценить план:
Задача SOAP

Цель SOAP Медицина »Больницы

 Оцените:
SOAP

Super Over-Rated Action Pig

Интернет» Chat

 Оцените it5 :

Приложение «Наблюдение за Священным Писанием» Молитва

Разное »Несекретный

 Оцените:
SOAP

Только надежно?

Интернет »Чат

 Оцените:
SOAP

Snakes On A Plane

Сообщество» Новости и СМИ
SOAP

Общество акушерской анестезии и перинатологии

Академические и научные общества

 Оцените это:
Оцените:
SOAP

Субъективная объективная оценка и план

5

5

 Разное»

Разное »

 Оценить it:
SOAP

Subjective, Objective, Assessment and Plan

Medical »British Medicine

 Оцените: