mtom soap что это
Mtom soap что это
javax.xml.ws.soap.MTOM
With Java API for XML-Based Web Services (JAX-WS), you can send binary attachments such as images or files along with web services requests. JAX-WS adds support for optimized transmission of binary data as specified by the SOAP Message Transmission Optimization Mechanism (MTOM) specification.
JAX-WS supports the use of SOAP Message Transmission Optimized Mechanism (MTOM) for sending binary attachment data. By enabling MTOM, you can send and receive binary data optimally without incurring the cost of data encoding needed to embed the binary data in an XML document.
JAX-WS applications can send binary data as base64 or hexBinary encoded data contained within the XML document. However, to take advantage of the optimizations provided by MTOM, enable MTOM to send binary base64 data as attachments contained outside the XML document. MTOM optimization is not enabled by default. JAX-WS applications require separate configuration of both the client and the server artifacts to enable MTOM support. For the server, you can enable MTOM on a JavaBean endpoint only and not on endpoints that implement the javax.xml.ws.Provider interface.
Develop Java artifacts for your JAX-WS application that includes an XML schema or Web Services Description Language (WSDL) file that represents your web services application data that includes a binary attachment.
If you are starting with a WSDL file, develop Java artifacts from a WSDL file by using the wsimport command to generate the required JAX-WS portable artifacts.
If you are starting with JavaBeans components, develop Java artifacts for JAX-WS applications and optionally generate a WSDL file using the wsgen command. The XML schema or WSDL file includes a xsd:base64Binary or xsd:hexBinary element definition for the binary data.
You can also include the xmime:expectedContentTypes attribute on the element to affect the mapping by JAXB.
Enable MTOM on a JavaBean endpoint.
To enable MTOM in the web service, specify the @java.xml.ws.soap.MTOM annotation on the service endpoint implementation class, as illustrated in the following example. Relevant code is shown in bold:
Additionally, you can use the @BindingType ( javax.xml.ws.BindingType ) annotation on a server endpoint implementation class to specify that the endpoint supports one of the MTOM binding types so that the response messages are MTOM-enabled. The javax.xml.ws.SOAPBinding class defines two different constants, SOAP11HTTP_MTOM_BINDING and SOAP12HTTP_MTOM_BINDING that you can use for the value of the @BindingType annotation.
11.1.2. Use MTOM policy in WSDL.
Following WSDL example demonstrates use of the Optimized Mime Serialization policy assertion:
Lines (8-11) in are a policy expression that includes an Optimized Mime Serialization policy assertion (Line 9) to indicate that the SOAP Message Transmission Optimization Mechanism (MTOM) may be used.
Lines (13-18) are a WSDL binding. Lines (14-16) indicate that the policy in Lines (8-11) applies to this binding, specifically indicating that MTOM encodings must be accepted over all the messages in the binding. Line (16) indicates policy is a required extension.
MTOM is used to optimize the transmission of SOAP message over the wire. MTOM uses a wire format of a SOAP message by selectively encoding portions of the message, whilst still presenting an XML Infoset to the SOAP application. Optimization is available only for element content that is in a canonical lexical representation of the xs:base64Binary data type.
Message Part: Consider a message with one of it part as base64Binary :
Binding: it shows how the binding use the MTOM policy:
The wire format below show how the SOAP envelope is transmitted using HTTP, take a note of the part2 which represent the binary data and how the data is trasmitted, note the data is not part of the SOAP envelope, instead it is transmitted as a separate MIME part:
Some of the points to note in the above wire format example are:
The binary attachment is packaged in a MIME multi-part message.
An element is used to mark where the binary data is.
The actual binary data is kept in a different MIME part.
11.1.3. Use MTOM in the deployment descriptors
You can enable MTOM on server by using the enable-mtom attribute in the sun-jaxws.xml configuration file. This allows the MTOM setting to be changed at deployment time:
11.1.4. Use MTOMFeature with javax.xml.ws.Endpoint API
javax.xml.ws.soap.MTOMFeature
Enabling this feature on either the server or client will result the JAX-WS runtime using MTOM and for binary data being sent as an attachment.
11.1.5. Use swaRef in WSDL.
An XML element of type wsi:swaRef is mapped to a DataHandler and is sent as attachment over the wire. For example:
Большие наборы данных и потоковая передача
Windows Communication Foundation (WCF) — это инфраструктура обмена данными на основе XML. Так как XML-данные обычно кодируются в стандартном текстовом формате, определенном в спецификации XML 1,0, разработчики и архитекторы подключенных систем обычно сталкиваются с объемом подключения (или размером) сообщений, отправляемых по сети, а текстовая кодировка XML создает специальные трудности для эффективной передачи двоичных данных.
Основные вопросы
Чтобы получить общие сведения о следующих сведениях для WCF, в этом разделе описываются некоторые общие вопросы и рекомендации по кодированию, двоичным данным и потоковой передаче, которые обычно применяются к инфраструктуре подключенных систем.
Кодирование данных: текстовый формат в сравнении с двоичным
Общие вопросы разработчиков включают в себя понимание того, что для XML характерна значительная нагрузка по сравнению с двоичными форматами из-за повторяющейся сущности открывающих и закрывающих тегов, и кодирование числовых значений требует значительно больших ресурсов, поскольку они выражаются текстовыми значениями, и эффективное выражение двоичных данных невозможно, т.к. они требуют специального кодирования для внедрения в текстовый формат.
В то время как многие из этих и аналогичных вопросов действительно актуальны, фактическое различие между сообщениями с кодированием в виде текста XML в среде веб-служб XML и сообщениями с двоичным кодированием в предыдущей среде удаленного вызова процедур (RPC) часто намного менее значимо по сравнению с изначальными соображениями.
Тогда как сообщения с кодированием в виде текста XML прозрачны и имеют удобочитаемый вид, двоичные сообщения часто непонятны в сравнении с ними и сложны для декодирования без специальных средств. Такая разница в читаемости становится причиной игнорирования того факта, что двоичные сообщения часто содержат встроенные метаданные в полезной нагрузке, что приводит к увеличению объема служебных данных как и в случае сообщений в виде текста XML. Это особенно актуально для двоичных форматов, направленных на обеспечение возможностей слабого соединения и динамического вызова.
Однако двоичные форматы в основном содержат такие описательные метаданные в «заголовке», что также объявляет макет данных для следующих записей данных. Полезная нагрузка согласуется с таким общим объявлением блока метаданных при минимальном увеличении объема служебных данных. В противоположность этому, XML заключает каждый элемент данных в элемент или атрибут, чтобы заключенные метаданные постоянно указывались для каждого сериализованного объекта полезной нагрузки. В результате этого размер одного сериализованного объекта полезной нагрузки аналогичен, если сравнивать текстовое и двоичное представление, поскольку некоторые описательные метаданные должны быть выражены для обоих форматов, но двоичный формат более удобен из-за описания общих метаданных с каждым дополнительным объектом полезной нагрузки, передаваемым благодаря низкой общей нагрузке.
В результате этого выбор между текстовым и двоичным форматом не так прост, как если бы принимался во внимание тот факт, что двоичные сообщения всегда меньше сообщений в виде текста XML.
Явное преимущество текстовых XML-сообщений заключается в том, что они основаны на стандартах и обеспечивают более широкие возможности взаимодействия и поддержки платформ. Дополнительные сведения см. в подразделе «кодировки» далее в этом разделе.
Двоичное содержимое
Сферами, где двоичное кодирование превосходит кодирование на основе текста в отношении получаемого размера сообщений, являются большие элементы двоичных данных, например изображения, видеоролики, звукозаписи или другие виды непрозрачных, двоичных данных, обмен которыми осуществляется между службами и их пользователями. Чтобы преобразовать эти типы данных в текст XML, они, как правило, кодируются с помощью кодирования Base64.
В строке с кодированием Base64 каждый символ представляет 6-разрядные данные вместо исходных 8-разрядных, в результате чего соотношение кодирование-нагрузка для Base64 равно 4:3, не считая символы дополнительного форматирования (возврат каретки/переход на новую строку), которые обычно добавляются. Тогда как значимость различий между кодированием XML и двоичным кодированием обычно зависит от сценария, увеличение размера более чем на 33% при передаче полезной нагрузки 500 МБ, как правило, неприемлемо.
Чтобы избежать такой чрезмерной нагрузки при кодировании, стандарт подсистемы оптимизации передачи сообщений (MTOM) позволяет внешне выражать большие элементы данных, содержащиеся в сообщении, и передавать их с сообщением в качестве двоичных данных без какого-либо специального кодирования. При использовании MTOM обмен сообщениями осуществляется аналогично сообщениям электронной почты по протоколу SMTP с вложениями или внедренным содержимым (рисунки и другое внедренное содержимое). Сообщения MTOM упаковываются как составные или связанные MIME-последовательности с корневым компонентом фактическим сообщением SOAP.
Сообщение MTOM SOAP изменяется с некодированной версии таким образом, что специальные теги элементов, относящиеся к соответствующим частям MIME, занимают место исходных элементов в сообщении, содержащем двоичные данные. В результате этого сообщение SOAP относится к двоичному содержимому, указывая на отправленные с ним части MIME, но передает только текстовые данные XML. Поскольку эта модель тесно связана с надежной моделью SMTP, существует широкая поддержка в виде средств для кодирования и декодирования сообщений MTOM на многих платформах, что обеспечивает исключительные возможности взаимодействия.
Тем не менее, как и в случае с Base64, для MTOM также характерен некоторый объем служебных данных для формата MIME, поэтому преимущества использования MTOM проявляются только, когда размер элемента двоичных данных превышает 1 КБ. Из-за служебных данных сообщения, закодированные в MTOM, могут оказаться больше, чем сообщения в кодировке Base64 для двоичных данных, если двоичная полезная нагрузка не превышает это пороговое значение. Дополнительные сведения см. в подразделе «кодировки» далее в этом разделе.
Содержимое данных большого объема
Если не учитывать расстояние передачи, ранее упомянутая полезная нагрузка 500 МБ также создает большую проблему в локальной среде на уровне службы и клиента. По умолчанию WCF обрабатывает сообщения в режиме буферизации. Это означает, что все содержимое сообщения находится в памяти до его отправки или после получения. Хотя это и является хорошей стратегией для большинства сценариев и необходимо для таких возможностей обмена сообщениями, как цифровые сигнатуры и надежная доставка, большие сообщения могут исчерпать системные ресурсы.
Стратегией обработки больших полезных нагрузок является потоковая передача. Хотя сообщения, в особенности выраженные в XML, как правило, считаются относительно компактными пакетами данных, сообщение может иметь размер в несколько гигабайт и напоминать непрерывный поток данных, а не пакет данных. Когда данные передаются в потоковом, а не буферизованном режиме, отправитель открывает содержимое тела сообщения для получателя в виде потока, и инфраструктура сообщения непрерывно направляет данные от отправителя получателю по мере их поступления.
Наиболее распространенным сценарием, при котором осуществляется передача содержания данных такого большого объема, является передача объектов двоичных данных, которые:
невозможно легко разбить на последовательность сообщений;
должны быть своевременно доставлены;
недоступны полностью при начале передачи.
Данные, не имеющие этих ограничений, обычно лучше отправлять в виде последовательностей сообщений в рамках одного сеанса, а не одним большим сообщением. Дополнительные сведения см. в подразделе «потоковые данные» Далее в этом разделе.
При отправке больших объемов данных необходимо задать maxAllowedContentLength параметр IIS (Дополнительные сведения см. в разделе Настройка ограничений запросов IIS) и maxReceivedMessageSize параметр привязки (например, System. ServiceModel. BasicHttpBinding. MaxReceivedMessageSize или MaxReceivedMessageSize ). maxAllowedContentLength Свойство по умолчанию имеет значение 28,6 МБ, а maxReceivedMessageSize свойство по умолчанию — 64 КБ.
Кодирование
Кодировка определяет набор правил, определяющих способ представления сообщений в сети. Кодировщик реализует такую кодировку и отвечает на стороне отправителя, Message чтобы превратить в память поток байтов или буфер байтов, который может быть отправлен по сети. На стороне получателя кодировщик преобразует последовательность байтов в сообщение в памяти.
WCF включает три кодировщика и позволяет писать и подключать собственные кодировщики, если это необходимо.
Каждая стандартная привязка включает в себя предварительно настроенный кодировщик, в соответствии с чем привязки с префиксом Net* используют двоичный кодировщик (путем включения класса BinaryMessageEncodingBindingElement), тогда как классы BasicHttpBinding и WSHttpBinding используют кодировщик текстовых сообщений (с помощью класса TextMessageEncodingBindingElement) по умолчанию.
Текстовое кодирование сообщений обычно идеальный выбор для любого пути передачи, требующего взаимодействия, а двоичное кодирование сообщений отлично подходит для любых других путей передачи. Двоичное кодирование, как правило, приводит к уменьшению размеров сообщений по сравнению с текстом применительно к одному сообщению, а на протяжении сеанса связи размеры сообщений неизменно становятся еще меньше. В отличие от текстового кодирования для двоичного не требуется специальная обработка двоичных данных, например использование Base64, и оно представляет байты как байты.
Если в решении не используется взаимодействие, но тем не менее следует использовать транспорт HTTP, можно создать BinaryMessageEncodingBindingElement в пользовательской привязке, использующей для транспорта класс HttpTransportBindingElement. Если для ряда клиентов службы необходимо обеспечить взаимодействие, рекомендуется открыть параллельные конечные точки, чтобы у каждой из них имелись правильные варианты транспорта и кодирования для соответствующих клиентов.
Реализация MTOM
Как уже упоминалось ранее, решение об использовании кодирования MTOM зависит от объема отправляемых данных. Кроме того, поскольку MTOM реализуется на уровне привязки, MTOM влияет на все операции в указанной конечной точке.
Поскольку кодировщик MTOM всегда выдает кодированное MTOM MIME/многоэлементное сообщение независимо от того, заканчиваются ли двоичные данные во время внешнего вывода, в обычной ситуации необходимо реализовывать MTOM только для конечных точек, в которых осуществляется обмен сообщениями объемом более 1 КБ двоичных данных. Кроме того, контракты служб, разработанные для использования с конечными точками с MTOM, должны, где возможно, ограничиваться указанием таких операций передачи данных. Связанная функциональность управления должна находиться в отдельном контракте. Это правило «только MTOM» применимо только к сообщениям, отправленным через конечную точку с MTOM; кодировщик MTOM также может декодировать и анализировать входящие сообщения, отличные от MTOM.
Использование кодировщика MTOM соответствует всем остальным функциям WCF. Обратите внимание, что это правило может соблюдаться не во всех случаях, например оно неприменимо при необходимости поддержки сеансов.
Модель программирования
Независимо от того, какой из трех встроенных кодировщиков используется в приложении, программирование аналогично таковому в случае передачи двоичных данных. Разница заключается в том, как WCF обрабатывает данные на основе их типов данных.
При использовании MTOM предыдущий контракт данных сериализуется в соответствии со следующими правилами.
Если binaryBuffer не null и по отдельности содержит достаточно данных, чтобы подтвердить служебные данные внешнего выделения MTOM (заголовки MIME и т. д.) при сравнении с кодированием Base64, данные внешне выводятся и передаются с сообщением как двоичная часть MIME. Если это пороговое значение не превышается, данные кодируются как Base64.
Строка (и все другие недвоичные типы) всегда представлена как строка внутри тела сообщения, независимо от размера.
Результат кодирования MTOM точно такой же независимо от того, используется ли явный контракт данных, как показано в предыдущем примере, используется ли список параметров в операции, имеются ли вложенные контракты данных или передается ли объект контракта данных в коллекции. Байтовые массивы всегда подлежат оптимизации и оптимизируются, если удовлетворяются пороги оптимизации.
В контрактах данных не следует использовать унаследованные типы System.IO.Stream. Потоковые данные должны передаваться с помощью модели потоковой передачи, которая рассматривается в разделе «Потоковая передача данных».
Потоковая передача данных
При наличии большого количества данных для передачи режим потоковой передачи в WCF является разумной альтернативой поведению по умолчанию для буферизации и обработки сообщений в памяти целиком.
Как упоминалось ранее, потоковую передачу следует реализовать только для больших сообщений (с текстовым или двоичным содержимым), если данные невозможно сегментировать, если сообщение должно быть своевременно доставлено или если данные еще не полностью доступны на момент начала передачи.
Ограничения
При включенной потоковой передаче нельзя использовать значительное количество функций WCF:
Цифровые сигнатуры для тела сообщения недоступны, поскольку для них требуется вычисление хэша по содержимому всего сообщения. При потоковой передаче содержимое не полностью доступно на момент создания и отправки заголовков сообщений, поэтому цифровую сигнатуру вычислить невозможно.
Шифрование зависит от цифровых сигнатур, по которым проверяется правильность восстановления данных.
Во время надежных сеансов отправленные сообщения должны помещаться в буфер клиента для повторной передачи в случае потери сообщения во время передачи, а также сообщения должны сохраняться в службе до их обработки в реализации службы, чтобы сохранить порядок сообщений в случае непоследовательного получения сообщений.
Из-за этих функциональных ограничений параметры безопасности для потоковой передачи можно использовать только на транспортном уровне, и невозможно реализовать надежные сеансы. Потоковая передача доступна только в следующих, определенных системой привязках.
Поскольку для базового транспорта NetTcpBinding и NetNamedPipeBinding характерна заведомо надежная доставка и поддержка сеанса на основе подключения, в отличие от HTTP, на практике на эти две привязки оказывается минимальное влияние такими ограничениями.
Потоковая передача недоступна с транспортом очереди сообщений (MSMQ), и, соответственно, не может быть использована с классом NetMsmqBinding или MsmqIntegrationBinding. Транспорт очереди сообщений поддерживает только передачу буферизованных данных с ограниченным размером сообщения, тогда как все остальные транспорты не имеют какого-либо реального ограничения размера сообщений для большинства сценариев.
Потоковая передача также недоступна при использовании транспорта однорангового канала и не может использоваться с NetPeerTcpBinding.
Потоковая передача и сеансы
При потоковой передаче вызовов с привязкой, основанной на сеансе, может возникнуть непредвиденное поведение. Все потоковые вызовы выполняются через один канал (канал датаграммы), который не поддерживает сеансы, даже если используемая привязка настроена так, чтобы она использовала сеансы. Если несколько клиентов выполняют потоковые вызовы одного объекта службы через привязку, основанную на сеансе, и задан «одиночный» режим параллелизма объекта службы и режим контекста его экземпляра как PerSession, все вызовы должны проходить через канал датаграммы, а потому может обрабатываться не более одного вызова одновременно. После этого может исключаться время ожидания одного или нескольких клиентов. Эту ошибку можно обойти, установив для режима контекста экземпляра объекта службы значение Перкалл или Concurrency to Multiple.
Свойство MaxConcurrentSessions в данном случае ни на что не влияет, поскольку имеется всего один сеанс.
Реализация потоковой передачи
Потоковую передачу можно включить следующими способами.
Отправляйте и принимайте запросы в режиме потоковой передачи, принимайте и возвращайте ответы в режиме буферизации (StreamedRequest).
Отправляйте и принимайте запросы в режиме буферизации, принимайте и возвращайте ответы в режиме потоковой передачи (StreamedResponse).
Отправляйте и получайте запросы и ответы в режиме потоковой передачи в обоих направлениях. (Streamed).
Потоковую передачу можно отключить, задав режим передачи как Buffered, что является параметром по умолчанию для всех привязок. В следующем коде показано, как задать режим передачи в конфигурации.
При инициализации привязки в коде следует задать соответствующее свойство TransferMode привязки (или элемент привязки транспорта, если создается пользовательская привязка) как одно из ранее упомянутых значений.
Потоковую передачу можно включить для запросов и ответов или обоих направлений по отдельности на любой стороне взаимодействующих сторон, не затрагивая функциональность. Однако следует всегда принимать во внимание, что размер передаваемых данных настолько важен, что включение потоковой передачи имеет смысл на обеих конечных точках канала связи. Для межплатформенного взаимодействия, когда одна из конечных точек не реализована с помощью WCF, возможность использования потоковой передачи зависит от возможностей потоковой передачи платформы. Другим редким исключением может быть сценарий с зависимостью от потребления памяти, когда клиент или служба должны свести к минимуму рабочий набор и способны обработать только небольшие объемы данных в буфере.
Включение асинхронной потоковой передачи
Модель программирования для потоковой передачи
Модель программирования для потоковой передачи является простой. Для получения потоковых данных следует указать контракт операции с одним параметром ввода типа Stream. Для возвращения потоковых данных следует возвратить ссылку Stream.
Во время операции Echo в предыдущем примере осуществляется получение и возврат потока, поэтому она должна использоваться в привязке с Streamed. Для операции RequestInfo наилучшим образом подходит StreamedResponse, поскольку он только возвращает Stream. Односторонняя операция наилучшим образом подходит для StreamedRequest.
Обратите внимание, что добавление второго параметра в операции Echo или ProvideInfo станет причиной возвращения модели службы к стратегии буферизации и использованию представления сериализации в среде выполнения потока. Со сквозной потоковой передачей запросов совместимы только операции с одним параметром входного потока.
Применение этого правила аналогично контрактам сообщений. Как показано в следующем контракте сообщения, в нем (являющимся потоком) можно расположить только один элемент тела. Если вместе с потоком требуется передать дополнительную информацию, ее следует указать в заголовках сообщений. Тело сообщения зарезервировано исключительно для содержимого потока.
Когда поток достигает конца файла (EOF), потоковая передача прекращается, и сообщение закрывается. При отправке сообщения (возврат значения или вызове операции) можно передать, FileStream а инфраструктура WCF извлекает все данные из этого потока, пока поток не будет полностью прочитан и не достигнет конца файла. Чтобы передать потоковые данные для источника, для которого не существует такого предварительно созданного унаследованного класса Stream, следует создать такой класс, наложить его на источник потока и использовать в качестве аргумента или возвращаемого значения.
При получении сообщения WCF конструирует поток по содержимому текста сообщения в кодировке Base64 (или к соответствующей части MIME при использовании MTOM), и поток достигает конца файла при считывании содержимого.
Потоковая передача на транспортном уровне также используется с любым другим типом контракта сообщения (списками параметров, аргументами контракта данных и явным контрактом сообщения), но поскольку для сериализации и десериализации сообщений таких типов требуется буферизация сериализатором, использование таких вариантов контрактов не рекомендуется.
Особые вопросы по безопасности данных большого объема
Угроза безопасности, относящаяся к сценарию потоковой передачи большого объема данных, вызывает отказ в обслуживании, приводя к буферизации данных, когда получатель ожидает их потоковой передачи. Например, WCF всегда помещает заголовки SOAP сообщения в буфер, и поэтому злоумышленник может создать большое вредоносное сообщение, состоящее только из заголовков для принудительного буферизации данных. Если включена потоковая передача, MaxReceivedMessageSize может быть задано как крайне большое значение, поскольку получатель не ожидает одновременной буферизации всего сообщения в память. Если WCF принудительно замещает сообщение в буфер, происходит переполнение памяти.
Также важно понимать, что эта квота ограничивает только буферизацию, выполняемую WCF, и не может защищать вас от любой буферизации, выполняемой в собственной службе или клиентской реализации. Дополнительные сведения о дополнительных вопросах безопасности см. в статье вопросы безопасности данных.
Решение по использованию буферизованной или потоковой передачи является локальным решением конечной точки. Для транспортов HTTP режим передачи не распространяется через подключение или на прокси-серверы и других посредников. Выбор режима передачи не отражается в описании интерфейса службы. После создания клиента WCF для службы необходимо изменить файл конфигурации для служб, предназначенных для использования с потоковой передачей, чтобы установить режим. Для транспортов TCP и именованного канала режим передачи распространяется в виде утверждения политики.