На главную страницу AlgoNet В сотрудничестве с ZDNet
АРХИВ СТАТЕЙ 2002-3-22 на главную / новости от 2002-3-22
AlgoNet.ru
поиск

 

Место для Вашей рекламы!

 

Все новости от 22 марта 2002 г.

Скелет в шкафу XML

КОММЕНТАРИЙ — XML быстро становится lingua franca электронных коммуникаций и составляет хребет всех протоколов веб-сервисов. Некоторые аналитики предсказывают, что в будущем году на долю XML придется целых 60% сетевого трафика. К сожалению, сетевая инфраструктура слепа по отношению к XML-трафику, что ведет к созданию узких мест и пробелов в защите.

Важный электронный контент и деловые документы все чаще передаются как шифрованные сетевые потоки XML, будь то ebXML, RosettaNet или новые веб-сервисы. Для ускорения трафика XML и его обработки не годятся решения, верой и правдой служившие для ускорения веб-контента — такие как выравнивание нагрузки HTTP, кэширование контента или ускорение операций SSL. Процесс XML-преобразования (с применением XSLT) часто оказывается слишком медленным для производственных систем. Типичная операция XSLT тащится со скоростью в несколько сотен килобайт в секунду — очень медленно.

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

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

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

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

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

Обычно XML-преобразование выполняется со скоростью в несколько сотен килобайт в секунду. Некоторые XML-устройства позволяют повысить ее на 30-50%. Но этого недостаточно. Нужно выбирать такое решение, которое довело бы эту скорость до быстродействия самой сети — 100 Мбит/с. Потому что сегодня это стандартный минимум производительности корпоративной сети, а XML-системы не должны отставать от других, смежных с ними систем. Эта разница на порядок означает, что один XML-ускоритель может заменить несколько серверов — а значит, инвестиции окупятся очень быстро.

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

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

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

Евгений Кузнецов — основатель и технический директор компании DataPower Technology. Он родился в Москве и переехал в США в 1990 году. Кузнецов получил степень бакалавра электронной техники в MIT.

 В продолжение темы:
2002-03-25   Чип-регулировщик для локальных сетей
2002-03-29   Xperanto — волшебное заклинание IBM для серверов
Обсуждение и комментарии
Skull - sibskullmail.ru
24 Mar 2002 11:20 AM
Базара нет! Только насчет "в будущем году на долю XML придется целых 60% сетевого трафика" - явный перебор! Может, он имел ввиду трафик своей конторы, а не мультимедийные трафики. Интересно, как порно и видео будут через XML пускать?
 

00alex - 00alexmail.ru
24 Mar 2002 7:57 PM
Причему тут XSLT и сетевой трафик?
Скорость XML трафика ограничивается либо временем XSLT преобразования либо пропускной способностью канала связи. Что уже, то и надо "чинить". В первом случае более быстрый сервер покупать, во втором - канал расширять.
Возможно статья расчитана на людей плохо представляющих, что такое XML, XSLT и маршрутизаторы и каналы связи - тогда да, объединить эти понятия в одну статью - "модно".
Выводов несколько:
1) XML трафик будет расти (потому, что XML - это удобно)
2) XSLT процессоры будут совершенствоваться (потому, что есть куда)
3) каналы связи будут расширяться по мере роста спроса на информацию (факт)
;-)
 

miroh - plasmonmail.ru
25 Mar 2002 11:09 AM
На сколько я все не правильно понял, речь идет о нардварных XSLT процессорах. У меня ява ксалан процессор 80кб процессит за 60 миллисекунд. - действительно мало (P!!! 650)
 

Олег А. Лебедев
25 Mar 2002 12:43 PM
Мне кажется что людям голову морочат :-), какое железо ускорит процессинг XML данных полученных от SQL сервера, ответ НИКАКОЕ! Единственно возможное решение закэшировать готовый результат от SQL сервера и HTML полученный после процессинга и отправленный клиенту, ну а с этим отлично справляется .NET. Аппаратный XSLT процессор это что? (Linux + Squid, для кэширования), ну дак такой аппаратный процессор и так применяется :-)
 

Олег А. Лебедев
25 Mar 2002 12:46 PM
Мне видиться что в сетевое это все выносить нет смысла, а вот создать чип сопроцессора для серверов возможно. Отдельный процессор который будет аппаратно парсить и транслировать и сидящий на материнской плате или на отдельной карточке. А ставить его в сеть смысла нет накладные расходы очень большие будут.
 

Null
25 Mar 2002 2:00 PM
Есть одна проблемка: благодаря некоторым фирмам (сам знаешь каким) XML не просуществует и года как стандарт де-факто, а будет постоянно меняться и становиться угребищней. Соответственно и парсеры нужно будет менять с частотой в несколько месяцев.
 

dogada
25 Mar 2002 3:21 PM
2Null
XML это не HTML, при изменении DTD парсер менять не надо.
 

REAL - realkemsu.ru
26 Mar 2002 7:35 AM
Ламерская какая-то статья. Тут даже добавить нечего.
 

HoolyGUN - whalerchat.ru
28 Mar 2002 2:04 PM
Бред какой-то, а не статья. Куча модных терминов, плюс вполне разумные (и очевидные) слова про рост траффика и требований к производительности восхитительно сочетаются с абсолютно ламерскими проколами в смысловой части.

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

Что касается скорости XSLT-преобразования, так она в основном зависит не от объемов в килобайтах, а от количества узлов в XML- и XSL-деревьях. Так что измерять ее в килобайтах-в-секунду по меньшей мере глупо. По моему опыту, скорость даже больше зависит от сложности XSL, а не от размера XML.
 

AT - 220220pager.icq.com
28 Mar 2002 10:22 PM
Ага .. Эпопея XML еще продлится не долго ...
Исспользуя обычную Zlib компресию XML пакуется раз в 10-20...
Смысл это дополнительного никому ненужного траффика мне пояснит кто-то ??
 

Map - mapjavaranch.com
29 Mar 2002 10:47 AM
"Бред какой-то, а не статья" - по-видимому, просто перевод :)
 

Bravo
29 Mar 2002 11:27 PM
да не - перевод - нормальный. просто у них там все менеджеры так мыслят. и вот один из них решил выплеснуть свой суп нам. хлебайте, ребята!
 

Caesar
30 Mar 2002 11:19 AM
Вот рождение ещё одной рекламной акции - необходимость приобретения XML-маршрутизаторов:))) ПОЛНЫЙ БРЕД.
 

Сергей - vip2000ozemail.com.au
1 Apr 2002 3:52 PM
Вообще тут в Австралии уже ходят о разговоры о положительных результатов применении XML для лечения рака. И что, народ интересуется...
А в целом - XML поможет делать бесконечные upgrades и не оставит без работы тех, кто не ленится набивать руки на этой муре.
В целом - если клиент это будет хотеть на XML - ну не нам же ему диктовать, как хотеть.
 

eXOR - billygmicrosoft.com
2 Apr 2002 9:18 PM
2 AT:
html почему - то до сих пор zlib'ом не жмут, хотя это и апач делать умеет и iis, и распаковывать может и мозилла и ie... т.е. для web-developer'a и для surfer'a все прозрачно... ан нет - не делают...

2 Сергей:
А мне нравится XML - удобно. Самое то логику отделять от структуры.
 

Ruslan
8 Apr 2002 11:26 AM
To Scull
>ввиду трафик своей конторы, а не мультимедийные трафики. >Интересно, как порно и видео будут через XML пускать?
A как быть с SVG?
 

eXOR - billygmicrosoft.com
8 Apr 2002 2:11 PM
2 Ruslan:
Ага, все прямо спят и видят девушек в векторном виде :-).
 

lazer
12 Apr 2002 12:58 PM
to eXOR: жмут ...
 

eXOR - billgmicrosoft.com
12 Apr 2002 2:08 PM
2 lazer:
В тэнзоры обращают.
 

Хозяин
8 May 2002 9:05 PM
Уехал в США?

Скатертью дорожка!
 

 

← февраль 2002 18  19  20  21  22  25  26  27  28 апрель 2002 →
Реклама!
 

 

Место для Вашей рекламы!