Все новости от 16 января 2005 г.

Как направить XML в скоростной ряд?

Эта проблема породила проекты по ускорению XML-трафика. Их сторонники утверждают, что рационализированный XML ускорит всё — от интернет-коммерции до обмена данными между сотовыми телефонами. Но чтобы это произошло, нужно прийти к технологическому консенсусу.

Проблема в следующем: сейчас стандарт XML предписывает хранить информацию в виде текста. Это означает, что XML-документ, такой как заказ-наряд или веб-страница, может легко воспринять человек или «считать» машина — при помощи многочисленных редакторов текста или XML-парсеров.

Но из-за тенденции XML к созданию очень крупных файлов возникают проблемы производительности. Отчасти причина в требовании, чтобы каждый элемент XML-документа помечался текстовыми метками. К тому же основанные на XML протоколы, называемые веб-сервисами, также генерируют значительный XML-трафик.

«XML не только многословен, но и чересчур избыточен с точки зрения пространства, приходящегося на единицу передаваемых полезных данных», — утверждает Джефф Лам, главный технолог компании Leader Technologies, где XML интенсивно используется для проведения телеконференций и где убеждены, что нужно что-то менять.

Основным кандидатом на роль средства, способного ускорить работу XML, служит технология, называемая бинарным XML, которая требует использования нового формата, компрессирующего XML-передачи.

Sun Microsystems инициировала проект open source Fast Infoset Project, основанный на бинарном XML, а ответственная за XML организация по стандартизации World Wide Web Consortium (W3С) сформировала рабочую группу Binary Characterization Working Group, которая займется переводом XML в двоичный формат.

На первый взгляд, компрессия XML-документов за счет использования другого формата может показаться разумным способом решения проблемы медлительности. Но сама идея вызывает у многих — включая пионера XML в самой Sun — опасения, что в результате могут появиться несовместимые версии XML. «Будь я властителем мира, я запретил бы бинарный XML, и я совершенно уверен, что те, кто его проталкивает, могли бы найти другое решение, — говорит Тим Брэй, соавтор XML и глава софтверного отделения Sun. — Но эти люди уверены в своей правоте, и они не глупы, так что не исключено, что они действительно правы. Поэтому остается надеяться, что они будут взаимодействовать с организациями по стандартизации и выпустят это ПО в виде открытого проекта open source — именно так, надо отдать им должное, поступают люди из Sun Fast-Infoset».

Пресс для XML
План Fast Infoset, ставший результатом более чем года работы, предполагает сжатие XML-документов в двоичный формат с целью ускорения процесса передачи файлов по интернету. Sun выбрала способ компрессии, уже стандартизованный в телекоммуникационной индустрии.

Инженеры Sun, участвующие в проекте Fast Infoset, утверждают, что преобразование в двоичный код необходимо, так как оно может существенно улучшить производительность, без чего в определенных ситуациях не обойтись. В ходе первых испытаний было установлено, что с этим ПО приложения работают в два-три раза быстрее. Цель проекта Fast Infoset — вызывать заинтересованность у разработчиков и со временем создать стандартизованный бинарный формат.

К созданию бинарного XML-формата призывают и производители потребительских устройств и мобильных телефонов, такие как Canon и Nokia. Без этого крупные файлы изображений слишком долго загружаются в устройства.

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

Брэй скептически настроен по отношению к идее преобразования XML в какой бы то ни было нетекстовой формат. «На практике тот факт, что XML — это обычный простой текст, который можно прочесть в Notepad... оказался благом, — говорит он. — При всяком отклонении от этого прямого и узкого пути мы рискуем утратить совместимость. Опыт взаимодействия через XML, как он есть, дает отличные результаты. Зачем что-то менять?»

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

Жанет Перна, генеральный менеджер IBM Information Management Group, называет в качестве одной из альтернатив бинарному XML борьбу с разрастанием XML-трафика путем ускорения сетевых операций. Пять или шесть лет назад считалось, что интернет будет слишком медленным для онлайновой коммерции, но со временем технология устранила это препятствие, напомнила она. «Я не считаю (растущий XML-трафик) ограничением. Думаю, что мы с этим справимся».

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

Рон Шмельцер из ZapThink говорит, что применение бинарного XML может ограничиться рыночными нишами, такими как приложения, в которых передаются очень большие объемы данных и где требуется максимальная производительность.

Лам из Leader Technologies поддерживает идею бинарного XML, но при одном важном условии — чтобы он был стандартизованным. «Число транзакций, содержащих XML, продолжает нарастать как снежный ком, и мы не хотим оказаться в ловушке, — говорит он. — Но если мы не сможем прийти к стандарту (бинарного XML), то я перестану поддерживать эту идею». 

 Предыдущие публикации:

Обсуждение и комментарии

	Коляныч - kolanychmail.ru 16 Jan 2005 5:14 PM
«XML не только многословен, но и чересчур избыточен с точки зрения пространства, приходящегося на единицу передаваемых полезных данных" плять! я об этом сразу подумал, как только этот долбанные хмл первый раз увидел.. может я великий и непроизнанный гений, а ... как думаете, отцы? «Будь я властителем мира, я запретил бы бинарный XML, и я совершенно уверен, что те, кто его проталкивает, могли бы найти другое решение, — говорит Тим Брэй, соавтор XML и глава софтверного отделения Sun» твоюмать! будь я начальником сана, я бы таких проектировщиков гнал бы... изобрели тормознутую хренотень (точнее слихали с хтмл) и еще тяфкают ... другое решение - это гигабитные сетки и сервера сан, что ли? а парни из Leader Technologies конечно молодцы, только это надо было еще 5 лет назад делать
	A 16 Jan 2005 8:31 PM
Бинаризация XML приведет к появлению кучи бинарных форматов последнего. Ну и как следствие, мы вернемся к прошлому десятилентию - куча всего несовместимого друг с другом. Это то, от чего народ хочет уйти. Вечно они велосипед изобретают. Взяли бы zip или bzip2 и зажимали бы обычный xml-файл.
	. 16 Jan 2005 9:29 PM
Торчяныч, ты опять на кольян присел ? Ты просто обдолбанный попугай который повторяет кем-то сказанные фразы причем
	. 16 Jan 2005 9:36 PM
причём даже не задействовав извилины
	Mossy 16 Jan 2005 11:17 PM
Кстати да. Чем xml.gz не устраивает, если надо много гонять данных? А то что XML слизан c HTML - это конечно новость'2005. Гениально!
	A 16 Jan 2005 11:20 PM
2 Mossy: Я ж о чем и говорю :)
	Bostonian 17 Jan 2005 12:55 AM
> Кстати да. Чем xml.gz не устраивает, если надо много гонять данных? тем что XML тредует кучи escaping & < > тем что он требует сложного parsing простейший solution - использование pascal like string ( word, strlen, datablock# ) (причем вначале стараться передавать structure, а данные потом) использование encoding для tag name, кодировать tagname в header (если есть DTD/Schema), или inline по мере первого использования если stream
	Bostonian 17 Jan 2005 12:59 AM
вот кстати пример кривизны XML-like систем zdnet не правильно кодирует ampersand "&amp;" symbol &amp;&amp;&amp; <><><><> Вообще, состема заставляющая пользователей(программистов) думать о ее внутреннем представлении данных - заведомо порочна.
	Bostonian 17 Jan 2005 1:01 AM
> Кстати да. Чем xml.gz не устраивает, если надо много гонять данных? gz - доблжно быть задачей транспорта(ssh -C) или файловой системы (chattr)
	hrun 17 Jan 2005 5:58 AM
А в чём сложность парсига XML? Просветите плиз...
	Мимо прыгал 17 Jan 2005 6:35 AM
А я думал, что XML и HTML были "слизаны" с SGML, а оказалось, что XML с HTML. Во как! Респект Торчанычу!
	asd 17 Jan 2005 12:41 PM
quote: утверждает Джефф Лам, главный технолог компании Leader Technologies, где XML интенсивно используется для проведения телеконференций может для телеконференций есть что-то более подходящее?
	Дядя Коля 17 Jan 2005 12:42 PM
Иногда люди забывают что есть RPC и CORBA...
	дядя Федя 17 Jan 2005 5:04 PM
to Дядя Коля >> Иногда люди забывают что есть RPC и CORBA... Да ну ?! И чем может помочь RPC и CORBA когда нужен обмен данными между различным системами? Иногда люди забывают что не все торчат от RPC и CORBA :)
	Black xxx 17 Jan 2005 6:05 PM
ДА IIOP РУЛИТ по любому. только иза DCOM MS CORBA загуналс.
	Black xxx 17 Jan 2005 6:07 PM
только не надо путать. RPC IIOP CORBA. хотя конечно последи два.. только разве IIOP не обеспечит норльмальы обмен данными?
	awas 18 Jan 2005 3:34 AM
Насколько я помню, во всех протоколах модемного обмена предусмотрено сжатие данных "на лету" перед отправкой по проводу (и соответственно распаковка принятых данных). Это видно даже невооружённым глазом, если следить за сообщениями, например, почтовых программ: текст писем передаётся в несколько раз быстрее, чем, например, приаттаченные GIF и JPG, потому что те уже сжаты и модем не может их сжать дополнительно. Так зачем же возиться с преобразованием текстовых тэгов в двоичный формат, если модем всё равно сожмёт эти текстовые тэги до 1-2 байтов? Правда, хранить эти тэги на дисках действительно накладно. Но при нынешней цене дисковой памяти такими расходами можно и пренебречь (или вернуться к сжатию "на лету" при записи на диск: в NTFS такая возможность предусмотрена, но ею, увы, мало кто пользуется). Словом, проблема надуманная -- явно ради выжимания денег под очередные громкие проекты.
	Bostonian 18 Jan 2005 7:21 AM
> А в чём сложность парсига XML? > Просветите плиз... если пихать его куда попало (что многие и делают), особенно во внутренние части приложений - то overhead на parsing и escaping - коллосальный. используя же binary constructions можно ускорить обработку в тысячи раз. (SIC!)
	Сергей Павлович - grayman2000mailinator.com 18 Jan 2005 11:53 AM
Гм... не пойму, из-за чего сыр-бор. Та же SUN давно использует в SO/OO XML с некоторыми доп. файлами, пожатые зипом, из-за чего документы в формате .SXx получаются заметно компактнее аналогичных по содержанию документов от MSO. А если еще и отключить "XML fine print", т.е. не тратить ресурсы на всякие красивости в виде отступов и избыточных CR/LF, то появляется еще бОльшая экономия.
	Black GNOME. 18 Jan 2005 12:33 PM
awas как будто дело только в АРХИВАЦИИ.. по запакованым данны сложно идексироваться. можно архивнуть и так и этак. ПРАВИЛЬНЫй нормальны бинарынй формат/стандарт бывает нанго проктичеее текстового. НО ГЛАВНОЕ Это открытость и ВОЗОМЖНОСТЬ МОдификации. ТЕ роста без переделываения самого формата. а рахивации как раз замедлит те XML.gz распоаковать а потом рапарстировать смысл БИНАРЫНОГО что его в прниципе партировать не надо ВСЕ УЖЕ построено на индексах. вообщем и базы даных же теоритически можно было в XML прямо на фалово системе хранить.?? ВЕДЬ да. :). и в каких то случаях так и делают.
	awas 20 Jan 2005 6:44 AM
to Black GNOME: Я говорю об упаковке "на лету". Процессорные ресурсы, необходимые для упаковки информации перед передачей в провод или записью на диск и для распаковки при приёме из провода или чтением с диска, ничтожно малы. На самом деле в современных машинах сжатие при записи на диск заметно экономит время: дополнительная работа процессора на порядки меньше, чем экономия времени на меньшем объёме обмена с диском. Поэтому, кстати, я до сих пор не понимаю, почему такой записью, скажем, в NTFS почти никто не пользуется. Но если мы сжимаем "на лету", то индексация архивных данных ничуть не осложняется: ведь в оперативной памяти -- во время индексации -- данные оказываются в исходном виде. Открытость же и возможность модификации текстовый формат обеспечивает несравненно проще и надёжнее _любого_ бинарного. По всем этим причинам я считаю обсуждаемый проект заведомо _тупиковой_ веткой. Как говорится, сами себе создали трудности, а затем с энтузиазмом их преодолевают.
	Black xxx 20 Jan 2005 11:43 AM
а я говрюю что не только в УПАКОВКЕ на лету не на лету дело. ну распаковал ты на лету XML.. а парсировать его надо ? всего в пямять поместить. и так далее. если это сами по себе текстовы данные то конечно никакой бинарнсти не надо. а если это не совссем текстовый данные. н напре набор чисел.. ВЕДь догичее его прямо в double хранить чем text <-> float каждый раз переконвертироватm при каждмо пересчете. и и так далее. ДЕЛО ведь не только в объеме.. а в том что С ДАНЫМИ УДОБНЕЕ рабоать в их исходном виде. сотвеснвео и передавать. а Xml это просто было придумано очень мета мета общее средство. НО Когда стоить говрить о чатсностях общенсоти только мешают. ТЕ созание более немене СТАНДРАТА ( не не будет такого стандрата ) кажды опять будет придумвать СВОЁ( xls doc итак далее) к чему это пиведт? но ВЕДь и так есть станадраты ( напрме не передачу тот же IIOP) можно придумать и на формат фалыо что нибть такое. точнее расширить. и как то инкасулировать его с XML. на само деле люди прост забыли зачем был придуман html изначать.. ЭТО ВСЕГО ЛИШЬ удобвны сопосбо читать ДОКИ.. а терпеь его раширили и всё на него пересраивают. и что хорошего.?
	Wolf 20 Jan 2005 6:05 PM
2 Black безграмотный Блин, как ты мне интеловские бинарные float/double... на 24 разрядном проце изобразишь, или как насчет big_endian/little_endian? Для этого-ведь и был xml сделан, чтобы документ на ЛЮБОМ процессоре/системе читался. P.S. Когда будешь ник в очередной раз менять, для разнообразия поменяй уж на безграмотный/криворукий, что-ли.
	Mark 20 Jan 2005 7:58 PM
а что, для того чтобы сказать компьютеру как интерпретировать данные, надо делать это в ASCII кодах и обязательно на английском языке? почему, для того чтобы сказать компьютерной программе, что это число в формате float (которое запросто умещается в четырех байтах) я должен каждую цифру этого числа преобразовать в ASCII байт и присовокупить к этому еще и объяснение на английском типа "<float>"? почему бы мне не договориться о неком универсальном двоичном формате как самого числа так и его характеристик, и спокойно его придерживаться? получится гораздо компактнее, удобнее для эффективной обработки, кодирования/декодирования, индексирования и т.д. и т.п. а для чисто визуального представления / редактирования использовать какой-нибудь редактор (платный или бесплатный) точно также как сейчас для этих целей используется текстовый редактор (платный или бесплатный) возражения есть?
	Wolf 20 Jan 2005 9:24 PM
2 Mark > возражения есть? Есть. ASCII (127 битный) все-таки худо-бедно, но понимается нонче всеми одинаково, а вот для плавучки - тапки, на каждом процессоре она своя. Равно как и представление int/long/long64 у каждого процессора/компилятора/системы свои. Я же простой пример привел для 24-разрядного проца (есть DSP такие) - он просто не УМЕЕТ с 32 разрядными словами работать - либо 24 разряда, либо 48. Так вот XML-ный тип данных (например в конфиге каком-нибудь) пропарсить малой кровью еще можно, а вот преобразовать Intel(а может и не Intel)-double во внутреннее представление - геморрой (сравнимый по объему кода с разбором строки). При этом, в общем случае, еще и порядок следования байтов на передающей/принимающей стороне неизвестен (endian то-есть). Это, кстати, вполне живой пример. >редактор (платный или бесплатный) точно также >как сейчас для этих целей используется >текстовый редактор (платный или бесплатный) А на кой мне нужен некий редактор, когда у меня в худшем случае 'echo "что ни-будь" > файл' УЖЕ существует?
	Wolf 20 Jan 2005 9:32 PM
Поправочка, ASCII конечно 7-битный, вечер однако :)
	Black Bat 20 Jan 2005 9:34 PM
XML - это религия. Типа, это круто, давайте его везде пихать. Видел я - запихали... чтобы хранить в базе описание заказа в xml-е (таблица заказов, для каждой записи в отдельной колонке свой xml). 100кб каждый xml, уже несколько сотек тысяч их. А потом окачалось что вообще то и запросы надо делать, наподобии SELECT * FROM o WHERE parse_xml(doc, 'dep_no') = '123' shit happened пришлось некоторые поля выносить
	Wolf 20 Jan 2005 10:01 PM
2 Black Bat Мда, за такие приколы в базах (и не только) надо долго пинать не снимая тяжелых ботинок.
	chkaloff 20 Jan 2005 11:12 PM
2 Black Bat: Тот пример, который ва привели говорит только о ошибках в проектировании, а не о том, что xml плох. По поводу размера. Ну вдумайтесь, обычно размер HTML кода в современном интернете на средней странице сравним с размером всех картинок на странице. Где-то больше, где-то меньше, но сравним. Так вот, что-то я не вижу большого движения типа «давайте придумаем новый бинарный HTML». Потому как это никому не нужно. Эта та вещь, на которую можно забить. Даже сделали возможность на многих веб серверах сжимать gzip'ом и deflat'ом HTML трафик. Ну и что, почти никто не пользуется этим. C xml - таже беда. Всем забить на это. Эта проблема яйца выеденого не стоит. Час работы программиста стоит $20-$40. За $20 в сша можно месячный adsl получить с таким трафиком, что мало не покажется. Пофиг на этот оверхед. Ну станут объемы проблемами, но будут сжимать их на лету. Только я сомневаюсь что это будет. Скорее увеличат каналы и производительность. Вот и все.
	Black xxx 21 Jan 2005 4:07 PM
HTML уже насчал себя изечерпывать. другео дело это ОБЩИЙ формат токоры понимаю ВСЕ. а не ктолько кто ток с кем то. только не надо путать XML с HTML. если бы XML пытаилсь запинуть толкьо в нишу где мог бы рабоать и Html. это ладно. а на DSp процоре и chat может быть не 8 бит.. так о какой эфективность "парсера" на DSP можно говорить.. как раз скорее было бы проще сделать преобразователь бинарного формата для этих геоптетически 24 биных DSP процов. чем ASCII 2 float для него же. в окнце концо IEEE есть. порчитайтет ка крешается big litl индиан в IIOP. так ЭТА проблема решена.. те iiop соеденяет разны платформ БЕЗ ЭТИХ проблем. ( хотя и не без некоторы хитростей. и вообще о чем ругаемся. мы же не предалгаем заменить XML на какой то бинарный. РЕЧЬ идет о том что бы придумать некую бинарную аналогию XML. кторая бы понималс всеми. это не значит что XML стнает бинарным.. те что БЫ изначально был ОБЩИ стантардт.. потому что неизбюежно многие все равно рано или поздно будет придумывать своё и в резльтатте ка краз и пойдет сброд и шатания.
	Александр Савенков - savenkovxmlhack.ru 22 Jan 2005 4:57 AM
Не совсем понятно, почему обсуждение статьи опять превращается в дискуссию на тему "Быть или не быть XML". Статья говорит совсем о другом. И важно помнить, что многословность - один из принципов, который лежал в основе XML. То есть тем, кому это не подходит, просто должны использовать другое решение. К переводчику статьи: по-моему, прекрасный перевод, читать приятно. Только вот в текст закралась досадная опечатка: написано WC3 вместо W3C. Всё же это консорциум, а не санузел номер три.
	glassy 22 Jan 2005 9:24 AM
Так горячо спорите... Интересно, из вас кто-нибудь ASN.1 хотя бы щупал?
	glassy 22 Jan 2005 9:32 AM
Каанешна... нет пиара, нет ASN.1 :(
	Константин 24 Jan 2005 9:01 PM
To glassy: вот-вот. У меня есть подозрение, что изобретателей XML плохо учили в школе, и они не заметили, что существует ASN. Может, я и не прав, но я много лет желаю услышать развернутый ответ на вопрос: зачем нужен XML, если есть ASN?