XML-Sapiens — орудие разделения функциональности сайта и программного ядра


Оглавление (нажмите, чтобы открыть):

XML-Sapiens — орудие разделения функциональности сайта и программного ядра

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

Так уже много лет существует стандарт XSLT, позволяющий формирование документов из разделенных источников: XML-файла со структурированным содержанием документа и XSL-шаблона с описанием того, как документ будет представлен на сайте. Причем само формирование документа, может происходить на стороне клиента. Достаточно передать браузеру XML-структуру данных, содержащую ссылку на XSL-шаблон и браузер сам «нарисует» страницу в том виде, как это предполагалось дизайнерами. Содержание каждой страницы сайта различается, однако форма подачи этого содержания, обычно, ограниченна небольшим числом шаблонов. Таким образом, XSLT позволяет нам одиножды написанный шаблон представления данных на сайте использовать многократно. Казалось бы, вот она идеальная технология для CMS. Однако повсеместное применение данной технологии сдерживает ряд факторов. Из них психологическая инерция — не главенствующий фактор. Описание функциональности сайта с помощью XSLT — весьма трудоемкая задача. Кроме того, XSL-шаблон слишком зависим от XML-документа с данными, что ограничивает гибкость решений на основе данной технологии.

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

Как устроен XML Sapiens

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

XML Sapiens и данные

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

XML документ типа поля, как и в случае набора полей, может содержать описания типа для различных состояний интерфейса. Если в системе определены состояния «администрирование» и «доставка содержания», то в первом случае данные могут быть представлены в форме запроса содержания, во втором «как есть».

XML Sapiens и функциональность

Документ описания функционального алгоритма (DDC) содержит инструкции анализа условий, аналогично XSLT. Синтаксис DDC также позволяет ссылаться на приложения CMS, которые, согласно переданным параметрам, возвращают потоки данных для дальнейшего анализа условий. При запросе функционального сценария допускается указание параметров запроса, позволяет многократное использование функциональных сценариев.

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

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

Информация об авторе

Занят разработкой программного обеспечения с 1987 года. Начиная с 1998 года опубликовал более 50 технических статей в специализированных изданиях. С 2001 года разрабатывает архитектурные решения и инструментальные средства для управления содержанием (Content Management, CMF, ECM).

Red Graphic Systems представила специализированный язык для разработчиков CMS

Red Graphic Systems представляет спецификацию универсального языка для разработчиков систем управления контентом XML Sapiens.

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

Язык XML Sapiens описывает концепцию управления контентом c разделением данных, представления и функциональности, что позволяет создавать новые интерфейсы сайтов, не изменяя программный код CMS.

Для поддержки XML Sapiens открыт проект XMLSapiens.org, где помимо спецификации представлен код ядра XML Sapiens на различных программных языках, а также CMS с открытым кодом SAPID. Сайт содержит сервис Works Gallery, который позволит разработчикам свободно обмениваться функциональными решениями для интерфейсов сайтов.

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

Спецификация XML Sapiens представлена на английском и русском языках.

XML Sapiens

Материал из Seo Wiki — Поисковая Оптимизация и Программирование

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

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

Язык наследует стиль синтаксиса открытых стандартов XSLT, XInclude, XEXPR. Для практического использования XML Sapiens потребуется процессор языка. В настоящий момент доступна для свободной загрузки версия процессора для языка PHP.

Содержание

Как устроен XML Sapiens

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

XML Sapiens и данные

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

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

XML документ типа поля, как и в случае набора полей, может содержать описания типа для различных состояний интерфейса. Если в системе определены состояния «администрирование» и «доставка содержания», то в первом случае данные могут быть представлены в форме запроса содержания, во втором «как есть».

XML Sapiens и функциональность

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

Файл описания функционального алгоритма (DDC) содержит инструкции анализа условий, аналогично XSLT. Синтаксис DDC также позволяет ссылаться на приложение CMS, которое, согласно переданным параметрам, возвращает поток данных для дальнейшего анализа условий.

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

XML-Sapiens — орудие разделения функциональности сайта и программного ядра

Что ж, с радостью отвечу на любые вопросы, связанные с Sapid. Хочу только подчеркнуть:
Весь проект XML Sapiens рассчитан на разработчиков, но то, что они будут предлагать свои функциональные решения и оценивать чужие. Предполагается, что создание такого коммьюнити сможет облегчить жизнь разработчикам CMS и сделать ее интереснее.
Мне, как разработчику Sapid и Диме Шейко, как автору идеи XML Sapiens затруднительно оценить жизнеспособность подобного проекта, поэтому будем рады любой критике и любой поддержке.

Все, что касается XML Sapiens (спецификация и т.п.) можно скачать с офф. сайта XML Sapiens

C уважением и надеждами,
Mephius
==========
Sheiko пишет:

Цитата:

Относительно проекта SAPID следует добавить следующее

Вы можете принять участие в разработке CMS SAPID присоединившись к проекту http://sourceforge.net/projects/sapid/

Замечания об ошибкахhttp://sourceforge.net/tracker/?at > Запросы на техническую поддержкуhttp://sourceforge.net/tracker/?at > Архив «заплаток»http://sourceforge.net/tracker/?at > Запросы на разработку новых возможностейhttp://sourceforge.net/tracker/?at > Публичная документацияhttp://sourceforge.net/docman/?group_ > Список рассылки http://lists.sourceforge.net/lists/listinfo/sapid-community

Ныне в тестировании SAP > Документация к ней: http://prdownloads.sourceforge.net/sapid/readme12b4.ru.pdf?download

Всего записей: 7 | Зарегистр. 11-10-2004 | Отправлено: 13:53 11-10-2004 | Исправлено: Antuan, 00:41 18-01-2005
fathersGrave

Advanced Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору А скоро будет б/м подробный таториал по созданию DDC под SAPID?
Всего записей: 716 | Зарегистр. 21-04-2003 | Отправлено: 12:14 12-10-2004
Mephius

Newbie

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору вопрос, конечно интересный.
Хотелось бы узнать в каком виде нужен ман. Просто структура DDC достаточно подробно описанa в спецификации.
Попробуйте описать, как бы вы хотели видеть хорошее руководство — на какие моменты больше сделать акценты, что немного опустить.

На самом деле, DDC представляет собой алгоритм, описанный в синтаксисе XML Sapiens.
Рассмотрим, например, контейнер построения новостной ленты:

Код:

Max Baryshnikov
mb@rg.by
www.redgraphic.com

Infochannel. CMS SAPID.

Сначала идет шапка с описанием и авторством:

Код:

Max Baryshnikov
mb@rg.by
www.redgraphic.com

Infochannel. CMS SAPID.

Открываем блок условий:

Код:

Открываем условие (выполняется всегда, потому, что в атрибуте exp указано выражение, всегда принимающее значение true):

Код:

Далее (внимание!) открываем цикл, в котором будет перебираться массив значений, который вернет функция get_news (описанная в автоматически включаемом файле usr/extensions/get_news.inc.php); массив двухмерный, логически предстваляет собой таблицу, т.е. в тело цикла будет передаваться строка с атрибутмаи текущей новости (дата, тело новости. )

Код:

Далее идут уже рассмотренные нами теги, открывающие вложенный блок условий, просмотр которых будет выполняться в цикле:

Описание того, что будет выводить DDC. В коде стоят указатели на элементы перебираемого массива: пример указателя — будет указывать на элемент массива массив[текущая строка][‘date’]:


Потом закрытие всего, что мы пооткрывали ранее:

Вот, в прнципе, и все по этому контейнеру.
Примерно такой формат мануала подойдет?

Всего записей: 7 | Зарегистр. 11-10-2004 | Отправлено: 12:43 12-10-2004
fathersGrave

Advanced Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Да с таким маном и в огонь, и в воду. А можно как-то в поставляемые DDC комментарии проставить? Еще интересуют PHP-шные бэкфункции:
о get_news.inc.php подключается именно после вызова select=»get_news()» ? И получается по файлу на функцию..
о в .inc.php вроде нужно использовать какой-то уже sapid’овский api?

Btw, на когда планируется версия с БД ?
Уфф.. ладно, кажется, я полностью проникся X-Sapiens’ом 8)

Всего записей: 716 | Зарегистр. 21-04-2003 | Отправлено: 13:19 12-10-2004 | Исправлено: fathersGrave, 13:22 12-10-2004
Mephius

Newbie

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:

get_news.inc.php подключается именно после вызова select=»get_news()» ? И получается по файлу на функцию..

не после вызова, а перед. т.е. строка

Код:

интерпретируется примерно вот так (если так понятнее):

Код:

$value) <
.
>
?>

Действительно получается по файлу на функцию, но чем это плохо? Если бы все функции я складывал в один файл, то при обращении к любой из них мне нужно было бы подключать все, что, в общем, не так уж и страшно, но все же.
sapid’овский api в них использовать отнюдь не обязательно, важно просто вернуть массив заданного формата.
можно использовать переменные окружения, генерируемые системой и функции дебага.
Вот простенькая функция построения меню:

Код:

map as $item) <
if ($item[«LEVEL»]!=0 and !$item[«MASK»] and ($level?($item[«LEVEL»]==$level):true)) <
$cnt++;
$stream[$cnt]=$item;
if($env[«page»][» ]=0;
for ($i=0; $i

в $tree хранится информации о структуре поднятая при инициализации из xml; $env — переменные окружения;
Поставьте в начале этой функции

Код:

d($tree); // отобразить массив $tree
d($env); // отобразить массив переменный окружения $env

и вы увидите, чем вы располагаете на данный момент.
Повторюь: использовать системный api вовсе не обязательно.

Версия на БД планируется тогда, когда текущая версия станет stable.
В принципе тогда будет достаточно просто переписать интерфейсы парсера к данным и все.

Цитата:

Уфф.. ладно, кажется, я полностью проникся X-Sapiens’ом 8)
Всего записей: 7 | Зарегистр. 11-10-2004 | Отправлено: 15:26 12-10-2004
fathersGrave

Advanced Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:

не после вызова, а перед

Ну это я понимаю Просто некорректно выразился. Подключает «после того, как находит» всю инструкцию.

Цитата:

Действительно получается по файлу на функцию, но чем это плохо?

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

Цитата:

sapid’овский api в них использовать отнюдь не обязательно, важно просто вернуть массив заданного формата.
можно использовать переменные окружения, генерируемые системой и функции дебага.

А Вам не кажется, что api все-таки иногда полезен в плане, хоть и не строгого, но соблюдения системных стандартов. Конечно, тут основным стандартом является X-Sapiens, но все же..
Я мало смотрел код, но переменные окружения, естественно, бросились в глаза. Просто хотел увидеть их описание в мане

Всего записей: 716 | Зарегистр. 21-04-2003 | Отправлено: 21:35 12-10-2004
Sheiko

Newbie

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Полагаю, имеет смысл добавить от себя некоторые соображения в пользу технологии внеобыденного характера:

1) Вы желаете полноценную интеграцию проектов, коммуникацию интернет приложений и приложений Интранет/ЛВС? На стороне XML Sapiens-ориентированной CMS достаточно разместить вызовы удаленных процедур XML RPC (http://www.xmlrpc.com/, http://www.php.net/manual/en/ref.xmlrpc.php) или же SOAP (http://www.w3.org/TR/SOAP, http://pear.php.net/package-info.php?pac вывод в массив перечня узлов формата array( id -> array( field -> value, f2 -> v2, ..), ..). Ни что нам более не мешает в объединении сетей

2) От вас требуют промо-сайт на Flash с некоторым числом редактируемых страниц? Создаете простейший DDC в SAPID для вывода XML-контейнеров содержания страниц. Открываете новую сцену во флеш и создаете там текстовое поле, назначаете ему имя. Далее пишем в action script
var doc = new XML(); // XML object id created.
doc.load(«http://yoursite_on_sapid.com/folder/»);

if(node.firstChild!=null) <
node=node.firstChild;
while(node!=null) <
if(node.nodeName!=null && node.nodeName!=’title’) <
name_of_template_ddc_tag=node.firstChild.nodeValue;
content_of_your_template_tag=node.firstChild.nodeValue;
// Прикрепляем содержание нужно тега к текстовому полю
>
>

В результате Flash-сайт с вполне управляемым содержанием

Всего записей: 13 | Зарегистр. 07-10-2004 | Отправлено: 11:57 13-10-2004
Sheiko

Newbie

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Вопрос:

Я еще не успел разобраться с XML Sapiens в целом и с SAPIDом в
частности, так что если мои вопросы окажутся глупыми или избыточными,
не серчайте, пожалуйста )

Пошарился я в area51 и могу описать увиденное, как cms для создания
общей структуры сайта + блочного построения каждой секции.

Если это так и есть на самом деле, то на след. вопросы наверное можно
не отвечать

Вопросы меня интересуют такие, наверное больше относящиеся к cmf:

1) Насколько XML Sapiens и/или SAPID могли бы помочь в создании cms,
которая бы позволяла юзерам редактировать сущности в бд. Классы
сущностей желательно было бы описывать на чем-нибудь типа xml.

2) Насколько XML Sapiens и/или SAPID могли бы помочь в создании
механизма разруливания прав в cms, где есть такие актеры:

— admin — полный контроль над user-management’ом, полный контроль над
сущностями всех классов.

— semi-admin — права на редактирование ограничены несколькими классами
сущностей. Изменения сущностей некоторых из этих классов должны
проходить разрешение у adminа.

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

1) Что касается SAPID, действительно речь о простой CMS для небольших сайтов, особенность которой — отделенная функциональность, управляемая специализированным языком

2) XML Sapiens — язык разметки интерфейсов сайтов. Мы рекомендуем алгоритмы разделения функциональности от представления и данных, но документную модель оставляем на усмотрение прочих технологий и конкретного разработчика. Впрочем, я могу привести в пример документную структуру Site Sapiens (www.sitesapiens.ru), где взаимосвязи документов в СУБД организуются в карту многоаспектных отношений (развитый граф). Однако независимо, по какой выборке вычислен идентификатор документа для XML Sapiens на вход приходит этот идентификатор и соответствующий ему шаблон представления и далее собираются должные DDC, SDC и QC

3) Управление пользователями отдельная тема, опять же несоприкасающаяся с XML Sapiens непосредственно. В том же Site Sapiens мы применили мат.модель графа для объектов пользователей. Т.е. при инициализации системы в момент запроса пользователем конкретного документа производиться выборка в СУБД массива прав этого пользователя, исходя из атрибутов его объекта, роли, суммы прав групп в которых он участвует

Всего записей: 13 | Зарегистр. 07-10-2004 | Отправлено: 13:33 15-10-2004
Mephius

Newbie

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Залил на http://demo.xmlsapiens.org новую версию (галерея, гостевая, голосовалки и т.п.). Пока это SAPID 1.09 — BETA.
Всего записей: 7 | Зарегистр. 11-10-2004 | Отправлено: 13:58 09-11-2004
fathersGrave

Advanced Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Супер, но я так и не врубился, что из себя представляет галерея. Похоже, что сейчас это просто страница.
Всего записей: 716 | Зарегистр. 21-04-2003 | Отправлено: 16:59 09-11-2004
chAlx

Advanced Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Mephius
А можно для начала пояснить обывателю, как установка просходит? Я скачал sapid110.tar.gz (как я понял, последний релиз) и поставил как смог. Т.е. выставил права на директории, запустил инсталл, поменял атрибуты ещё полсотни запрошенных файлов — что-то получилось. Ещё пришлось в .htaccess прописать «php_value include_path /web/sapid/lang», иначе ничего не работало. Теперь в корне демо-сайт появляется, но никакие средства управления не найти.

Код:

$env[«http_path»]=$http_path=»http://www.host.ru/sapid/»;
$admin_login=»login»;
$admin_password=»pass»;
$admin_path=»a51″;
$MODREWRITE=»enabled»;

Пробую www.host.ru/sapid/a51/ и www.host.ru/sapid/area51/ — вылезает 404. (Если создать ./a51/ вылезает — 403.)
В корне только это (плюс тексты):
/web/sapid/etc/
/web/sapid/kernel/
/web/sapid/lang/
/web/sapid/log/
/web/sapid/usr/
/web/sapid/index.php
/web/sapid/preview_image.php

Как правильно и надёжно ставить?

Добавлено
И ещё есть орг.вопрос: по безопасности CMS в целом (на примере sapid, но не привязываясь к ней) здесь писать, или тему делать?

Добавлено
А то существующие темы какие-то дохлые..

Всего записей: 1687 | Зарегистр. 19-03-2003 | Отправлено: 17:07 23-11-2004
Mephius

Newbie

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Да, в 1.10 нашлась куча глюков. Признаю. Исправляю по мере обнаружения.
Как только скомпоную новый релиз — выложу.

А вообще более менее живые темы вот на этом форуме http://cmsobzor.ru/forum/index.php?s=a6a903e5b2134b2a6ac6e4128ffbb03f&showforum=29

Всего записей: 7 | Зарегистр. 11-10-2004 | Отправлено: 12:56 24-11-2004
chAlx

Advanced Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Mephius
Лежит там форум: наверно, движок форума не обновили, вот базу и хакнули..

А с САПИДом что теперь делать: ставить 1.09б или ждать следующего релиза?

Архитектура операционной системы

Под архитектурой операционной системы понимают структурную и функциональную организацию ОС на основе некоторой совокупности программных модулей. В состав ОС входят исполняемые и объектные модули стандартных для данной ОС форматов, программные модули специального формата (например, загрузчик ОС, драйверы ввода-вывода), конфигурационные файлы, файлы документации, модули справочной системы и т.д.

На архитектуру ранних операционных систем обращалось мало внимания: во-первых, ни у кого не было опыта в разработке больших программных систем, а во-вторых, проблема взаимозависимости и взаимодействия модулей недооценивалась. В подобных монолитных ОС почти все процедуры могли вызывать одна другую. Такое отсутствие структуры было несовместимо с расширением операционных систем. Первая версия ОС OS/360 была создана коллективом из 5000 человек за 5 лет и содержала более 1 млн строк кода. Разработанная несколько позже операционная система Mastics содержала к 1975 году уже 20 млн строк [17]. Стало ясно, что разработка таких систем должна вестись на основе модульного программирования.

Большинство современных ОС представляют собой хорошо структурированные модульные системы, способные к развитию, расширению и переносу на новые платформы. Какой-либо единой унифицированной архитектуры ОС не существует, но известны универсальные подходы к структурированию ОС. Принципиально важными универсальными подходами к разработке архитектуры ОС являются [5, 10, 13, 17]:

  • модульная организация;
  • функциональная избыточность;
  • функциональная избирательность;
  • параметрическая универсальность;
  • концепция многоуровневой иерархической вычислительной системы, по которой ОС представляется многослойной структурой;
  • разделение модулей на две группы по функциям: ядро – модули, выполняющие основные функции ОС, и модули, выполняющие вспомогательные функции ОС;
  • разделение модулей ОС на две группы по размещению в памяти вычислительной системы: резидентные, постоянно находящиеся в оперативной памяти, и транзитные, загружаемые в оперативную память только на время выполнения своих функций;
  • реализация двух режимов работы вычислительной системы: привилегированного режима (режима ядра – Kernel mode), или режима супервизора (supervisor mode), и пользовательского режима (user mode), или режима задачи (task mode);
  • ограничение функций ядра (а следовательно, и количества модулей ядра) до минимального количества необходимых самых важных функций.

Первые ОС разрабатывались как монолитные системы без четко выраженной структуры (рис. 1.2).

Для построения монолитной системы необходимо скомпилировать все отдельные процедуры, а затем связать их вместе в единый объектный файл с помощью компоновщика (примерами могут служить ранние версии ядра UNIX или Novell NetWare). Каждая процедура видит любую другую процедуру (в отличие от структуры, содержащей модули, в которой большая часть информации является локальной для модуля, и процедуры модуля можно вызвать только через специально определенные точки входа).

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

Рис. 1.2. Монолитная архитектура


Такая организация ОС предполагает следующую структуру [13]:

  • главная программа, которая вызывает требуемые сервисные процедуры;
  • набор сервисных процедур, реализующих системные вызовы;
  • набор утилит, обслуживающих сервисные процедуры.

В этой модели для каждого системного вызова имеется одна сервисная процедура. Утилиты выполняют функции, которые нужны нескольким сервисным процедурам. Это деление процедур на три слоя показано на рис. 1.3.

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

Рис. 1.3. Структурированная архитектура

Особый класс функций ядра служит для поддержки приложений, создавая для них так называемую прикладную программную среду. Приложения могут обращаться к ядру с запросами – системными вызовами – для выполнения тех или иных действий, например, открытие и чтение файла, получение системного времени, вывода информации на дисплей и т.д. Функции ядра, которые могут вызываться приложениями, образуют интерфейс прикладного программирования – API (Application Programming Interface).

Для обеспечения высокой скорости работы ОС модули ядра (по крайней мере, большая их часть) являются резидентными и работают в привилегированном режиме (Kernel mode). Этот режим, во-первых, должен обезопасить работу самой ОС от вмешательства приложений, и, во-вторых, должен обеспечить возможность работы модулей ядра с полным набором машинных инструкций, позволяющих собственно ядру выполнять управление ресурсами компьютера, в частности, переключение процессора с задачи на задачу, управлением устройствами ввода-вывода, распределением и защитой памяти и др.

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

Вспомогательные модули обычно подразделяются на группы:

  • утилиты – программы, выполняющие отдельные задачи управления и сопровождения вычислительной системы;
  • системные обрабатывающие программы – текстовые и графические редакторы (Paint, Imaging в Windows 2000), компиляторы и др.;
  • программы предоставления пользователю дополнительных услуг (специальный вариант пользовательского интерфейса, калькулятор, игры, средства мультимедиа Windows 2000);
  • библиотеки процедур различного назначения, упрощения разработки приложений, например, библиотека функций ввода-вывода, библиотека математических функций и т.п.

Эти модули ОС оформляются как обычные приложения, обращаются к функциям ядра посредством системных вызовов и выполняются в пользовательском режиме (user mode). В этом режиме запрещается выполнение некоторых команд, которые связаны с функциями ядра ОС (управление ресурсами, распределение и защита памяти и т.п.).

В концепции многоуровневой (многослойной) иерархической машины структура ОС также представляется рядом слоев. При такой организации каждый слой обслуживает вышележащий слой, выполняя для него некоторый набор функций, которые образуют межслойный интерфейс. На основе этих функций следующий верхний по иерархии слой строит свои функции – более сложные и более мощные и т.д. Такая организация системы существенно упрощает ее разработку, т.к. позволяет сначала «сверху вниз» определить функции слоев и межслойные интерфейсы, а при детальной реализации, двигаясь «снизу вверх», – наращивать мощность функции слоев. Кроме того, модули каждого слоя можно изменять без необходимости изменений в других слоях (но не меняя межслойных интерфейсов!).

Многослойная структура ядра ОС может быть представлена, например, вариантом, показанным на рис. 1.4.

Рис. 1.4. Многослойная структура ОС

В данной схеме выделены следующие слои.

  1. Средства аппаратной поддержки ОС. Значительная часть функций ОС может выполняться аппаратными средствами [10]. Чисто программные ОС сейчас не существуют. Как правило, в современных системах всегда есть средства аппаратной поддержки ОС, которые прямо участвуют в организации вычислительных процессов. К ним относятся: система прерываний, средства поддержки привилегированного режима, средства поддержки виртуальной памяти, системный таймер, средства переключения контекстов процессов (информация о состоянии процесса в момент его приостановки), средства защиты памяти и др.
  2. Машинно-зависимые модули ОС. Этот слой образует модули, в которых отражается специфика аппаратной платформы компьютера. Назначение этого слоя – «экранирование» вышележащих слоев ОС от особенностей аппаратуры (например, Windows 2000 – это слой HAL (Hardware Abstraction Layer), уровень аппаратных абстракций).
  3. Базовые механизмы ядра. Этот слой модулей выполняет наиболее примитивные операции ядра: программное переключение контекстов процессов, диспетчерскую прерываний, перемещение страниц между основной памятью и диском и т.п. Модули этого слоя не принимают решений о распределении ресурсов, а только обрабатывают решения, принятые модулями вышележащих уровней. Поэтому их часто называют исполнительными механизмами для модулей верхних слоев ОС.
  4. Менеджеры ресурсов. Модули этого слоя выполняют стратегические задачи по управлению ресурсами вычислительной системы. Это менеджеры (диспетчеры) процессов ввода-вывода, оперативной памяти и файловой системы. Каждый менеджер ведет учет свободных и используемых ресурсов и планирует их распределение в соответствии запросами приложений.
  5. Интерфейс системных вызовов. Это верхний слой ядра ОС, взаимодействующий с приложениями и системными утилитами, он образует прикладной программный интерфейс ОС. Функции API, обслуживающие системные вызовы, предоставляют доступ к ресурсам системы в удобной компактной форме, без указания деталей их физического расположения.

Повышение устойчивости ОС обеспечивается переходом ядра в привилегированный режим. При этом происходит некоторое замедление выполнения системных вызовов. Системный вызов привилегированного ядра инициирует переключение процессора из пользовательского режима в привилегированный, а при возврате к приложению – обратное переключение. За счет этого возникает дополнительная задержка в обработке системного вызова (рис. 1.5). Однако такое решение стало классическим и используется во многих ОС (UNIX, VAX, VMS, IBM OS/390, OS/2 и др.).

Рис. 1.5. Обработка системного вызова

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

Суть этой архитектуры состоит в следующем. В привилегированном режиме остается работать только очень небольшая часть ОС, называемая микроядром. Микроядро защищено от остальных частей ОС и приложений. В его состав входят машинно-зависимые модули, а также модули, выполняющие базовые механизмы обычного ядра. Все остальные более высокоуровневые функции ядра оформляются как модули, работающие в пользовательском режиме. Так, менеджеры ресурсов, являющиеся неотъемлемой частью обычного ядра, становятся «периферийными» модулями, работающими в пользовательском режиме. Таким образом, в архитектуре с микроядром традиционное расположение уровней по вертикали заменяется горизонтальным. Это можно представить, как показано на рис. 1.6.

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

Рис. 1.6. Переход к микроядерной архитектуре

Схематично механизм обращений к функциям ОС, оформленным в виде серверов, выглядит, как показано на рис. 1.7.

Рис. 1.7. Клиент-серверная архитектура

Схема смены режимов при выполнении системного вызова в ОС с микроядерной архитектурой выглядит, как показано на рис. 1.8. Из рисунка ясно, что выполнение системного вызова сопровождается четырьмя переключениями режимов (4 t), в то время как в классической архитектуре – двумя. Следовательно, производительность ОС с микроядерной архитектурой при прочих равных условиях будет ниже, чем у ОС с классическим ядром.

Рис. 1.8. Обработка системного вызова в микроядерной архитектуре

В то же время признаны следующие достоинства микроядерной архитектуры [17]:

  • единообразные интерфейсы;
  • простота расширяемости;
  • высокая гибкость;
  • возможность переносимости;
  • высокая надежность;
  • поддержка распределенных систем;
  • поддержка объектно-ориентированных ОС.

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

Может быть, это покажется парадоксальным, но есть и такой подход к микроядерной ОС, как уменьшение микроядра.

Для возможности представления о размерах микроядер операционных систем в ряде источников [17] приводятся такие данные:

  • типичное микроядро первого поколения – 300 Кбайт кода и 140 интерфейсов системных вызовов;
  • микроядро ОС L4 (второе поколение) – 12 Кбайт кода и 7 интерфейсов системных вызовов.

В современных операционных системах различают следующие виды ядер.

  1. Наноядро (НЯ). Крайне упрощённое и минимальное ядро, выполняет лишь одну задачу – обработку аппаратных прерываний, генерируемых устройствами компьютера. После обработки посылает информацию о результатах обработки вышележащему программному обеспечению. НЯ используются для виртуализации аппаратного обеспечения реальных компьютеров или для реализации механизма гипервизора.
  2. Микроядро (МЯ) предоставляет только элементарные функции управления процессами и минимальный набор абстракций для работы с оборудованием. Большая часть работы осуществляется с помощью специальных пользовательских процессов, называемых сервисами. В микроядерной операционной системе можно, не прерывая ее работы, загружать и выгружать новые драйверы, файловые системы и т. д. Микроядерными являются ядра ОС Minix и GNU Hurd и ядро систем семейства BSD. Классическим примером микроядерной системы является Symbian OS. Это пример распространенной и отработанной микроядерной (a начиная c версии Symbian OS v8.1, и наноядерной) операционной системы.
  3. Экзоядро (ЭЯ) предоставляет лишь набор сервисов для взаимодействия между приложениями, а также необходимый минимум функций, связанных с защитой: выделение и высвобождение ресурсов, контроль прав доступа и т. д. ЭЯ не занимается предоставлением абстракций для физических ресурсов – эти функции выносятся в библиотеку пользовательского уровня (так называемую libOS). В отличие от микроядра ОС, базирующиеся на ЭЯ, обеспечивают большую эффективность за счет отсутствия необходимости в переключении между процессами при каждом обращении к оборудованию.
  4. Монолитное ядро (МнЯ) предоставляет широкий набор абстракций оборудования. Все части ядра работают в одном адресном пространстве. МнЯ требуют перекомпиляции при изменении состава оборудования. Компоненты операционной системы являются не самостоятельными модулями, а составными частями одной программы. МнЯ более производительно, чем микроядро, поскольку работает как один большой процесс. МнЯ является большинство Unix-систем и Linux. Монолитность ядер усложняет отладку, понимание кода ядра, добавление новых функций и возможностей, удаление ненужного, унаследованного от предыдущих версий кода. «Разбухание» кода монолитных ядер также повышает требования к объёму оперативной памяти.
  5. Модульное ядро (Мод. Я) – современная, усовершенствованная модификация архитектуры МЯ. В отличие от «классических» МнЯ, модульные ядра не требуют полной перекомпиляции ядра при изменении состава аппаратного обеспечения компьютера. Вместо этого они предоставляют тот или иной механизм подгрузки модулей, поддерживающих то или иное аппаратное обеспечение (например, драйверов). Подгрузка модулей может быть как динамической, так и статической (при перезагрузке ОС после переконфигурирования системы). Мод. Я удобнее для разработки, чем традиционные монолитные ядра. Они предоставляют программный интерфейс (API) для связывания модулей с ядром, для обеспечения динамической подгрузки и выгрузки модулей. Не все части ядра могут быть сделаны модулями. Некоторые части ядра всегда обязаны присутствовать в оперативной памяти и должны быть жёстко «вшиты» в ядро.
  6. Гибридное ядро (ГЯ) – модифицированные микроядра, позволяющие для ускорения работы запускать «несущественные» части в пространстве ядра. Имеют «гибридные» достоинства и недостатки. Примером смешанного подхода может служить возможность запуска операционной системы с монолитным ядром под управлением микроядра. Так устроены 4.4BSD и MkLinux, основанные на микроядре Mach. Микроядро обеспечивает управление виртуальной памятью и работу низкоуровневых драйверов. Все остальные функции, в том числе взаимодействие с прикладными программами, осуществляются монолитным ядром. Данный подход сформировался в результате попыток использовать преимущества микроядерной архитектуры, сохраняя по возможности хорошо отлаженный код монолитного ядра.
  7. Наиболее тесно элементы микроядерной архитектуры и элементы монолитного ядра переплетены в ядре Windows NT. Хотя Windows NT часто называют микроядерной операционной системой, это не совсем так. Микроядро NT слишком велико (более 1 Мбайт), чтобы носить приставку «микро». Компоненты ядра Windows NT располагаются в вытесняемой памяти и взаимодействуют друг с другом путем передачи сообщений, как и положено в микроядерных операционных системах. В то же время все компоненты ядра работают в одном адресном пространстве и активно используют общие структуры данных, что свойственно операционным системам с монолитным ядром.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Учись учиться, не учась! 10369 — | 7883 — или читать все.

Ядро архитектуры

Ядро архитектуры (программное ядро) — это определенный принцип построения программного обеспечения и реализации повторного использования. До сих пор обобщенных определений дано не было, но как правило, об архитектуре ядра говорят применительно к операционным системам. Со временем, выделение так называемого ядра стали осуществлять в крупных программных комплексах. Другое возможное использование этого термина применяют когда разрабатываются некие независимые библиотеки программ (SDK), так например, говорят о графических или физических движках.

Содержание

Ядро — как библиотека функций [ править ]

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

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

Надежность ядра [ править ]

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

Мы можем ввести два термина:

  1. Безболезненность для окружения. Метод изменения содержимого программного фонда называется безболезненным для окружения, если его применение не влечет за собой необходимости редактирования существовавших ранее текстов программ и других первичных материалов.
  2. Безболезненность для работоспособности. Метод изменения содержимого программного фонда называется безболезненным для работоспособности, если его применение не может нарушить работоспособность отлаженных ранее конкретных конфигураций программ и других первичных материалов. Необходимое условие безболезненности для работоспособности – безболезненность для окружения.

Таким образом, выделенные и оттестированные функции составляют ядро, и его использование является безболезненным как для окружения, так и для работоспособности.

Ядро — это не только библиотека функций [ править ]

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


Так например, примеры хорошо реализованных ядер можно найти почти исключительно только в реализации известных операционных систем (см. w:en:Kernel (computing)), или на уровне «железа» в реализации работы процессора (см. w:Микроархитектура). А многие т.н. движки, необоснованно называют ядром того или иного программного комплекса. Они, как правило, не выполняют никакой архитектурной роли, за исключением библиотеки функций, и могут рассматриваться лишь как SDK для разработки ПО.

Архитектура ядра с кольцами защиты [ править ]

Здесь мы рассмотрим понятие кольца защиты, и её применение к современной трёхуровневой архитектуре.

Кольца защиты обеспечивают информационную безопасность и отказоустойчивость на уровне аппаратного разделения системного и пользовательского уровней привилегий. Структуру привилегий можно изобразить в виде нескольких концентрических кругов. В этом случае системный режим (нулевое кольцо), обеспечивающий максимальный доступ к ресурсам, является внутренним кругом, тогда как режим пользователя с ограниченным доступом — внешним. Традиционно семейство микропроцессоров x86, начиная с x386 обеспечивает четыре кольца защиты.

На практике процессор программируется в защищенном режиме определенным образом. Для каждой локальной задачи выделяется свое локальное адресное пространство (память). В каждый момент времени в определенном регистре процессора может быть указатель только на одну из задач. Поэтому задача работает только в своем адресном пространстве и не может физически иметь доступ к другим локальным задачам. Для смены задач осуществляется т.н. переключение задач. Каждая задача имеет т.н. уровень привилегий дискриптора (DPL). Этот уровень как раз и указывает в каком кольце находится задача. Основные правила защиты по привилегиям сводятся к следующим:

  1. Данные из задачи (программы) с некоторым уровнем привилегий могут быть получены только программой того же или более внутреннего уровня
  2. Программа с некоторым уровнем привилегий может быть вызвана только программой того же или более внешнего уровня, причем вызов программы другого уровня должен осуществляться не непосредственно, а через шлюз вызова
  3. Все команды, управляющие механизмами защиты могут использоваться только в программах нулевого уровня, что исключает вмешательство в организацию операционной системы со стороны прикладных программ

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

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

Таким образом, такого рода ядро реализует:

  1. так называемый каркас архитектуры для управления ходом выполнения клиентских приложений (об этом мы поговорим в следующей статье каркас архитектуры)
  2. внутри себя реализует библиотеку функций (внутренний SDK — для разработчика ядра)
  3. часть функций, как правило в определенной «обертке» (API), из своей библиотеки, через механизм защиты (например, путем callback-функций) предоставляет клиентским приложениям

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

И этих слоев как минимум два, т.н. клиент-серверная архитектура. Так сложилось, что для работы с данными повсеместно используются реляционные базы данных и, как правило, в серьезных приложениях используют или Oracle или MS SQL. Вся работа с данными преимущественно происходит посредством работы на языке SQL. Более того, как правило в хорошо разработанной архитектуре, запрещается какое-либо прямое обращение к базе данных, и вся работа с базой данных ведется посредством вызова только хранимых процедур, а уже в них на SQL так или иначе ведется работа с данными. Поэтому слой базы данных уже традиционно выделен и фактически отделен. Единственно плохо когда некоторые архитектуры, пользуясь возможностями языков программирования, прямо обращаются в серверу базы данных. В тоже время программировать пользовательский интерфейс на языке SQL невозможно. Для этого используют новейшие объектно-ориентированные языки.

Но можно пойти и еще дальше, пример более общей структуры представляет трёхуровневая архитектура. В ней также отделен сервер базы данных, но аналогично технологии MVC происходит разделение бизнес-логики и визуализации. Мы уже говорили о проблемах реализации классического MVC, но сам принцип разделения остается важным, хотя и может быть реализован более качественно. Но если в технологии MVC разделение касалось на уровне одного класса с его подклассами, то в трёхуровневой архитектуре речь идет о выделении всей визуализации в отдельную самостоятельную программу, а выделению отдельной программы (сервера) бизнес-логики. Понятно, что такое физическое разделение можно осуществить только тогда, когда логически в программе строго все было уже разделено или согласно технологии MVC, или другими более современными способами.

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

Что такое XML Sapiens

В 1995 году компания Vignette представила на рынке первую™ коммерческую систему класса™ CMS (систем™ управления контентом). С тех пор число коммерческих CMS неустанно растет™ и ныне сам термин™ CMS прижился на рынке и, как правило, не требует расшифровки. За последние годы было утверждено множество открытых стандартов, позволяющих структурировать информацию на сайтах™, отделить ее от дизайна, но, по-прежнему, большинство CMS не следует им. Так уже много лет существует стандарт XSLT, позволяющий формирование документов из разделенных источников: XML-файла со структурированным содержанием документа и XSL-шаблона с описанием того, как документ будет представлен на сайте.

Причем™ само формирование документа, может происходить на стороне клиента. Достаточно передать браузеру XML-структуру данных™, содержащую ссылку™ на XSL-шаблон™ и браузер сам «нарисует» страницу в том виде, как это предполагалось дизайнерами. Содержание каждой™ страницы сайта различается, однако™ форма подачи™ этого содержания, обычно™, ограниченна небольшим числом™ шаблонов. Таким образом, XSLT позволяет нам одиножды написанный шаблон™ представления данных™ на сайте использовать многократно. Казалось бы, вот она идеальная технология для CMS. Однако™ повсеместное применение данной™ технологии сдерживает ряд факторов. Из них психологическая инерция — не главенствующий фактор™. Описание функциональности сайта с помощью XSLT — весьма™ трудоемкая задача™. Кроме того, XSL-шаблон™ слишком зависим от XML-документа с данными, что ограничивает гибкость решений на основе™ данной™ технологии.

Таким образом, XSLT представляет собой концептуально безупречное, но на практике трудоемкое решение. Данное™ обстоятельство побуждает разработчиков искать™ новые решения, включающие преимущества утвержденных открытых стандартов и, в то же время, относительно удобные в использовании. Одно из таких решений – декларативный язык XML Sapiens (www.xmlsapiens.org).

Как устроен XML Sapiens

Так же как и XSLT, с каждым™ документом сайта должен™ быть связан™ определенный шаблон™. Шаблон™ может содержать любой код представления (например, HTML) и инструкции XML Sapiens. В шаблон™ могут быть, включены несколько файлов™. Для этого используется инструкция sapi:include, близкая к аналогу в открытом стандарте xInclude.

Прочие™ инструкции XML Sapiens позволяют доставить в документ содержание и функциональные блоки.

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

XML Sapiens и данные™

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

Набор полей содержит инструкции доставки данных™. Эти инструкции связывают указанный идентификатор данных™ с типом поля, описанным во внешнем XML-документе.

XML документ типа поля, как и в случае™ набора™ полей, может содержать описания типа для различных состояний интерфейса. Если в системе определены состояния «администрирование» и «доставка содержания», то в первом™ случае™ данные™ могут быть представлены в форме запроса содержания, во втором™ «как есть».

XML Sapiens и функциональность

В шаблоне страницы также могут содержаться инструкции запроса сценария функциональности. Алгоритм этого сценария описан™ в заданном XML-файле.

Документ описания функционального алгоритма (DDC) содержит инструкции анализа условий, аналогично XSLT. Синтаксис DDC также позволяет ссылаться на приложения CMS, которые, согласно переданным параметрам, возвращают потоки™ данных™ для дальнейшего анализа условий.

value1
value2

Records not found
CMS-application error

При запросе функционального сценария допускается указание параметров запроса, позволяет многократное использование функциональных сценариев.

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

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

Ядро архитектуры

Ядро архитектуры (программное ядро) — это определенный принцип построения программного обеспечения и реализации повторного использования. До сих пор обобщенных определений дано не было, но как правило, об архитектуре ядра говорят применительно к операционным системам. Со временем, выделение так называемого ядра стали осуществлять в крупных программных комплексах. Другое возможное использование этого термина применяют когда разрабатываются некие независимые библиотеки программ (SDK), так например, говорят о графических или физических движках.

Содержание

Ядро — как библиотека функций [ править ]

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

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

Надежность ядра [ править ]

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

Мы можем ввести два термина:

  1. Безболезненность для окружения. Метод изменения содержимого программного фонда называется безболезненным для окружения, если его применение не влечет за собой необходимости редактирования существовавших ранее текстов программ и других первичных материалов.
  2. Безболезненность для работоспособности. Метод изменения содержимого программного фонда называется безболезненным для работоспособности, если его применение не может нарушить работоспособность отлаженных ранее конкретных конфигураций программ и других первичных материалов. Необходимое условие безболезненности для работоспособности – безболезненность для окружения.

Таким образом, выделенные и оттестированные функции составляют ядро, и его использование является безболезненным как для окружения, так и для работоспособности.

Ядро — это не только библиотека функций [ править ]

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

Так например, примеры хорошо реализованных ядер можно найти почти исключительно только в реализации известных операционных систем (см. w:en:Kernel (computing)), или на уровне «железа» в реализации работы процессора (см. w:Микроархитектура). А многие т.н. движки, необоснованно называют ядром того или иного программного комплекса. Они, как правило, не выполняют никакой архитектурной роли, за исключением библиотеки функций, и могут рассматриваться лишь как SDK для разработки ПО.

Архитектура ядра с кольцами защиты [ править ]

Здесь мы рассмотрим понятие кольца защиты, и её применение к современной трёхуровневой архитектуре.

Кольца защиты обеспечивают информационную безопасность и отказоустойчивость на уровне аппаратного разделения системного и пользовательского уровней привилегий. Структуру привилегий можно изобразить в виде нескольких концентрических кругов. В этом случае системный режим (нулевое кольцо), обеспечивающий максимальный доступ к ресурсам, является внутренним кругом, тогда как режим пользователя с ограниченным доступом — внешним. Традиционно семейство микропроцессоров x86, начиная с x386 обеспечивает четыре кольца защиты.

На практике процессор программируется в защищенном режиме определенным образом. Для каждой локальной задачи выделяется свое локальное адресное пространство (память). В каждый момент времени в определенном регистре процессора может быть указатель только на одну из задач. Поэтому задача работает только в своем адресном пространстве и не может физически иметь доступ к другим локальным задачам. Для смены задач осуществляется т.н. переключение задач. Каждая задача имеет т.н. уровень привилегий дискриптора (DPL). Этот уровень как раз и указывает в каком кольце находится задача. Основные правила защиты по привилегиям сводятся к следующим:

  1. Данные из задачи (программы) с некоторым уровнем привилегий могут быть получены только программой того же или более внутреннего уровня
  2. Программа с некоторым уровнем привилегий может быть вызвана только программой того же или более внешнего уровня, причем вызов программы другого уровня должен осуществляться не непосредственно, а через шлюз вызова
  3. Все команды, управляющие механизмами защиты могут использоваться только в программах нулевого уровня, что исключает вмешательство в организацию операционной системы со стороны прикладных программ

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


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

Таким образом, такого рода ядро реализует:

  1. так называемый каркас архитектуры для управления ходом выполнения клиентских приложений (об этом мы поговорим в следующей статье каркас архитектуры)
  2. внутри себя реализует библиотеку функций (внутренний SDK — для разработчика ядра)
  3. часть функций, как правило в определенной «обертке» (API), из своей библиотеки, через механизм защиты (например, путем callback-функций) предоставляет клиентским приложениям

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

И этих слоев как минимум два, т.н. клиент-серверная архитектура. Так сложилось, что для работы с данными повсеместно используются реляционные базы данных и, как правило, в серьезных приложениях используют или Oracle или MS SQL. Вся работа с данными преимущественно происходит посредством работы на языке SQL. Более того, как правило в хорошо разработанной архитектуре, запрещается какое-либо прямое обращение к базе данных, и вся работа с базой данных ведется посредством вызова только хранимых процедур, а уже в них на SQL так или иначе ведется работа с данными. Поэтому слой базы данных уже традиционно выделен и фактически отделен. Единственно плохо когда некоторые архитектуры, пользуясь возможностями языков программирования, прямо обращаются в серверу базы данных. В тоже время программировать пользовательский интерфейс на языке SQL невозможно. Для этого используют новейшие объектно-ориентированные языки.

Но можно пойти и еще дальше, пример более общей структуры представляет трёхуровневая архитектура. В ней также отделен сервер базы данных, но аналогично технологии MVC происходит разделение бизнес-логики и визуализации. Мы уже говорили о проблемах реализации классического MVC, но сам принцип разделения остается важным, хотя и может быть реализован более качественно. Но если в технологии MVC разделение касалось на уровне одного класса с его подклассами, то в трёхуровневой архитектуре речь идет о выделении всей визуализации в отдельную самостоятельную программу, а выделению отдельной программы (сервера) бизнес-логики. Понятно, что такое физическое разделение можно осуществить только тогда, когда логически в программе строго все было уже разделено или согласно технологии MVC, или другими более современными способами.

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

ГЛАВА 10

Производительность и XML

Введение: работа с XML

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

XML имеет много сходства с другим популярным форматом кодирования информации — HTML. HTML — это аббревиатура от HyperText Markup Language — язык гипертекстовой разметки, что, говоря простыми словами, означает использование «текстовых дескрипторов, описывающих то, как выглядит документ». Аналогичным образом, XML — это extensible Markup Language — расширяемый язык разметки документов, что в переводе на обычный язык означает использование «текстовых дескрипторов, описывающих данные». Язык XML является продуктом накопления опыта в процессе эволюции HTML, и оба эти языка происходят от более старого абстрактного формата SGML (Standard Generalized Markup Language — стандартный обобщенный язык разметки). Полуструктурированный иерархический текстовый формат HTML на практике доказал свою большую гибкость по сравнению со многими существующими до этого двоичными форматами. Популярные адаптированные варианты HTML, а затем и XML продемонстрировали, что компактностью двоичных форматов часто имеет смысл пожертвовать ради гибкости, расширяемости и переносимости текстовых форматов. Синтаксис дескрипторов и атрибутов, используемый в HTML для описания внешнего вида и содержимого документов, рассматривался многими разработчиками как мощная, расширяемая модель описания данных. Недостатки HTML обусловлены его быстрой эволюцией; поскольку в течение ряда лет этот формат претерпел естественные эволюционные изменения, в его синтаксисе имеются несоответствия, которые при последовательном подходе к разработке языка считались бы недопустимыми.

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

Как и HTML, язык XML имел успех постольку, поскольку была достигнута договоренность о его использовании для обмена информацией между различными системами. Важность широкого принятия этой методики невозможно переоценить. После того как формат получает всеобщее одобрение, вступают в силу сетевые эффекты, и популярная технология очень быстро становится доминирующей. На протяжении последних лет сфера применения XML постоянно расширяется, и теперь он используется в качестве базового формата для многих высокоуровневых коммуникационных форматов, включая SOAP (Simple Object Access Protocol — простой протокол доступа к объектам; лежит в основе Web служб), WSDL (Web Service Description Language — язык описания Web служб), XSL (eXtensible Schema Language — расширяемый язык описания схем), RSS (Really Simple Syndication — подлинно простое объединение данных; механизм распространения данных) и многие другие форматы. Некоторые XML-форматы носят универсальный характер, тогда как другие являются специфическими для определенной отрасли или технологии, принятой в компании. В настоящее время при проектировании новых форматов хранения и обмена данными вопрос часто заключается не в том, следует ли использовать XML, а в том, какой уровень абстракции поверх XML следует использовать. Вероятнее всего, установленные на вашем мобильном устройстве приложения, взаимодействующие с сетью, используют для нужд связи, хранения и обмена данными именно XML. Вы можете использовать данные в XML- форматах других систем, но вам также может потребоваться разработка собственных XML-форматов, которые должны будут использовать другие люди. Существуют различные подходы к организации работы с XML-документами, соответствующие различным уровням абстракции. Каждый из них характеризуется своими достоинствами и недостатками. По этим причинам очень важно твердо знать, как работать с XML, чтобы это наилучшим образом отвечало вашим запросам.

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

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

XML или не XML?

При всех тех возможностях, которые кроются в XML, легко предположить, что этот язык должен был бы привлекаться всегда, когда требуется осуществлять обмен данными или их хранение. Тем не менее, это не так. Гибкость XML придает ему мощь, но это дается за счет увеличения размера документов. Если требуется осуществить обмен данными сравнительно небольшого объема, то XML великолепно подходит для этой цели. Так, при загрузке 20 строк форматированных записей базы данных размер XML-файла может достигать 20 Кбайт, тогда как при использовании для передачи данных двоичного формата они могут быть сжаты до 2 Кбайт или менее.

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

Для сравнительно небольших объемов данных использование XML является вполне оправданным, поскольку это позволяет вам воспользоваться при обмене данными всеми преимуществами этого гибкого формата. Однако, что если объем данных увеличится в 10 раз и для выбора варианта проектного решения вам придется отвечать на вопрос: что лучше использовать — 200 Кбайт данных XML или 20 Кбайт двоичных данных? Начиная с таких объемов данных, длительность ожидания пользователем завершения процесса передачи данных между устройством и сервером становится все более заметной, и для принятия взвешенного решения требуется выполнить объективные измерения для каждого варианта реализации.

Важным фактором, который обязательно должен учитываться, является скорость передачи данных в сетях, используемых вашим мобильным устройством. Для некоторых данных при работе в сетях Wi-Fi проблемы длительности процесса обмена данными вообще не существует, тогда как в случае сетей мобильных телефонов, использующих протокол GRPS, может потребоваться тщательный анализ временных и стоимостных факторов. Если бы объем передаваемых данных был еще на порядок больше и вам пришлось бы выбирать между 2 Мбайт XML-данных и 200 Кбайт двоичных данных, то от вашего решения, какой формат данных использовать, зависело бы еще больше, поскольку теперь уже, скорее всего, задержки на установку соединения будут пренебрежимо малы по сравнению с длительностью фактической передачи данных. И при всем этом нельзя сбрасывать со счетов тот факт, что синтаксический анализ XML-данных потребует, как правило, большего времени по сравнению с анализом двоичных данных, специально оптимизированных под многократные загрузки.

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

Сравнение XML с другими текстовыми форматами

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

Различные способы хранения данных в виде текста

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

Сохранение данных в виде XML

Как и в случае HTML, в XML данные сохраняются в виде текста, заключенного между дескрипторами, которые дополняют передаваемые данные контекстом:

Следует отметить, что в XML те же данные можно сохранить с использованием атрибутов, например:

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

Сохранение данных в текстовых файлах с разделителями-запятыми

Ранее для сохранения данных рассматриваемого типа часто применялись файлы, в которых для разделения элементов данных используются запятые:

Сохранение данных в INI-файлах

В прошлом популярным способом сохранения данных были INI-файлы. В INI-файлах данные сохраняются в виде пар «имя-значение»:

Существуют и другие распространенные форматы, например PropertyBag, которые по своим структурным свойствам и гибкости занимают промежуточное положение между XML и INI-файлами и были популярными среди разработчиков на Visual Basic 5 и 6. Что выделяет XML и ставит его выше многих предыдущих форматов — так это дополнительное структурирование данных. Эта структура делает возможным создание иерархических данных без расположения их в определенном порядке. Такой формат оказывается несколько более детализированным, чем многие другие текстовые форматы, но зато и гораздо более гибким. Эта гибкость значительно облегчает учет различий в версиях данных, а также сопровождение и передачу данных между различными системами.

Иерархическая структура XML-данных

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

Здесь мы сделали узлы Name и Address подузлами UserInfo.

Другие возможности XML

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

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

Различные способы работы с XML

Широкая применимость и всеобщее признание языка XML способствовали его быстрому развитию. Параллельно со становлением языка возникли модели, которые значительно упрощают работу с XML. Как правило, если существуют специализированные API-интерфейсы, ориентированные на XML, то при работе с XML следует избегать использования API-интерфейсов обычного файлового ввода вывода. Достоинством высокоуровневых АРI-интерфейсов является то, что они значительно повышают производительность труда разработчика, перекладывая бремя проектирования и тестирования соответствующих средств на специалистов, чьей единственной задачей было создание высокоэффективных XML-анализаторов. Если вы возьметесь за написание собственного анализатора, то потратите массу времени на решение задачи, которая уже давно решена на множестве самых различных платформ; лучше приложите свои усилия в тех областях, где вы сможете предложить что-то новое.

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

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

2. Использовать высокоуровневые универсальные методы синтаксического анализа с произвольным доступом, основанные на модели XML DOM. DOM (Document Object Model — объектная модель документов) обеспечивает возможность работы с XML-данными, хранящимися в памяти в виде иерархического дерева объектов. В результате использования высокоуровневого API-интерфейса для работы с XML вы получаете в высшей степени надежный код, удобный в сопровождении. Такой подход является оптимальным для небольших XML-документов, а также документов, при работе с которыми требуется постоянный произвольный доступ ко всем частям дерева XML документа, или документов, которые должны быть заново целиком сохранены в файле на диске.

3. Использовать низкоуровневый API-интерфейс XML, обеспечивающий выполнение лишь однонаправленных операций чтения-записи данных. Применение низкоуровневых API-интерфейсов позволяет максимально повысить производительность, но возлагает дополнительную нагрузку на программистов. Эти API-интерфейсы поддерживают выполнение операций чтения записи данных только в прямом направлении и позволяют считывать или записывать данные XML-дерева в виде потока XML-элементов без сохранения всего документа в памяти. В случае мобильных устройств, для которых память всегда является дефицитным ресурсом, и особенно при работе с большими объемами данных или данными, предназначенными только для чтения, только такой подход и обеспечивает достижение приемлемой производительности. Он представляет собой хорошую основу, являющуюся промежуточной между использованием высокоуровневых АРI-интерфейсов и развертыванием собственной методики. Такой путь является разумным, если привлечение высокоуровневых API-интерфейсов для удовлетворения ваших нужд требует интенсивных дополнительных вычислений и приводит к чрезмерному расходу памяти.

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

Простой пример, иллюстрирующий применение модели XML DOM и однонаправленного чтения-записи XML-документов

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

XML-Sapiens — орудие разделения функциональности сайта и программного ядра

Случалось ли вам искать Open Source CMS для сборки своего сайта? Наверняка, вы столкнулись со сложностями при реализации своих функциональных моделей. Возможно, вам пришлось даже отказаться от некоторых идей по части интерфейса и ограничиться базовыми возможностями CMS. Скорее всего, у вас даже возникала мысль: «Хорошо было бы с помощью какого-нибудь макроязыка самостоятельно описывать интерфейсы сайтов, не ограничиваясь какими-либо штампами».

И действительно, существует ряд реализаций CMS, но нет общей концепции, описывающей модель CMS, где функциональность сайта не была бы привязана к программному ядру. Нет?! Все же есть. Это концепция представлена в спецификации XML Sapiens – XML-ориентированного языка, описания пользовательских интерфейсов, представленной компанией Red Graphic Systems.

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

Как это работает? Скажем, мы планируем разместить на всех страницах сайта типа, определенного шаблоном A вертикальное навигационное меню. Для этого нам следует создать описание этого контейнера динамических данных в XML Sapiens. В этом описании будет размещен указатель на приложение CMS, возвращающее массив со структурой сайта. Мы располагаем возможностью задания условий и стиля вывода в код контейнера содержания данного массива. Теперь осталось лишь разместить указатель на данный контейнер в шаблоне А. Таким же образом формируются самые различные навигационные формы, интерактивные формы, информационные каналы различных типов. Более того, шаблон и его контейнеры можно настроить для отображения веб-документов в виде XML, что будет корректно воспринято Flash, Java-applet, WAP, SVG.

Зачем ограничивать себя в проектировании? Используйте XML Sapiens и ваши проекты будут не похожи на чужие.

Мастер Йода рекомендует:  Введение в DNS-записи
Добавить комментарий