Опять концепция ОСС // выпуск 6

Приветствую всех! Несколько вечеров провел за написанием нижеизложенного. Надеюсь оцените по достоинству. Из-за острой нехватки времени не успел дописать два параграфа: 1) структура и сценарий работы каждого базового компонента и приложения отдельно, 2) описание и требования первой версии системы. Это будет сделано на следующей неделе. В конце выпуска я дам некоторое обощение проделанной работы.

Прототип ОСС уже можно заказывать. Пишите заявки мне на почту. В заявке укажите, как вам лучше передать, в виде ссылки на файл или вложенный файл. Файл небольшой по размерам.

А теперь основное содержание выпуска.

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

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

Для того, чтобы реализовать возможность создания подобных связей, нужно разработать универсальный интерфейс связи между модулями. Либо заранее определять классы модулей, чтобы любой вновь разрабатываемый модуль мог знать о возможности существования того или иного класса микромодулей. И мог предоставлять подключение к себе известных ему микромодулей. Но на мой взгляд эффективней будет создание универсального интерфейса. А также список типов передаваемых данных (список адресатов, например, который является потомком типа простой список любых элементов).

Список требований

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

Список терминов

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

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

Дерево навигации. Дерево навигации представляет из себя список разделов сайта в древовидной форме. С наследованием. И с правами доступа. То есть многие свойства разделов могут наследоваться из родительских разделов. У любого дерева навигации есть свойство "шаблон пути". Оно предназначено для выбора этого дерева по веб-запросу. В сценарии работы ядра это будет описано. В дереве кроме разделов могут находится и ссылки на разделы.

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

Одно из приложений является ведущим (главным), которое определяет список страниц в разделе и основное наполнение этих страниц. Меню страниц выдает тоже ведущее приложение. Остальные (ведомые) приложения являются вспомогательными (например, выводят дополнительную информацию на колонках страниц).

Итак, каким образом раздел вызывается по веб-запросу? Запрос выглядит в общем виде так:

http://доменное.имя/путь_к_разделу/параметры

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

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

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

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

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

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

Ядро. Ядра как такового нет. Есть компоненты ядра. И ключевые компоненты. К ключевым относятся: Диспетчер компонент, Консоль управления ядром, Базовый обработчик запросов (то что я именовал в рассылке под словом Сайт), Хранилище данных, Диспетчер приложений, Учетные записи и права доступа, Диспетчер xsl-шаблонов, Конвертер xml-данных в веб-ответ. И есть еще базовые компоненты: журнал событий, почтовая служба и задания по расписанию. Так вот, набор компонент под определенные нужды и есть ядро. Как Линукс поставляется с разными наборами и видами ядра и приложений. Тут тоже самое. Компоненты по ходу дела можно доустанавливать. Диспетчер компонент выполняет две важные функции: регистрация компонент (установка и деинсталяция) и выбор компонента, обрабатывающего запрос в зависимости от самого запроса (то есть у диспетчера компонент есть список соответствия запроса и какого-либо компонента, обрабатывающего этот запрос, естественно множества запросов описаны регулярными выражениями).

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

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

Веб-запрос. Пока это обычный http-запрос. Не только адрес, но и всякие post-данные и заголовки. Они обрабатываются автоматически интерпретатором языка, на котором вся система и будет написана.

Веб-ответ. Пока, для упрощения, это просто html-страница. А в общем, это файл любого типа.

Ведущее приложение в разделе. Приложение в разделе, которое помечается ведущим, предназначено для вывода основного содержания страниц. Это приложение определяет меню страниц в разделе. Также, ведущее приложение может менять заголовки страницы, что логично.

Ведомое приложение в разделе. Такое приложение считается вспомогательным. И выводит неосновное содержание страницы.

Учетная запись пользователя. Запись из логина, имени пользователя, основного почтового адреса пароля есть начало учетной записи пользователя системы. В соответствие учетной записи выставляются права доступа к объектам системы. Также назначаются роли.

Специальные учетные записи. Такие профили имеют логин, начинающийся со знака подчеркивания. Обычные профили не могут иметь логин, начинающийся со знака подчеркивания. Вот весь список специальных учетных записей:
_anonimous — любой неавторизованный вход;
_default — значения учетной записи по-умолчанию, используется при регистрации новых пользователей;
_key — учетная запись владельца ключа сайта;
_system — общая системная учетная запись для скриптов;
_root — зарезервировано для черного входа в случае потери всех паролей, в том числе и ключа сайта.

Экземпляр прав доступа. Каждый экземпляр прав ставит в соответствие субъект-объект-действие с разрешением/запрещением на это действие субъекта по отношению к объекту. То есть цепочка такая:

субъект — объект — операция — доступ

В качестве субъекта выступает учетная запись или роль. Объекты есть системные (дерево, раздел сайта...) или назначаемые приложениями (автоматически или добавляемые пользователем). Операции тоже есть системные, предустановленные что-ли и назначаемые приложениями. Доступ может либо разрешение этой операции этому субъекту или запрещение.

Роль учетной записи. Роль это группировка действий. Например, у роли Продавец могут быть действия Разместить товар в каталоге, а у роли Покупатель могут быть действия Купить товар, Посмотреть список товаров и т.п. Роли есть системные: Владелец сайта, Администратор, Администратор раздела и т.п. И роли могут быть назначенные приложением. Например, приложение Веб-магазин добавит роли покупателя и продавца, ну может еще дилера, который имеет права на действие: Сделать клон сайта под свое доменное имя.

Группа учетных записей. Вспомогательная примочка. Может пока не стоит ею заморачиваться. Тоже входит в список субъектов.

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

Консоль управления ядром. Специальный компонент на случай, если погасят свет. Например, если отрубится база данных по причине изменения пароля. Консоль позволяет производить вход по специальным учетным записям: _key, _system, _root. И собственно исправить подключение к базе данных, где хранятся все остальные учетные записи.

Контрольная панель управления сайтом. Это приложение. Которое обеспечивает управление сайтом. Оно имеет свое дерево навигации (вот пример того, зачем нужны в навигаторе несколько деревьев). В нем регистрируются другие приложения. И в дереве навигации контрольной панели вновь устанавливаемые приложения оставляют ссылки на моды, которые ими управляют.

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

Итак, расширенные определения основных терминов даны. Теперь переходим к более детальному описанию системы.

ОСС в виде черного ящика

Система взаимодействует с веб-сервером как черный ящик. То есть система кроме интерпретатора языка ничего не использует. Разве что, через интерпретатор может обращаться к каким-либо библиотекам. Все запросы веб-сервера отсылаются (например, при помощи mod_rewrite) в ОСС игнорируя файловую систему (по-умолчанию, любой веб-сервер интерпретирует веб-запрос как запрос какого-либо файла из домашнего каталога сайта).

Структура ОСС

Состав ОСС таков: ядро (набор компонент ядра), приложения, микромодули, шаблоны, данные сайта.

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

Сценарий работы ОСС

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

Также у диспетчера компонент есть startup-список тех компонент, которые запускаются при любом запросе. Например, компонент Учетные записи всегда запускаются (для авторизации запроса).

Выходной xsl-шаблон собирается из набора шаблонов (путем import). В список обязательно входит xsl-шаблон для стандартных элементов интерфейса, а также динамически подключаются те шаблоны, элементы которых были включены в выходной xml-поток. Этот список заполняется самими компонентами, чьи нестандартные элементы попали в выходной xml-поток.

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

Результаты приложений складируются в общую xml-пачку (области вывода в xsl-шаблоне) и передаются на выход для xsl-трансформации.

Базовый состав ОСС

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

Резюме

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

В следующем выпуске: будут два параграфа: 1) структура и сценарий работы каждого базового компонента и приложения отдельно, 2) описание и требования первой версии системы. Выпуск выйдет к понедельнику.

Всего доброго!
С вами был Хусамов Сухроб из Санкт-Петербурга.

Адрес для личных сообщений: khusamov@mail.ru или khusamov@yandex.ru
Подписка на дискуссионный лист: inet.webbuild.khusamov.discussion-list@subscribe.ru