Главная » Java, Web, XML » SOAP-послание с дополнениями

0

Компоненты распределенного приложения часто должны обмениваться не только текстовыми SOAP-посланиями, но и графическими документами: изображениями, схемами, чертежами, рукописями. Такие документы обычно оформляются в бинарных форматах GIF, JPEG, PDF. Метод POST протокола HTTP может передавать не только текстовую, но и самую разнообразную информацию, определяемую MIME-типами text, image, audio, video, application, multipart, message. Остается только совместить передачу SOAP-посланий и бинарной информации. Для этого удобен М1МЕ-тип multipart, введенный рекомендацией RFC 2046.

MIME-тип multipart/related

Тип multipart объединяет несколько сообщений разных типов, каким-то образом связанных между собой, в одно целое сообщение. Например, можно переслать фильм и звук к нему в одном HTTP-сообщении. Сообщение типа multipart начинается с заголовка, в котором, в частности, определяется разделитель отдельных частей сообщения. После заголовка и пустой строки на отдельной строке записывается разделитель, после него первая часть сообщения, состоящая из своего заголовка, пустой строки и тела первой части. Потом на отдельной строке записывается разделитель, после него вторая часть сообщения, опять состоящая из заголовка, пустой строки и тела и так далее. В конце всего сообщения опять ставится разделитель.

Пустая строка создается двумя ASCII-символами CRLF, на языках C/C+ + , Java они записываются как "\г\п".

Разделитель определяется обязательным параметром boundary поля Content-Type HTTP-заголовка и представляет собой любой набор символов, не совпадающий с начальными символами ни одной строки сообщения. Например:

Content-Type: multipart/related; boundary=vT45fke0nS34x

В строке, отделяющей одну часть от другой, перед разделителем записывается два дефиса:

—vT45fke0nS34x

В конце разделителя, завершающего все сообщение, ставятся еще два дефиса:

—vT45fke0nS34x—

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

которого означает

Content-Type: text/plain; charset="US-ASCII"

В зависимости от степени связанности сообщений в типе multipart различают несколько ПСД1ИГОВ alternative, parallel, related. Для технологии Web Services наиболее удобен подтип related.

Тип multipart/related описан в рекомендации RFC 2387. Это тип сообщения, состоящего из тесно связанных частей. В сообщении выделяется одна начальная (start) часть, с нее начинается обработка полученного сообщения. На начальную часть указывает необязательный параметр start поля content-Type заголовка MIME-сообщения. Если параметр start отсутствует, то начальной считается первая часть сообщения. Тип содержимого начальной части записывается в обязательном параметре type поля content- Type. Например:

Content-Type: multipart/related; boundary=delimeter; start="<ivanl206@some.com>"; type=text/xml ;

start-info="-o -df type"

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

В технологии Web Services в начальной части записывается SOAP-послание, остальные части содержат дополнительную информацию.

Заголовок каждой части сообщения типа multipart/related снабжается полем content-ID, содержащим идентификатор этой части, уникальный в пределах всего Интернета. Он описан рекомендациями RFC 1521, RFC 1873 и RFC 2045 как уникальный адрес электронной почты, заключенный в угловые скобки. Например:

Content-ID: <ivanl206@some.com>

Идентификатор начальной части сообщения используется в параметре start для ссылки на нее. В начальной части записываются ссылки на идентификаторы других частей сообщения.

Еще один необязательный параметр start-info поля Content-туре содержит дополнительные сведения о начальной части сообщения, предназначенные программе, которая будет обрабатывать начальную часть. Например, это могут быть аргументы командной строки программы-обработчика.

В заголовке каждой части сообщения может быть поле Disposition, описанное рекомендацией RFC 1806. Оно указывает, встроенная это часть, inline, или присоединенная, attachment. Любая часть сообщения может не находиться непосредственно в сообщении, а быть записанной в файл. В таком случае параметр поля filename содержит имя файла, содержащего данную часть сообщения. Например:

Content-Disposition: attachment; filename=myface.gif

Вот и все описание MIME-типа multipart/related. Приведем пример сообщения этого типа, состоящего из двух частей: HTML-текста и изображения в формате GIF.

MIME-Version: 1.0

Content-Type: multipart/related; boundary=delimeter; type=text/html —delimeter

Content-Type: text/html; charset="windows-1251" <htmlxbody><p>

Какой-то текст, затем показана картинка, <img src="cid:myface2409@some. net">

расположенная в другой части сообщения. </body></html> —delimeter

Content-ID: myface2409@some.net Content-Type: image/gif Content-Transfer-Encoding: base64

ROlGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmFldGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A

… дальнейший код …

—delimeter—

В этом примере, в HTML-теге <img>, для ссылки на вторую часть сообщения применена разновидность URL со схемой cid: (Content-ID), специально разработанной для ссылок на другие части сообщения в рекомендации RFC 2111. После символов cid: просто записывается значение поля без угловых скобок.

Рекомендация RFC 2557 добавила необязательное поле Content-Location, которое можно поместить в заголовок каждой части сообщения. Его значение — строка URL, идентифицирующая данную часть сообщения так же, как И ПОЧТОВЫЙ адрес В Поле заголовка Content-ID. Поле Content-Location можно использовать вместе или вместо поля       Его отличие от

поля                  заключается в том, что его значение — URL, а не адрес

электронной почты. Следовательно, при ссылке на него не надо применять схему cid. Вот ТОТ же пример, С добавлением ПОЛЯ Content-Location И ссылки на него.

MIME-Version: 1.0

Content-Type: multipart/related; boundary=delimeter; type=text/html —delimeter

Content-Type: text/html; charset=Mwindows-1251" <htmlxbody><p>

Какой-то текст, затем показана картинка, <img src="cid:myface2409@some.net"> <img src=="images/myface2409 . gif ">

расположенная в другой части сообщения. </bodyx/html> —delimeter

Content-ID: myface2409@some.net Content-Location: images/myface2409.gif

Content-Type: image/gif Content-Trans fer-Encoding: base64

ROIGODIhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5

NSBJRVRGLiBVbmFldGhvcml6ZWQgZHVwbGlj YXRpb2 4 gcHJvaGliaXRlZC4A

… дальнейший код …

—delimeter—

Оформление SOAP-послания с дополнениями

В 2000 году консорциумом W3C выпущена спецификация "SOAP-послания с дополнениями" (http://www.w3.org/TR/SOAP-attachments/), опирающаяся на версию SOAP 1.1. В спецификации описаны правила включения SOAP- послания в MIME-сообщение типа multipart/related и правила пересылки его по протоколу HTTP. Правила эти просты.

1.         SOAP-послание помещается в начальную часть MIME-сообщения типа

multipart/related.

2.         Тип MIME-сообщения устанавливается как text/xmi.

3.       Заголовок начальной части содержит поле content-ID, a HTTP- заголовок, также как и заголовок MIME-сообщения, содержит поле Content-Type с параметром start, ссылающимся на значение поля content-ID начальной части. Остальные части могут содержать поле

Content-ID и/или Поле Content-Location.

4.       Ссылки на другие части MIME-сообщения выполняются в SOAP- послании с помощью атрибута href.

В листинге 3.13 приведен пример SOAP-послания, ссылающегося на два изображения в форматах GIF и JPEG.

Листинг 3.13. POST-запрос с SOAP-посланием и двумя изображениями

POST /services/SomeServlet HTTP/1.1 Host: www. some. com

Content-Type: multipart/related; boundary=delimeter; type=text/xml;

start="<info2709.xml@some.com>" Content-Length: XXXX

SOAPAction: http://some.com/services/InfoServlet —delimeter

Content-Type: text/xmi; charset=utf-8 Content-Trans fer-Encoding: 8bit Content-ID: <info2709.xml@some.com>

<?xml version=’1.0′ ?> <env:Envelope

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <ns:todayinfo

xmlns:ns="http://some.com/infonames"> <ns:map href="cid:info2709.gif@some.com" /> <ns:map href="cid: info2709. jpeg@some. com" /> </ns:todayinfo>

</env:Body> </env:Enve1ope >

—delimeter

Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <info27 09.gif@some.com>

. . .Здесь GIF-изображение в коде base64… —delimeter

Content-Type:

Content-Transfer-Encoding: binary Content-ID:

…Здесь изображение в формате JPEG… —delimeter—

Остается заметить, что MIME-сообщение, подготовленное по этим правилам и содержащее SOAP-послание, самым естественным образом передается по почтовому протоколу SMTP.

Литература:

Хабибуллин И. Ш. Разработка Web-служб средствами Java. — СПб.: БХВ-Петербург, 2003. — 400 с: ил.

По теме:

  • Комментарии