GetInfo.Ru – Компьютерная библиотека
Последние поступления
Как выбрать систему управления базы данных
Базы данных03/09/14
Этапы загрузки UNIX (в схеме)
Unix27/03/12
Gatewall Antispam: тотальный контроль электронной почты
Спам21/04/11
Мастер-класс: создаем Интернет-магазин (Часть 1)
Обзоры ПО20/04/11
CorelDRAW Graphics Suite X5: Что нового?
Обзоры ПО20/07/10
Добавить статью
Самые читаемые материалы
DOM для Web-сервисов, часть 1(11578)
XML-формат обмена данными Сбалансированной системы показателей: практический пример (часть II)(10253)
XML и базы данных? Доверьтесь своей интуиции(10247)
XML Viewer (IBM alphaWorks)(9447)
Обзор XML-стандартов, часть 2(9128)
Всего статей: 793Всего авторов: 364Подразделов: 47Добавлено за сутки: 0
Статьи  СТАТЬИ Форум  ФОРУМ Рейтинг  РЕЙТИНГ Поиск  ПОИСК Контакты  КОНТАКТЫ
» Главная » XML » SOAP 1.2 и запрос GET

SOAP 1.2 и запрос GET


Intersoft Lab
market@iso.ru
http://www.iso.ru/

Дата: 04-03-2004
Автор: Бёнуа Маршаль (Benoit Marchal)
Перевод: Intersoftlab

Беглый взгляд на модели ответа MEP

Новые возможности, появившиеся в SOAP 1.2, позволяют более тесно связать Web-сервисы и структуру Интернет. Так, одно из нововведений – это метод GET. Этот метод имеет огромное значение, поскольку с его помощью можно выполнять разнообразную оптимизацию. Значимость GET подтверждает сам Web – достаточно вспомнить, настолько широко в нем используется данный запрос. Эта статья посвящена методу GET.

Одним из недостатков первой версии спецификации SOAP (SOAP 1.0) считалась ее зависимость от метода HTTP POST. Хотя в SOAP и использовался популярный протокол (HTTP), архитектура, на основании которой был построен протокол SOAP, вызвала достаточно нареканий.

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

О методе GET

Чем же плох POST? Если попытаться объяснить в двух словах, то HTTP определяет различные методы для взаимодействия с сервером, основными из которых являются GET и POST. На практике GET используется для большинства запросов, тогда как POST предназначен для форм, которые обновляют сайт. Согласно спецификации HTTP, предназначение GET - извлечения информации, этот метод должен быть безопасным и идемпотентным.

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

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

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

Различие между GET и POST не всегда столь жёсткое, а некоторые их аспекты довольно непрозрачны. Многие сайты инкапсулируют извлечение информации в запросе POST, возможно, из-за того, что разработчики считали, что такой подход более простой.

Несмотря на то, что это обсуждение методов HTTP может показаться излишне абстрактным и теоретизированным, это далеко не так. Обеспечение оптимальной производительности браузеров и промежуточного программного обеспечения (прокси, брандмауэров и решений по доставке контента а-ля Akamai) зависит от возможности различать запросы (см. Ресурсы).

Объединение SOAP и GET

Первоначально SOAP поддерживал только запросы POST. Однако, Web-сервисы могут предоставлять услуги, которые безопасны согласно приведенному выше определению. Например, сервис, который запрашивает о выполнении заказа, является и безопасным, и идемпотентным. В соответствии со спецификацией HTTP, он мог бы быть реализован как запрос GET. А согласно спецификации SOAP 1.0, он должен быть POST.

В спецификации SOAP 1.2 появились модели MEP (Message Exchange Patterns, модели обмена сообщениями) и новое связывание HTTP, комбинируя которые можно реализовать Web-сервисы, которые могут отвечать на запросы GET. Модели MEP регистрируют модели взаимодействия клиента и сервера. Модель SOAP Request-Response MEP (модель запрос-ответ SOAP) – это типичное взаимодействие Web-сервиса: клиент посылает запрос на сервер, а сервер отвечает.

В этой статье подробно рассматривается модель SOAP Response MEP (модель ответа SOAP). Эта модель определяет только ответ, без запроса. На практике, это означает, что отправленный запрос не является запросом SOAP – только ответ является сообщением SOAP. При комбинировании с этим новым связыванием HTTP модель Response MEP допускает запросы GET. Ниже описано, как работает эта модель:

  • Клиент выдает запрос GET. Чтобы запросить ответ SOAP, он присваивает заголовку Accept значение application/soap+xml.

  • Cервер отвечает, и клиент обрабатывает ответ как нормальный ответ SOAP.

Используя заголовок Accept, сервер отличает запросы SOAP от обычных запросов HTTP. Чтобы указать свои предпочтения, клиент может воспользоваться свойством q, задавая различный контент/тип в заголовке Accept.

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

Разумеется, поскольку запрос не является частью SOAP, может возникнуть вопрос о том, каким образом клиент узнает, какой унифицированный локатор вызвать и какие параметры передавать. Ответ на этот вопрос прост: сервер SOAP должен делать то, что делают обычные Web-серверы, и включать этот унифицированный локатор ресурса в предыдущее взаимодействие SOAP. Ничто не мешает соединять и сочетать GET и POST.

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

Axis и поддержка WSDL

На момент написания этой статьи Axis поддерживает только SOAP 1.1, хотя реализует в ограниченном виде GET. Используя его унифицированный локатор ресурса и указав параметр method и другие параметры, можно активизировать любой запрос.

Предположим, например, что автор статьи реализовал по адресу (с унифицированным локатором ресурса) http://joker.psol.com/axis/order/Status.jws сервис, предназначенный для сообщения статуса заказа. У этого сервиса два метода - track и detailTrack, которые принимают номер заказа (number) в качестве параметра. Этот сервис может быть активизирован через http://joker.psol.com/axis/order/Status.jws?method=track&onumber=56544322.

Язык WSDL 2.0 (разработкой которого в настоящий момент занимается консорциум W3C) добавляет атрибут pattern в определение операций. Этот атрибут указывает, какую модель SOAP MEP поддерживает сервис (WSDL вызывает модели MEP, поэтому между SOAP и WSDL нет путаницы). Пример сервиса отслеживания приведен в Листинге 1.

Листинг 1. Фрагмент WSDL

<operation name="track" pattern="http://www.w3.org/2003/11/wsdl/out-only">
   <output message="trackResponse"/>
</operation>

Заключение

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

Автор рекомендует читателям, ожидающим того момента, когда в их любимых инструментальных средствах появится поддержка SOAP 1.2 и WSDL 2.0, пересмотреть свои Web-сервисы и выявить безопасные операции, являющиеся основными кандидатами на переход к связыванию GET.

Ресурсы

  • Форум, посвященный обсуждению статей в колонке Беноита Марчала (Benoît Marchal) “XML в действии” (Working XML).

  • На странице WSDL 2.0 приведена информация о ходе работ над этим языком с учетом последних изменений в SOAP.

  • На странице рабочей группы XML Protocol консорциума W3C содержится подробная информация о SOAP.

  • Изучив страницу HTTP, можно узнать текущую позицию W3C в отношении этого протокола.

  • На сайте Брайена Д. Дэвисона (Brian D. Davison) Ресурс по Web-кэшированию и доставке контента приводится много полезной информации о кэшировании, прокси и доставке контента.

  • В статье Ли Доддса (Leigh Dodds) «Когда использовать GET» (When to use GET?) рассказывается об истории включения поддержки GET в SOAP.

  • Статья Расселла Бутека (Russell Butek) «Отправка и получения сообщений SOAP с JAX-RPC» (Send and receive SOAP messages with JAX-RPC) (developerWorks, сентябрь 2003г.).

  • IBM WebSphere Studio Application Developer – это продукт для разработки приложений, с помощью которого можно создавать всевозможные приложения, реализующие различные технологии: XML, JSPTM, сервлеты, HTML, Web-сервисы, базы данных и EJBs.

  • Множество других ресурсов в зоне XML рубрики developerWorks. Полный список статей колонки «Совет» (Tip) приведен на странице с кратким описанием этой рубрики.

  • На странице информационный бюллетень Web-cервисов/Советов по XML можно подписаться на еженедельную рассылку новостей рубрики developerWorks.

  • На странице IBM Certified Developer in XML and related technologies приведена информация о том, как стать сертифицированным разработчиком XML.

Об авторе

Бёнуа Маршаль (Benoît Marchal) – бельгийский консультант. Он автор многих книг, посвященных XML, в том числе «XML на примерах, второе издание» (XML by Example, Second Edition). Беноит Марчал специализируется в области XML, технологий Java и электронной коммерции. Более подробную информацию о нем можно получить на его сайте www.marchal.com. С ним можно связаться по адресу bmarchal@pineapplesoft.com.


Оригинальный текст статьи можно посмотреть здесь: Tip: SOAP 1.2 and the GET request

 
07.05.2004
Версия для печати Версия для печати Запомнить ссылку Запомнить ссылку
Ваша оценка:  1   2   3   4   5     

 О проектеПерепечаткаАвторамПартнерыО нас пишут
Наверх
©2003—2007. GETINFO.RU. ВСЕ ПРАВА ЗАЩИЩЕНЫ.