Элементы SOAP-сообщения. Назначение, теги и атрибуты.

Оболочка SOAP – это XML документ, которым обмениваются между собой взаимодействующие узлы. Она включает в себя:

Элемент документа оболочка SOAP, который имеет локальное имя Envelope и URL пространства имен http://www.w3.org/2001/06/soap-envelope. Этот элемент может иметь необязательный дочерний элемент с локальным именем Header и тем же пространством имен. Если этот элемент присутствует, то он должен быть первым прямым дочерним элементом и может быть использован для добавления информации в оболочку без предварительного соглашения с узлами сети, которые участвуют в обмене.

Следующий дочерний элемент оболочки должен иметь локальное имя Body. Этот обязательный элемент должен быть вторым прямым дочерним элементом оболочки, если присутствует Header. Если элемент Header отсутствует, то элемент Body должен быть первым прямым дочерним элементом.

<env: Envelope xmlns.env = “…”>

<env: Header/>

<env: Body/>

</env: Envelope>

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

Пример атрибута заголовка mustUnderstand:

<env: Header>

<authentification xmlns = “http://myDomain/app” env: mustUnderstand = “1”>

<user>Kate</user>

<password>1234</password>

</authentification>

</env: Header>

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

Пример тела:

<env: body>

<test:getMyMethodResponse Xmlns: test = ”http://myDomain/service”>

<test_mess>

<symbol>EDS</symbol>

</test_mess>

</test:getMyMethodResponse>

</env: body>

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

<soap-env.fault>

<faultcode>SOAP-ENV.server</faultcode>

<faultstring>ServerError</faultstring>

<detail>

<e: myxmlns:e = “someURL”>

<message>My App didn’t work </message>

<errorcode>/06/</errorcode>

</e: myxmlns:e >

</detail>

</soap-env.fault>

Архитектура REST

REST (Representational state transfer) – это стиль архитектуры программного обеспечения для распределенных систем, таких как World Wide Web, который, как правило, используется для построения веб-служб. Термин REST был введен в 2000 году Роем Филдингом, одним из авторов HTTP-протокола. Системы, поддерживающие REST, называются RESTful-системами.
В общем случае REST является очень простым интерфейсом управления информацией без использования каких-то дополнительных внутренних прослоек. Каждая единица информации однозначно определяется глобальным идентификатором, таким как URL. Каждая URL в свою очередь имеет строго заданный формат.
А теперь тоже самое более наглядно:
Отсутствие дополнительных внутренних прослоек означает передачу данных в том же виде, что и сами данные. Т.е. мы не заворачиваем данные в XML, как это делает SOAP и XML-RPC, не используем AMF, как это делает Flash и т.д. Просто отдаем сами данные.
Каждая единица информации однозначно определяется URL – это значит, что URL по сути является первичным ключом для единицы данных. Т.е. например третья книга с книжной полки будет иметь вид /book/3, а 35 страница в этой книге — /book/3/page/35. Отсюда и получается строго заданный формат. Причем совершенно не имеет значения, в каком формате находятся данные по адресу /book/3/page/35 – это может быть и HTML, и отсканированная копия в виде jpeg-файла, и документ Microsoft Word.
Как происходит управление информацией сервиса – это целиком и полностью основывается на протоколе передачи данных. Наиболее распространенный протокол конечно же HTTP. Так вот, для HTTP действие над данными задается с помощью методов: GET (получить), PUT (добавить, заменить), POST (добавить, изменить, удалить), DELETE (удалить). Таким образом, действия CRUD (Create-Read-Updtae-Delete) могут выполняться как со всеми 4-мя методами, так и только с помощью GET и POST.
Вот как это будет выглядеть на примере:
GET /book/ — получить список всех книг
GET /book/3/ — получить книгу номер 3
PUT /book/ — добавить книгу (данные в теле запроса)
POST /book/3 – изменить книгу (данные в теле запроса)
DELETE /book/3 – удалить книгу
ВАЖНОЕ ДОПОЛНЕНИЕ: Существуют так называемые REST-Patterns, которые различаются связыванием HTTP-методов с тем, что они делают. В частности, разные паттерны по-разному рассматривают POST и PUT. Однако, PUT предназначен для создания, реплейса или апдейта, для POST это не определено (The POST operation is very generic and no specific meaning can be attached to it). Поэтому мой пример будет правильным и в таком виде, и в виде если поменять местами POST и PUT.
Вообще, POST может использоваться одновременно для всех действий изменения:
POST /book/ – добавить книгу (данные в теле запроса)
POST /book/3 – изменить книгу (данные в теле запроса)
POST /book/3 – удалить книгу (тело запроса пустое)
Это позволяет иногда обходить неприятные моменты, связанные с неприятием PUT и DELETE.

 

69. П онятие сервлета. Интерфейсы для работы с сервлетами.

Сервлеты представляют собой фрагменты исходного кода Java™, которые добавляют новые функциональные возможности на Web-сервер так же как апплеты добавляют функциональные возможности в броузер. Сервлеты поддерживают модель вычислений запрос-ответ, которая широко используется Web-серверами. Согласно этой модели, клиент посылает сообщение с запросом на сервер, а сервер, в свою очередь, отвечает клиенту, посылая ответное сообщение. Запросы могут приходить в форме HTTP, URL, FTP, URL или по специальному протоколу.

Схема работы сервлеты:

1. Пользователь вводит URL в браузере. Конфигурационный файл вашего Web-сервера указывает, что этот URL предназначен для сервлета, управляемого контейнером сервлетов (Tomacat) сервере.

2. Если экземпляр сервлета еще не был создан (существует только один экземпляр сервлета для приложения), контейнер загружает класс и создает экземпляр объекта.

3. Контейнер вызывает метод init() сервлета.

4. Контейнер вызывает метод service() сервлета и передает HttpServletRequest и HttpServletResponse.

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

6. При необходимости, когда сервлет выполнил полезную работу, контейнер вызывает метод destroy() сервлета для его финализации.

Java Servlet API включает несколько интерфейсов Java и полностью определяет связь между сервером и сервлетами. Servlet API определяется как расширение стандартного JDK. Расширения JDK пакетируются в библиотеке javax – корневой в дереве библиотек расширений Java. Java Servlet API содержит следующие пакеты: javax.servlet и javax.servlet.http

Сервлеты выполняются на платформе Web-сервера как часть того же процесса, что и сам Web-сервер. Web-сервер отвечает за инициализацию, вызов и уничтожение каждого экземпляра сервлета. Web-сервер взаимодействует с сервлетом через простой интерфейс: javax.servlet.Servlet. Этот интерфейс состоит из трех главных методов:

• init() - вызывается при первой загрузке. Гарантируется, что данный метод завершится прежде чем будет вызван любой другой метод. Вызывается только один раз; он не будет вызываться до тех пор, пока сервлет не будет выгружен и затем загружен сервером снова..

• service() – ключевой метод. Вызывается при каждом запросе клиента. Читает запрос и формирует ответ при помощи 2ух аргументов: 1) Объект ServletRequest содержит данные от клиента. Данные состоят из пар имя/значение и InputStream. 2) Объект ServletResponse содержит ответ сервлета клиенту. Во время подготовки ответа прежде всего вызывается метод setContentType() для установки типа MIME ответа.

• destroy() - вызывается для того, чтобы возможность освободить все ресурсы перед выгрузкой сервлета.

Технология JSP. Основные понятия.

Java Server Pages - это технология Java2 Platform, Enterprise Edition (J2EE) для создания приложений, генерирующих динамическое web-содержимое - HTML, DHTML, XHTML и XML. Технология Java Server Pages даёт возможность легко создавать динамическое содержимое web-страниц, предельно мощное и гибкое.

Эта технология основывается на следующих понятиях:

Template Data\Шаблонные Данные

Некоторая часть динамического содержимого является фиксированным, или шаблонным, содержимым. Фрагменты текста или XML являются типичными шаблонными данными. JSP-технология поддерживает естественное манипулирование шаблонными данными.

Добавление Динамических Данных

JSP-технология предоставляет простой, но мощный способ добавлять динамические данные к шаблонным данным.

Инкапсуляция Функциональности

JSP-технология предоставляет два механизма для инкапсуляции функциональности: архитектура компонентов JavaBeans и библиотеки тэгов.

Поддержка Утилитами

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

JavaServer Pages (JSP) позволяют вам отделить динамическую часть ваших страниц от статического HTML. Вы, как обычно, пишете обычный код в HTML, используя для этого любую программу для создания Web страниц. Затем вы заключаете динамическую часть кода в специальные таги, большинство которых начинаются с "<%" и завершаются "%>". В качестве примера рассмотрим секцию JSP страницы, результатом которой будет что-то вроде "Спасибо за покупку Core Web Programming " по запросу с URL: http://host/OrderConfirmation.jsp?title=Core+Web+Programming:

Спасибо за покупку <I><%= request.getParameter("title") %></I>

Помимо стандартных HTML конструкций существуют еще три основных типа конструкций JSP, котрые вы можете включить в страницу: элементы скриптов, директивы и действия. Элементы скриптов позволяют вам указать код на языке Java, который впоследствии станет частью в конечный сервлет, директивы дадут вам возможность управлять всей структурой сервлета, а действия служат для задания существующих используемых компонентов, а также для контроля поведением движка JSP. Для упрощения элементов скриптов, вы имеете доступ к нескольким заранее определенным переменным, таким, например, как переменная request, использованная в приведенном выше отрывке.