Hardware XML Accelerator - куда катится этот мир?

[dastapov]

Сначала я думал, что коллеги надо мной шутят, утверждая, что XML hype дошел до того, что уже производятся сервера, занимающиеся исключительно "аппаратной" обработкой XML/XSLT.

Но нет - lo and behold - IBM WebSphere DataPower XML Accelerator XA35.

Как утверждается, решение "provides a drop-in, self-learning network device that dynamically adopts XML and XSLT, reducing the need for code changes or changes to the network, servers, or applications to help streamline application deployment. The XA35 supports XML routing, XML pipeline processing, XML compression, XML/XSL caching, as well as other intelligent processing capabilities to help manage XML traffic."

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

Чем-то это мне напоминает ситуацию с WebServices/SOAP. Вроде и работает, и в плюсы записываем потенциальную human readability всего на свете - от спецификаций интерфейса до сообщений протокола. Плюс - у нас все plain-text и может работать поверх обычного HTTP. Правда, занимает "многа байт" и тормозит на серьезных реальных задачах.

Не беда - делаем Fast WebServices. Это те же WebServices, только со сжатием (чуть ли не при помощи gzip) того, что идет over-the-wire. Правда, не всегда работает over HTTP. Не беда - тут подпилим, там подставим, и будет счастье...

С нетерпением жду появления hardware accelerator-а для VisualBasic for Applications. Вот он появится, и это будет the next big thing. Всякие недоделки типа Java/C#/... - на помойку.

UPDATE: поясню, что меня больше всего удивляет. Больше всего меня удивляет подход к архитектуре. Зачем выносить отдельно именно этот кусок функциональности (к которому и от которого наверняка будут неслабые потоки данных)? В случае enterprise service bus - да, может быть и есть смысл. Но решение-то позиционируется гораздо шире. Если овчинка реально стоит выделки, то почему не делают отдельно стоящие network-enabled аппаратные JIT-компиляторы, например? Или отдельно стоящие network-enabled SQL processor-ы (ключевое слово тут - отдельно стоящие)?

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

UPDATE2: надо было мне меньше читать marketing hype, и больше разглядывать картинки :) Из этой фиговины наружу лезет ни разу не XML, а wml, html, fop, ... Пойду посыплю голову пеплом. Хоть бери и пост удаляй :)

Comments

[to-the-future.livejournal.com]

Раньше появится PHP accelerator ;-)

[to-the-future.livejournal.com]

Хотя нет. Сначала появится какой нибудь чудовищный метаязык, который одновременно будет и перлом и руби и питоном и пхп и всеми остальными скриптовыми языками. И вот уже для него сделают акселератор. ;)))

[zayatsz.livejournal.com]

Этот язык уже есть, называется MSIL :) В него компиляться и C#, и Delphi, и VB и т.п. и т.п. :) Вот как сделают процессор с хардварным MSIL... Даже вроде как наметки и проекты уже есть подобные.

[yurri.livejournal.com]

Есть всё же принципиальная разница между сжатием понятного и непонятного изначально. Вводим ещё одну операцию в стеке, и всех делов.

А bandwidth постоянно растёт, так что надо предполагать всегда повышение к концу разработки.

[nidd.livejournal.com]

http://en.wikipedia.org/wiki/XML_appliance

В 2005-ом интел купил sarvegу, которая и занимается производством таких штук. так вот теперь тут будут сидеть ребята и её хакать. XML router это называется. никто не знает, что это такое и зачем это нужно, но готовы взяться за работу.

[abbra]

Ага. А Дима тебе указывает на уже продающийся IBMовский продукт того же типа. :-)

[webushka.livejournal.com]

Я так понял, что это просто вынесенный в отдельную железку xslt processor плюс кеш ?
Дык полезная штука же. Зачем загружать универсальный CPU тупыми задачами, пусть бизнес-логику обрабатывает. Пользуется же народ платами-акселераторами для регекспов (я бы тоже пользовался, только дорогие они), платами для ускорения mod_deflate, ускорителями-концентраторами для ssl и железными криптотуннеляторами...
Правильный подход, между прочим - собирание системы из кубиков.

[breqwas.livejournal.com]

+1. Праведный гнев мне совершенно непонятен.

[filonov.livejournal.com]

Старый анекдот вспомнился:

- Что тут думать, трясти надо
- За умеренную цену мы готовы вам предложить наш патентованный пальмотряс...

[nikon-nlg.livejournal.com]

платами-акселераторами для регекспов
Это который Bivio 2000 ?

[http://users.livejournal.com/_adept_/]

Так это нифига не лисп-машина. Это сервер, который берет набор s-exp, делает lambda lifting, etha-reduction, что-то еще в этом роде, и возвращает получившиеся s-exp обратно :)

[webushka.livejournal.com]

Вся прелесть s-выражений - их хоть читать глазами можно :)

[akorsun.livejournal.com]

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

По поводу VBA. А чем лучше Java (на которой я программирую уже 5 лет) VBA, если assembler всё равно быстрее? От hardware JVM Вы бы отказались?

Какие-то безосновательные, мне кажется, рассуждения. При всём увжении - из серии "Windows - написали дураки, потому что дураки".

[http://users.livejournal.com/_adept_/]

От hardware JVM на отдельном сервере (как вот этот акселератор) - отказался бы. Как вы себе это видите? Мы туда суем jar-ы/class-ы, а оттуда ... что?

Соединения по RMI к неускоренной JVM на general-purpose сервере, в которой крутится "все остальное"? Поток XML, который мы заливаем в XML-акселератор? А что будет с Swing-ом?

Извините, но у меня как-то аналогия не вырисовывается. (Вот, кстати, сам себя и подставил - я VBA приплел для красного словца, и совершенно зря).

[http://users.livejournal.com/_adept_/]

Да, а про "ассемблер все равно быстрее" - это такая urban legend, не проверяемая на современных real-life задачах, да? :)

[filonov.livejournal.com]

А зачем вообще нужен стандартный формат для абсолютно разнородных вещей? К тому же настолько нечитабельный.

[dbg.livejournal.com]

Это все фигня. А вот когда цыска пытается упихать все это ексемельное безобразие в network path, вот тогда начинается веселье: http://cisco.com/go/aon

[http://users.livejournal.com/_adept_/]

Название хорошее (AON). Читаю и не могу отделаться от мысли, что там внутри - Zilog Z80, или даже несколько :)

[k0l7gxb1kicxm.livejournal.com]

не надо пост удалять.

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

Тут ширина функциональности (или, напротив, узкоспециализированность) будет лишь предпосылкой для конкуренции отдельных компаний.

[egorfine.livejournal.com]

А между тем, было бы полезно иметь девайс, куда по одному порту льешь XML+XSLT, а по другому принимаешь результат трансформации и принимаешь быстро. Именно что hardware xslt accel. Сейчас пока делается путем установки отдельного сервера трансформаций.

[selfmade.livejournal.com]

http://j-walk.com/other/wifispray/

[http://users.livejournal.com/_adept_/]

Да уж, это вам не token ring :)

Тут все серьезно, с научным обоснованием. Формулы меня пленили. Пойду, куплю ящик.

[blackshaman.livejournal.com]

Offtopic: http://doc-serfar-.nnm.ru/kompyutery_proslushivayutprichem_vse/page-82

[http://users.livejournal.com/_adept_/]

90 страниц комментариев. Ужас ...