Кажется, вы слегка путаетесь между вложениями, SOAP Attachment и MTOM.
SOAP-Приложение впервые было введено в December 2000 as a W3C note (а не в спецификации) и определено расширение механизмов привязки транспорта, определенных в SOAP 1.1. В частности, эта нота определяется:
привязки для SOAP 1.1 сообщения, которое будет осуществляться в течение/сообщений, связанного MIME из нескольких частей таким образом, что правила обработки сообщения SOAP 1.1 preserved.The MIME-механизм многочастного для инкапсуляции составных документов можно использовать для объединения объектов, связанных с сообщением SOAP 1.1, например вложениями.
Проще говоря, он определил механизм для нескольких документов (вложений), которые должны быть связаны с сообщением SOAP в их родных форматах, используя многостраничную структуру mime для транспорта. Это было достигнуто с использованием combination of "Content-Location" and "Content-ID" headers вместе с set of rules для интерпретации URI, на который ссылались заголовки «Содержимое-местоположение».
сообщение SOAP в этом формате можно визуализировать, как показано ниже (инкапсулированный в качестве составного/MIME):
Это также формат, который вы, возможно, работали с тем, когда вы использовали SAAJ, но является больше не рекомендуется, если вы не работаете с устаревшим кодом. В 2004 году примечание W3C было пересмотрено до уровня «функции» (наряду с SOAP 1.2) и было eventually superseded механизмом SOAP MTOM.
SOAP Оптимизация передачи сообщений механизма (MTOM) официально определяется как не один, а three separate features, которые работают вместе, чтобы обеспечить функциональность:
"Abstract SOAP Transmission Optimization Feature" описывает абстрактную функцию оптимизации формата передачи и/или проволоки сообщения SOAP посредством выборочного кодирования частей сообщения, при этом все еще представляя XML-информацию в SOAP-приложении.
"An optimized MIME Multipart/Related serialization of SOAP Messages" описывает оптимизированную MIME-многостраничную/связанную сериализацию сообщений SOAP, реализующих абстрактную функцию оптимизации передачи SOAP в независимом привязке.
"HTTP SOAP Transmission Optimization Feature" описывает реализацию абстрактной функции оптимизации транспорта для связывания HTTP-протокола SOAP 1.2.
Если вы читали второй документ, вы поймете, что «вложения» было заменено XML binary optimized "packages" или XOP.
Пакет XOP создается путем размещения сериализации XML Infoset внутри расширяемого формата упаковки (такой MIME Multipart/Related, см. [RFC 2387]). Затем выделенные части его содержимого, которые являются двоичными данными, закодированными в base64, извлекаются и повторно кодируются (то есть данные декодируются из base64) и помещаются в пакет. Расположение этих выбранных частей помечено в XML специальным элементом, который связывается с упакованными данными с использованием URI.
Простыми словами это означает, что вместо того, чтобы инкапсулировать данные как «вложение» в сообщение multipart/mime, теперь данные ссылаются на «указатель» или ссылки. Следующие диаграммы могут помочь в понимании:
Теперь, когда у нас есть фон, давайте вернемся к вашим вопросам.
Как служба сообщает, что она принимает/обслуживает двоичные данные как вложения MTOM в запросе/ответе? Это не так. Нет концепции вложения с MTOM, и поэтому сервер не может заявить, что он принимает вложения.
Как клиент правильно распознает, что двоичные данные могут быть отправлены/получены с использованием вложений MTOM для данной услуги? Как я уже сказал выше, для клиента нет способа сделать это, поскольку «вложения» не поддерживаются.
Сказав, что, есть еще один W3C спецификации на XML media types, который гласит:
xmime:contentType приписывать информационный элемент позволяет веб-сервисов приложений для оптимизации обработки двоичных данных, определенных с помощью двоичного элемента информации и должны рассматриваться как метаданные. Наличие атрибута xmime: contentType не изменяет значение содержимого элемента.
При включении MTOM с помощью xmime:contentType и xmime:expectedContentTypes="application/octet-stream (* should not be used), сгенерированный WSDL будет иметь такую запись:
<element name="myImage" xmime:contentType="xsd:base64Binary" xmime:expectedContentTypes="application/octet-stream"/> Это путь сервера того, чтобы объявить, что он может получить XML бинарный оптимизированный пакет (который может быть разбит на многоточечное сообщение MIME).
Когда клиент видит выше, клиент знает, что сервер может принимать XML бинарных оптимизированных пакетов и генерирует соответствующие HTTP-запросов, как определено Identifying XOP Documents:
XOP документов, при использовании в MIME-подобных систем, которые идентифицируются с тип носителя «application/xop + xml» с требуемым параметром «тип», передающим тип связанного с исходным текстом сериализации XML.
Надеюсь, что это поможет!
