Тег path служит своего рода вместилищем, где промежуточные серверы могут хранить сведения о дате и другую информацию, чтобы маршрут (и с помощью расширения обратный маршрут) был виден всем серверам вдоль пути.
Общий формат полного сообщения BizTalk показан во врезке «Анатомия сообщения BizTalk».
БИЗНЕС-МОДЕЛЬ BIZTALK
Учитывая, что эти спецификации документов являются общедоступными и любой желающий может использовать схемы BizTalk бесплатно, вы можете резонно спросить, как Microsoft собирается извлекать прибыль с помощью XML? Ответ прост — за счет продажи инструментария XML.
Как считает Шмидт, главным источником прибыли для Microsoft должен стать серверный продукт для регулирования обмена BizTalk-совместимыми сообщениями XML между партнерами по бизнесу. По его словам, бета-версия этого продукта должна появиться в конце осени 1999 года; готовый же продукт должен выйти после Windows 2000.
Возможно также, что одним из источников прибыли могут стать ориентированные на конкретные рынки оперативные службы (на таких узлах, как Microsoft MSN), где BizTalk будет использоваться производителями для сообщения рыночной службе о предложении новых продуктов и специальных скидок.
Как поясняет Шмидт, если такая оперативная служба появится, то она не будет базироваться на сервере BizTalk, поскольку он предназначен исключительно для целей создания библиотеки и общественного центра, где бы компании и разработчики могли свободно обмениваться идеями. «Мы не рассматриваем biztalk.org в качестве портала для организации сделок между компаниями», — уверяет Шмидт. В настоящее же время основные усилия BizTalk сосредоточены на том, чтобы отраслевые группы приняли BizTalk Framework в качестве общего знаменателя их усилий в области XML.
XML ПОВЕРХ ICE
Независимо от того, как структурируется документ XML — с помощью DTD или XML Schema, — его разбиение на отдельные элементы (задача DTD и схемы) — это только часть общей картины. Не менее важное значение — если, конечно, вы собираетесь чего-то достичь с помощью документа — имеют правила и рекомендации, касающиеся использования документов XML, задаваемые в рамках определяющего DTD или схемы.
Необходимость в «правилах использования» (т. е. протоколах) становится очевидной в случае компаний, основная задача которых состоит в создании документов. Такой компанией является, например, агентство новостей «Рейтер». Наверняка, путешествуя по Web, вы обратили внимание, что в последнее время «шапки» «Рейтер» стали мелькать тут и там.
До появления ICE всякий раз, когда «Рейтер» заключало соглашение с каким-либо сервером Web о включении своего информационного наполнения, обеим сторонам приходилось прибегать к дополнительному программированию, чтобы заголовки и блоки новостей могли быть интегрированы в целевой узел Web.
Учитывая то, что основные затраты на распространение новостей, таким образом, приходились на переопределение соединений и преобразования, несколько игроков на рынке объединились для создания ICE — протокола базового механизма регулярной рассылки новостей. В июле 1999 года представители инициативной группы разработчиков продуктов для ICE, агентств новостей и их подписчиков собрались в Чикаго на ICE Summit. Эта встреча была организована Исследовательским институтом Ассоциации графических коммуникаций.
Встреча продемонстрировала, что 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.
ТЕГ — ЭТО СООБЩЕНИЕ
ICE является далеко не единственным предложенным стандартом, где XML применяется для определения коммуникационного протокола. К слову сказать, уже один тег Эти детища двух инициатив — одной, стремящейся более строго и полно регламентировать, что должен собой представлять правильно составленный документ XML, и второй, решившей применить XML к «диалоговым» приложениям, — показывают, что XML не удастся подвести под одну мерку.
В своей основе XML очень прост, но в реальном мире разные задачи, такие, как преобразование стилей, спецификации печатных данных и иерархические схемы, смешиваются настолько энергично, что в результате мы рискуем получить барочный букет угловых скобок. Однако с учетом того, что инструменты для упорядочения хаоса XML становятся все лучше, вполне вероятно, что его усложнение будет иметь положительный эффект, так как оно позволит решить с помощью XML и другие задачи вычислительного мира. Но мы должны считаться с фактом, что, как и HTML до него, XML имеет самостоятельную ценность и круг задач.
Хотя практически в любом обзоре XML (не исключая и статью «XML: время пришло») говорится, что грамматика и синтаксис правильно составленного документа XML определяются DTD, скорее всего, дни DTD уже сочтены. На смену DTD должен прийти новый стандарт — XML Schema.
DTD вполне достаточно для базового определения документа, но они имеют несколько недостатков. Во-первых, они даются не на XML. Учитывая высокую степень адаптируемости и расширяемость XML, наличие еще одного формата для определения документов представляется излишним.
Во-вторых, элементы DTD внутри документа XML требуют полного определения всего, что находится внутри этих элементов. Другими словами, никакие подэлементы «на перспективу» не допускаются — если таковые будут присутствовать в документе, то, по определению, документ не будет являться правильно составленным. Между тем определения XML Schema используют модель открытого информационного наполнения, в которой неопределенные элементы вполне допустимы.
В-третьих, DTD ограничиваются только грамматикой и синтаксисом (т. е. отношением одного элемента к другому), тогда как XML Schema может также задавать непосредственные ограничения на тип данных, которые элемент может содержать. Это значительно упрощает реализацию передачи данных приложения по сравнению с более традиционным текстовым документом. Например, точно так же, как это делают разработчики в языках программирования, вы можете явным образом указать, что данная область хранения может содержать только целочисленные данные. Наконец, разработчикам, работающим в средах Wintel, будет весьма удобно то обстоятельство, что XML Schema легко отображается на Microsoft Document Object Model. Таким образом, работающая с документами XML программа может запросить у соответствующей схемы имеющееся определение для элемента документа по своему выбору. Код выглядит следующим образом:
Однако как же будет выглядеть сам содержащий схему документ изнутри? Во-первых, он будет содержать теги XML, объявляющие, что это схема, наподобие:
Каждый пункт внутри схемы объявляется затем индивидуально, причем особенности каждого элемента расшифровываются с помощью вложенных тегов, например:
определяет элемент <Inventor> как могущий содержать только текстовые данные.
Подобные схемы могут оказаться весьма трудны для чтения, но они легко поддаются разбору с помощью инструментов XML. Другими словами, вам не потребуется специальный редактор для работы с документом XML Schema, как в случае DTD.
Отмечу также, что в случае правил на базе XML для форматов коммерческих данных вы можете использовать для отображения одной схемы на другую встроенные функциональные возможности преобразования XML — расширяемый язык таблиц стилей (Extensible Stylesheet Language, XSL).
На ICE Summit в Чикаго в июле 1999 года было продемонстрировано три ICE-совместимых менеджера распространения новостей.
WebExpress ShiftKey Syndication System Vignette Syndication Server Принимающее приложение узнает о том, что это сообщение BizTalk, на основании конверта (он сообщает конкретную схему, использованную для формулирования данного документа). Оно понимает формат ваших специфических данных, потому что тег <MsgType> указывает на схему, которую вы используете внутри для форматирования своих данных:
Теги маршрута Ваш документ
Вся информация о BizTalk, в том числе полная спецификация тегов BizTalk, имеется на http://www.biztalk.org.
Полная спецификация Internet Content Exchange (ICE) доступна интерактивным образом на http://www.w3.org/TR/NOTE-ice.
Дополнительную информацию о XML Schema можно найти на http://www.w3.org/TR/xmlschema-1/
и http://www.w3.org/TR/xmlschema-2/.
[an error occurred while processing this directive]
Новая схема
var bookNode = doc.documentElement
<Schema name=”schema_sample_1”>
... содержание схемы
</Schema>
<ElementType name=”PERSONA” content=”textOnly” />
Три реализации ICE
Arcadia Technology
http://www.arcadiatech.com
Ввиду того, что пока webExpress имеется лишь в бета-версии, говорить о том, чем этот пакет отличается от своих конкурентов, было бы несколько преждевременно. Однако судя по тому, что было продемонстрировано на ICE Summit, это будет непосредственная реализация протокола ICE без каких-либо излишеств.
ShiftKey Software
http://www.shiftkey.com
ShiftKey решила повысить ценность своего продукта за счет добавления поддержки ряда средств преобразования информационного наполнения после его поступления на сервер подписчика. В конце концов, ICE просто доставляет информационное наполнение в стандартном формате, а он ведь может и не подходить для прямого включения данных в Web-страницы подписчика. Один из поддерживаемых ShiftKey методов трансформации — Extensible StyleSheet Language (XSL), он определяет, как теги XML должны отображаться в браузере. Необходимые преобразования описывают таблицы стилей.
Что касается серверной стороны, ShiftKeySoftware на момент публикации статьи была единственной компанией, поддерживающей распространение по запросу подписчика (pull) и по каналам агентства (push) и предоставляющей сервер ICE, не привязанный к системе управления информационным наполнением.
Vignette
http://www.vignette.com
Syndication Server рассматривается как отдельный продукт, но его основное назначение состоит в упрощении достижения соглашений о рассылке новостей с помощью имеющегося продукта, а не в ориентации на рынок рассылки новостей сам по себе.
Предложение Vignette тесно привязано к Vignette Story Server, системе управления информационным наполнением Web старшего класса, используемой такими издательскими гигантами, как Time Warner, Ziff-Davis и Chicago Tribune.
Анатомия сообщения BizTalk
<BizTalk xmlns=”urn:shemas-
biztalk-org:BizTalk/biztalk-0.81.xml”>
<Route>
</Route>
<Body>
<MsgType xmlns=
”urn:ваше-пространство-имен”>
Ресурсы Internet