Алексей Валиков - Технология XSLT

Рис. 2.5. XSLT на стороне сервера

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

Идея использования XSLT на стороне клиента (рис. 2.6) заключается в том, чтобы отдавать клиенту отдельно нужные ему данные и отдельно преобразование, которое будет создавать для этих данных требуемое представление (например — HTML-страницу). Четкое разделение данных и их представления предоставит клиенту полную свободу распоряжаться полученной информацией. Преобразование в этом случае всего лишь предлагает возможную трактовку этой информации, ни к чему не обязывая.

Рис. 2.6. XSLT на стороне клиента

Еще одним (правда, чисто техническим) достоинством выполнения преобразований на стороне клиента является разгрузка сервера, ведь такой подход освобождает его от необходимости выполнять процедуру преобразования.

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

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

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

□ клиент запрашивает определенный документ;

□ сервер находит (или генерирует) этот документ;

□ сервер находит (или генерирует) преобразование, ассоциированное с этим документом, и применяет его к документу;

□ результат преобразования возвращается клиенту (например, в виде HTML-файла).

В подобной системе можно выделить три базовых компонента (рис. 2.7):

□ генератор — модуль, который создает документ на основе информации, хранящейся в базе данных или просто в файлах на сервере;

□ процессор преобразований — модуль, который применяет преобразования к сгенерированному документу;

□ сериализатор — модуль, создающий физическую репрезентацию результата преобразования.

Рис. 2.7. Декомпозиция системы Web-публикации

В таком виде XSLT создает сильную конкуренцию серверным скриптовым языкам типа ASP, JSP, PHP, Python и так далее. Web-системы, построенные на XML и XSLT, гораздо гибче и легче в реализации, а их масштабируемость нельзя даже сравнивать. В традиционных системах добавление еще одного представления данных (например, текстовой версии документа или версии "для печати") — это еще одна программа на сервере, в то время как в системах, использующих XSLT, — это всего лишь еще одно преобразование (рис. 2.8).

Рис. 2.8. Создание множественных представлений с использованием XSLT

XSLT является одной из основных технологий систем Web-публикации, как Cocoon от Apache XML Project и XSQL от Oracle. Решения на основе. Cocoon и XSQL отличаются мощностью, гибкостью и простотой; ожидается, что системы этого класса займут в скором времени лидирующие позиции.

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

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

Действительно, предположим, что наши приложения уже имеют определенный XML-интерфейс (рис. 2.9):

Рис. 2.9. Приложение с XML-интерфейсом

Под XML-интерфейсом в данном случае подразумевается возможность экспортировать и импортировать данные в некотором XML-языке (пусть даже своем для каждого из приложений).

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

Рис. 2.10. Интеграция приложения с XML-интерфейсом в общую схему

Упомянутая выше задача перевода, или, по-другому, преобразования, есть очевидная область применения языка XSLT. Общая схема интеграции на основе XML и XSLT показана на рис. 2.11.

Рис. 2.11. Схема интеграции приложений на основе XML/XSLT

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

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