45743 (762134)
Текст из файла
Понимание SOAP
Viktor Shatokhin , Aaron Skonnard, DevelopMentor
Введение
Изначально SOAP расшифровывался как "Протокол доступа простых объектов" (Simple Object Access Protocol). Если бы вы спросили кого-нибудь о том, что значит SOAP, несколько лет назад, то получили бы примерно такой ответ:"это для работы DCOM и Corba (т.е. RPC вызовов) через Internet". Первые авторы признавали тогда, что они фокусировались на "доступе к объектам", но со временем захотелось, чтобы SOAP обслуживал более широкую аудиторию. Таким образом, фокус спецификации быстро сместился с объектов на обобщенную оболочку обмена XML сообщениями.
Этот переход создал небольшую проблему с "O" в аббревиатуре SOAP. Интересно, что Рабочая группа SOAP 1.2 сохранила (до сих пор) имя SOAP (оно так популярно, как же может быть иначе?), но было решено не расшифровывать его, чтобы не вводить разработчиков в заблуждения. Сегодня в официальном определении, приводимом в самых последних спецификациях SOAP 1.2, объекты даже не упоминаются:
SOAP – это облегченный протокол, предназначенный для обмена структурированной информацией в децентрализованной, распределенной среде. Для определения наращиваемой оболочки обмена сообщениями, обеспечивающей структуру сообщения, которая может быть использована при обмене различными базовыми протоколами, SOAP использует XML технологии. Эта оболочка разработана независимой от любой конкретной модели программирования и других особых семантик реализации.
Это определение действительно отражает суть того, чем является SOAP сегодня. SOAP определяет способ перемещения XML сообщений из точки А в точку В (см. Рисунок 1). Это делается путем обеспечения оболочки обмена сообщениями на базе XML, которая является: 1) наращиваемой; 2) пригодной к использованию различными базовыми сетевыми протоколами; 3) независимой от моделей программирования. Давайте немного более детально остановимся на каждой из этих трех характеристик.
Рисунок 1. Простой обмен сообщениями SOAP
Во-первых, ключевым в SOAP является его наращиваемость. Когда аббревиатура еще что-то означала, буква "S" имела значение "Простой". Если мы хоть чему-то и научились в Web, так это тому, что простота всегда одерживает верх над эффективностью или техническим качеством, и когда делается ставка на способность к взаимодействию, она становится абсолютным требованием. Простота остается одной из основных целей при разработке SOAP, что доказывает отсутствие в SOAP различных возможностей распределенных систем, таких как безопасность, маршрутизация, надежность и т.д. SOAP определяет оболочку взаимосвязи, в которой есть возможность добавить эти возможности в будущем как многоуровневые расширения. Microsoft, IBM и другие производители программного обеспечения активно работают над созданием общего пакета расширений SOAP, которые добавят многие из этих возможностей, ожидаемых большинством разработчиков. Первым шагом стала Глобальная архитектура XML Web сервисов (Global XML Web Services Architecture (GXA)). Microsoft уже выпустила реализацию некоторых спецификаций GXA под названием Расширения Web сервисов 1.0 SP1 для Microsoft .NET (Web Services Enhancements 1.0 SP1 for Microsoft .NET (WSE)).
Во-вторых, SOAP может использоваться в любом транспортном протоколе, таком как TCP, HTTP, SMTP или даже MSMQ (см. Рисунок 1). Тем не менее, чтобы поддерживать возможность взаимодействия, должны быть определены взаимосвязи co стандартными протоколами, структура которых различна для каждой среды. Спецификация SOAP обеспечивает гибкую оболочку для определения взаимосвязей произвольных протоколов и сегодня обеспечивает явное связывание для HTTP, поскольку он так широко используется.
В-третьих, SOAP разрешен для всех моделей программирования и не привязан к RPC. Большинство разработчиков сразу же отождествили SOAP с осуществлением RPC вызовов к распределенным объектам (т.к. первоначально говорилось об "организации доступа к объектам"), в то время как в действительности фундаментальная модель SOAP более близка к традиционным системам обмена сообщениями, таким как MSMQ. SOAP определяет модель обработки отдельных, однонаправленных сообщений. Вы можете объединить множество сообщений в общий процесс обмена сообщениями. Рисунок 1 иллюстрирует простое однонаправленное сообщение, при котором отправитель не получает ответа. Однако получатель может послать отправителю ответ (см. Рисунок 2). SOAP предусматривает любое количество схем обмена сообщениями, запрос/ответ является всего лишь одним из них. Другие примеры включают требование/ответ (обратный запросу/ответу), нотификации и длительные одноранговые разговоры.
Рисунок 2. Схема обмена сообщениями запрос/ответ
Разработчики часто путают запрос/ответ с RPC, в то время как это совершенно разные вещи. RPC использует запрос/ответ, но запрос/ответ необязательны для RPC. RPC является моделью программирования, которая дает возможность разработчикам работать с вызовами методов. RPC требует преобразования сигнатуры метода в SOAP сообщения. Из-за популярности RPC SOAP описывает соглашение об использовании RPC с SOAP (см. раздел RPC и кодирование данной статьи)
Вооруженная этими тремя главными характеристиками, оболочка обмена SOAP сообщениями способствует обмену XML сообщениями в гетерогенных средах, для которых возможность взаимодействия долгое время была проблемой.
SOAP версии
От первой опубликованной спецификации SOAP до сегодняшней широко применяемой SOAP 1.1 многое изменилось: начиная от малейших деталей, заканчивая значительными подвижками в мышлении. SOAP 1.1 была предложена W3C и опубликована как заметка в мае 2000. Статус "Заметка W3C" сделало SOAP 1.1 несколько большим, чем хорошей идеей, т.к. она не прошла строгости обработки W3C, по окончании которого окончательно достигла бы статуса "Рекомендации". Тем не менее, из-за широкой поддержки как крупных, так и мелких производителей, сегодня SOAP 1.1, фактически, все еще считается стандартом.
W3C использовал Заметку SOAP 1.1 в качестве источника для новой Рабочей группы XML протокола, ответственной за создание следующей версии SOAP, SOAP 1.2. Сейчас SOAP 1.2 является "Кандидат в Рекомендации", это означает, что она находится на стадии реализации и недалека от завершения. Как только SOAP 1.2 станет "Рекомендацией", она, вероятно, быстро найдет поддержку у производителей.
После введения SOAP 1.2 производители должны будут продолжать поддерживать SOAP 1.1 для обеспечения обратной совместимости. Разработка новых версий SOAP основывается на пространствах имен XML. SOAP 1.1 определяется пространством имен http://schemas.xmlsoap.org/soap/envelope/, в то время как SOAP 1.2 – пространством имен http://www.w3.org/2002/12/soap-envelope (хотя оно изменится, когда SOAP 1.2 станет Рекомендацией).
В Таблице 1 представлены пространства имен и местоположения спецификаций каждой версии. Далее статья будет посвящена наиболее важным вопросам SOAP 1.1. В текущей спецификации SOAP 1.2 вы можете найти подробный список различий между этими двумя версиями.
Таблица 1. Информация по SOAP версиям
| SOAP 1.1 | |
| Имя пространства имен | http://schemas.xmlsoap.org/soap/envelope/ |
| Местоположение спецификации | http://www.w3.org/TR/SOAP/ |
| SOAP 1.2 | |
| Имя пространства имен | http://www.w3.org/2002/12/soap-envelope |
| Местоположение спецификации | http://www.w3.org/TR/soap12-part0/ http://www.w3.org/TR/soap12-part1/ http://www.w3.org/TR/soap12-part2/ |
Оболочка обмена сообщениями
Основной раздел спецификации SOAP – это оболочка обмена сообщениями. Оболочка обмена сообщениями SOAP определяет набор элементов XML для организации пакетов произвольных XML сообщений для передачи их между системами.
Оболочка состоит из следующих основных XML элементов: Envelope, Header, Body и Fault. Все они из пространства имен http://schemas.xmlsoap.org/soap/envelope/ SOAP 1.1. Я привел здесь полное описание XML Schema для SOAP 1.1. Лично для себя я нашел полезным просмотр схемы при ознакомлении с конструкциями XML.
Описание XML Schema SOAP 1.1
xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/" targetNamespace="http://schemas.xmlsoap.org/soap/envelope/" > maxOccurs="unbounded" processContents="lax" /> processContents="lax" /> maxOccurs="unbounded" processContents="lax" /> processContents="lax" /> maxOccurs="unbounded" processContents="lax" /> processContents="lax" /> type="tns:encodingStyle" /> minOccurs="0" /> minOccurs="0" /> maxOccurs="unbounded" processContents="lax" /> processContents="lax" /> Если вы закончили рассмотрение complexType для Envelope, вы можете быстро ознакомиться с тем, какое отношение эти элементы имеют друг к другу. Следующий шаблон сообщения иллюстрирует структуру Конверта SOAP: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> Элемент Envelope всегда является корневым элементом SOAP сообщения. Таким образом, приложения могут, просто взглянув на имя корневого элемента, распознать "SOAP сообщения". Приложения также могут определить версию используемого SOAP, проверяя имя пространства имен элемента Envelope. Элемент Envelope содержит необязательный элемент Header (более подробно см. в разделе Расширяемость), за которым следует обязательный элемент Body. Элемент Body представляет полезный груз сообщения. Элемент Body является контейнером, в котором может содержаться любое количество элементов из любого пространства имен. Именно здесь размещаются данные, которые вы пытаетесь отправить. Например, следующее SOAP сообщение представляет запрос для трансфара фондов между банковскими счетами: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 22-342439 98-283843 100.00 Если получатель поддерживает запрос/ответ и может успешно обработать сообщение, он отправит другое SOAP сообщение назад отправителю. В этом случае информация ответа также будет содержаться в элементе Body, как показано в данном примере: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:x="urn:examples-org:banking"> 22-342439 33.45 98-283843 932.73 Оболочка обмена сообщениями также определяет элемент Fault для представления ошибок в пределах элемента Body, когда что-то идет не так. Это важно, потому что без стандартного представления ошибки каждому приложению придется вводить собственные, что сделает невозможным для общей инфраструктуры различить успех и неудачу. Следующий пример SOAP сообщения содержит элемент Fault, который представляет ошибку "Несоответствующие фонды", происходящую при обработке запроса: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> soap:Server Insufficient funds 22-342439 100.00 89.23 Элемент Fault должен содержать элемент faultcode, за которым следует элемент faultstring. Элемент faultcode, используя имя определенного пространства имен, классифицирует ошибку, в то время как элемент faultstring обеспечивает читабельное описание ошибки для человека (подобно тому, как работает HTTP). В Таблице 2 приведены краткие описания определенных в SOAP 1.1 кодов ошибок (все они в пространстве имен http://schemas.xmlsoap.org/soap/envelope/) Элемент Fault также может содержать элемент detail для предоставления деталей ошибки, которые могут помочь клиентам диагностировать проблему, особенно в случае кодов ошибки Client и Server. Таблица 2. Коды ошибок в SOAP 1.1 Name Meaning VersionMismatch Обрабатывающая сторона обнаружила неверное пространство имен для SOAP элемента Envelope. MustUnderstand Ближайший дочерний элемент SOAP элемента Header, который был или не понят, или не подходил обрабатывающей стороне, содержит SOAP атрибут mustUnderstand со значением "1". Client Класс ошибок Client показывает, что сообщение было неправильно сформировано или не содержит соответствующей информации для того, чтобы быть успешно обработанным. Это обычно свидетельствует о том, что не надо повторно отправлять сообщение, не изменив его. Server Класс ошибок Server показывает, что сообщение не может быть обработано не из-за его содержимого, но, скорее, из-за сбоя при обработки сообщения. Сообщение может пройти успешно, если будет повторно отправлено в более поздний момент времени. Теперь представьте, что вы хотите в оригинальное сообщение добавить некоторую идентификационную информацию, чтобы получатель мог определить, имеет ли отправитель соответствующие права на выполнение пересылки. Чтобы сделать это, необходимо добавить удостоверяющую информацию в Body, как показано ниже:
Характеристики
Тип файла документ
Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.
Будьте внимательны на мобильных устройствах, так как там используются упрощённый функционал даже в официальном приложении от Microsoft, поэтому для просмотра скачивайте PDF-версию. А если нужно редактировать файл, то используйте оригинальный файл.
Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
