XML ПОВЕРХ ICE
Независимо от того, как структурируется документ XML — с помощью DTD или XML Schema, — его разбиение на отдельные элементы (задача DTD и схемы) — это только часть общей картины. Не менее важное значение — если, конечно, вы собираетесь чего-то достичь с помощью документа — имеют правила и рекомендации, касающиеся использования документов XML, задаваемые в рамках определяющего DTD или схемы.
Необходимость в «правилах использования» (т. е. протоколах) становится очевидной в случае компаний, основная задача которых состоит в создании документов. Такой компанией является, например, агентство новостей «Рейтер». Наверняка, путешествуя по Web, вы обратили внимание, что в последнее время «шапки» «Рейтер» стали мелькать тут и там.
До появления ICE всякий раз, когда «Рейтер» заключало соглашение с каким-либо сервером Web о включении своего информационного наполнения, обеим сторонам приходилось прибегать к дополнительному программированию, чтобы заголовки и блоки новостей могли быть интегрированы в целевой узел Web.
Учитывая то, что основные затраты на распространение новостей, таким образом, приходились на переопределение соединений и преобразования, несколько игроков на рынке объединились для создания ICE — протокола базового механизма регулярной рассылки новостей. В июле 1999 года представители инициативной группы разработчиков продуктов для ICE, агентств новостей и их подписчиков собрались в Чикаго на ICE Summit. Эта встреча была организована Исследовательским институтом Ассоциации графических коммуникаций.
 |
| ICEберг. Пакет (или полезная нагрузка, как называется полное сообщение) Internet Content Exchange (ICE) содержит главным образом один или несколько тегов элементов ICE, а те, в свою очередь, могут включать текстовое наполнение в формате XML, двоичные данные в кодировке base64 или URL, указывающий на хранящийся в Web файл, который следует загрузить и включить как часть полезной нагрузки. |
Встреча продемонстрировала, что ICE достиг критической массы для создания работающих на его базе продуктов и что по крайней мере несколько компаний используют данный протокол для решения своих задач (см.
врезку «Три реализации ICE»). Это не тот протокол, где переопределяется все устройство вселенной (его претензии гораздо скромнее), но он удовлетворяет вполне определенные потребности бизнеса и делает свое дело с учетом всех тонкостей решаемой задачи, избегая при этом всяких излишеств. Спецификация ICE содержит DTD, определяющие, какими должны быть сообщения с различными запросами и ответами как при переговорах о новой подписке, так и при предоставлении информационного наполнения. (Пока что инициативная группа избегает использования XML Schema, поскольку та еще должна быть доработана и принята W3C.) ICE отличается от типичного приложения XML тем, что в нем XML применяется для форматирования сообщений внутри протокола, а не для определения более традиционных документов. Кроме того, в то время как XML чаще всего служит для предоставления размеченных документов клиенту (обычно браузеру Web, выполняемому на машине конечного пользователя), ICE предназначен преимущественно для межсерверных коммуникаций, где необходимость в визуальном представлении данных (и участии человека) отсутствует.
ICE позволяет агентству новостей предложить схему доставки и соответствующие условия подписки в формате XML. ICE описывает не только элементы данных в составе предложения, но также и методологию обмена копиями предложений в процессе согласования окончательных условий. Например, агентство новостей может предложить подписчику доступ для загрузки информационного наполнения по выходным с 2 до 3 часов ночи. Однако подписчику это может оказаться неудобно, поскольку в это время он загружает информационное наполнение из других источников, поэтому он может сделать контрпредложение о перенесении времени загрузки на час позже.
Таким способом ICE позволяет согласовать следующие два аспекта подписки: во-первых, как будет доставляться подписка — по запросу подписчика (pull) или по каналам агентства (push); во-вторых, каким будет график доставки.
На ICE Summit Рик Левин, архитектор Web в Sun Microsystems, отметил, что серверы согласуют только техническую, а не финансовую или информационную сторону соглашения.
« Участие человека при оформлении подписки на новости по-прежнему будет необходимо. Без делового ужина обойтись не удастся». Как он отмечает, очередь ICE приходит после заключения договора. ICE — это система для доставки информационного наполнения, причем эта система понимает настройки, которые провайдер новостного информационного наполнения хотел бы применить к своей интеллектуальной собственности.
В типичной ситуации провайдер информационного наполнения хотел бы передавать регулярные обновления некоторых сегментов своего информационного наполнения на клиентский сервер Web, а тот в свою очередь хотел бы интегрировать полученное информационное наполнение в свою структуру. Это именно тот тип деловых соглашений, которые новостные издания издавна заключали с издателями комиксов и программ телепередач, — и, как можно видеть, комиксы и программы передач по сей день собирают обширную подписку в Web.
Не затрагивая всех деталей порядка обмена сообщениями и механизмов подтверждения, все же полезно будет взглянуть, как осуществляется типичная доставка при использовании ICE. Общая схема приведена на Рисунке. Как видно, сообщение состоит из полезной нагрузки (группы информационных компонентов) и конверта, куда она помещается — только ваш базовый заголовок документа XML и пара соответствующих тегов.
Сама полезная нагрузка также формализуется с помощью тегов XML. Кроме того, контроль над тем, как обрабатываются элементы, описываются в полезной нагрузке с помощью свойств соответствующих тегов XML. Сила протокола, по сравнению с более ранним и тривиальным форматом определения канала (Microsoft Channel Definition Format), состоит в том, что ICE вводит постоянные элементы подписки. Например, новость всегда должна иметь заголовок. Содержание заголовка может меняться, но ему отводится определенное место, где его всегда можно найти.
ICE описывает несколько вариантов запроса данных (при распространении по запросу подписчика) или простой отсылки данных (по каналам агентства или в ответ на запрос).Наиболее важной из этих опций является возможность задания определяемых агентством состояний в истории доставки сообщений и возврата информационного наполнения к этому состоянию по требованию. Подумав, вы поймете, что здесь ICE выходит за пределы полномочий XML, и определения ICE начинают жить собственной жизнью, потому что в этом случае ICE указывает, какие программные (а не информационно-центрические) возможности должны иметь реализации ICE.
