XML – поразительная вещь. Он создал стандартный промышленный способ представления данных, выражения взаимоотношения данных и взаимодействия с данными, который был так хорошо принят, что сегодня практически каждая платформа обработки данных имеет, в том или ином роде, XML поддержку. Это всеобщее признание XML является одним из ключевых факторов в принятии SOAP и Web сервисов, поскольку он делает идею возможности взаимодействия сетей очень реальной. Несмотря на мощность XML, существует достаточное количество сценариев в широком многообразии приложений, когда, возможно, имеет больший смысл посылать Web сервису не XML данные. Например, возможно, имеет смысл посылать двоичные данные, такие как JPEG изображения, вместе с SOAP сообщением. Возможно, также будет уместным просто упаковывать данные вместе. Например, одно SOAP сообщение может включать другое SOAP сообщение, как можно обычно увидеть в сообщениях электронной почты, которые имеют присоединенные к ним сообщения. Прямая инкапсуляция Internet сообщений (Direct Internet Message Encapsulation - DIME) – обеспечивает механизм для объединения частей данных. WS-Вложения, которые определяют, как DIME может использоваться для включения вложений в SOAP сообщения и как обращаться к этим вложениям в пределах DIME пакета.

Эта статья углубляется в логическое обоснование вложений, включая ключевые идеи упаковки и распаковки сообщения, и затем рассматривает то, как на базе этих идей возникли DIME и WS-Вложения.

До того, как электронная почта стала вездесущей, деловой мир использовал нечто, называемое меморандумом или мемо (уведомлением (memorandum) или memo). Мемо были достаточно структурированы, учитывая возможность изменения среды передачи. У них был выраженный заголовок с элементами To, From и Subject, тело сообщения и нижний колонтитул, содержащий, кроме всего прочего, место для записи вложений. Вложения - это дополнительная информация, которую, по различным причинам, не имеет смысла включать в текст сообщения. Это могли быть сообщения, генерируемые кем-то еще, возможно, фотокопия счета или другого документа, или даже другое мемо, которое имело смысл включить в первое сообщение.

Интерес к мемо с вложениями вызывает этот список вложенных документов в оригинальном мемо. Если они присоединяются к оригинальному мемо, почему вы должны включать еще и их перечень? Разве не может читающий просто пролистать бумаги и увидеть то, что было вложено? Одним из ответов на этот вопрос является: "Нет, если их там нет". Страницы могут быть запросто утеряны при перевозке или пропущены во время ручной сортировки. В таком случае получатель при получении документа будет предупрежден о том, что что-то было утеряно. Один из механизмов решения проблемы утери вложений – это упаковка мемо с его вложениями в многократно используемый почтовый конверт. Дополнительная упаковка всей информации обеспечивает дополнительный уровень уверенности в том, что все части дойдут до получателя вместе. Получатель также будет уверен, что если главное мемо ссылается на отчет, его вложенная в конверт копия именно та, на которую ссылается мемо. Если на отчет ссылаются, но его экземпляра нет в конверте с мемо, неизбежно возникнет вопрос о том, где этот отчет можно найти и будет ли найденный отчет тем, на который ссылается главное мемо.

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

Также важно, чтобы возможность упаковывания вместе мемо и его вложений была доступна SOAP сообщениям потому, что как и в случае с почтовыми конвертами, есть вероятность утери или подмены частей информации во время пересылки. Например, SOAP сообщение может ссылаться на XML документ с помощью URL, но что произойдет, если этот XML документ изменится в промежуток времени между формированием SOAP сообщения и его получением? Возможность упаковывания XML документа с SOAP сообщением является ключевой, и она должна быть частью архитектуры вложений.

Есть ряд способов упаковки SOAP сообщения и его вложений. В потоковом мире Internet важно, что наша система упаковки обеспечивает механизм передачи различных частей через один поток. Это обеспечивает возможность пакетам проходить через наиболее популярные на сегодняшний день протоколы, такие как TCP, HTTP и SMTP. Это означает без всяких исключений, что упаковка должна иметь возможность обозначать, где одна часть пакета заканчивается и начинается следующая, и должен быть некоторый механизм отображения того, что пакет пришел полностью.

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

Другим преимуществом приложения, работающих с пакетами из потоков, является способность идентифицировать каждую часть, входящую в пакет. В мире бумажных мемо это обычно делалось путем упоминания автора вложенного документа. К сожалению, потенциально это может быть проблематичным, поскольку велика вероятность того, что в пакете будет два вложения от одного и того же автора. Конечно же эту проблему можно решить, включая и дату, и автора, или даже, включая тему, если надо. Но что вы делаете, если у вас есть что-то вроде фотографии, которая не имеет точной информации в заголовке, какая есть в мемо? Приложения, работающие с пакетами из потоков, хотят иметь определенный механизм для идентификации каждой части пакета. Также было бы не лишним иметь возможность идентифицировать тип информации, хранящейся в каждой части нашего пакета.

Все это является всего лишь основными возможностями, необходимыми для того, чтобы приложения обрабатывали SOAP сообщения с вложениями. Спецификация Direct Internet Message Encapsulation (DIME) кратко и эффективно охватывает все этим вопросы.

DIME – механизм упаковки, который дает возможность множеству записей произвольно отформатированных данных передаваться в потоке совместно. Записи сериализуются в поток одна за другой и разграничиваются подготовленным двоичным заголовком. В первой записи DIME сообщения есть флаг MB (Message Begin – начало сообщения), установленный в заголовке, а в последней записи есть установленный флаг ME (Message End- конец сообщения). Заголовок также включает фиксированную длину части, что облегчает вычисление абсолютной длины записи. Эффективное определение длин записей важно для быстрого перемещения с одной записи потока данных на следующую.

Для больших записей или записей, в которых размер данных изначально неизвестен, DIME определяет "фрагмент записи". DIME использует фрагменты записи, чтобы поддержать разбиение единой записи на множество частей.

В каждом фрагменте записи есть заголовок и полезный груз, как и в нормальных записях, однако, фрагмент записи устанавливает CF (Chunk Flag) в заголовке. Он показывает, что данные являются лишь частью фрагментированной записи, и остальные данные этой записи последуют далее. Данные для фрагментированной записи считываются сериями из фрагментов записи, которые следуют до тех пор, пока не будет обнаружен последний фрагмент записи, в котором больше нет CF. На Рисунке 1 приведено DIME сообщение с пятью записями. Последние три записи – это фрагменты записи, которые составляют одну фрагментированную запись.

Рисунок 1. DIME сообщение, включающее фрагменты записи.

Кроме информации о длине записи и некоторых флагов, заголовок DIME записи включает версию используемой DIME, информацию о типе данных полезного груза записи, ID для уникальной идентификации каждой записи и поддержку для добавления любой необязательной информации, которая может передаваться с отдельными записями. Тип, ID, необязательные данные и полезный груз – все это может быть произвольной длины, таким образом, начало заголовка записи – это участок фиксированной длины, включающий версию, флаги и длины этих четырех участков записи, имеющих переменную длину. Как только мы определили местоположение начала записи, обнаружить начало следующей записи так же просто, как сложить длину фиксированной части заголовка (12 байт) и длину необязательной части, id, типа и частей данных, которые располагаются в определенных местах заголовка.

Рисунок 2. Формат записи данных DIME

Одной из приятных характеристик DIME является то, что в нем нет ограничений на содержимое записи. Кстати, полезный груз записи DIME может содержать другое DIME сообщение. Обобщающая запись просто должна показывать, что тип записи - "application/dime".

Более подробно о формате DIME сообщений см. в статье Jeanine Hall Gailey Sending Files, Attachments, and SOAP Messages Via Direct Internet Message Encapsulation (http://msdn.microsoft.com/msdnmag/issues/02/12/DIME/default.aspx) (MSDN Magazine, декабрь 2002).

Сам по себе, DIME – это просто механизм упаковки набора произвольно отформатированных записей данных. Он не устанавливает требований на содержимое полезного груза записи, на то, что содержится в полях ID или как SOAP сообщение должно инкапсулироваться в DIME сообщении. WS-вложения используют идеи, обсуждаемые нами ранее в вопросе о мемо с вложенными документами, определяют то, как может быть объединено множество документов, как они связаны друг с другом и как можно использовать DIME упаковку для обеспечения возможности вложения, которую могут использовать Web сервисы.

Первое и самое важное в определении механизма вложения SOAP сообщения – это возможность идентифицировать, что есть SOAP сообщение, а что есть вложение. В бумажных мемо, когда берешь пачку бумаги, соединенную скрепкой, легко определить, какое сообщение является главным мемо. Главное мемо –самое верхнее в пачке. Более того, главное мемо – это то, в конце которого есть список вложений. Для SOAP сообщений мы собираемся обращаться к главному сообщению как к "Основной части SOAP сообщения" ("Primary SOAP Message Part"). К любым вложенным статьям будем обращаться как к "Дополнительным частям" ("Secondary Parts"). WS-вложения указывают, что Основная часть SOAP сообщения должна входить в первую запись DIME сообщения. Это аналогично расположению главного мемо самым первым в пачке.

Следующим необходимо рассмотреть вопрос о возможности ссылаться на вложения из Основной части SOAP сообщения. Точно так же, как мемо ссылается на документы, прикрепленные к нему, SOAP сообщение должно иметь возможность ссылаться на свои вложения. WS-вложения определяют для этого использование атрибута href. Атрибут href – это URI, который может использоваться для указания на HTTP URL, если требуется. Но WS-вложения также определяют возможность ссылаться на определенную DIME запись с помощью ID поля заголовка DIME записи. Таким образом, если в Дополнительной части DIME сообщения есть ID

uuid:6FF57C24-74A1-426f-92D9-98861E105B4F

тогда Основная часть SOAP сообщения, так ссылающаяся на вложение, должна выглядеть следующим образом:

<?xml version='1.0' ?>
<s:Envelope
    xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:mes="http://example.org/message/response">
  <s:Body>
    <mes:responseMesssage>
      <responseTo
          href="uuid:6FF57C24-74A1-426f-92D9-98861E105B4F"/>
      <messageText>Hello World!</messageText>
    </mes:responseMessage>
  </s:Body>
</s:Envelope>

В элементе responseTo тела сообщения есть атрибут href, который определяет ID DIME записи. Вероятно, данные в DIME записи являются другим SOAP сообщением, на которое отвечает это сообщение. Получателям DIME сообщения не надо будет отслеживать сообщение, на которое отвечает Основная часть SOAP сообщения, они просто могут найти его в указанной дополнительной части DIME сообщения.

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

WS-вложения также определяют детали того, как можно в HTTP запросе отправлять сложное SOAP сообщение. По большей части это аналогично простому отправлению основной части SOAP сообщения, за исключением того, что HTTP Content-Type заголовок должен быть задан как "application/dime", и телом HTTP запроса является DIME сообщение, а не SOAP сообщение.

Кроме DIME, существует еще один общепринятый механизм для упаковки множества частей данных вместе. Это спецификация Многоцелевые расширения электронной почты в сети Internet (Multipurpose Internet Mail Extensions (MIME)) и, в частности, многоэлементный MIME. Многоэлементный MIME используется в различных целях, но чаще всего для отправки сообщений электронной почты с вложениями. Очевидно, что есть взаимосвязь между нашим обсуждением мемо вложений и отправкой электронной почты с вложениями. Хорошо, что проблема, с которой работает DIME, может быть также решена путем использования MIME. Кстати, есть более ранняя спецификация, которая называется SOAP with Attachments, созданная с помощью Microsoft и использующая многоэлементный MIME для решения проблем вложений для SOAP сообщений. Итак, почему сначала был создан DIME?

Прежде всего, важно понять некоторые ключевые отличия между многоэлементным MIME и DIME. Как и DIME, во многоэлементном MIME есть "записи данных", в каждой из которых есть заголовок и полезный груз. Вместо использования длины данных для определении начала следующего заголовка, многоэлементный MIME использует разделительную строку. Она помещается в начале MIME сообщения и затем вставляется между каждой записью данных. Код, анализирующий MIME сообщение, должен просматривать данные до тех пор, пока не встретит разделительную строку, в этот момент он знает, что нашел следующую запись данных.

Подход многоэлементного MIME разработан для эффективной отправки MIME сообщений в некоторый поток данных. Отправителю не надо знать, сколько данных было послано прежде чем послать пакет. Данные просто отправляются, и в конце их прибавляется разделительная строка.

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

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

Конечно же, проблемы размера буфера и поиска границ решаемы в MIME. MIME очень гибок в том, как могут использоваться его заголовки записей данных, и есть большое количество ситуаций, в которых люди добавляют заголовки Content-Length в свои MIME записи данных. Но теперь возникает вопрос: зачем нужны разделительные строки, если мы уже знаем длину записи данных? А также, если вы добавляете MIME заголовки Content-Length в записи данных, вы теряете гибкость, обеспечиваемую отправителем, имеющим возможность просто отправлять данные до достижения их конца. Ему теперь надо будет знать полный размер записи данных еще даже до того, как он начнет отправлять их.

Конечно же, проблема необходимости знать размер данных до их отправки тоже решаема. Точно так же, как DIME имеет поддержку для фрагментирования, в многоэлементном MIME может быть найдено решение для фрагментированных данных. Но подумайте о том, как будет выглядеть это описываемое нами решение.

По существу, мы пришли к выводу о том, что решение в многоэлементном MIME должно: 1) включать длину содержимого записей данных, что означает 2) разделительная строка, разделяющая записи данных, больше не нужна и 3) должен быть определен механизм фрагментирования, чтобы решить проблемы с неизвестным размером данных. Если вы попытаетесь решить все эти проблемы в рамках оболочки многоэлементного MIME, не сложно догадаться, что вы начнете искать более простое их решение. Если вы включите также дополнительные преимущества легкости синтаксического анализа частей заголовка DIME записи фиксированной длины и простоты перескакивания с записи на запись в DIME сообщении, не трудно понять привлекательность подхода DIME.

Важно отметить, что простота имеет дополнительное преимущество, являющееся критичным для Web сервисов. Возможность взаимодействия – это гигантская часть того, почему Web сервисы стали настолько популярными и привлекательными, как они есть. Ключом к успешному взаимодействию является простота. Код, простой в написании и прямой в разработке, может запросто воспроизводиться на многих платформах. Если необходимо отправить сложный документ с платформы Windows на платформу Unix, если формат сложного документа прост, без множества дополнительных правил и с небольшим диапазоном возможных интерпретаций, тогда есть шансы, что документ будет понят на обеих платформах. Хорошим критерием простоты является количество строк кода, необходимого для реализации решения. Сравните логику, необходимую для реализации решения DIME, и логику многоэлементного MIME решения. Многоэлементный MIME требует специальной логики для создания разделительных строк, которые неприятно встречать в отправляемых данных. Необходима логика для прохождения по данным при поиске разделительных строк. Необходима логика для синтаксического анализа заголовка, которая может обрабатывать различное количество заголовков различной длины путем последовательных сравнений. Наиболее сложной частью в создании или синтаксическом разборе DIME записи – это, вероятно, работа с битовым порядком целых (integers), передаваемых в частях фиксированной длины заголовков записей данных. Самая малая сложность означает несколько дефектов и лишь несколько интерпретаций. Результатом должна стать простая возможность взаимодействовать.

DIME и WS-вложения формируют простое и эффективное решение для упаковывания вложений вместе с SOAP сообщениями. Они обеспечивают способность включать данные любого формата в SOAP сообщения таким образом, что с главным SOAP сообщением могут приходить JPEG изображения, документы с цифровой подписью, дополнительные SOAP сообщения и даже другие DIME пакеты. Они также определяют механизм для обращения к вложенным данным из SOAP сообщения в пределах пакета. Теперь многие инструментальные средства Web сервисов поддерживают DIME and WS-вложения, и в будущем вы можете ожидать увидеть еще больше реализаций. Скоро идея включения вложений в SOAP сообщения будет стандартной возможностью Web сервисов и их пользователей на любой платформе.