Pull to refresh

Иллюзии XML/XSLT технологий

Reading time 7 min
Views 3.7K
Иногда в компьютерном мире происходят всплески интереса к той или иной технологии. Всплески не случайные, а явно поддержанные производителями этих технологий. Это и не удивительно, ведь сложно продавать одно и то же, проще продавать что-то новое или старое, но названное иначе. Ничто так хорошо не продается, как функция, которой нет в прошлой модели. Почему так устроен потребитель? А мнение потребителя банально эксплуатируется, ему просто навязывается желание. Крупные производители ПО очень часто исчерпывают рынок сбыта и нуждаются в постоянной смене технологий для того, чтобы продать обновления и просто увеличить цены на программы. Ну и проще отстраиваться от конкурентов, заверяя, что у нас лучшие и новейшие технологии.

Так случилось с XML. Ведь XML — это, в общем-то, ничего нового. XML — это упрощённое подмножество языка SGML, который берет свое начало еще в GML 1960 года выпуска компании IBM. XML, по сути, просто стандартизировал формат обмена информацией и все.

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

Да чего далеко заглядывать назад, вот он AJAX и вот он объект для рекламы и продаж. Теперь только ленивый не говорит, что он с AJAX.

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

В своей статье «Программирование как искусство» я упоминал уже об увлечении программистов технологической модой. И как я уже говорил, я сам программист и мне и моим коллегам было свойственно увлекаться. И в этой статье я расскажу о наших ошибках связанных с использованием XML/XSLT технологий. Возможно, этот опыт будет кому-то полезен и поможет ему найти правильное место для использования этих технологий. Хотя твердо можно сказать, что эта статья вызовет и большую критику в мой адрес.

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

Один из таких продуктов — «Битрикс: Инфо-портал». Один из самых сложных продуктов, который мы создавали. Разработанный для платформы Microsoft на базе технологий ASP с базой данных MSSQL, он был предназначен для создания веб-решений на платформе MS.

В первой версии этого продукта (в 1999 или 2000 году, кажется) мы создали свой самописный шаблонизатор, в котором инструкции стояли в правильных тегах и выглядели примерно так #DATA()#. В нем были простые условия и циклы: Ну кто этого не проходил? Да все кто когда-то делал систему, которую предполагалось передать кому-то в использование и настройку, делали свой шаблонизатор.

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

Действительно, было написано много книг и учебников, в которых программистов и проектировщиков учили, что лучший способ создать шаблонизатор или абстрагировать внешний вид (представление) от данных — это загнать все в XML, пропустить потом через XSLT и уже на выходе получить HTML. Т.е. XSLT и станет для вас лучшим шаблонизатором.

Утверждалось, что проекты с XSLT шаблонами должны быть проще и удобнее, чем любые другие шаблоны и ими будет удобнее управлять. Много говорилось о безопасности, удобстве переносимости и простоте развития таких проектов.

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

Совершили подвиг, заставив XSLT шаблоны работать достаточно быстро, вложили кучу сил, времени и денег в разработку технологии… Самые большие каталоги товаров вмещали по 70 тысяч товаров.

Но клиенты голосовали рублем и внесли ясность.

Что мы получили в итоге:

1. Иллюзия простоты XSLT шаблонов.

Проекты с использованием XML/XSLT оказалось очень тяжело поддерживать клиентам и нашим партнерам. Стоимость владения такими проектами очень велика и имеет тенденцию к росту по мере роста проекта. Специалистов по XSLT очень мало. Технологичный шаблон может подправить только специалист достаточно высокой квалификации. Через XPATH выбирать данные тоже не особенно удобно. Таким образом, развеялась иллюзия, о простоте для клиентов и удобстве в управлении проектами.

2. Иллюзия управляемости и гибкости.

Шаблонов XSLT в большинстве своем недостаточно для написания серьезной бизнес-логики в публичной части сайта. Зачем перекладывать серьезную бизнес-логику на шаблон с XSLT? Да так получается в некоторых приложениях, что данные одни и те же, а вот от пользователя или ряда условий зависит, что и в каком виде он увидит. А это уже шаблон и в нем нужна логика. XSLT не развивался как полноценный язык программирования, на нем можно делать только простые условные представления и ограниченную логику. Нет возможности использовать весь потенциал современных языков программирования и библиотек (графика, представление, сервисные функции и т.п.).

3. Иллюзия производительности, дешевого размещения и масштабируемости.

Как не стараются РАЗРАБОТЧИКИ, производительность XML/XSLT систем остается очень низкой, несмотря на все усилия индустрии. Да и как выжать эту производительность? Сначала данные из SQL базы преобразуются в XML (а это текстовый файл большого размера в силу своей структуры). Потом XML данные загружаются в XML парсер уже в серверной части, где они занимают еще больше памяти для работы XPATH, формирования индексов по XML данным в момент загрузки и т.п. Далее XSLT проходит по огромному массиву данных, получая на выходе опять же текст, который занимает память.

Реальное решение производительности просматривается только в многоуровневом кешировании, что не всегда возможно, или нежелательно, или просто дорого, как в разработке, так и в использовании.
Иногда спорят, мол, зачем вам много данных в XML? Ну чтобы сделать шаблон сайта или просто форума, например, на XSLT, в XML должны быть почти все данные: авторизация пользователя, данные по статистике, каталог, ветки товаров или статей: Некоторое решение лежит в области управления и запросе нужных данных в XML прямо из XSLT. Но все равно, данных приходится извлекать заметно больше, условий нужно больше, памяти и запросов приходится делать больше, ну и сам шаблон усложняется и фактически становится уже полноценным программным приложением, что убивает первоначальную цель, сделать шаблон простым.

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

4. Иллюзия удобства абстрагирования данных и внешнего вида.

Один из плюсов, за которым все гонятся, используя технологии XML/XSLT — добиться качественной абстракции внешнего вида. Но только уже после создания первых шаблонов все понимают, что абстракция получилась, только никому она уже больше не нужна. Шаблон XSLT очень сложен для представления внешнего вида, тем более, современного AJAX приложения. Корректировка такого шаблона требует много сил. Полная смена дизайна требует полного переписывания всех шаблонов, что в расчете на сложность создания XSLT получается еще дороже. Таким образом, получается, что цена владения технологией XML/XSLT очень высока как для разработчиков, так и для их клиентов.

5. Невозможность создавать библиотеки и повторно использовать результаты работ

Созданные шаблоны или XSLT приложение нельзя объединить в библиотеку, чтобы уже в следующем шаблоне упросить работу с типовой операцией. Программисты крайне ограничены в передаче своих наработок своим коллегам. Выявленные ошибки приходится отслеживать в нескольких шаблонах.

6. Нелинейный рост сложности разработки при развитии приложения

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

И что получается в результате героических усилий разработчиков по освоению технологии?

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

Значит ли это, что надо вообще отказаться от XML? Конечно, нет. XML/XSLT очень красивая технология (программистская фраза, правда?) и будет еще развиваться. XML отлично работает для связи между проектами (RSS, Яндекс.Маркет, CommerceML и другие). Для небольших шаблонов и фрагментов и сегодня вполне эффективно используется XSLT для обработки XML.

.NET полностью поддерживает XML во всех его проявлениях. XSLT трансформация тоже поддерживается: если нужно — применяй, не нужно — нет. Но на использовании XML/XSLT никто не настаивает.

Есть даже очень яркие примеры, когда крупнейшие проекты используют XML/XSLT. Насколько мне известно, Яндекс использует данную комбинацию для своих сервисов. И для меня лучшим результатом эффективности является финансовый результат. Не буду утверждать, но предположу, что себестоимость разработки в отношении к скорости разработки для Яндекса довольно высока, очевидно, в пределах допустимого для данного проекта, но все же не так комфортна, как хотелось бы. Но это только мое предположение. Аналогии с Яндексом я не провожу, это неуместно. Мы делали тиражный продукт, а они делают внутренние сервисы для себя и располагают возможностью использования всех инструментов оптимизации и конфигурирования приложения, обслуживают его только своей командой.

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

Для чего вся эта статья? Выбирайте инструменты обдуманно, не руководствуйтесь только модой и заверением разработчиков технологии о ее невероятной эффективности. Если вы делаете тиражный продукт, как мы, учитывайте экономику партнеров и клиентов. Если для использования продукта разработчику нужно будет знать язык программирования платформы (ASP, JAVA, PHP...) и еще в нагрузку использовать XSLT в шаблонах и XPATH для поиска данных, одно это может сделать проект невыгодным для использования, не говоря уже о массе других причин.

В общем, голову никто не отменял.
Tags:
Hubs:
+13
Comments 24
Comments Comments 24

Articles